情報セキュリティ目的（6.2）の決め方と例｜測れる形にする12の要求

連載「ISMS審査員・監査への道」の第9回です。第8回では、管理策を決めて適用宣言書にまとめる話を扱いました。今回はその次で、決めたことを目的の形に落とす条項に入ります。

情報セキュリティ目的で検索すると、例や具体例を求める語が並びます。規格が様式を決めていないのは前回と同じです。ただ今回は「様式は自由です」で終わらせません。探している人が欲しいのは目的の文そのものだからです。後半で、自治体の現場に置き換えた例を自分で作って並べます。

あわせて箇条6.3、変更の計画策定も扱います。こちらは2022年版で新しく置かれた条項です。

---

6.2 情報セキュリティ目的とは —— 方針を採点できる形にしたもの

6.2は、情報セキュリティ目的と、それを達成するための計画策定を求めた条項です。ひとことで言えば、方針で示した方向を、達成できたか判定できる形に落としたものになります。

方針が「どこへ向かうか」なら、目的は「どこまで行けたか」を測る物差しです。方針は抽象的でかまいません。むしろ抽象的でないと組織全体に掛かりません。ただ、そのままでは達成したかどうかを誰も判定できない。そこで、方向のうち測れる部分を切り出したものが目的になります。

条項の並びで見ると、方針（5.2）、目的（6.2）、監視・測定（9.1）の順です。目的は真ん中に立っていて、上に方針、下に測定がぶら下がる形になります。

なぜ目的が要求されるのか（規格の意図）

ISMSが回っていることを外から確かめる手掛かりが要るからだと考えています。

規格は「情報セキュリティを良くしなさい」とは書けません。良いか悪いかの基準が、組織ごとに違うためです。そこで基準そのものは組織に決めさせて、決めた基準に対して達成できたかを見る形をとります。目的は、その組織が自分で置いた採点基準です。

だから審査で見られるのは、目的の水準の高さより、方針とつながっているか、測れる形になっているか、決めた期限までに誰かが見ているか、のほうだと考えています。立派な目的を毎年並べて達成できない組織のほうが、かえって説明に困ります。

6.2 が求める12項目 —— 目的の条件と、計画で決めること

6.2は二段構えになっています。前半が目的そのものが満たすべき条件、後半が達成の計画で決めることです。

区分	細目	求められていること（筆者の言い換え）
目的の条件	a)	情報セキュリティ方針と整合していること
	b)	実行可能な場合は、測定可能であること
	c)	適用される情報セキュリティ要求事項、リスクアセスメントとリスク対応の結果を考慮すること
	d)	監視すること
	e)	伝達すること
	f)	必要に応じて更新すること
	g)	文書化した情報として利用できる状態にすること
計画で決めること	h)	実施事項（何をするか）
	i)	必要な資源
	j)	責任者（誰がやるか）
	k)	達成期限（いつまでに）
	l)	結果の評価方法（どう確かめるか）

合わせて12項目です。数だけ見ると多く感じます。ところが後半のh)からl)は、業務の計画書に普通に並んでいる欄です。何を、いくらで、誰が、いつまでに、どう確かめるか。行政の実施計画とほぼ同じ骨格になります。

前半で落としやすいのはd)とe)だと思っています。目的を決めた記録は残るのに、途中で見た記録と、現場へ伝えた記録が残らない。決めることは会議の議題になりますが、見ることと伝えることは誰かの日常業務にしないと続きません。学習に使っている教科書も、達成結果だけでなく途中の実績を定期的に確認できる形が望ましい、と書いていました。要求ではなく推奨の書き方です。

面白いのは、そのd)とg)が2022年版で追加された細目だという点です。規格の改定作業に関わった委員の解説資料に、d)の「監視する」と、g)の「文書化した情報として利用可能な状態にする」を列挙に加えたと書かれています。2013年版でも、目的に関する文書化した情報を保持することは求めていました。足されたのは「利用可能な状態にする」ほうです。「保持する」が「利用可能な状態にする」に変わったのは6.2だけではありません。規格全体での言い回しの変化は第11回（7.5）で扱っています。

つまり改定は、目的を決めることより、見ることと出せることに寄っています。落としやすい2つが、そのまま新しい要求だったわけです。

c)も見落とされがちです。目的は思いつきで置くものではなく、リスクアセスメントとリスク対応の結果を受けて決めるものだと書かれています。第7回と第8回の出力が、ここへ流れ込んでくる構造です。

6.2 b) 測定可能には2通りある

測定可能にする方法は、率で測る形と、やったかどうかで測る形の2つがあります。

