ISMS附属書Aとは？役割・選び方・SoA・規程への落とし込みまで完全解説【2022年版対応】

「ISMS附属書Aって、結局どう使えばいいの？全部やらないといけないの？」
このような疑問や不安を感じたことはないでしょうか。

ISMS（ISO/IEC 27001）に取り組む中で、附属書Aは必ず目にする存在です。しかしその一方で、「管理策をそのまま規程に書けばいい」「とりあえず全部適用しておけば安心」といった誤解から、運用が形骸化してしまうケースも少なくありません。

附属書Aは、単なるチェックリストでも、守るべきルール集でもなく、自社のリスクに応じたセキュリティ対策を選び、説明し、運用するための道具です。その位置づけや使い方を正しく理解しないまま進めてしまうと、審査対応に苦労したり、現場に定着しないISMSになってしまいます。

この記事では、ISMS附属書Aについて、役割や考え方といった基礎から、ISO/IEC 27001・27002との関係、2022年版での構成の変化、リスクアセスメントやSoAとのつながり、そして規程への落とし込み方やよくある失敗例まで、実務目線で体系的に解説します。

最後までお読みいただくことで、「附属書Aをどう選び、どう書き、どう運用すればよいのか」が整理され、審査に強く、かつ現場で機能するISMS運用のイメージを持てるようになるはずです。

1.【結論】ISMS附属書Aの役割とは？

(1)附属書Aは「セキュリティ対策の網羅性チェックリスト（管理策カタログ）」

ISMS附属書Aは、組織が検討すべき情報セキュリティ対策を体系的に整理した管理策の一覧（カタログ／メニュー表）です。国際的に認められた『標準的な管理指針』に基づき、対策を講じます。

ここで重要なのは、附属書Aが

• そのまま導入するための手順書ではないこと
• 「何を必ず実施せよ」という答えを示すものではないこと

です。
附属書Aはあくまで、検討漏れを防ぐための網羅的なリストであり、自社にとって必要な対策を選び出すための起点として位置づけられています。

なお、ISMSの本文（要求事項）が「マネジメントの仕組み（PDCA）」を規定しているのに対し、附属書Aは「何を（What）守るか」という管理策の選択肢を示す役割を担っています。

(2)なぜ“必須ではなく選択式”なのか

ISMSは「リスクベースアプローチ」を前提としています。そのため、すべての管理策を一律に適用することは求められていません。

組織ごとに事業内容や環境が異なれば、想定されるリスクも異なります。
例えば、

• オフィスのみの企業にとって、データセンターの物理警備は過剰となる場合がある
• 紙媒体を扱わない企業では、クリアデスクに関する対策の重要性は限定的になる

また、フルリモートのSaaS企業と、自社工場を持つ製造業とでは、守るべきリスクが根本的に異なります。

このような前提から、ISMSでは

• 自社に必要な管理策を選択すること
• 不要な管理策は、リスク評価に基づき論理的に除外すること

が認められています。
合理的に「やらない」と判断することも、附属書Aの考え方に含まれています。

(3)認証取得における位置づけ

認証審査において評価されるのは、附属書Aをどれだけ網羅的に理解しているかではありません。
審査では、

• どの管理策を選定したのか
• なぜその管理策を選んだのか、または除外したのか
• 選定した管理策がどのように運用されているのか

といった点が確認されます。

附属書Aは、自社のリスクアセスメント結果と照合し、対策に漏れがないかを確認するためのベンチマークとして機能します。附属書Aに記載されている管理策を採用しない場合でも、その判断がリスクに基づき、妥当な理由として説明できることが求められます。

したがって、認証取得において重要なのは、「附属書Aをすべて適用しているか」ではなく、管理策の選定理由と運用の一貫性です。

2．附属書Aの正しい位置づけ（ISO/IEC 27001との関係）

(1)本文（要求事項）との関係

ISO/IEC 27001の本文は、「情報セキュリティマネジメントシステム（ISMS）として何を管理すべきか」を定めたマネジメントシステムの要求事項です。
これに対して、附属書Aは、情報セキュリティリスクに対応するための具体的な管理策の例（選択肢）を示しています。

ISO/IEC 27001の「6.1.3 情報セキュリティリスク対応」では、決定した管理策を附属書Aと比較し、必要な管理策が見落とされていないかを確認することが求められています。
このことから、本文と附属書Aの関係は以下のように整理できます。

