ランサムウェアは暗号化による業務停止に加え、窃取情報の公開を盾にする二重恐喝も一般化しています。ですが、支払いは復旧や漏えい回避を確約する手段ではありません。復号鍵が機能しない、復旧に時間がかかる、後日データが流出する、支払う企業として再標的化される、といったリスクが残ります。
さらに支払いは攻撃者の資金源を増やし、攻撃の連鎖を助長します。短期的な損失回避に見えても、中長期で不確実性と追加コストを積み上げやすい点を経営に説明できる状態が重要です。
現場が支払いに傾く背景には、技術だけでなく事業側の制約があります。RTO/RPOが曖昧なままだと、被害時に「とにかく早く戻す」圧力が意思決定を支配します。バックアップがあっても暗号化されていたり、復旧手順が検証されていなかったりすると、選択肢が狭まります。
また封じ込めが遅れ、復旧の最中に再暗号化されると被害は急拡大します。侵入経路の遮断、特権IDの無効化、ネットワーク分離などの初動が遅れるほど、経営判断は誤りやすくなります。
危機対応は感情ではなく手順で動かす必要があります。まず被害範囲（暗号化・窃取・特権侵害）を見極め、横展開を止めた封じ込め状況を確認します。次にバックアップの健全性と復旧時間を見積もり、法務・規制・契約・保険・説明責任の論点を並行整理します。
特に「侵害が継続している状態」での支払いは、復号しても再暗号化される可能性が高く最悪の投資対効果になり得ます。封じ込め、証拠保全、復旧設計の順序を崩さない体制化が要点です。
侵入を前提に「止める・戻す」を設計します。3-2-1（オフライン/イミュータブル含む）を前提に、定期的な復旧テストで復元可能性を担保します。VPNや管理画面など主要経路のMFA、特権IDの常用禁止と監査ログも必須です。
加えて、認証基盤・バックアップ基盤・重要サーバの分離で横展開を抑止し、EDR/SIEMとIRプレイブックで初動速度を高めます。委託先・子会社の踏み台化を想定し、MFAや報告SLAなどの要求事項を契約と点検に落とし込みましょう。
