ISO27001:2022 附属書A 管理策一覧｜4テーマ93項目と2013年版からの変更点

附属書Aとは何か（ISO27001とISO27002の関係）

附属書AはISO/IEC 27001:2022の一部で、情報セキュリティ管理策の参照リストです。規範的な位置づけであり、ここに並ぶ管理策を「知らなかった」で済ませないための照合対象になります。一方で、各管理策をどう実装するかの手引きは別の規格ISO/IEC 27002:2022が担当します。27002は手引きであり、審査基準そのものではありません。

この2つの役割の違いは、作業の順番にそのまま影響します。まずリスクアセスメントとリスク対応で、自組織に必要な管理策を決めます（ISMSのリスクアセスメントで手順を扱っています）。次に、決めた管理策の一覧を附属書Aと突き合わせ、見落としている領域がないかを確認します。ここで初めて27002を開き、実装の考え方や具体例を参照する、という流れです。

2013年版からの変更点（114→93、14分野→4テーマ）

2013年版の附属書Aは14分野114管理策という構成でした。2022年版では4テーマ93管理策になっています。数が減ったのは要求が緩くなったからではなく、内容の重複していた管理策が統合されたためです。分類の粒度が粗くなったぶん、1つの管理策がカバーする範囲は広がっています。

新設された11管理策は、クラウド利用、テレワーク、ログ監視、開発現場の実務といった、この10年で当たり前になった働き方と技術に対応するものです。具体的には5.7 脅威インテリジェンス、5.23 クラウドサービスの利用における情報セキュリティ、5.30 事業継続のためのICTの備え、7.4 物理的セキュリティの監視、8.9 構成管理、8.10 情報の削除、8.11 データマスキング、8.12 データ漏えい防止、8.16 監視活動、8.23 ウェブフィルタリング、8.28 セキュリティに配慮したコーディングの11項目です。SaaSを開発・利用するIT企業にとっては、いずれも既に何らかの形で運用している領域が多いはずで、ゼロから作るというより、既存の運用を管理策として言語化する作業になります。

もう1つの変更が属性です。2022年版では各管理策に5種類の属性が付与されました。管理策タイプ（予防／検知／是正）、情報セキュリティ特性（機密性／完全性／可用性）、サイバーセキュリティ概念（識別／防御／検知／対応／復旧）、運用能力（ガバナンス、資産管理など）、セキュリティドメイン（ガバナンスとエコシステム、保護、防御、レジリエンス）の5つです。これは管理策を別の切り口で並べ替えて分析するための仕組みで、属性による分類そのものが要求事項になっているわけではありません。

組織的管理策（5.1〜5.37）の一覧

37項目と最も数が多く、方針・体制・供給者管理・インシデント対応・法令順守までを含みます。2013年版で分野をまたいでいた管理策が、ここに集約されている点が特徴です。文書として整備する対象が多いテーマでもあり、必要な文書の全体像はISMSで必要な文書一覧にまとめています。

人的管理策（6.1〜6.8）の一覧

採用から退職までの人に関わる管理策です。8項目と少ないものの、就業規則・雇用契約・入退社手続きといった既存の人事プロセスと重なるため、情報システム部門だけでは完結しません。リモートワークが独立した管理策になっている点は、2013年版との実務上の差が出やすいところです。

物理的管理策（7.1〜7.14）の一覧

入退管理、装置、記憶媒体、廃棄までを扱います。自社サーバールームを持たずクラウドのみで運用する企業でも、オフィスの入退室、社用PCの持ち出し、返却と廃棄は対象に残ります。適用範囲の切り方によって関係する項目が変わるテーマです。

技術的管理策（8.1〜8.34）の一覧

34項目とテーマ別では2番目に多く、新設11のうち7項目がここに含まれます。アクセス制御、暗号、ログ、ネットワーク、開発ライフサイクルが対象で、IT企業では既存の開発・運用ルールと重複する部分が大きくなります。

適用宣言書（SoA）での使い方

附属書Aの93管理策が最終的に集約されるのが、箇条6.1.3 d)が求める適用宣言書（SoA）です。SoAは93行の表として作られることが多く、各行に次の情報を持たせます。

1. 管理策番号と名称（附属書Aの93項目すべてを行として持つ）
2. 適用するかどうかの区分
3. 適用する理由（どのリスク対応から導かれたか、または法令・契約・自社方針のどれによるか）
4. 除外する場合の理由（自組織の活動に該当しない、という説明が成り立つか）
5. 実施状況と、実施を裏づける文書・記録の参照先

ここで審査時に確認されやすいのが、リスク対応計画とSoAの行き来ができるかです。リスク対応で選んだ管理策がSoAで適用になっていない、逆にSoAで適用としたのに対応する文書も記録も見当たらない、といった不整合は目につきやすい部分です。除外の理由も「該当なし」の一言では説明が弱く、なぜ該当しないのかを自社の活動に即して書く必要があります。

なお、除外できるかどうかはリスクアセスメントの結果次第です。たとえば自社で開発を行っていない企業が開発関連の管理策を除外することはあり得ますが、外部委託で開発している場合は8.30 外部委託による開発が関係してきます。「使っていないから除外」ではなく「自社の業務に登場しないから除外」という筋で考えてください。

中小IT企業が優先しやすい管理策の例

優先順位は本来リスクアセスメントの結果で決まるもので、一律の正解はありません。そのうえで一般論として、100名規模までのIT企業では次の領域が着手の起点になりやすい傾向があります。自社の既存運用がそのまま管理策の実施状況になるため、新規に作る負担が比較的小さい領域でもあります。

• 5.15／5.18／8.2 アクセス権と特権の管理 — SaaSアカウントの棚卸しが起点になり、入退社手続きとも連動する
• 5.9／5.10 情報資産の目録と利用の許容範囲 — 何を守るかが決まらないと他の管理策の根拠が書けない
• 5.23 クラウドサービスの利用における情報セキュリティ — 利用中のSaaSの選定・契約・退出の考え方を明文化する
• 8.8 技術的脆弱性の管理 — 依存ライブラリとOSの更新について、検知から適用までの流れを決める
• 8.15／8.16 ログ取得と監視活動 — 取得済みのログについて、誰がいつ見るかを決めるところから始める
• 6.3 情報セキュリティの意識向上，教育及び訓練 — 年1回の実施記録が残せる形にする
• 5.24〜5.27 インシデント管理 — 軽微な事象を含めて報告が上がる導線を作る

逆に、初期の負荷が大きくなりやすいのは、新設の8.11 データマスキングや8.12 データ漏えい防止のように、ツール導入を伴う可能性がある管理策です。これらは扱う情報の性質によって必要性が大きく変わるため、リスクアセスメントの結果を踏まえて判断してください。認証取得までの全体の進め方はISO27001認証取得の進め方で扱っています。

93管理策をツールで管理するという選択

93管理策の一覧そのものは、スプレッドシートでも十分に作れます。負荷が増えるのは、リスク、管理策、SoA、文書、記録の4つ以上を相互に紐づけて維持する部分です。リスクを1件更新したときに、どのSoAの行とどの文書に影響するかを目視で追う運用は、管理策の数が93あると現実的に破綻しやすくなります。

紐づけをツール側に持たせると、更新の波及が自動的に追跡され、適用・除外の理由が空欄のまま残っている行も検知しやすくなります。自社が93管理策のどこまで説明できる状態かを先に確かめたい場合は、ISMS現在地セルフチェックから始めるとよいでしょう。

本記事は一般的な情報提供を目的としており、審査結果や認証取得を保証するものではありません。制度・費用は変わることがあるため、最新情報は審査機関等でご確認ください。