ISMSリスクアセスメントのやり方｜情報資産の洗い出しから適用宣言書まで6ステップ

リスクアセスメントはISO/IEC 27001のどこに位置づくか

リスクアセスメントは、ISMSの中で「何を守るか」と「どの管理策を入れるか」をつなぐ唯一の橋です。管理策を先に決めて理由を後付けすると、審査で根拠を問われます。規格が求めているのは次の4点です。

• 箇条 6.1.2（情報セキュリティリスクアセスメント） — リスク受容基準と実施基準を定め、一貫性があり比較可能で妥当な結果を出せるプロセスにすること。リスクの特定・分析・評価と、リスク所有者の特定を含みます。
• 箇条 6.1.3（情報セキュリティリスク対応） — 対応の選択肢を選び、必要な管理策を決め、附属書Aと照合して見落としを確認し、適用宣言書（SoA） を作成すること。リスク対応計画と残留リスクは、リスク所有者の承認が必要です。
• 箇条 8.2 / 8.3 — 計画した間隔で、また重大な変化があった場合にアセスメントを実施し、対応計画を実行して、結果を文書化した情報として保持すること。
• 附属書A — 93の管理策の参照リスト。ここから選ぶのではなく、決めた管理策の抜け漏れを照合する一覧として使います。

認証取得までの全体の流れはISO27001認証取得の進め方で扱っています。着手は適用範囲の決定の直後、管理策の実装より前が定石です。

ステップ1: リスク基準（受容基準・評価基準）を先に定義する

最初に決めるのは資産ではなく基準です。基準がないまま資産を並べ始めると担当者ごとに評価がぶれ、後からすべて付け直すことになります。決めるのは、発生可能性の尺度、影響度の尺度、スコアの計算方法、リスク受容基準の4つ。中小規模の組織なら3段階で十分に運用できます。

影響度は、機密性・完全性・可用性（CIA）が損なわれたときの事業影響で測ります。「顧客データの外部流出は重大（3）」のような判断例を基準書に併記すると評価がぶれません。リスク受容基準も「スコア3以下は受容、4以上は対応を検討」のように数値で明文化します。

ステップ2: 情報資産を洗い出して資産台帳を作る

次に、適用範囲の中にある情報資産を洗い出します。対象はデータだけでなく、それを保持・処理する仕組みや、扱う人・場所も含みます。台帳には最低限、次の項目を持たせます。

粒度が分かれ目です。ファイル1本ずつ数えると数千件になって運用できず、「社内システム」とまとめると粗すぎて管理策に落とせません。目安は業務システム単位・データベース単位・共有フォルダ単位で、〜100名規模なら50〜150件程度です。資産台帳は認証で求められる文書でもあり、ISMSで必要な文書一覧と合わせて整理すると効率的です。

ステップ3: 脅威と脆弱性を特定する（資産ベースと事象ベース）

リスクの特定には大きく2つのアプローチがあり、ISO/IEC 27001:2022 はどちらも強制しません。実務では併用が現実的です。

• 資産ベースアプローチ — 資産ごとに「脅威（何が起こりうるか）」と「脆弱性（なぜ起こりうるか）」を組み合わせます。例: 顧客マスタ × 権限設定の誤り × 退職者アカウントの残存 → 不正閲覧。網羅性が高い反面、件数が膨らみやすいのが弱点です。
• 事象ベース（シナリオベース）アプローチ — 「ランサムウェアで基幹システムが停止する」のように、起こりうる事象から出発します。件数を抑えられ経営層に説明しやすい反面、抜け漏れの確認に別途チェックリストが要ります。
• 併用の型 — 資産台帳で網羅性を担保しつつ、影響の大きい事象（サプライチェーン、内部不正、災害、クラウド事業者の障害）をシナリオとして別立てで追加します。

このとき、各リスクにリスク所有者を必ず割り当てます。規格が求めているのは資産の所有者ではなくリスクの所有者で、対応方針を決め残留リスクを承認する役割です。実務上は部門長クラスです。

ステップ4・5: リスク分析と評価で優先順位を決める

ステップ1で決めた尺度を使い、各リスクに発生可能性と影響度を付けてスコアを算出します。分析では、既存の管理策が効いている状態（現状リスク）を評価するのが原則です。何も対策していない前提で評価すると、全件が最高リスクになって優先順位が付きません。

評価では、スコアを受容基準と突き合わせて対応が必要なリスクを選びます。同じスコアが並んだときは、法令・契約上の要求の有無、事業継続への影響、対応コストの順で判断します。ここまでの結果がリスクアセスメント表として残ります。

ステップ6: リスク対応の4つの選択肢と附属書A管理策の選択

対応が必要と判断したリスクごとに、次の4つから方針を選びます。すべてを低減で埋める必要はなく、受容や移転を選んだ理由が記録されていることが重要です。

適用宣言書（SoA）とリスク対応計画

方針が決まったら必要な管理策を決定し、附属書Aの93管理策と照合して見落としがないかを確認します。そのうえで作るのが適用宣言書（SoA）です。適用する管理策とその根拠、実装状況、適用しない管理策の除外理由を記載します。「適用しない」と書くこと自体は問題ではなく、理由がアセスメント結果と整合していることが必要です。

1. リスク対応の方針（低減・回避・移転・受容）をリスクごとに決定する
2. 低減を選んだリスクについて、必要な管理策を具体的に決める
3. 決めた管理策を附属書Aと照合し、見落とした領域がないか確認する
4. 適用宣言書（SoA）に、適用する管理策・根拠・実装状況・除外理由を記載する
5. リスク対応計画に、実施事項・責任者・期限・必要な資源を落とし込む
6. 残留リスクを算定し、リスク対応計画とあわせてリスク所有者の承認を得る

残留リスクの承認と見直しの頻度

管理策を入れても残るリスクが残留リスクです。再評価して受容基準の範囲内であることを確認し、リスク所有者の承認を記録に残します。承認の記録がないまま運用に入るのは、指摘されやすい典型パターンです。見直しは年1回以上を計画的に行い、加えて新システムの導入、事業所の移転、重大なインシデント、委託先の変更時に再評価します。全体の工数感はISMS認証取得の費用で整理しています。

よくある失敗と実務のコツ

• 資産を挙げすぎる — ファイル単位で数百件を超えると、年1回の見直しが回らなくなります。システム・データベース・共有フォルダ単位に丸めるのが実務的です。
• 基準が曖昧でスコアがぶれる — 「影響度：中」の判断例を書いていないと、担当者が変わった翌年に同じ資産のスコアが変わります。基準書に判断例を必ず添えます。
• SoAとリスクアセスメント表の不整合 — SoAで「適用する」とした管理策が、対応計画のどのリスクにもひも付いていないケース。両者は相互参照できる形にします。
• リスク所有者が担当者になっている — 承認権限のない担当者を所有者にすると、残留リスクの承認が形骸化します。決裁できる役割を割り当てます。

台帳とマトリクスをツールで管理する

ここまでの成果物は、資産台帳・リスクアセスメント表・SoA・リスク対応計画の4つで、いずれも相互に参照し合います。Excelでも始められますが、資産が100件を超えると、台帳の更新がSoAに反映されない、同時編集で版が分かれる、評価をいつ誰が変えたか示せない、といった問題が出てきます。

4つを同じデータとしてつなぎ、変更履歴と承認記録が自動で残る形にしておくと、年1回の見直しが棚卸しではなく差分の確認で済みます。Riscala AI for ISMS はこの形の管理を提供します。まず自社がどのステップまで進んでいるかを確かめたい場合は、ISMS現在地セルフチェックから着手状況を整理してみてください。

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