本文が「枠組み」や「戦略」を示し、附属書Aが「手段」や「戦術の選択肢」を提供する関係にあり、附属書Aは本文を補完する位置づけにあります。

(2)附属書A＝そのまま実装ではない理由

附属書Aに記載されているのは、管理策の名称や管理目的であり、具体的な運用手順や作業レベルのルール（SOP）ではありません。
そのため、附属書Aの内容をそのまま導入しても、実務としては運用できません。

例えば、「アクセス制御を実施すること」という管理策があった場合でも、

• 誰が対象なのか
• どのシステムに適用するのか
• どのような権限区分とするのか
• 認証方式は何を用いるのか
• いつ、どのように見直すのか

といった点は、附属書Aには記載されていません。

また、「指紋認証を導入するのか」「パスワードを12桁にするのか」といった具体的な実装内容は、各組織のリスク許容度やコスト、事業特性に基づいて決定されるものです。
このように、附属書Aに記載された抽象的な管理策を、自組織の状況に合わせて具体化・定義するプロセスが不可欠です。

(3)ISO/IEC 27002との違い（ルールとガイドの関係）

附属書AとISO/IEC 27002は、役割が明確に分かれています。

附属書Aは「方向性」や「何を行うべきか」を簡潔に示すにとどまり、具体的な実装方法までは踏み込みません。
一方、ISO/IEC 27002では、附属書Aの各管理策について、実装例や留意点などが詳細に解説されており、管理策を実運用レベルに落とし込むための参考資料として機能します。

そのため、附属書Aのみでは管理策の全体像しか把握できず、ISO/IEC 27002を参照することで、具体的な運用設計が可能になります。

3．【2022年版】附属書Aの構成と管理策の全体像

(1)93管理策（4カテゴリ）の整理

2022年版の附属書Aでは、管理策は93項目に整理され、従来の「章（ドメイン）構成」から、管理対象ベースの4カテゴリへ再編されています。
これにより、組織のどの領域に関する対策かを直感的に把握しやすい構造となっています。

この再編により、従来の「分野ごとの分断」ではなく、管理対象に着目した横断的な理解が可能になっています。

(2)旧版（114管理策）との違い

旧版では114の管理策が定義されていましたが、2022年版では93管理策へ統合・再編されています。
主な変更点は以下のとおりです。

• 管理策数：114 → 93 へ削減
• 重複・類似する管理策の整理・統合
• 各管理策に「属性（タグ）」を付与

この「属性」により、管理策を以下のような観点で横断的に整理できます。

• 管理目的
• セキュリティ特性（機密性・完全性・可用性 など）

また、現代のサイバー脅威やIT利用形態を反映し、「脅威インテリジェンス」「クラウドサービスの利用」「データマスキング」「データ漏洩防止」「活動の監視（ログモニタリング）」などを含む11項目が新たに追加されています。

(3)“全部理解しなくていい”理由と読み方

93の管理策すべてを詳細に理解・暗記する必要はありません。重要なのは、自社のリスクに関連する管理策を重点的に理解することです。

実務上の読み方としては、以下の観点が有効です。

• 自社の業務内容や情報資産と管理策を紐付ける
• 想定しているリスクシナリオと照合する
• 関連性の高い管理策のみを精読する

各管理策について、「自社のどの資産を、どの脅威から守るためのものか」を把握することが、附属書Aを実務で活用する上でのポイントとなります。

4．附属書Aはどう選ぶ？リスクアセスメントとの関係

(1)リスクベースで管理策を選定する考え方

附属書Aの管理策は、「対策ありき」で選ぶものではなく、リスクアセスメントの結果として選定することが前提です。ISMSでは、資産・脅威・脆弱性を特定し、リスクが存在するからこそ対策を講じる、という順序が求められます。

基本的な流れは以下のとおりです。

このうち、附属書Aを参照するのは「4．リスク対応」の段階です。リスクアセスメントの結果として「低減が必要」と判断されたリスクに対し、その手段として附属書Aに示された管理策を選択します。

(2)「とりあえず全部適用」はNGな理由

附属書Aの管理策を「念のためすべて適用する」という考え方は、実務上適切ではありません。

主な理由は以下のとおりです。

