セキュリティ対策の候補は増え続けます。脆弱性診断、EDR、ログ監視、バックアップ、認証強化、教育、委託先管理など、 どれも必要に見える一方、予算、人材、停止できる時間には限りがあります。そのため、対策項目を並べて未実施のものから埋めるだけでは、 自社にとって何を先に守るべきか、経営者がどの残存リスクを引き受けるのかを説明しにくくなります。

IPAが2026年4月に公開した「プラクティス・ナビ」のプラクティス4-1は、経営層や事業部門との討議を通じて重要な情報やシステムを特定し、 攻撃手法や脆弱性の情報と組み合わせ、リスクの高い組み合わせから対策する実践例を示しています。 同じくプラクティス3-1は、必要な追加対策、優先度、概算費用を経営会議へ継続的に報告する考え方を紹介しています。

NIST IR 8286 Rev.1も、サイバーセキュリティリスクを企業のミッションや事業目的の文脈で扱い、 リスク登録簿を通じて全社的リスク管理へ接続することを重視しています。 本記事では、チェックリストを否定するのではなく、チェック結果を事業影響に結び付け、限られた資源の配分を判断する方法を整理します。

具体的な課題：対策数は増えても、優先順位の理由が見えない

チェックリストは抜け漏れの確認に役立ちます。しかし、すべての項目を同じ重みで扱うと、 事業停止や重要情報の毀損につながるリスクと、影響が限定的なリスクが同じ一覧に並びます。 その結果、現場は対策数を増やし、経営は費用だけを見て判断するという分断が起こりやすくなります。

  • 資産棚卸しが終わらない：すべての機器やデータを同じ粒度で洗い出そうとして、重要業務の議論まで進めない。
  • 脅威だけで順位が決まる：話題の攻撃手法へ反応する一方、自社で被害が生じた場合の事業影響を確認していない。
  • 製品導入が目的になる：「何を買うか」は説明できても、どの損失シナリオをどこまで減らすかが曖昧である。
  • 残存リスクが見えない：対策後にも残るリスク、例外、未承認施策、外部依存が経営判断へ上がらない。
  • 見直しの契機がない：新サービス、組織変更、委託先変更、インシデント後も、古い優先順位が使われ続ける。
優先順位は「未実施項目の多さ」ではなく、「守るべき事業成果に対して、どのリスクをどこまで下げるか」で決めます。

考え方：事業目的から残存リスクまでを一本につなぐ

NIST IR 8286Dは、事業影響分析（BIA）を可用性だけでなく、機密性や完全性を含む損失へ広げ、 重要な事業機能を支える資産と、損失シナリオを結び付ける考え方を示しています。 実務では、次の五つを一つの意思決定単位として扱うと、技術と経営の会話をつなぎやすくなります。

  1. 事業目的：何を継続・達成できることが重要か。
  2. 事業影響：停止、漏えい、改ざんが起きたとき、顧客、売上、契約、信用、業務へ何が起こるか。
  3. リスクシナリオ：どの脅威が、どの弱点や依存関係を通じて影響を生むか。
  4. 対応策：回避、低減、移転、受容のうち、どの組み合わせを選ぶか。
  5. 残存リスク：対応後に何が残り、誰が、いつまで、どの条件で受け入れるか。

リスク値は判断を補助する道具であり、精密な将来予測ではありません。 相対的な重要度、発生可能性、現行対策の有効性を同じ基準で比較し、根拠と不確実性を残すことが重要です。

実践手順1：重要な事業成果から対象を絞る

最初から全資産を同じ深さで評価せず、経営層、事業責任者、情報システム、セキュリティ、法務・コンプライアンスなどで、 「止められない業務」「失うと回復が難しい情報」「誤ると重大な判断につながるデータ」を挙げます。 顧客への提供価値、法令・契約上の約束、主要な収益、社会的役割など、重要である理由も記録します。

その後、各事業成果を支える業務、データ、クラウド、端末、ID、ネットワーク、委託先を関連付けます。 台帳を完成させてから議論するのではなく、重要業務を起点に必要な範囲を掘り下げることで、優先順位の判断に使える粒度へ早く到達できます。

実践手順2：損失シナリオを具体的に書く

「ランサムウェアが怖い」「情報漏えいの可能性がある」といった抽象的な表現では、対策を比較できません。 主体、経路、対象、起こる変化、事業影響を一文にします。 たとえば「委託先の認証情報が悪用され、受注データが改ざんされ、誤出荷と顧客対応が発生する」のように、 技術事象から業務結果までをつなぎます。

