ISMS構築で作る文書のうち、**審査員が最初に開き、審査の最後まで参照し続けるのが適用宣言書（SoA：Statement of Applicability）**です。規程集や台帳は必要な部分だけ抜き出して見られますが、適用宣言書は全体を通して読まれます。ここに書いたことが、以降の質問の起点になるためです。
にもかかわらず、実務では「93行のExcelを埋める作業」として扱われ、雛形の文言をそのままコピーして提出されることが少なくありません。その結果、審査で「この管理策は適用と書かれていますが、実際にどう運用していますか」と聞かれて答えられない、あるいは除外の理由が「該当なし」の一言しかなく説明を求められる、という事態が起きます。
本記事は、適用宣言書をリスクアセスメント結果と整合した形で書き上げるための実務ガイドです。列の構造、記載の粒度、除外の正当化の書き方、そして更新のタイミングまでを扱います。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の文書作成はそれらに基づいて行ってください。
適用宣言書とは何か
適用宣言書は、ISO/IEC 27001 の箇条6.1.3（情報セキュリティリスク対応）で作成が求められる、文書化した情報です。求められている中身は次の4つに整理できます。
- 必要と判断した管理策（リスク対応のために決定した管理策）
- それを含めた理由
- その管理策を実施しているかどうか
- 附属書Aの管理策を除外した場合、その除外の正当化
つまり、適用宣言書は「管理策の一覧表」ではなく、自社が何をなぜ必要と判断し、いま実施できているのかを一枚で説明する文書です。
附属書Aは2022年版で93の管理策を4テーマに整理しています。適用宣言書はこの93すべてについて態度を示す必要があります。
| テーマ | 管理策数 | 主な内容 |
|---|---|---|
| 組織的管理策（A.5） | 37 | 方針、役割と責任、資産管理、アクセス制御方針、委託先管理、インシデント管理、事業継続、法令遵守 |
| 人的管理策（A.6） | 8 | 選考、雇用条件、教育、懲戒、雇用終了後の責任、機密保持、リモートワーク、報告 |
| 物理的管理策（A.7） | 14 | 境界、入退管理、執務環境、装置、ケーブル、保守、クリアデスク、媒体の廃棄 |
| 技術的管理策（A.8） | 34 | 端末、特権、認証、暗号、バックアップ、ログ、監視、ネットワーク、セキュア開発、変更管理、テストデータ |
管理策ごとの読み方は 附属書A 2022年版｜93管理策と4テーマの全体像 と、テーマ別の 組織的管理策37項目の読み方、技術的管理策34項目の読み方 にまとめています。ISMS全体の位置づけは ISMS（ISO/IEC 27001）とは をご覧ください。
「93すべてを実施する義務」はない
誤解されやすい点なので明記します。93の管理策すべてを実施する義務はありません。 自社のリスクアセスメント結果に照らして必要な管理策を決め、必要でないものは理由を書いて除外できます。
ただし、除外できるのは「自社に該当しない」ことを説明できる場合だけです。「まだ実施できていない」は除外の理由になりません。それは適用としたうえで、実施状況の欄に未実施であることと計画を書くのが正しい扱いです。
リスクアセスメント結果との対応
2022年版で押さえておきたいのは、管理策の決め方の順序です。
- リスクアセスメントの結果に基づき、リスク対応に必要な管理策を決定する
- 決定した管理策を附属書Aと比較し、必要な管理策が漏れていないかを検証する
- 適用宣言書を作成する
附属書Aから選ぶのではなく、先に自社に必要なものを決め、附属書Aは漏れのチェックリストとして使うという順序です。実務では附属書Aを見ながら進めることが多いですが、記録としては「リスクが先、管理策が後」の対応関係が説明できる状態にしてください。
この対応関係を保つ最も簡単な方法は、リスクアセスメント表と適用宣言書に相互参照の列を持たせることです。
| 文書 | 追加する列 | 内容 |
|---|---|---|
| リスクアセスメント表 | 適用する管理策 | そのリスクに対して採用した管理策番号（A.5.1、A.8.9 など） |
| 適用宣言書 | 関連リスクID | その管理策を必要とした根拠となるリスクの識別番号 |
この2列があるだけで、審査での「この管理策を適用とした根拠は何ですか」という質問に、リスク行を指して答えられるようになります。逆にこの紐づけがないと、適用宣言書が雛形の丸写しに見えてしまいます。
リスクアセスメントの設計は リスクアセスメントの進め方｜評価基準の設計、対応方針の決定は リスク対応計画とリスク受容の判断 をご覧ください。前提となる箇条は 箇条4｜組織の状況、箇条5 リーダーシップ、箇条6 計画 で解説しています。
記載例：列の構造
適用宣言書の様式は規格で指定されていません。ただし、要求される4要素を満たしつつ審査で使いやすい構造は、おおむね次のようになります。
| 列 | 記載内容 | 例 |
|---|---|---|
| 管理策番号 | A.5.1 〜 A.8.34 | A.8.9 |
| 管理策名 | 附属書Aの名称（自社訳でよい） | 構成管理 |
| 適用／除外 | 適用・除外の二択 | 適用 |
| 適用の理由／除外の正当化 | なぜ必要か、またはなぜ不要か | クラウド上の本番環境の設定変更が主要なリスク源であり、意図しない構成変更の検知が必要なため |
| 関連リスクID | リスクアセスメント表の行番号 | R-012、R-018 |
| 実施状況 | 実施済／一部実施／未実施 | 一部実施 |
| 実施方法の概要 | どう運用しているか（1〜2文） | IaCで構成を管理し、ドリフト検知を日次実行。検知時は変更管理チケットを起票 |
| 関連文書・記録 | 参照先の規程名や記録の所在 | 情報セキュリティ管理規定 §7、構成変更チケット一覧 |
| 未実施の場合の計画 | 期限と担当 | 2026年12月までにドリフト検知の対象範囲を検証環境へ拡大（情シス） |
| 最終更新日 | 版管理用 | 2026-09-14 |
「実施方法の概要」列が実質的に最も価値があります。 ここが1〜2文でも書かれていると、審査員はどの記録を見ればよいか判断できます。空欄だと、口頭での説明を一から求められることになります。
記載の粒度
すべての行に長文を書く必要はありません。粒度の目安は次のとおりです。
| 管理策の性質 | 粒度 | 例 |
|---|---|---|
| 自社のリスクの中核にあたるもの | 詳しく。実施方法と記録の所在まで | アクセス制御、ログ、暗号、委託先管理、バックアップ |
| 一般的な運用でカバーされるもの | 1文で十分 | クリアデスク、機密保持契約 |
| 除外するもの | 理由を具体的に。1文でも「なぜ該当しないか」が読み取れること | 開発機能を持たない場合のセキュア開発関連 |
除外の正当化をどう書くか
除外の書き方は、審査でのやりとりを最も左右する部分です。「該当なし」「対象外」の一言は正当化になりません。
正当化とは、適用範囲・事業内容・扱う資産の事実から、その管理策が必要ない理由を導いた説明です。
| 管理策の例 | 弱い除外理由 | 通用する除外理由 |
|---|---|---|
| 物理的な入退管理（自社オフィスを持たない場合） | 該当なし | 適用範囲にフルリモート勤務の従業者のみが含まれ、自社管理の物理的施設を保有しない。業務データはすべてクラウド上にあり、物理媒体を扱わないため |
| ソフトウェア開発関連の管理策 | 開発していないため | 適用範囲に含まれる業務はSaaSの選定・運用のみで、自社でのソフトウェア開発・改修は行っていない。開発は行わないため、対象となるプロセスが存在しない |
| 媒体の廃棄 | 紙を使わない | 業務で紙媒体および可搬記憶媒体を使用しない運用としており、使用禁止を情報セキュリティ管理規定 §9 で定めている。持込み・持出しは入退室手順で確認している |
| 開発環境と本番環境の分離 | 環境が1つのため | （正当化困難。分離していないこと自体がリスクであり、除外ではなく適用としたうえでリスク受容または代替策を説明すべき） |
最後の行が重要な教訓です。 「できていないから除外」は成立しません。できていないものは適用としたうえで、実施状況を「未実施」とし、リスク対応計画に載せてください。未実施の項目が存在すること自体は、審査で必ずしも不適合になりません。未実施を把握し、計画があり、リスクとして受容の判断がなされているなら、それは管理された状態です。
また、除外の正当化を書くときは、その記述が適用範囲の定義と矛盾しないかを必ず確認してください。適用宣言書で「自社施設を持たない」と書きながら、適用範囲に本社オフィスが含まれていれば、その時点で整合が崩れます。適用範囲の決め方は ISMS適用範囲の決め方 をご覧ください。
審査で最も読まれる文書である理由
適用宣言書が審査で重視されるのは、それが「自社のISMSの目次」として機能するからです。審査員は限られた時間で組織の実態を把握しなければならず、適用宣言書を読めば、どの管理策を重視し、どこに弱点があるかの当たりがつきます。
具体的には、次のような使われ方をします。
| 審査の場面 | 適用宣言書の使われ方 |
|---|---|
| 1次審査（文書審査） | 適用宣言書とリスクアセスメント表の整合、除外理由の妥当性、適用範囲との一致を確認する。ここで矛盾があると2次審査の焦点が決まる |
| 2次審査のサンプリング設計 | 「実施済」と書かれた管理策から数件を選び、記録を確認する。実態と記載のずれを探す |
| 内部監査の網羅性の確認 | 「適用とした管理策は、内部監査で網羅されていますか」という質問の起点になる |
| サーベイランス審査 | 前回からの変更点（適用／除外の変更、実施状況の進捗）を確認する |
つまり、適用宣言書に書いた「実施済」は、記録で裏づけられる必要があります。 実態より前向きに書くと、2次審査で必ず露見します。「一部実施」を正直に使うことが、結果的に最も安全です。
審査の進み方は 1次審査（文書審査）で見られること と 2次審査（実地審査）で見られること、典型的な指摘は 審査でよくある不適合と対策 にまとめています。内部監査での網羅性の担保は 箇条9 パフォーマンス評価 で扱っています。
属性（attribute）は書くべきか
2022年版の附属書Aには、各管理策に属性（管理策タイプ、情報セキュリティ特性、サイバーセキュリティ概念、運用能力、セキュリティドメイン）という分類軸が導入されました。属性の使用は任意であり、適用宣言書に属性列を設ける義務はありません。
実務的には、次の場合に追加する価値があります。
- 管理策を予防／検知／是正で分類し、検知系の偏りを可視化したい
- 機密性・完全性・可用性のどれをどれだけカバーしているかを経営層に説明したい
- 他のフレームワーク（NISTのCSFなど）との対応を示したい
逆に、初回取得で運用の負荷を抑えたい場合は、属性列を入れないという判断も合理的です。属性の詳細は ISO/IEC 27001:2022への移行｜2013年版との差分 で扱っています。
更新のタイミングと版管理
適用宣言書は作って終わりの文書ではありません。リスクの変化に追随して更新されることが前提です。更新契機を先に定義しておくと、サーベイランス審査で説明しやすくなります。
| 更新の契機 | 典型的な変更 |
|---|---|
| 定期のリスクアセスメント（年1回など） | 実施状況の更新、リスクIDの追加 |
| 適用範囲の変更（拠点・事業・子会社の増減） | 除外していた管理策の適用化、またはその逆 |
| 新しいサービス・技術の導入 | 関連する技術的管理策の適用状況変更 |
| 重大インシデントの発生 | 是正処置に伴う実施方法の変更 |
| 委託先の変更 | 委託先管理関連の実施方法の更新 |
| 法令・ガイドラインの改定 | 法令遵守関連の記述の更新 |
| 未実施項目の計画完了 | 「未実施」→「実施済」への更新 |
版管理では、改訂日・改訂者・承認者・変更内容の要約を残してください。「どこを変えたか」が分かる状態にしておくと、サーベイランス審査で前回からの差分を説明する作業が数分で終わります。
文書管理の仕組み全体は 箇条7 支援｜力量・認識・文書化した情報 と ISMS文書体系｜何をどこまで作るか、運用実行の記録は 箇条8 運用 をご覧ください。
ヘルスケア企業での記載の勘所
ヘルスケア企業の適用宣言書には、一般的なIT企業と異なる書きぶりが求められる箇所があります。
医療情報を扱うことを適用理由に明示する
アクセス制御、暗号、ログ、バックアップ、委託先管理といった管理策では、適用の理由に「医療情報／要配慮個人情報を取り扱うため」という事実を書き込むと、なぜ厳格な運用をしているのかが一読で伝わります。取引先からチェックシート回答を求められたときにも、この記述がそのまま使えます。
3省2ガイドライン由来の要求を実施方法に書く
医療機関向けサービスでは、ガイドラインが求める水準（真正性・見読性・保存性の確保、リモート保守時の管理、外部保存の要件など）が実施方法に反映されているはずです。適用宣言書の実施方法欄にガイドラインとの対応を1行入れておくと、ISMS審査と顧客監査の双方で使えます。統合の考え方は ISMS文書と3省2ガイドライン対応文書の統合、ガイドラインの要点は 3省2ガイドラインとは をご覧ください。
クラウド利用の管理策は責任分界を書く
A.5.23（クラウドサービスの利用における情報セキュリティ）のように2022年版で新設された管理策は、自社が担う範囲とクラウド事業者が担う範囲を分けて書くと実態に合います。責任共有モデルの整理は AIカルテのセキュリティ設計と責任共有モデル で扱っています。
除外の判断が事業内容に依存する
たとえば開発を外部委託しているヘルスケア企業では、セキュア開発関連の管理策を「自社では開発しないため除外」とするか、「委託先に要求する形で適用」とするかの判断が分かれます。委託先に要求している場合は除外ではなく適用とし、実施方法に「委託契約のセキュリティ要件として規定し、年次で確認」と書くのが整合的です。委託先管理の実務は 外部委託先管理｜チェックシートと契約条項 をご覧ください。
まとめ
適用宣言書について押さえるべき点は次のとおりです。
- 適用宣言書は**「必要な管理策」「含めた理由」「実施の有無」「除外の正当化」**の4要素を満たす文書。管理策の一覧表ではない
- 93すべてを実施する義務はない。 ただし除外できるのは「該当しない」を説明できる場合のみで、「まだできていない」は除外理由にならない
- 決め方の順序はリスクが先、管理策が後。附属書Aは漏れのチェックリストとして使う。リスクIDの相互参照列を持たせると審査で強い
- 除外の正当化は「該当なし」では通らない。適用範囲・事業内容・扱う資産の事実から理由を導く
- 実施状況は実態より前向きに書かない。「一部実施」を正直に使うのが最も安全
- 属性列は任意。 初回取得では入れない判断も合理的
- 更新契機を先に定義し、改訂履歴で差分を説明できる状態にしておく
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。適用宣言書は雛形を提供したうえで、リスクアセスメント結果との紐づけと除外理由の妥当性まで一緒に詰めます。審査機関とのやり取りも当社が主導するため、御社には判断に集中していただけます。
支援内容と料金は ISMS認証取得支援サービス をご覧ください。すでに作成した適用宣言書のレビューだけでも お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- JIS Q 27001:2023｜日本産業標準調査会
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※管理策の名称・番号および要求事項の解釈は、規格本文（JIS Q 27001:2023／ISO/IEC 27001:2022 附属書A）をご確認ください。適用宣言書の様式・記載粒度の期待値は審査機関により差があります。