• 運用負荷が過剰になる
• 現場で守りきれなくなる
• ルールが形骸化する

その結果、実際には守られないルールが量産されることになります。

また、事業実態と合わない管理策を定めた場合、運用の実態が伴わず、審査においても指摘対象となります。
このように、「全部やる」ことはリスク低減につながらず、かえってISMSの信頼性を損なう可能性があります。

(3)実務での選定ステップ

実務では、以下のような手順で管理策を選定するのが現実的です。

このプロセスにおける重要なポイントは、「管理策起点」ではなく「リスク起点」で考えることです。

附属書Aは、リスク対応の結果を具体的な管理策に落とし込むための参照資料として活用されます。

5．附属書Aと適用宣言書（SoA）の関係

(1)SoA（Statement of Applicability）とは何か

SoA（適用宣言書）とは、

• どの附属書Aの管理策を適用するのか
• なぜ適用または不適用と判断したのか
• 適用する管理策をどのように実施しているのか

を一覧化した文書です。

ISMS認証においてSoAは、「自社はこの管理策を採用し、これらのルールを守る」ことを示す対外的な誓約書という位置づけになります。
言い換えると、附属書Aをどのように使ったか、その判断結果を可視化したものがSoAです。

(2)適用／不適用の判断基準

管理策の適用・不適用は、恣意的に決めるものではなく、以下の判断軸に基づいて決定されます。

適用とされるのは、リスク低減に必要なもの、または法的・契約上求められる管理策です。
一方、不適用とされるのは、組織の業務範囲に物理的・実態的に存在しないものです。
例えば、自社開発を行わない組織において、「安全な開発ライフサイクル」に関する管理策は、不適用と判断される場合があります。

(3)不適用の正しい書き方とNG例

SoAにおいて、不適用とする管理策は、論理的に説明できる理由を明記する必要があります。

【良い例（具体的・論理的な記載）】

• 「物理的サーバーを所有せず、すべてAWSを利用しているため、A.7.1〜A.7.4（物理的周辺境界等）は適用除外とする。なお、データセンター側の管理については、A.5.23（クラウドサービス利用）にて評価する。」
• 「当社は紙媒体を扱わないため、本管理策は適用外とする。」

【NG例（理由になっていない記載）】

• 「該当なし」
• 「不要」
• 「現在実施していないため」

不適用の是非そのものよりも、なぜ不適用と判断したのかが説明できているかが重要です。

(4)審査で最も見られるポイント

認証審査において、SoAは特に重点的に確認されます。
審査員が主に確認するポイントは以下のとおりです。

• リスクアセスメント結果とSoAの整合性
• 不適用理由の妥当性
• 規程や実際の運用との一致

具体的には、

• リスクとして特定されているにもかかわらず、対応する管理策が「不適用」になっていないか
• 逆に、業務実態と合わない管理策が不自然にすべて「適用」になっていないか

といった点が厳しくチェックされます。
SoAは、附属書A・リスクアセスメント・規程・運用をつなぐ中核文書として扱われます。

6．附属書Aをセキュリティ規程に落とし込む方法

(1)管理策 → 規程への変換方法

附属書Aに記載されている管理策は、汎用的かつ抽象的な表現で書かれています。そのままでは現場で運用できないため、「誰が、いつ、何を、どうするか」という職務・行動レベルの規程へ翻訳する必要があります。

変換の基本構造は以下のとおりです。

【変換例】

• 管理策（附属書A）
  「情報のバックアップをとること」
• 規程（社内ルール）
  「IT推進部長は、基幹システムのデータベースを毎日2時に自動バックアップし、バックアップデータは30日間の世代管理を行うものとする。」

別の例として、

• 管理策：「アクセス権を管理する」
• 規程：「情報システム部門は、四半期ごとに全システムのアクセス権をレビューする」

このように、管理策を具体的な行動に落とし込むことが規程化の本質です。

(2)「コピペ運用」が失敗する理由

附属書Aや規格の文言を、そのままセキュリティ規程にコピーする運用は、多くの場合うまくいきません。
理由は以下のとおりです。

• 抽象的で、現場が「何をすればよいか」分からない
• 実際の業務や運用実態と乖離する
• 実施状況を示す証跡が残らない

その結果、

• 誰も読まない
• 誰も守らない

