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

ISMSの取得は、取引先からの要望や、DX推進における信頼性確保をきっかけに検討されることがよくあります。

規格の本体はISO/IEC 27001:2022で、対応する日本の規格はJIS Q 27001:2023です。2024年2月には、組織の状況（4.1）と利害関係者の要求（4.2）を検討する際に、気候変動が自組織に関係する課題かどうかの考慮を求める追補（ISO/IEC 27001:2022/Amd 1:2024）が発行され、認証審査でも確認の対象になりました（ISMS-AC）。日本では、対応する追補JIS Q 27001:2023/AMENDMENT 1:2025が2025年5月に発行されています。追補は本体の一部を改める文書で、本体と併せて読みます。

費用と期間は、適用範囲の規模と認証機関によって大きく変わります。見積もりを比べるときは、比べる期間と、含まれる審査をそろえます。例えば3年間で比べるなら、初回審査、毎年のサーベイランス審査、3年目の再認証審査のどこまでを含むかを確かめます。追加の審査、交通費、外部支援の費用、社内工数（事務局担当者の稼働）のように見積もりに入っていない費用は、未確認として分けて記録します。認証が取引や入札の条件を満たすかは、提出先・調達先の条件と認証の対象範囲で確認します。質問票での扱いは、セキュリティチェックシートの回答方法で説明しています。

ISMSの構築から認証取得までを、この記事では7つのステップに整理しています。規格がこの順序を固定しているわけではなく、実際には工程が重なったり、前の工程に戻ったりします。どの工程でも、規格の要求事項（箇条4〜10）は省けません。附属書Aの管理策は、リスクなどに基づいて必要なものを選び、適用しないものには理由を残します（JIPDEC ISMSユーザーズガイド、本文p.12）。

ISMSで行う判断の土台になるのが、リスクアセスメントです。ここが形だけになると、後のSoAや運用で、なぜその対策を選んだのかを説明できなくなります。作業は、資産の特定、リスクの分析、評価、対応の決定の順で進めます。

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

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

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

資産価値は、漏えいしたときの影響（機密性）、改ざん・欠損したときの影響（完全性）、使えなくなったときの影響（可用性）を、それぞれ3段階程度で評価します。3軸の最大値や合計値を資産価値とする方法があります。次の表は、3軸の最大値を資産価値とし、「資産価値 × 脅威 × 脆弱性」でリスク値を出す、この記事の計算例です。

リスク値の算出式は自社で定義し、手順書に明記します。規格は特定の計算方法を要求していないため、誰が評価しても、毎回同じ基準で同じ結果を出せるように定めておきます。点数が低くても、法令や契約上の義務、業務への影響から対応が必要になる場合があるため、点数だけで受容を決めません。

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

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

4. 4つの対応から選ぶ

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

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

ISO/IEC 27001:2022の附属書A（Annex A）には、93の管理策が4つのカテゴリで示されています。附属書Aは管理策の包括的な一覧で、リスク対応で決めた管理策と照らし合わせ、必要なものを見落としていないかを確かめるために使います。必要な管理策は、リスクアセスメントの結果と、法令・契約・事業上の要求から決めます。附属書Aにない管理策を自社で追加することもできます（JIPDEC ISMSユーザーズガイド、6.1.3、本文p.46〜47）。その結果をまとめた文書が「適用宣言書（Statement of Applicability：SoA）」です。93項目を無条件にすべて実施するものでも、カテゴリごとに除外を決めるものでもありません。なお上場準備を並行して進める場合、ここで整備するアクセス管理・変更管理の記録はIT全般統制（ITGC）の証跡としても使えます。

附属書Aの管理策を適用しない場合は、その理由を記録します。理由は、リスクアセスメントの結果や、対象となる業務・情報の実態から説明できるように書きます（同ガイド、本文p.12）。