率で測る形は、研修の受講率を年度内に100パーセントにする、といった数値目標です。達成度が段階で見えるので、途中の進み具合も分かります。もう一方は、規程を年度内に改訂する、といった実施の有無。0か1しかありませんが、教科書はこれも測り方の一つとして挙げていました。

正直、後者の形もあると知って少し気が楽になりました。数値目標を作れない領域は、現場にいくらでもあります。もっとも、実施の有無にすれば何でも通るわけではないはずです。その目的を達成したと言えるかどうかが、0か1で本当に判定できるか、という話は残ります。

そもそもb)は「（実行可能な場合）測定可能である」という括弧つきの書き方です。経済産業省の情報セキュリティ管理基準にも、6.2を参照した項目として同じ括弧書きが載っていました。測れないものを無理に数値化しなくてよい、という逃げ道が最初から用意されているわけです。

期間も1年に限らず、複数年で置く形もあります。組織全体の目的を部門へ、部門から各担当へと分けていく形も、教科書では紹介されていました。

教科書が注意点として挙げていたのは、適用範囲の中に目的と関係のない人が出ないようにすることです。ただ、全員が何かの目的を持たなければならない、という意味ではないと思います。目的が特定の部署にしか関係しないと、その外にいる人にはISMSが他人事になる。適用範囲を決めたときに含めた人たちと、目的との関係を説明できる状態にしておきたい、という話だと読んでいます。

情報セキュリティ目的の例 —— 自治体の業務に置き換える

例で探している人が多いので、ここで自分なりに作ってみます。教科書に載っている例は企業向けでした。同じ形を行政の仕事に置き換えると、次のようになると考えています。

目的	測り方	責任者の置き方	評価方法
全職員が年度内に情報セキュリティ研修を受ける	受講率（率）	研修を所管する係	年度末の受講記録の集計
公開サーバの脆弱性情報を、公表から決めた日数以内に評価する	期限内に評価できた割合（率）	システムの運用担当	月ごとの対応記録の確認
委託先の点検結果を、年度内に全件確認する	確認済みの割合（率）	契約を所管する係	点検票の受領と確認の記録
持ち出し可能な端末の台帳を年度内に最新化する	実施の有無（0か1）	資産を管理する係	台帳の更新日と現物の突き合わせ
インシデントの一次報告を、発生から決めた時間内に上げる	時間内に上げた割合（率）	情報部門の担当	報告記録の時刻の確認

作ってみて分かったことがあります。難しいのは目的の文ではなく、それを誰が数えるかを決めるほうでした。

目的の文は、正直どうにでも書けます。受講率なら、研修の記録を持っている係が数えられる。ところが「意識を高める」のような目的だと、数える人が決まりません。数える人のいない目的は、b)を満たしているように見えてd)で止まります。

なので例を作るときは、目的の文から考えないほうがいい。すでに誰かが持っている記録から逆に辿ると、測れる目的になりやすいと思っています。

6.3 変更の計画策定 —— 2022年版で新しく置かれた条項

6.3は、ISMSを変更するときは計画的に行うことを求めた条項です。2022年版で新設されました。2013年版には対応する規定がありません。

学習に使っている教科書の付録にも、両版の構成を並べた比較表があります。そこでも6.3は新設、6.2は追記の扱いでした。追記というのは、条項自体は両版にあって文言が足された、という意味になります。

なぜ足されたのかも分かっています。マネジメントシステム規格に共通で使われる文章（MSS共通テキスト）の改定を反映したもので、ISMSに固有の事情から生まれた条項ではありません。ISO9001など他のマネジメントシステムと足並みをそろえた追加です。

変更の中身については、教科書が2種類に整理していました。組織レベルの変更と、資産のリスクを動かす変更です。前者は適用範囲（4.3）や役割・責任・権限（5.3）に関わる体制の変更が当たります。後者は業務の見直し、情報システムの新規導入や改修です。

ここは条件付きで読んだほうがいいと思います。6.3が言っているのはISMSの変更です。機器を入れ替えたこと自体が、そのまま6.3になるわけではありません。その変更が管理策や手順、役割に及ぶときに6.3の話になる、という理解でいます。

やることとして教科書が挙げているのは大きく2つ。関連する規程類に矛盾が出ないか見直して改訂すること。そして変更後のリスクをアセスメントして、必要な対応を取ることです。

ただし、条文そのものが求めているのは、変更を計画的に行うところまでだと理解しています。規程の改訂やリスクの再評価は、条文に並んでいる手順ではなく、その計画の中身として出てくる話です。何を見直すかは変更の内容で変わります。