といった状態になり、規程が形骸化します。
このような規程は、実務上も審査上も意味を持たない「死んだ規程」になってしまいます。

(3)既存ルールとのマッピングの考え方

附属書Aに対応するために、必ずしも新しい「ISMS専用規程」を一から作成する必要はありません。重要なのは、新規作成ではなく、既存ルールとの紐付け（マッピング）です。

例えば、以下のような既存文書がすでに存在している場合があります。

• 就業規則
• 秘密保持契約（NDA）
• IT利用規程
• ネットワーク運用マニュアル
• 入退室ルール

これらが、附属書Aのどの管理策をカバーしているのかを整理し、対応関係を明確にするだけで十分な場合も多くあります。

このマッピングにより、

• 不要なルールの乱立を防げる
• 現場に浸透している既存ルールを活かせる

という効果があり、実効性の高いISMS運用につながります。

7．失敗しないセキュリティ規程作成の3つのコツ

(1)コツ①：現場運用に合わせる（形骸化防止）

セキュリティ規程は、「理想的であること」よりも現場で守れることが前提です。実態とかけ離れたルールは、定めた瞬間から守られなくなり、形骸化します。

重要なのは、現在の実力値に少し上乗せしたレベル（現状＋α）で規程を設計することです。
例えば、多要素認証（MFA）が未導入の状態で「MFAを必須とする」と規程に記載すると、その時点で実態と不一致となり、不適合の原因になります。

規程は「目標」ではなく、「今の運用を確実に回すためのルール」として設計する必要があります。

(2)コツ②：責任・ルールを明確化する

セキュリティ規程では、曖昧な表現は避けなければなりません。

【NGとなる表現の例】

• 「適切に管理する」
• 「十分に配慮する」

これらの表現では、

• 誰が
• 何を
• どこまでやればよいのか

が分からず、運用も評価もできません。

そのため、規程では以下を明確に定義します。

例えば、「アクセス権を適切に管理する」ではなく、「情報システム部門長は、四半期ごとに全システムのアクセス権をレビューし、結果を記録する」といったレベルまで具体化することが求められます。

(3)コツ③：証跡（エビデンス）まで設計する（審査対策）

規程は「決める」だけでは不十分で、実施した証拠を残せる設計になっている必要があります。特にISMSでは、「やっているかどうか」ではなく、「やったことを示せるか」が重要です。

そのため、規程作成時には必ず、「このルールを守った証拠として、何を残すのか」をセットで考えます。

【代表的な証跡の例】

• ログ（アクセスログ、操作ログなど）
• 記録（点検記録、レビュー結果）
• 承認履歴（申請・承認フローの記録）

例えば、「ログを確認する」と規程に書くだけでは不十分で、

• 確認結果を記録する様式
• 誰が、いつ確認したか分かる承認ログ

まで含めて設計して初めて、運用が定着し、審査にも耐えられる規程になります。

8．よくある失敗パターンと改善のヒント

(1)管理策の丸写し

【失敗パターン】

附属書Aや規格の文言を、そのままセキュリティ規程に転記してしまうケースです。
抽象的な表現のまま規程化されるため、現場では

• 何をすればよいのか分からない
• 自社の業務やシステムと結び付かない

といった状態になり、結果として運用不能になります。

【改善のヒント】

管理策は、自社の実態に合わせて具体化します。
具体的には、

• 社内で使っているシステム名
• 実在する役職名・部門名
• 実際の業務フロー

に置き換え、「誰が・何を・どうするか」が分かる表現に修正します。規格の言葉ではなく、現場の言葉で書き直すことが重要です。

(2)過剰管理による現場崩壊

【失敗パターン】

リスクの低い業務や情報資産に対しても、過度に厳格な管理策を一律に適用するケースです。
例えば、重要度の低い業務にまで、大企業並みの物理的制限や承認プロセスを課すと、

• ルールが多すぎて守れない
• 現場の負担が増大する

といった問題が発生します。

【改善のヒント】

リスクの大きさに応じて、対策の強さを調整します。
具体的には、

• リスクが高いものには厳格な対策
• リスクが低いものには簡素な対策

といったように、リスクベースで管理レベルを分ける（ティア分け）ことで、現場の負担を抑えつつ、実効性を確保できます。

(3)SoAと規程の不整合

【失敗パターン】

