【経営層に伝わる】NIST IR 8286で学ぶ「セキュリティ＝事業リスク」の説明技法
「セキュリティの話をするな」
ある経営会議で、CISOがそう言われた。予算申請のプレゼンを準備して、脆弱性の数も、攻撃の傾向も、対策の必要性も丁寧に説明したのに。
返ってきたのは「で、結局いくら損するの？」という一言だった。
この光景、見覚えがある人は多いと思う。セキュリティの「技術的な正しさ」と、経営層が求める「事業への影響」の間には、深い溝がある。その溝を埋めるためのフレームワークが、NISTから出ている。NIST IR 8286だ。
経営層と「言語」が違う問題
セキュリティ担当者が経営層に説明するとき、よくある失敗パターンがある。
技術的な正確さを追求しすぎる。「CVSSスコア9.8の脆弱性が3件」と言っても、経営層には響かない。彼らが知りたいのは「それで何が起きるのか」「いくらかかるのか」「放置したらどうなるのか」だ。
逆に言えば、セキュリティリスクを「事業リスク」として語れれば、経営層との対話は一変する。予算も通りやすくなるし、優先順位の議論もしやすくなる。
問題は、その「翻訳」の方法を体系化したものが少なかったこと。
NIST IR 8286シリーズの全体像
NISTが2020年から発行しているIR 8286シリーズは、まさにこの「翻訳」のためのフレームワークだ。2025年12月にRev.1として改訂され、シリーズ全5文書が更新された（うち3文書は全面改訂、2文書は軽微な修正）。特にCSF 2.0で新設されたGOVERN機能（組織全体でサイバーセキュリティの方針・役割・責任を定義し、経営層の関与を明確化する機能）との整合が強化され、サイバーセキュリティを経営の意思決定プロセスに組み込む仕組みが明確化されている。
シリーズは5つの文書で構成されている。
| 文書 | 役割 | ひとことで言うと |
|---|---|---|
| IR 8286 | 統合の全体像 | CSRMとERMをつなぐ設計図 |
| IR 8286A | リスクの特定・推定 | 「何が危ないか」を洗い出す |
| IR 8286B | リスクの優先順位付け | 「どれから対処するか」を決める |
| IR 8286C | ガバナンスとCSRMの双方向統合 | 経営層がCSRM活動を指導し、結果がリスク許容度の調整にフィードバックされる仕組み |
| IR 8286D | ビジネスインパクト分析 | 「事業への影響」を数値化する |
注目してほしいのは、IR 8286Cの存在だ。単なる「報告方法」ではなく、ガバナンス構造がCSRM活動を指導し、その結果が経営層にフィードバックされて戦略やリスク許容度の調整に活かされる——この双方向のループを設計している。NISTがセキュリティと経営の「対話」を重視している証拠だ。
核心コンセプト: CSRM → ERM統合
IR 8286の核心は、CSRM（サイバーセキュリティリスク管理）をERM（全社的リスク管理）に統合するという考え方にある。
以下の図で、CSRMからERMへの情報の流れを確認してほしい。
ポイントは「ロールアップ」という概念だ。
現場のセキュリティチームが把握している個別のリスク情報を、組織レベル、そして全社レベルへと集約していく。このとき、技術的な詳細は抽象化され、「事業への影響」という共通言語に翻訳される。
従来、セキュリティ部門は「自分たちの領域」の中で完結しがちだった。IR 8286は、セキュリティを経営アジェンダの一部として位置づけ直す。これが「統合」の意味だ。
CSRR: 翻訳の実装
では、具体的にどう「翻訳」するのか。その実装がCSRR（Cybersecurity Risk Register: サイバーセキュリティリスクレジスター） だ。
CSRRとは、識別されたリスクを一覧化した台帳のこと。IR 8286では、以下の要素を含めることを推奨している。
| 項目 | 内容 | 経営層への訴求ポイント |
|---|---|---|
| リスクシナリオ | 「何が起きうるか」の具体的な記述 | ストーリーとして理解しやすい |
| 影響度 | 事業への影響（財務・評判・法的） | 「いくら損するか」に直結 |
| 発生確率 | 年間発生確率の推定 | 「本当に起きるのか」への回答 |
| 現状の対策 | 既存のコントロール | 「何もしてないのか」への回答 |
| 残留リスク | 対策後も残るリスク | 受容の判断材料 |
| 推奨対応 | 追加対策の提案 | 予算申請の根拠 |
具体例: ランサムウェアリスクの表現
技術的な言い方と、事業リスクとしての言い方を比較してみる。
技術的な表現（Before）:
「RaaSによる標的型ランサムウェア攻撃のリスクがあります。EDRの検知率は約85%で、15%は初動で見逃す可能性があります。バックアップは日次で取得していますが、RTOは48時間です」
経営層の反応:「で、結局どうなの？」
事業リスクとしての表現（After）:
| 項目 | 内容 |
|---|---|
| リスクシナリオ | 製造ラインの制御システムがランサムウェアに感染し、生産停止 |
| 影響度 | 1日あたり売上損失: 約2億円 / 評判への影響: 顧客離れリスク |
| 発生確率 | 年間15%（※下記「発生確率の考え方」参照） |
| 現状の対策 | EDR導入済み、日次バックアップ |
| 残留リスク | 復旧に最大48時間。その間の損失は約4億円 |
| 推奨対応 | オフラインバックアップ追加（年間費用: 3,000万円※）＋復旧訓練の実施でRTOを4時間に短縮目標 |
※費用は企業規模・データ量により大きく異なる。RTO短縮には、バックアップ導入だけでなく復旧手順の整備と定期的な訓練が前提となる。
経営層の反応:「4億円のリスクを3,000万円で4時間に短縮できるなら、やろう」
同じリスクでも、伝え方で判断のしやすさが全く変わる。
発生確率の考え方
正直に言えば、発生確率の「正確な数値」を算出することは困難だ。
理由はシンプルで、公開統計（警察庁の2024年は222件など）は「報告された被害」のみであり、実態は氷山の一角だからだ。
では、どうするか？
経営層への説明では、「正確な確率」よりも判断できる粒度で示すことが重要。以下のアプローチを推奨する。
アプローチ1: 定性評価（高・中・低）
| 評価 | 目安 | 判断材料の例 |
|---|---|---|
| 高 | 同業他社で直近1年以内に被害あり | 業界レポート、ニュース、IPA注意喚起 |
| 中 | 業界で被害報告あり、自社も対象となりうる | 攻撃グループの標的業種、サプライチェーン上の位置 |
| 低 | 直接的な脅威情報なし、対策も整備済み | 脆弱性対応状況、セキュリティ投資水準 |
アプローチ2: レンジで示す
「年間発生確率は5〜20%と推定。同業他社の被害状況、自社のVPN/RDP対策状況を踏まえると、当社は中〜高リスクと判断」
経営層が本当に知りたいのは:
- 「うちも狙われるのか？」 → 業界・規模・サプライチェーン上の位置
- 「放置したらどうなる？」 → 影響度（停止日数×日次損失）
- 「対策したらどう変わる？」 → 残留リスクの低減効果
確率の精度を追求するより、上記3点に答えられる準備をしておく方が実践的だ。
リスク分析方法論の選択肢は、IR 8286A（Identifying and Estimating Cybersecurity Risk）で紹介されている。
CSRRの書き方がわかったところで、次は「どう導入を進めるか」を見ていこう。
日本企業での活用
「NISTは米国の標準でしょ？」という声が聞こえてきそうだ。
実は、経済産業省の「サイバーセキュリティ経営ガイドライン Ver.3.0」は、NIST CSFとの対応関係を付録で明示している。IR 8286はCSFと整合するリスク管理フレームワークであり、どちらも「経営者のリーダーシップ」と「リスクベースのアプローチ」を重視している点で親和性が高い。
日本企業での導入ステップとしては、以下が現実的だ。
Step 1: CSRRの作成から始める（目安: 1〜2週間）
いきなり全社統合を目指すと挫折する。まずは自部門のリスクを「事業言語」で整理するところから。上の表のフォーマットを参考に、事業インパクトが大きい主要なリスクシナリオを3〜5個書き出してみる。
Step 2: 既存のリスク管理プロセスとの接続（目安: 1〜2ヶ月）
多くの企業には、すでにERMの仕組みがある（形骸化していることも多いが）。CSRRを、その枠組みの中に位置づける。「サイバーリスク」という新しいカテゴリを追加する形が取りやすい。既存のリスク所管部門との調整が必要になるため、非公式な根回しから始めるのが現実的だ。
Step 3: 経営報告資料への組み込み（目安: 四半期ごと）
四半期報告や取締役会資料に、CSRRのサマリーを入れる。最初は「情報共有」レベルでいい。継続的に報告することで、経営層の理解も深まる。
「翻訳」しても通らなかったら？
正直に言えば、事業リスクとして説明しても予算が通らないことはある。経営層が短期利益を優先したり、「そのリスクは受容する」という判断を下すこともある。
そのとき大事なのは、意思決定を文書化しておくことだ。
「このリスクについて報告し、経営層は○○の理由でリスク受容を選択した」と記録しておく。これは責任転嫁ではない。次回の報告時に「前回は受容としたリスクですが、状況が変化しました」と議論を再開できる。そして万が一インシデントが発生したとき、「警告はしていた」という事実が残る。
「翻訳」は魔法ではない。でも、少なくとも議論のテーブルには載る。それだけでも、技術の話しかできなかった頃とは大きな違いだ。
まとめ
3つのポイントを整理する。
-
セキュリティと経営の「言語の壁」は構造的な問題。技術的に正しい説明が、経営判断に使えるとは限らない。
-
NIST IR 8286は「翻訳」のフレームワーク。CSRMをERMに統合し、セキュリティを経営アジェンダの一部にする。
-
CSRRが「翻訳」の実装。「いくら損するか」「どれくらい起きるか」を、経営層が判断できる形で提示する。
最初のCISOに話を戻そう。
「セキュリティの話をするな」と言われた彼は、次の会議で「事業リスクの話」をした。ランサムウェアで生産ラインが止まったら何億円の損失になるか。その確率はどれくらいか。対策にいくらかかり、どこまでリスクを下げられるか。
予算は通った。
あなたのチームでも、同じ「翻訳」ができるはずだ。
Discussion