SoAには、必要と判断した管理策とその理由、その管理策を実施しているかどうか、附属書Aから除外した管理策とその理由を記録します。附属書Aにない管理策を自社で追加した場合も、その内容と理由を書きます（JIPDEC ISMSユーザーズガイド、6.1.3、本文p.46〜47）。審査で確認される文書のため、記録する項目を最初に決めておきます。

形式は一つに決まっていません。附属書Aの93項目を1行ずつ並べる一覧は、照合の漏れを防ぎやすい整理の方法の一つです。その場合も、自社で追加した管理策を書ける欄を設けます。

記録する項目の例

1. 管理策：附属書Aと照合できるように番号と名称を書く。自社で追加した管理策は区別して記録する
2. 必要かどうか：リスクアセスメントの結果、法令、契約、事業上の要求から判断する
3. 理由：必要と判断した根拠、または除外した理由
4. 実施状況：実施している規程・手順・設定。未実施や一部実施なら、その状態と対応の計画
5. 根拠文書：規程、手順書、設定の記録、委託先との契約など

適用範囲・必要性・実施状況を分ける

SoAで迷いやすいのは、「適用範囲に入っているか」「その管理策が必要か」「実際に実施しているか」を混ぜてしまうことです。必要な対策をまだ実施できていない場合は、適用しないことにはせず、未実施として担当と期限を付け、リスク対応計画で進めます。除外する場合の理由は、「対象が存在しない」の一種類とは限らず、リスクや対象の実態から説明します。

クラウドサービスの提供者や委託先が認証を取得していても、それは提供者側の管理を示すものです。自社が行う設定、端末やアカウントの管理、委託先の選定と管理は、自社の範囲として確認します。次の表は、在宅勤務・クラウド事業者の設備・自社のSaaS設定の3つを想定した記入例です。該当する管理策の番号は、附属書Aと自社の管理策を照らし合わせて決めます。

更新のタイミング

SoAは、作成した後も次の場合に見直します。組織変更や新しいSaaSの導入で適用範囲や管理策が変わったとき、リスクアセスメントを再実施したとき（あらかじめ定めた間隔、または重大な変更のとき）、重大なインシデントが発生して対策を追加したときです。未実施だった管理策を実施したときも、実施状況を更新します。更新履歴（版数・日付・変更理由）を文書内に残します。

認証は、取得までよりも取得後の維持の期間のほうが長くなります。初回審査の後も、年1回以上のサーベイランス審査と、3年ごとの再認証審査が行われます（ISMS-AC）。社内の活動は、審査の時期とは別に、リスク・変更・法令や契約の義務に応じて計画します。運用が止まりやすいのは、担当者が交代するときと、初回審査の翌年です。次の表は、計画の一例です。

内部監査の実務

内部監査では、監査員を選ぶときに、監査の客観性と公平性を保つことが求められます（JIPDEC ISMSユーザーズガイド、9.2、本文p.66）。自分が担当する業務を自分で監査すると、見落としや利害の偏りが生じやすいため、部門間の相互監査や外部の監査員の活用などで体制を組みます。小規模な組織で完全に独立した監査員を置けない場合も、偏りを減らす工夫をします。確認するのは、ルールどおりに運用されているか、規格の要求を満たして有効に続いているかです。具体的には、アクセス権の棚卸し記録、入退社時のアカウント処理、教育の受講記録、インシデント報告の記録といった日付の入った証拠を見ます。

形骸化を防ぐ運用

審査の直前にまとめて記録を作る状態になったら、規程と実務がずれている可能性があります。規程どおりに運用できていないことは不適合にあたるため（同ガイド、10.2、本文p.71〜72）、まず原因と影響、満たすべき規格・法令・契約の要求を確かめます。そのうえで、運用を規程どおりに是正するか、要求を満たしたまま実際に運用できる手順へ規程を改めるかを判断します。どちらの場合も、変更を記録して周知し、是正の効果を確かめます。過去の記録を後から作ったり、要求を満たさない形にルールを緩めたりして、ずれを解消したことにはしません。

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