---

［現場］年度の目標は、外からの依頼で立ち上がる

ここから現場の話です。

情報セキュリティの数字が、庁内の計画として先に立つ場面を、私はあまり見ていません。私の見えている範囲では、外部から求められたときに資料を作る、という形が中心です。数字が要るから作る。要らなければ作らない。

これを緩いと読むのは、たぶん間違いです。自治体の情報セキュリティ対策は、国や県が示す方針に沿って組み立てられます。外からの要求に応えることは、制度どおりの動きです。

規格の側から見ても、外から来ること自体はまったく問題になりません。6.2のc)は、適用される情報セキュリティ要求事項を考慮に入れろと書いています。4.2で拾った利害関係者の要求は、この「適用される要求事項」に含まれると読んでいます。つまり外からの要求は、考慮すべき入力の側にあります。

違いが出るのは、そのあとに一手あるかどうかだと思っています。

外からの依頼に応える資料は、提出物です。期限を決めるのも、評価するのも向こう側。

ここで効いてくるのが後半の5つです。6.2は、実施事項・資源・責任者・達成期限・評価方法を、組織が決めることを求めています。外から期限が来ても、庁内でいつまでに何を集めるか、どこまでを完了と見るかは、組織の側で決められる部分です。

つまり後半の5つは、外に出ていくものではありません。提出して終わりにすると、決めたのではなく借りた状態のまま残ります。外から見たとき、決めていないのか借りているのかは区別がつきません。

そして今回、私が答えられなかった問いがあります。その数字を実際に数えているのは誰か、です。

分からない、が答えでした。派遣という立場で見えていない可能性は十分にあります。ただ、数える人がすぐに浮かばないという感覚は、それ自体が情報だと思っています。d)の監視には主体が要ります。誰が見るかが決まっていない指標は、提出した時点で役目が終わります。

［現場］変更の計画に、規程の改訂は入っていない

次は6.3です。

システムの更改や機器の入替が終わったあと、規程や手順書の改訂まで工程に入っているか。私の見ている範囲では、入っていないように思います。作業計画に最初から載っている形ではありません。

言い出すとすれば職員側です。そして必要になる場面は、おそらく完了検査のときだろうと思っています。ここは推測を含みます。

面白いのは、順番としては正しいところです。第6回で書いたとおり、情報セキュリティの役割は事務分掌で職に割り当てられています。決定の権限は職員にある。規程を直すという判断が職員側から出るのは、権限の所在どおりの動きです。技術担当が勝手に規程を書き換える組織のほうが、審査では危ういでしょう。

問題は、その判断が工程表に載っていないことだと思います。載っていないと、改訂のきっかけが締切に引っ張られます。

行政には、変更を管理する枠が先にあります。仕様書、契約、完了検査という一式です。これは相当に強い変更管理です。6.3が計画的に実施することを求めているなら、枠自体はもう持っていることになります。

ただ、その枠が見ているものは成果物の完成です。ISMSの文書との整合ではありません。

	完了検査が見るもの	6.3が見るもの
対象	成果物が仕様どおりか	変更後の姿とルールが合っているか
時点	作業の終わり	変更を決めたとき（事前）
出力	検査調書	改訂された規程と、やり直したリスクアセスメント
こぼれやすいもの	手順書の記述、リスクの再評価	—

この表を作って、6.3が足された意味がようやく見えた気がしました。変更管理の仕組みは、どの組織にもだいたいあります。足りるかどうかは、その計画の中に規程とリスクを見直す欄があるかどうかで決まる。欄が1つ増えるだけの話です。ただ、欄がないものは誰も埋めません。

［現場］監視の仕組みは、動き出したばかり

3つめは自己点検です。

対策の実施状況を各課が自分で点検する仕組みは、外部からの点検を機に動き出したところです。それまでは基本的にありませんでした。仮に集計する場面があったとしても、外部への報告のときだったのでしょう。

つまりこの現場では、6.2のd)や9.1に当たる監視の仕掛けが、いま組織の中に入ってくる途中にあります。

正直なところ、審査員を目指す立場で見ると、この状態はいちばん見どころがあります。仕組みが動き出した直後は、なぜこの項目を点検するのかという理由が、まだ人の頭と記録の両方に残っています。年数がたつと様式だけが残って、理由のほうが消える。同じ点検票を見ても、読み取れる情報量がまるで違います。

もうひとつ、第8回で書いた話とつながります。対策のリストは前からありました。実施しているかどうかを一枚で見渡す文書は、私は見た記憶がありませんでした。動き出した自己点検は、その空白を埋める形をしています。

