連載「ISMS審査員・監査への道」の第16回です。第15回で附属書Aの全体像を見ました。今回から各論に入ります。
最初は組織的管理策（A.5）です。37と数が多いので、4回に分けて読みます。今回はその1回目、A.5.1からA.5.8までの8つです。
読み始めてすぐ、既視感がありました。「情報セキュリティのための方針群」「情報セキュリティの役割及び責任」。第6回で読んだ本文の箇条5と、ほぼ同じ名前が並んでいます。同じことを2回求めているのか。今回はまずそこをほどいてから、8つを順に見ていきます。
- A.5.1〜A.5.8の8つが、何をひとまとまりにしたものか
- 本文の5.1〜5.3と、附属書Aの同じ名前の管理策の違い
- 職務の分離を「人が足りない」で終わらせないための考え方
- 2022年版で新しく入った脅威インテリジェンスで、集めた後に何をするか
- プロジェクトマネジメントの管理策が、IT案件だけの話ではない理由
- 筆者の現場で、8つのうちどれが既に形になっているか
A.5.1〜A.5.8をひとことで言うと——ISMSの上流を固める8つ
ひとことで言うと、情報セキュリティをどういう体制で、誰の責任で回すかを決める管理策の集まりです。方針、役割、分担、外との連絡、案件への組み込み。個々の対策を打つ前に決めておく、上流の部分にあたります。
経済産業省の情報セキュリティ管理基準は、組織的管理策の37を7つのグループに分けています。この8つはその最初のグループで、一覧での見出しは「情報セキュリティのための経営陣の方向性」でした。まさに上流という扱いです。
| 番号 | 管理策 | ひとことで | 2013年版 |
|---|---|---|---|
| A.5.1 | 情報セキュリティのための方針群 | 方針と、テーマごとの方針を作り、伝え、見直す | A.5.1.1、A.5.1.2 |
| A.5.2 | 情報セキュリティの役割及び責任 | 誰が何に責任を持つかを決めて割り当てる | A.6.1.1 |
| A.5.3 | 職務の分離 | ぶつかり合う仕事を一人に持たせない | A.6.1.2 |
| A.5.4 | 管理層の責任 | 管理する立場の人が、全員に方針どおりの行動を求める | A.7.2.1 |
| A.5.5 | 関係当局との連絡 | 法執行機関や監督官庁などとの連絡体制を持つ | A.6.1.3 |
| A.5.6 | 専門組織との連絡 | 専門家の団体や研究会との連絡体制を持つ | A.6.1.4 |
| A.5.7 | 脅威インテリジェンス | 脅威の情報を集めて分析し、対策に使う | 新規 |
| A.5.8 | プロジェクトマネジメントにおける情報セキュリティ | 案件の進め方に情報セキュリティを組み込む | A.6.1.5、A.14.1.1 |
管理策の名前は、管理基準の表記に合わせています。2013年版の番号は、連載で使っている教科書の付録にある対応表（27002:2022の附属書Bをもとにしたもの）から引きました。2013年版では4か所に散っていました。方針（A.5）、組織（A.6）、人的資源（A.7）、システムの取得・開発（A.14）です。それが1つのグループにまとまった形です。
この記事で紹介する各管理策の細目は、管理基準の「詳細管理策」から引いています。27002の手引をもとに組み立てられた部分で、附属書Aの管理策の文そのものではありません。管理策の意味そのものはISMS用語集にまとめてあります。
本文と附属書Aで、同じ名前が2度出てくる理由
結論から言うと、筆者は、本文をISMSという仕組みそのものへの要求事項、附属書Aをその中で選んで実施する個々の管理策、と読むと整理しやすいと考えています。似た名前でも、見ている粒度が別物です。
扱いの差から見ていきます。JIPDECのISMSユーザーズガイド（2025年3月版）によると、箇条4〜10の要求事項は例外なく実施するものです。一方の附属書Aは、理由を示せば適用を除外できる、と説明されています。第15回で見た「附属書Aは6.1.3を通して効く」と同じ向きです。
ただし、好きに外せるという意味ではありません。同じガイドでは、除外する理由としてリスクアセスメントに基づく合理的な説明が求められ、その理由は適用宣言書に書く、とされています。
中身の違いは、並べると分かりやすくなります。
| 本文 | 附属書A | 附属書A側で広がっているところ |
|---|---|---|
| 5.2 情報セキュリティ方針 | A.5.1 情報セキュリティのための方針群 | 方針1つではなく、テーマごとの方針まで含めた「群」。見直しの間隔ときっかけも扱う |
| 5.3 組織の役割、責任及び権限 | A.5.2 情報セキュリティの役割及び責任 | 資産の保護、個々のプロセス、残留リスクの受容、全要員の責任まで割り当てる |
| 5.1 リーダーシップ及びコミットメント | A.5.4 管理層の責任 | 主語がトップマネジメントから管理層へ。全員に方針どおりの行動を求める側の責任 |
第6回で見た通り、本文の5.3が名指ししていた役割は2つでした。規格への適合と、トップへの報告です。附属書AのA.5.2は、そこから先の個々の管理策の担い手を決める話になります。教科書もA.5.2を、5.3に加えて個々の管理策の役割と責任を割り当てるもの、と説明していました。
この表は筆者が管理基準の文を並べて作ったものです。ただ、同じ名前を見て「本文で済んでいる」と読み飛ばすと、附属書A側で広がった部分が抜け落ちます。
A.5.1 情報セキュリティのための方針群——トピックごとの方針まで含む
A.5.1は、一番上の方針と、その下のテーマごとの方針を定義し、承認し、伝え、見直すことを扱います。一番上の方針だけでなく、テーマごとの方針まで対象にしていることが、本文5.2との大きな違いです。
テーマごとの方針は、管理基準では「トピック固有の方針」と訳されています。教科書では「個別方針」です。例として、アクセス制御、バックアップ、暗号及び鍵管理、情報の分類及び取扱いなどが挙がっています。承認する人も違います。一番上の方針はトップマネジメント、テーマごとの方針は適切なマネジメントレベル、という整理でした。
見直しのきっかけには、事業戦略や技術環境、脅威の変化に加え、インシデントから学んだ教訓も挙がっています。伝え方も具体的です。意図する読者にとって適切で、アクセスでき、理解しやすい形で伝える。必要なら、理解と順守への同意の確認を求める、とまで書かれていました。
2013年版では、方針群の定義と見直しは別々の管理策でした。27002の改定を解説した講演資料では、この2つを1つにまとめた例として紹介されています。
現場から：対策基準は、トピック固有の方針に近い
自治体の情報セキュリティポリシーは、基本方針と対策基準、それを具体化する実施手順で整理されることが多いです。第3回の対応表では、対策基準を「個別方針」に近いものとして置きました。A.5.1を読むと、この置き方で大きく外れていなかったと感じます。
同じ第3回で、職員が読むのは基本方針まで、と書きました。読みやすい場所に置かれていないことも一因です。A.5.1の「アクセスでき、理解しやすい形で」は、まさにそこを突く書き方です。方針を作ったかではなく、届いているかを見ている。本文5.2で見た伝達の話が、テーマごとの方針にまで降りてきた形だと思います。
A.5.2 情報セキュリティの役割及び責任——委任しても、説明責任は残る
A.5.2は、情報セキュリティの役割と責任を、組織のニーズに沿って定めて割り当てる管理策です。割り当てる対象として、次の4つが挙がっています。
- 情報とその他の関連資産の保護
- 特定の情報セキュリティプロセスの実施
- リスクマネジメント活動、とくに残留リスクの受容
- 組織の情報と資産を使う全ての要員
この中で目に留まったのが、委任の扱いです。責任を割り当てられた人は、職務を他者に委任してよい。ただし説明責任（アカウンタビリティ）はその人に残り、委任した職務が正しく行われているかを確認する、と書かれています。教科書も、委任しても責任は移らないことを明確にする、と強調していました。
現場から：責任は筆者、権限は職員
第6回で、筆者の現場では情報セキュリティの役割が事務分掌で係長級の職に割り当てられている、と書きました。職に紐づいているので、人が異動しても役割が残ります。
もう一つ、同じ回で書いたのが、作業上の責任は筆者にあり、権限と決定は職員にある、という分担でした。これをA.5.2の委任の書き方に当てはめると、見え方がはっきりします。作業を委ねても、その職務を割り当てられた側の説明責任まで移るわけではない。誰が最終的な説明責任を持つかは組織の役割分担で決まる話ですが、筆者の現場の分担は、この形に収まっているように見えます。
歪みに見えていたものが、規格の言葉で書くと設計どおりになる。第6回で途中から結論が変わった話の、続きを読んだ気分でした。
A.5.3 職務の分離——人が足りないときの答えも書いてある
A.5.3は、相反する職務や責任範囲を分けることを扱います。目的は、不正や誤り、管理策のすり抜けのリスクを減らすことです。
分離が必要になりうる活動の例は7つ挙がっていました。変更の提案・承認・実行や、アクセス権の要求・承認・付与などです。最後には、管理策の設計・監査・保証まで入っています。
ここで意外だったのは、小さな組織への配慮まで書かれていることです。
| 場面 | 管理基準の書き方 |
|---|---|
| 分離を設計するとき | 共謀のおそれも考慮する |
| 小さな組織 | 分離は難しい場合がある。ただし実施可能な限り適用する |
| 分離が困難なとき | 活動の監視、監査証跡、管理層による監督などの他の管理策を考慮する |
| 役割でアクセスを制御するとき | 一人に相反する複数の役割を許可しない |
つまり、人数が足りないから分けられない、で話は終わりません。分けきれない部分は、別の手段で補うことを考える。そこまで含めて書かれている管理策です。
現場から：分離は、承認の段で起きている
第11回で、委託側が作る文書に職員の承認が付くかは、グループウェアのワークフローに乗せるかどうかで決まると書きました。乗れば、起案者・日付・承認者が自動で残ります。
これはA.5.3の例の最初、「変更の提案、承認及び実行」の分離に近い形に見えます。起案する人と承認する人が別で、その跡が記録に残る。監査証跡の役目も兼ねていそうです。もちろん、ワークフローがあるだけでこの管理策を満たす、という話ではありません。どの文書を乗せるかの線引きが、ここでも問われます。
第13回では、日々の数字を測る人と読む人が同じ（筆者）だ、とも書きました。一人で完結しているように見えて、判断を職員に報告し、決めるのは職員です。分離は作業の段ではなく、決定の段で起きている。職務の分離を人数の問題として読むと、この構造は見落とします。
A.5.4 管理層の責任——アクセスを渡す前に伝える
A.5.4は、管理層が全ての要員に対し、方針や手順に従った情報セキュリティの適用を求める管理策です。本文5.1の主語はトップマネジメントでしたが、こちらは管理層です。部署を預かる立場の人全体に向いています。2013年版では「経営陣の責任」という名前で、人的資源のセキュリティ（A.7）の中に置かれていました。
管理層の責任として、8つの事項が並んでいます。とくに実務で効きそうなのは次の4つです。
- 情報や資産へのアクセスを許可する前に、役割と責任の要点を伝える
- 雇用条件や契約、合意を守らせる
- 方針や手順への違反を報告する、匿名の報告経路を用意する（例として内部通報）
- セキュリティのプロセスや管理策を実施するための、資源と計画の時間を用意する
特に目につくのが、「アクセスを許可する前に」という順番です。教科書でも、秘密情報や情報システムへのアクセスが許可される前の責任説明が、図の中心に置かれていました。匿名の報告経路では、報告した人に不利益が出ないような配慮にも触れています。
現場から：教育の経路は2本ある
第4回で書いた通り、筆者は着任時に派遣元から、個人情報とセキュリティのルールをチェックリストで確認されました。常駐先の職員向けeラーニングを受けることもありました。
A.5.4に当てはめると、この2本は役割が違います。着任時のチェックリストは、仕事で情報に触れる前に要点を伝え、契約を守らせる側。常駐先の研修は、組織の中での認識を一定の水準に保つ側です。二重に見えて、それぞれ別の項目に答えている。筆者はそう受け取りました。
A.5.5 関係当局との連絡／A.5.6 専門組織との連絡——一覧を作っただけでは足りない
A.5.5は法執行機関や監督官庁などとの連絡体制、A.5.6は専門家の団体や研究会との連絡体制を扱います。A.5.5はインシデント時の報告だけでなく、当局の現在と今後の期待を理解するための連絡も含みます。A.5.6は、専門家との情報交換の側です。
教科書は、A.5.5の方法として緊急連絡先の一覧を作る例を挙げていました。管理基準の詳細管理策はもう一歩踏み込んでいて、いつ、誰が連絡するか、インシデントを時機を失せず報告する方法まで決めておく書き方です。一覧は、誰がいつ動くかが決まって初めて使えます。なおA.5.5は、2013年版の同名の管理策（A.6.1.3）を変更少なく引き継いだ例として、講演資料で紹介されています。
A.5.6では、研究会や会議に参加する目的が6つ挙がっています。最新の慣行を知ること、攻撃やぜい弱性の早期警戒を受け取ること、専門家の助言を得ることなどです。
現場から：手元にあるのは、委託先の連絡先
大きな障害のとき、筆者が連絡先を把握しているのは保守の委託先です。それ以外の関係する機関への連絡がどう決まっているかは、筆者の位置からは見えません。
ここで少し引っかかりました。教科書は、関係当局との連絡の例に保守委託先への連絡も挙げています。一方で管理基準は、関係当局の例として法執行機関、規制当局、監督官庁を挙げています。
これは「例えば」として挙がっているもので、関係当局がこの3種類に限られるとまでは読めません。教科書の図にも消防が入っていました。ただ、通常の保守委託先を当局と同じ意味で扱う根拠も、筆者は見つけられていません。筆者の手元にある連絡先は、当局との連絡というより、供給者との連絡として整理するほうが自然だと考えています。
そう整理すると、当局への連絡は筆者の作業範囲の外にあります。どう決まっているかは、派遣の立場では判別できません。A.5.2で見た分担が、連絡の向きにも表れている形です。
受け取る側（A.5.6）の話は、第10回の7.4で書きました。外からの注意喚起は、会議かグループウェアの2本の経路で届きます。
A.5.7 脅威インテリジェンス——集めた後に3つの使い道がある
A.5.7は、2022年版で新しく入った管理策です。脅威に関する情報を集めて分析し、脅威インテリジェンスを作ることを扱います。目的は、適切なリスク低減の手を打てるよう、組織を取り巻く脅威の状況を把握することです。
管理基準では、脅威インテリジェンスを3つの層で考えるとしています。
| 層 | 中身 | 筆者の言い換え |
|---|---|---|
| 戦略的 | 脅威の動向の大局的な情報 | どんな攻撃者が、どんな種類の攻撃をしているか |
| 戦術的 | 攻撃者が使う手法、ツール、技術 | よく使われる侵入の手口 |
| 運用上 | 特定の攻撃の技術的な詳細 | 個別の攻撃で観測された特徴 |
集めた情報には条件も付いています。組織の保護に関係し、正確で詳しく、いつ・どこでという状況が分かる。そして、組織がそれをもとに素早く動けることです。
主な使い道として、3つが挙がっていました。リスクマネジメントのプロセスに取り込む。ファイアウォールやマルウェア対策のような、予防と検知の技術的な管理策への入力にする。セキュリティテストの入力にする。さらに、他の組織と相互に共有することにも触れています。
A.5.6と似て見えますが、向きが違うと感じました。A.5.6は情報の入口を持つこと。A.5.7は、入ってきた情報を自分たちに関係する形に加工して、使うところまでです。
現場から：届くことと、使える形になることは別
前述の通り、筆者の現場では注意喚起が2本の経路で届きます。A.5.7の目で見ると、届いた時点ではまだ「情報」の段階です。自分たちの環境に関係があるか。あるならどの機器か。いつまでに何をするか。管理基準の詳細管理策は、集めた情報を処理・分析し、関係する人が使える形にして、リスク対応などにつなげるところまでを挙げています。
筆者の現場で、この「関係があるか」を判断しているのは、保守の委託先です。該当するかどうかの見立てが、委託先から届く形になっています。
これを緩さとは思いません。機器やソフトの中身を一番よく知っているのは、構築や保守を担う側です。管理基準も、情報源として外部を挙げています。第10回で書いた、力量を外から手に入れる形と同じ構図です。
ただ、A.5.2の委任の考え方を当てはめると、分析を外に委ねても、結果を受けて何をするかを決める責任は組織の側に残ります。委託先の見立てが、組織の中で作業に移れる形で届いているか。新規の管理策ですが、問われているのは新しい道具ではなく、受け取ってから動くまでの距離だと感じています。
A.5.8 プロジェクトマネジメントにおける情報セキュリティ——IT案件だけの話ではない
A.5.8は、情報セキュリティをプロジェクトマネジメントに組み込む管理策です。プロジェクトの一生を通して、情報セキュリティのリスクに対処できるようにすることが目的です。
管理基準の詳細管理策（27002の手引にあたる部分）では、プロジェクトマネジメントで扱う事項として、次の4つが挙がっています。
- 情報セキュリティリスクを、プロジェクトリスクの一部として、早い段階から定期的に評価し、対応する
- 情報セキュリティ要求事項には、プロジェクトの早い段階で対処する
- 内外への伝達の側面なども含め、実行に伴うリスクを一生を通して考え、処理する
- リスク対応の進み具合をレビューし、有効性を評価し、試験する
見落としやすいのが適用範囲です。規模や期間、分野にかかわらず、あらゆる種類のプロジェクトに当てはまるとされ、例には施設管理も挙がっています。要求事項を決めるのも、ICT開発のプロジェクトだけではない、と明記されていました。教科書も、プロジェクトの例に事務所の移転や新規事業の立ち上げを並べています。
一方で、要求事項を決めるときの考慮事項を見ると、情報システムを思わせる項目が目立ちます。認証に求める信頼のレベル、特権を持つ利用者へのアクセスの与え方、ログ取得や監視などです。教科書もこの部分を、情報システムの取得や開発の初期段階で要求事項を明確にする話として説明していました。
理由は2013年版を見ると分かります。教科書の対応表では、A.5.8の元は2つの管理策でした。A.6.1.5「プロジェクトマネジメントにおける情報セキュリティ」と、A.14.1.1「情報セキュリティ要求事項の分析及び仕様化」です。全ての案件が対象という書き方と、システム寄りの項目が同居しているのは、2つの管理策を1つにまとめた跡だと読めます。
現場から：段階の枠は、もう持っている
管理基準には、あらかじめ定めた段階で、適切な人やプロジェクトの運営委員会などがフォローアップする、という一文もありました。第9回で、行政は仕様書・契約・完了検査という強い変更管理の枠を先に持っている、と書きました。段階そのものは、新しく作らなくても既にあります。
第7回では、現行の構成から変わる仕様について協議の場があり、筆者も技術面で出席していると書きました。変わることで何が起きるかを洗い出す場です。A.5.8の最初の項目、プロジェクトリスクの一部として情報セキュリティリスクを評価する作業は、この場で既に一部が行われているように見えます。
では、ログの取り方、権限の割り方、認証の方式といった具体的な要件は、どこで固まるのか。筆者の現場では、構築の途中で決まっていきます。
「早い段階で対処する」と並べると、後ろ寄りに見えます。ただ、これも緩さとして読むのは違うと考えています。設計や構築を委託する調達では、仕様書で枠を示し、細部は委託先の設計の中で詰める流れになりやすいからです（ここは筆者の見方です）。
そうなると効いてくるのが、4つ目の項目です。リスク対応の進み具合をレビューし、有効性を評価し、試験する。完了検査は成果物が仕様どおりかを見る場ですが、途中で決まった細部がそこでどう扱われるかは、筆者の位置からは見えていません。A.5.8で問われるのは、決まる時期そのものより、決まったものを確かめる段がどこにあるかだと考えています。
よくある落とし穴／審査で指摘されやすい点
本文5.2の方針を作って、A.5.1も済んだことにする
前述の通り、A.5.1は方針「群」です。一番上の方針だけで、テーマごとの方針や見直しの仕組みがないと、附属書A側で広がった部分が空いたままになります。適用宣言書で採用と書くなら、どこまでを指しているかを言えるようにしておきたいところです。
職務の分離を「人が足りない」で除外する
管理基準は、小さな組織では分離が難しい場合があると認めたうえで、監視や監査証跡、管理層の監督といった補う手を挙げています。分けられない理由だけを書いて止めると、代わりに何を考えたのかが見えません。
脅威インテリジェンスを「情報を購読している」で終える
集めることは入口にすぎません。分析して、関係する人に伝えて、リスク対応や技術的な管理策に使うところまでが一続きです。受信の記録だけでは、使ったことの説明になりにくいと思います。
A.5.8をシステム開発案件だけに当てる
管理基準は、あらゆる種類のプロジェクトを対象にしています。施設の移転や業務の立ち上げのような案件が、情報セキュリティの考慮なしに進んでいないか。ここは見落としたくない範囲です。
まとめ
- A.5.1〜A.5.8は、方針・役割・分担・外との連絡・案件への組み込みという、ISMSの上流を固める8つです。管理基準の一覧では「情報セキュリティのための経営陣の方向性」の見出しでまとめられています
- 本文5.1〜5.3と名前が重なりますが、本文は例外なく実施する要求事項、附属書Aはリスクアセスメントの結果から採否を決め、採らないなら理由を示す管理策です。附属書A側は、テーマごとの方針や個々の管理策の担い手まで広がっています（この対応は筆者の整理です）
- 職務の分離は、分けきれないときに補う手を考えるところまで含めて書かれています
- 2013年版では方針・組織・人的資源・開発の4か所に散っていた管理策が、1つのグループにまとまりました。A.5.8に2つの話が同居しているのも、その跡です
- 脅威インテリジェンスは2022年版の新規。集めるだけでなく、分析して使うところまでを扱います
- プロジェクトマネジメントの管理策は、IT案件に限らずあらゆる案件が対象です
次回は組織的管理策の2回目、A.5.9〜A.5.18です。資産の目録、情報の分類、アクセス権の管理と、一気に手触りのある管理策が並びます。
連載の入口は第1回です。
参考にした一次資料
- 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の5a（5.1〜5.8）で、各管理策の文・目的・詳細管理策を確認しました。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
- ISMSユーザーズガイド JIS Q 27001:2023（ISO/IEC 27001:2022）対応（JIPDEC／2025年3月31日） … 箇条4〜10は例外なく実施するもの、附属書Aは理由を示して適用を除外できるもの、除外の理由を適用宣言書に書くこと、という説明を確認しました。リンク先はJIPDECの関連文書の一覧ページです
- 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002改定の解説」（土屋直子／NTTテクノクロス）で、5.1が2013年版の2つの管理策をまとめたものであること、5.7が新規であることを確認しました
- 「ISO/IEC 27001 及び ISO/IEC 27002 の活用 ー情報セキュリティ管理策を軸にー」（山下真／JNSA 日本ISMSユーザグループ 情報セキュリティマネジメント・セミナー2023／2023年12月18日） … 5.5が2013年版の同名の管理策を変更少なく引き継いだ例であることを確認しました
- 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。32節（A.5）のうち、A.5.1〜A.5.8の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています
引っかかった点
本文と附属書Aの対応表は、筆者が作ったものです。規格や管理基準がこの3組を対応させているわけではありません。扱いの違い（本文は例外なし、附属書Aは理由を示して除外できる）は、JIPDECのガイドにあります。一方、「本文は仕組み、附属書Aは管理策の粒度」という言い方は筆者の読みです。
職務の分離の例は、管理基準では7つ、教科書では6つでした。教科書には「コードの設計、実装及びレビュー」がありません。記事は管理基準に合わせています。どちらの訳の元になった版かは確かめていません。
2013年版の番号は、教科書の付録の対応表から引きました。表には27002:2022の附属書Bをもとに作成したと注記されています。附属書Bそのものは読んでいません。A.5.1・A.5.5・A.5.7の3つは、講演資料の記述とも一致しました。管理基準の5aの見出しは、一覧では「情報セキュリティのための経営陣の方向性」、本文のページでは「組織的管理策」と、2通りの表記がありました。記事では一覧の見出しを引いています。