火曜日は「3年の階段」で、今年やることと“やらないこと”を決める話をしました。

でも、現場で必ず起きるのがこれです。

「新サービスを来月リリースしたいのに、セキュリティチェックで2ヶ月待てって言われた」
「セキュリティは大事だけど、売上が落ちたら会社が潰れる」

セキュリティ側は「危ないから待て」と言い、事業側は「待てない」と押し返す。
この対立構造が続くと、セキュリティは“仕事の邪魔をする部署”になり、やがて無視されるようになります。

今日は、この構造を変える「リスクを共通言語にした調整術」の話をします。

目次 [ close ]
  1. なぜ「セキュリティvs事業」になるのか
  2. 「リスク」を数字と言葉に翻訳する
  3. リスクマトリクス（簡易版）
  4. 「待ってもらう」のではなく「分割する」
  5. 段階リリース（コピペ用テンプレ）
  6. 「リスク受容」という経営判断を明文化する
  7. リスク受容メモ（Slack 1行テンプレ）
  8. 今週やること（60分でできる）
  9. 問いかけ
  10. 参考資料（リンク）

なぜ「セキュリティvs事業」になるのか

問題の根っこは、判断基準が違うことです。

  • セキュリティ：「事故が起きたら会社が終わる」という最悪ケースから考える
  • 事業：「今月の目標を達成しないと予算が削られる」という短期の確実性から考える

どちらも正しいのに、話が噛み合わない。

だから、「どっちが正しいか」ではなく、「どのリスクをどこまで取るか」を共通の土俵で話す必要があります。
NIST CSF 2.0も、経営層と現場の“双方向”コミュニケーションで、優先順位と資源配分をリスクとして合意することを重視しています。​

「リスク」を数字と言葉に翻訳する

セキュリティの人間が「危ない」と言っても、事業側には伝わりません。
逆に、「このリスクは、最悪で◯◯万円の損失と、◯日間の業務停止につながります」と言えば、経営判断ができます。

使えるのは、シンプルな「リスクマトリクス」です。
リスクを「発生確率（Likelihood）」と「影響（Impact）」で見て、マトリクスで優先順位を決める考え方は、NIST SP 800-30の解説でも一般的に用いられます。​

リスクマトリクス（簡易版）

影響度＼発生確率高中低
致命的（全社業務停止、法的責任）即対応即対応3ヶ月以内対応
重大（一部業務停止、顧客影響）即対応1ヶ月以内対応半年以内対応
軽微（限定的影響）1ヶ月以内対応半年以内対応監視のみ

この表を使って、こう言い換えます。
「今回の新サービスは個人情報を扱うので『影響度：重大、発生確率：中』に該当します。つまり1ヶ月以内の対応が必要です」

ここまで落とすと、セキュリティは“感情”ではなく“判断材料”になります。

「待ってもらう」のではなく「分割する」

セキュリティチェックで2ヶ月待て、と言うと事業は止まります。
でも、「リリースは予定通り。ただし個人情報の機能だけは2週間後に追加でリリース」という分割案なら、双方が動けます。

これは「段階リリース」の考え方です。

  • フェーズ1：限定ユーザー、限定機能でスタート（リスクを小さくして早く出す）
  • フェーズ2：セキュリティチェックを並行して進め、OKが出たら全ユーザーに拡大
  • フェーズ3：個人情報や決済など、高リスク機能を追加

「全部ダメ」ではなく、「ここまでならOK」を出せるセキュリティチームは、事業に信頼されます。

段階リリース（コピペ用テンプレ）

  • フェーズ1で出す範囲：＿＿＿＿（データ種別／対象ユーザー／権限）
  • フェーズ2の拡大条件：＿＿＿＿（MFA必須、監査ログ保全、脆弱性診断完了 など）
  • フェーズ3の解禁条件：＿＿＿＿（個人情報、決済、外部連携 などの要件）

「リスク受容」という経営判断を明文化する

重要なのは、セキュリティが全部を止める責任を負わないことです。

  • セキュリティチームは「このリスクがあります」と提示する
  • 事業責任者と経営が「それでも進める」と判断する
  • その判断を文書（メールやSlackでもOK）で残す

NIST CSF 2.0は、リスク対応として「mitigating（低減）」「transferring（移転）」「avoiding（回避）」「accepting（受容）」などを挙げ、影響や発生可能性を踏まえて選ぶ考え方を説明しています。​
「受容」は“放置”ではなく、認識した上で選ぶ経営判断にします。​

リスク受容メモ（Slack 1行テンプレ）

「（案件名＿＿＿）について、（リスク＿＿＿）を認識の上、（判断者＿＿＿）の判断で（期限＿＿＿）まで事業優先で進めることを承認します。代替策／次の見直し条件：＿＿＿」

この1行があるだけで、次回から「セキュリティが待てと言った」ではなく、「リスクを共有して、どう進めるか一緒に決めた」に変わります。

今週やること（60分でできる）

次に事業側から「急ぎでリリースしたい」という相談が来た時のために、準備をしておきます。

  • リスクマトリクスの簡易版を1枚作る（影響度定義を自社用に具体化、例：致命的＝顧客情報100件以上漏洩 など）
  • 「段階リリース」のテンプレを用意（フェーズ1で出せる範囲／フェーズ2で追加できる条件を2〜3行で）
  • 「リスク受容」の文書フォーマットを決める（承認1行テンプレ、誰が承認できるかまで）

問いかけ

直近で「セキュリティvs事業」の対立が起きた案件、ありましたか？
その時、「リスクの大きさ」と「誰がそのリスクを受け入れるか」は明文化されていましたか？

もし曖昧だったなら、次回はリスクマトリクスを1枚持っていくだけで、会話の質が変わります。
セキュリティは“止める人”ではなく、“リスクを見える化して、経営判断を助ける人”です。

来週の火曜日は、「クラウドとオンプレの共存期」をどう乗り切るか、という現実的な移行戦略の話をします。

参考資料（リンク）