外から点検が入ることで、内側の監視が始まる。順番としては規格の想定と逆です。それでも、始まってしまえば着く場所は同じだと思っています。

	外から来る点検	6.2が求める目的
起点	外部からの依頼や点検	方針とリスク対応の結果
期限	提出期限	自分で決めた達成期限
評価する人	依頼した側	組織が決めた責任者
終わったあと	提出で完了	更新して次の期へ続く

右の列に寄せていく作業が、おそらくISMS取得の実務なのだろうと考えています。左の列を捨てる話ではありません。同じ数字を、自分の物差しとして持ち直すだけです。

---

よくある落とし穴／審査で指摘されやすい点

目的と方針が別々に育っている

方針は数年前に作ったまま、目的は毎年の担当者が書く。この形だとa)のつながりが切れます。目的を見直すときに、方針の文を横に置いて読むかどうかで差が出ます。

提出用の数字をそのまま目的として並べる

外部への報告項目は、揃っていて見栄えもします。ただ責任者と期限と評価方法を、外の都合のまま借りている状態です。前述の通り、自分で決め直す工程が要ります。

目的が前年度の写しになっている

c)とf)に関わります。リスクアセスメントをやり直したのに目的が去年と同じなら、結果を考慮したとは言いにくい。逆に、リスクが変わっていないのに目的だけ毎年書き換えるのも説明が難しくなります。

変更のあとに規程の改訂が後追いになる

6.3です。動いてしまったあとに文書を合わせる形だと、その間の状態を説明できません。変更を決めた時点で、直す文書と再評価するリスクを洗い出しておくのが筋だと理解しています。

---

まとめ

• 6.2は二段構え。目的そのものの条件が7つ、達成計画で決めることが5つある
• d)の監視とg)の文書化した情報は、2022年版で追加された細目
• 測定可能は率だけではない。やったかどうかで測る形もある
• 目的の文より、誰が数えるかを先に決めたほうが測れる目的になる
• 6.3は2022年版の新設。要求は変更を計画的に行うことで、規程の改訂やリスクの再評価は計画の中身として出てくる
• 行政は完了検査という強い変更管理を持っている。ただし見ているのは成果物で、ISMSの文書との整合ではない
• 目標が外からの依頼で立ち上がっても、後半の5つは組織が決めるもの。借りたままにしない一手が要る
• 次回（第10回）は7.1から7.4、資源・力量・認識・コミュニケーションを扱います。目的を達成する人と、その人へ届ける手段の話になります

用語の意味を確認したいときはISMS用語集に戻ってください。連載の入口は第1回です。

参考にした一次資料

• ISMS適合性評価制度の概要（一般社団法人情報マネジメントシステム認定センター） … 制度の入口。認証基準の版数はこのサイト内の一覧から辿れます
• 情報セキュリティマネジメントシステム（ISMS）2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … このうち「ISO/IEC 27001改定内容と関連規格の動向」（山下真／ISO/IEC JTC 1/SC 27 WG1・WG4議長）で、6.2のd)とg)の追加、6.3の新設を確認しました
• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 6.2を参照した項目があります。「（実行可能な場合）測定可能であること」の括弧書きと、計画で決める5つはここでも確認できました。JIS Q 27001:2023とJIS Q 27002:2024に準拠した版です
• 地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省 地方行政のデジタル化） … 本文で触れた国や県との関係の出どころ。PDFは改定のたびに差し替わるため、この一覧ページから最新版を開いてください

引っかかった点

a)からl)という記号が、規格本文の記号と同じなのかは分かっていません。この記事の並びは、学習に使っている教科書の訳に合わせたものです。おもしろいのは、経済産業省の管理基準では同じ内容がa)とb)の2つにまとめられ、中身が箇条書きで並んでいる点です。7つと5つという内訳と並び順は同じでした。記号の振り方は、訳し方や載せ方で変わる部分だと考えています。

6.2の書き出しについても、確かめたいことが残りました。目的は「関連する機能及び階層」に設定するものだ、という読み方があります。もしそうなら、適用範囲の全員が目的を持つ話ではなく、関係する部門と階層に置く話になります。この記事は後者の立場で書きましたが、条文の言い回しは確認できていません。

もう一つ、教科書の図には「管理目的及び管理策の実施」という語も出てきます。これは2013年版の27002で管理策の上位にあった概念です。2022年版では管理策ごとの「目的（Purpose）」に置き換わり、附属書Aから記述が無くなったと改定内容の資料にありました。6.2の情報セキュリティ目的とは別のものです。附属書Aの話なので、この回では立ち入っていません。