ISMS（ISO/IEC 27001）導入ロードマップ：スコープ設計からリスクアセスメント、運用定着まで

取引先からの要望や、DX推進における信頼性確保のためにISMS取得を検討する企業が増えています。

費用と期間は、適用範囲の規模と審査機関によって大きく変わります。審査機関は複数から見積もりを取り、初回審査だけでなく3年間の総額（初回＋サーベイランス2回）で比較してください。社内工数も、事務局担当者の稼働として予算に含めます。

ISMSの構築から認証取得までの標準的な流れです。全ての工程を完璧に行う必要はありませんが、順序を守ることは重要です。

ISMSの中核はリスクアセスメントです。ここが形だけになると、以降のSoAも運用も根拠を失います。作業は「資産の特定 → リスクの分析 → 評価 → 対応の決定」の順で進めます。

1. 資産台帳の粒度を決める

台帳をPC1台ごとに作ると更新が続きません。「営業部の顧客データ」「開発環境のソースコード」のように、管理責任者と取扱いルールが同じ単位でまとめます。各資産には管理責任者、保管場所（SaaS名を含む）、機密区分を記録します。

2. 機密性・完全性・可用性の3軸で評価する

資産価値は、漏えいしたときの影響（機密性）、改ざん・欠損したときの影響（完全性）、使えなくなったときの影響（可用性）を、それぞれ3段階程度で評価します。3軸の最大値または合計値を資産価値とする方法が一般的です。

リスク値の算出式（資産価値 × 脅威 × 脆弱性など）は自社で定義し、手順書に明記します。規格は特定の計算方法を要求していないため、毎回同じ基準で再現できることが重要になります。

3. リスク受容基準を先に決める

「リスク値が何点以上なら対応が必要か」を、アセスメントを始める前に経営層の承認を得て決めます。評価結果を見てから基準を決めると、対応したくない項目に合わせて基準が動き、審査で指摘されます。

4. 4つの対応から選ぶ

• 低減：管理策を適用してリスクを下げる（MFAの導入、アクセス権の見直しなど）。多くはこれに該当します。
• 移転・共有：サイバー保険や委託契約で影響を分担する。委託先の管理責任は残ります。
• 回避：リスク源そのものをやめる（不要な個人情報の取得停止、使っていないSaaSの解約など）。
• 保有（受容）：受容基準の範囲内として対応しない。判断した人と日付を記録します。

決定した内容は「リスク対応計画」として、対応内容、担当者、期限、完了の確認方法を表にまとめます。この計画がSoAの根拠になります。

ISO/IEC 27001:2022では、93個の管理策（Control）が Annex A として定義されています。これら全てを実施する必要はなく、自社のリスクに合わせて「適用する/しない」を選択します。その結果をまとめた表が「適用宣言書 (Statement of Applicability: SoA)」です。なお上場準備を並行する場合、ここで整備するアクセス管理・変更管理の記録はIT全般統制（ITGC）の証跡としても使えます。

SoAにおいて「適用しない」とした場合、その正当な理由（例：物理オフィスが存在しないため物理的対策の一部は対象外、など）を文書化する必要があります。

SoAは93個の管理策すべてについて、適用の有無と理由を1行ずつ記載した一覧表です。審査で必ず確認される文書のため、記載項目を最初に固めます。

記載する5項目

1. 管理策番号と名称：Annex Aの番号（5.1〜8.34）をそのまま使います。抜けがあると不適合になります。
2. 適用可否：適用する／適用しない、の2択で記載します。
3. 選択した理由：適用する場合は「リスクアセスメントの結果」「法令要求」「契約要求」のどれに基づくかを示します。
4. 実施状況：どの規程・手順書・設定で実現しているかを具体的に書きます。ここが空欄だと、宣言と実態が一致していないと見なされます。
5. 除外理由：適用しない場合のみ、その根拠を記載します。

除外理由の書き方

審査で問題になるのは、除外理由が「該当なし」「未実施」のように、判断の根拠を示していない場合です。「適用範囲にその対象が存在しない」ことを事実として書くのが基本形です。

更新のタイミング

SoAは一度作って終わりではなく、次の場合に見直します。組織変更や新しいSaaSの導入で適用範囲が変わったとき、リスクアセスメントを再実施したとき（年1回が一般的）、そして重大なインシデントが発生して対策を追加したときです。更新履歴（版数・日付・変更理由）を文書内に残します。

認証は取得後の維持のほうが長い期間になります。運用が止まりやすいのは、担当者交代のタイミングと、初回審査の翌年です。年間サイクルを先に決めておくと、審査前の駆け込み作業を避けられます。

内部監査の実務

内部監査は、監査する側が自部門を監査できません。部門間で相互に監査するか、外部の監査員へ委託します。確認するのは「ルール通りに運用されているか」であり、具体的にはアクセス権の棚卸し記録、入退社時のアカウント処理、教育の受講記録、インシデント報告の記録といった日付の入った証拠です。

形骸化を防ぐ運用

審査直前にまとめて記録を作る状態になったら、規程が実務に合っていない可能性があります。その場合は運用を規程に合わせるのではなく、規程を実際の運用に合わせて改訂するほうが定着します。規程の改訂自体はISMSで想定された手続きであり、変更履歴とマネジメントレビューでの承認を残せば問題ありません。

ISMS認証取得に向けた準備状況を確認するための項目です。