影響は、停止時間だけでなく、機密性、完全性、可用性、安全性、顧客対応、復旧作業、取引先への波及を確認します。 金額へ換算できない場合は無理に単一数値へせず、「どの顧客に」「どの期間」「どの判断ができなくなるか」を具体化します。

実践手順3：重要度・可能性・現行対策を同じ表で比較する

各シナリオについて、事業影響の大きさ、攻撃や事故の起こりやすさ、現行対策の有効性、検知・復旧の難しさを評価します。 3段階や5段階など、説明できる単純な尺度から始め、評価根拠、情報源、評価日、担当者を残します。

IPAの実践例のように、重要な情報・システムと、攻撃手法・脆弱性の影響を組み合わせることで、 「重要だが十分に守れていない組み合わせ」を抽出します。 数式で順位を自動確定せず、重大だが低頻度のシナリオ、複数業務へ連鎖する依存関係、評価情報が不足する領域は、別途討議します。

実践手順4：対応策を事業上の選択肢として比べる

一つのリスクに一つの製品を対応させるのではなく、予防、検知、封じ込め、復旧、移転を組み合わせます。 それぞれに、期待するリスク低減、概算費用、必要人材、導入期間、業務への影響、前提条件、責任者を付けます。

  • 回避：危険な機能や接続を廃止し、リスクの原因となる活動をやめる。
  • 低減：権限分離、認証強化、監視、バックアップ、訓練などで可能性や影響を下げる。
  • 移転：契約、外部サービス、保険などで影響の一部を分担する。責任そのものが消えるとは限らない。
  • 受容：根拠、期限、監視条件、承認者を明らかにした上で残存リスクを引き受ける。

予算未承認の対策も消さず、優先度と概算費用、実施しない場合の残存リスクを継続的に経営会議へ示します。 これにより、承認・延期・代替策の選択を記録された経営判断にできます。

実践手順5：決定と残存リスクを継続監視する

リスク登録簿には、シナリオ、事業影響、所有者、現在値、目標値、対応策、進捗、残存リスク、承認者、次回見直し日を記録します。 経営向けには技術項目の件数だけでなく、重要業務別の高リスクシナリオ、期限超過、例外、予算未承認、 リスク低減後の状態を報告します。

新規サービス、M&A、クラウド移行、委託先変更、新しい脅威、インシデント、監査結果を見直しの契機にします。 対策を導入しても、設定不備や運用停止で効果が落ちることがあります。ログ、演習、復旧試験、例外利用などの実績から有効性を確認し、 優先順位と残存リスクを更新します。

注意点：リスク表を精密に見せることが目的ではない

  • 点数を事実と扱わない：評価は前提と情報に依存する。根拠、不確実性、反対意見を残す。
  • 低頻度・重大影響を落とさない：単純な掛け算だけで順位を下げず、事業存続や安全に関わるシナリオは個別に判断する。
  • 準拠と安全を混同しない：基準適合は重要だが、自社のシナリオに対する対策効果を別に確認する。
  • BIAを停止時間だけに限定しない：漏えい、改ざん、誤判断、信用、サプライチェーンへの影響も含める。
  • 受容権限を曖昧にしない：現場が事実上リスクを抱え込まないよう、影響に応じた承認者と期限を定める。
  • 制度を機械的に転用しない：NIST資料は有用な参考枠組みだが、日本企業へ一律に適用される法的義務を示すものではない。
  • 個別要件を確認する：法令、契約、業界基準、保険、会計・開示に関する判断は、関係部門や必要に応じて専門家へ確認する。

まとめ

セキュリティ投資の優先順位は、製品一覧や未実施項目だけでは説明できません。 重要な事業成果を起点に、損失シナリオ、現行対策、対応の選択肢、残存リスクをつなぎ、 誰が何を判断したかを記録することが必要です。

最初の一歩は、全社の台帳を完成させることではありません。 一つの重要業務を選び、経営・事業・ITで「何が起きると困るのか」を三つ程度のシナリオにしてください。 そのシナリオに対して、現在の守り、追加策、概算費用、残るリスクを一枚にまとめると、 セキュリティの会話を技術項目の確認から事業判断へ変えられます。

参考にした公式資料

本記事は公的資料をもとに一般的なサイバーセキュリティリスク管理の考え方を整理したものであり、 個別組織の法令適合性、契約、監査、保険、会計、開示その他の専門的判断を保証するものではありません。 公式資料は2026年8月7日時点で確認しており、実際の判断時には最新情報を確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る