適用宣言書（SoA）では「適用」とされている管理策が、社内規程には記載されていない、またはその逆の状態です。この不整合は、認証審査で非常に指摘されやすいポイントです。

【改善のヒント】

SoAと規程を相互に確認し、整合性を取ります。
有効な方法として、

• SoAに記載された管理策
• 対応する社内規程・手順書

を対照できる一覧（対応表）を作成し、網羅性を確認します。これにより、「SoAでは適用だが、規程や運用が存在しない」といった漏れを防ぐことができます。

SoA・規程・実際の運用が同じ内容を指しているかを定期的にチェックすることが、不整合防止の鍵となります。

9.まとめ

本記事では、ISMSの附属書Aをテーマに、その正しい理解と実務での使い方について解説しました。要点を整理します。

まず、ISMS附属書Aの基本的な役割として、以下を解説しました。

• 附属書Aは、情報セキュリティ対策を体系的に整理した「管理策の網羅性チェックリスト（管理策カタログ）」であること
• 附属書Aは手順書や実装指示ではなく、自社に必要な対策を選ぶための出発点であること
• ISMSはリスクベースアプローチを前提としており、附属書Aの管理策は必須ではなく選択式であること
• 認証審査では、管理策を「どれだけ適用したか」ではなく、「なぜ選び、どう運用しているか」が評価されること

次に、ISO/IEC 27001との関係性について、以下を整理しました。

• 本文（要求事項）はマネジメントシステムの枠組みを定め、附属書Aは具体的な管理策の候補を示す関係であること
• 附属書Aは抽象的に記載されており、そのまま実装できるものではないこと
• 附属書Aが「何を行うべきか」を示すのに対し、ISO/IEC 27002は「どのように実施するか」を示す実践ガイドであること

2022年版附属書Aの特徴として、以下を解説しました。

• 管理策が93項目に整理され、「組織的・人的・物理的・技術的」の4カテゴリ構成となったこと
• 旧版114管理策からの統合・再編により、重複整理と属性（タグ）付けが行われたこと
• 全管理策を網羅的に理解する必要はなく、自社リスクに関係する管理策を重点的に読むことが重要であること

附属書Aの選び方とリスクアセスメントとの関係については、以下を説明しました。

• 管理策は「対策ありき」ではなく、リスクアセスメントの結果として選定するものであること
• 「とりあえず全部適用」は、運用負荷増大や形骸化を招くため適切ではないこと
• 実務では、リスク起点で管理策を選定し、その結果をSoAへ反映する流れが現実的であること

適用宣言書（SoA）との関係については、以下を整理しました。

• SoAは、どの管理策を適用・不適用としたか、その理由と実施状況を一覧化した文書であること
• SoAは附属書Aの「使い方の結果」であり、認証における対外的な誓約書であること
• 不適用理由は「該当なし」ではなく、業務範囲やリスクに基づき論理的に説明する必要があること
• 審査では、リスクアセスメント結果とSoA、規程・運用の整合性が最も重視されること

さらに、附属書Aをセキュリティ規程へ落とし込む方法として、以下を解説しました。

• 管理策は「誰が・いつ・何を・どうするか」という具体的な職務ルールに翻訳する必要があること
• 規格文言のコピペ運用は、現場で理解されず形骸化する原因となること
• 新規規程を乱立させるのではなく、既存の就業規則やIT規程と附属書Aをマッピングする考え方が有効であること

失敗しない規程作成のポイントとして、次の3点を示しました。

• 理想ではなく、現場で守れる「現状＋α」のルールにすること
• 責任者、対象、頻度、基準などを曖昧にせず明確に定義すること
• ルールだけでなく、ログや記録など「やった証拠（エビデンス）」まで設計すること

最後に、附属書A運用でよくある失敗と改善のヒントとして、以下を整理しました。

• 管理策の丸写しによる運用不能を防ぐため、自社用語・実務ベースで具体化すること
• 過剰管理による現場崩壊を避けるため、リスクに応じて管理レベルを調整すること
• SoAと規程の不整合を防ぐため、両者の対応関係を常に確認すること

本記事を通じて、附属書Aは「全部守るためのチェックリスト」ではなく、リスクに基づき、自社に合ったセキュリティ対策を設計・説明・運用するための道具であることを一貫して解説しました。