連載第1回「日本企業のデジタルレジリエンス能力の現在地」では、NRIが2025年に日本企業366社に対して実施した「デジタルレジリエンス能力の実態調査」の結果から、デジタルレジリエンスの成熟度が「レベル2（プロジェクトやチーム内でのルールや手順が一部存在するが、組織全体で標準化されていない状態）」に留まっている実態をお伝えしました。その中でも特筆すべきは、ランサムウェア対策の最後の砦となる「バックアップ・リカバリ」において、約35%の企業が組織的なルール・手順化ができていないという事実です。

ランサムウェア対策というと、EDR（Endpoint Detection and Response）や監視サービスの導入といった「防御」に目が向きがちです。しかし、侵入を100%防ぐことが不可能な現在、真に問われているのは「倒れても、決められた時間内に起き上がる力」、そして「システム停止中も最低限の業務を継続する力」、すなわち、レジリエンスの獲得が求められているのです。

レジリエンスの獲得に向けて、私たちはランサムウェア攻撃を想定したサイバーBCP（事業継続計画）の整備を推奨しています。
「うちはBCP（事業継続計画）策定済みだから大丈夫」
そう考える経営者や担当者の方も多くいらっしゃいます。しかし、現実にランサムウェア被害に遭った企業の多くが、長期間のビジネス停止に追い込まれています。そして、その中には既にBCPを整備している企業も含まれています。なぜ、BCPを策定しているにもかかわらず、現場は大混乱し、事業は止まってしまうのでしょうか？今回は、その原因を「ビジネス（業務）」と「IT（システム）」の断絶という観点から紐解き、真に機能するBCPの構築手法について解説します。

多くの日本企業が整備しているBCPは、主に地震や水害などの「自然災害」を想定しています。自然災害対策では、データセンターの免震対応や遠隔地へのバックアップ（DR対策）によって、「物理的に拠点を分散させれば、システムやデータは守られる」というアプローチが有効でした。被災していないデータセンターへ切り替えることで、多くの場合、数時間から数日程度でシステムを復旧できます。
しかし、ランサムウェア攻撃を受けた際の復旧においては、この前提は通用しません。攻撃者はネットワークを通じてシステム深部に侵入し、データそのものを暗号化したり、バックドア（不正な侵入経路）を設置したりします。たとえサーバや通信機器が物理的に無事でも、「攻撃者がまだネットワーク内に潜んでいるかもしれない」「バックアップデータも汚染されているかもしれない」というリスクが残るのです。このリスクがあるために、ランサムウェア被害からの復旧は自然災害と比較にならないほど長期化します。具体的には、以下の3つの工程が必要となり、それぞれに時間を要します。

• 侵害範囲の特定（フォレンジック）：攻撃者がどこまで侵入し、何を改ざん・窃取したかを調査する
• バックアップデータの安全性検証：復元に使用するデータにマルウェアが潜伏していないかを確認する
• 段階的な復元と再発防止措置：検証済みのデータから順次復元しながら、再侵入を防ぐ対策を講じる

これらの工程を経なければ、復旧したシステムが再び感染するリスクがあります。そのため、自然災害のように「バックアップからすぐに書き戻す」という迅速な復旧は行えません。結果として、ビジネス停止が数週間から数ヶ月に及ぶケースも珍しくありません。
このように「システムが長期間使えない」ことが前提となるランサムウェア対策においては、「システムをどう復旧させるか」以上に、「システムの復旧を待たずにどうやって業務を継続させるか」という代替手段の整備が、自然災害以上に重要になるのです。

企業の業務継続に関わるリスクとしては、自然災害やランサムウェア被害以外にも、パンデミックなど多種多様なものが存在します。各企業の事業環境を踏まえ、リスクに応じたBCPが求められます。ランサムウェア被害に対しても、その特性を踏まえた専用のBCPが必要なのです。

全社としてのBCP（以下、全社BCP）に加え、IT部門はIT-BCP（情報システム運用継続計画）を整備することが推奨されます。全社BCPは、自然災害やサイバー攻撃による被害などの緊急事態において、企業の中核事業を中断させない、または早期に復旧させるための計画です。目的は、企業活動の継続です。それに対して、IT-BCPは、ITサービスを目標時間内に復旧させることを目的とした計画で、全社BCPの一部として機能します。業務が情報化されてきた歴史を踏まえると必然ではありますが、IT-BCPの考え方自体は古く、2008年には経済産業省から「ITサービス継続ガイドライン」も公表されています。しかしながら、全社BCPとIT-BCPは所管部門が異なることが多く、密に連携されていないことも散見されます。

ビジネス部門は「ランサム攻撃を受けてもこのシステムは使えるだろう。システムが止まったらIT部門がなんとかしてくれるだろう」と考え、一方、IT部門はビジネス上の優先順位を考慮しないまま、システムを復旧することだけを考えてしまいがちです。このような事態を招かないためにも、全社BCPとIT-BCPが互いの前提条件を共有・連携し、実効性の高いBCPを整備する必要があります。中でも、ランサムウェア被害に対する対応では、両者の連携が不可欠です。

では、なぜこのような連携不足が生じるのでしょうか。
それは、背景にビジネス側とIT側それぞれに「盲点」があるからです。つまり、互いの前提条件が共有されていないことで、「復旧にかかる時間」と「業務が許容できる停止時間」の間に大きなギャップが生まれているのです。

ビジネス側の盲点：「IT部門ならわかっているはず」という思い込み

ランサムウェア攻撃ではシステムが被害を受けます。そのため、「システムのことはIT部門の領域だ」という意識から、ビジネス部門はランサムウェア対策の検討において受動的な姿勢になりがちです。たとえば「この業務は24時間以上止められない」「このデータがなければ顧客対応ができない」といった、自分たちの業務要件を、IT部門に能動的に伝えようとしないのです。
「IT部門なら、業務のことも理解しているはずだ」「重要なシステムは優先的に復旧してくれるだろう」こうした思い込みが、認識のギャップを生みます。特に問題となるのは、復旧時間に対する期待値のずれです。ビジネス側は「24時間以内に業務再開が必要」と考えていたとしても、それをIT部門に伝えていなければ、IT部門は技術的に現実的な「1週間」という前提で計画を立てます。結果として、有事の際に「なぜこんなに時間がかかるのか」「そんな要件は聞いていない」という衝突が起き、復旧が混乱します。

また、ビジネス側で「システムが止まったら紙で対応する」とシステムの停止を織り込んだ計画を立てていたとしても、実際には顧客データも在庫データも全て暗号化され、紙伝票すら発行できず、現場が立ち尽くすことになります。具体的な被害の影響範囲をビジネス部門とIT部門とすり合わせなくてはなりません。

ビジネス部門がBCPを検討する際には、IT部門と認識を合わせて策定することが肝要です。

IT側の盲点：目的が「業務継続」ではなく「システム復旧」になっている

災害対策を含めたIT-BCP全般の課題ですが、IT部門の意識が「いかに早くシステムを元の状態に戻すか（システム復旧）」に集中しすぎてしまう傾向があります。IT-BCPは、ITサービスを目標時間内に復旧させるための計画であるため、一見正しいことのようにも思えますが、その計画が業務継続と直結していなければ、企業経営の観点からは目的から逸れていると言わざるを得ません。

自然災害の場合、DRサイトへの切り替えによってシステム全体が比較的早期に復旧するため、この考え方でも大きな問題にはなりにくいと言えます。しかし、前述の通り、復旧が長期化しやすいランサムウェア被害において、この「システム復旧だけに集中してしまうこと」は致命的です。安全確認のためにシステム再開まで1ヶ月かかると判明した時、「システムが直るまで業務も全て止める」という判断は、企業の存続に関わります。
この時、本来の目的である「事業を止めないこと（業務継続）」に立ち返れば、「システム画面は開かなくてもいい、顧客データさえあればアナログで商売ができる」という判断ができるはずです。
しかし、目的を見失っていると、「システム復旧を待たずに、データベースからCSVデータだけを抽出する」といった泥臭い緊急避難措置の発想が出てこず、ひたすらシステムの完全復旧を待ち続けることになってしまいます。

IT部門がBCPを検討する際には、業務継続と直結した計画とすることが何よりも重要です。

では、実効性のある計画にするにはどうすればよいのでしょうか。
その答えは、ビジネス部門とIT部門が情報を相互連携させながら同時並行で検討を進め、段階的に完成度を高めていくアプローチ（アジャイル型アプローチ）にあります。
そして、計画策定をゴールとするのではなく、そこから導き出された要件をもとに「具体的なシステム対策」と「詳細手順の整備」へ落とし込むことが重要です。

BCP整備の進め方は企業の置かれた状況によって様々ですが、以下の4フェーズに分けて検討を進めることが多いです。

Phase 1：全社BCPとIT-BCPの並行策定

ランサムウェア攻撃を受けた際の影響範囲・被害シナリオについて、ビジネス部門とIT部門が早期に前提条件をすり合わせて、同時に全社BCPとIT-BCPの「初版」作成に着手します。
全社BCPでは、ビジネス側が「どの重要業務をいつまでに復旧させるか」を定めます。業務視点での復旧目標を定義することが重要です。一方、IT-BCPでは、「システムやデータをどうやって復旧させるか」を定めます。ランサムウェア被害を想定し、希望的観測を排除した現状の構成における「復旧時間の実力値」や「被害シナリオ」を整理します。
この段階で、お互いに初版を見せ合い、「ビジネスが求める目標」と「ITの対応力」の間にどのような乖離があるかを早期に共有することがスタートラインです。

規模の大きな企業であれば、整備対象となる業務・システムの数も多く、どうしてもBCPの策定に時間がかかります。そのような場合は、対象となる業務・システムを絞ってスモールスタートすることが有効です。範囲を絞って、BCP策定の型を作り上げることで、その他の業務・システムを対象にする際に、効率よく整備を進めることができます。

Phase 2：対策具体化と全社BCP・IT-BCPのブラッシュアップ

Phase 1で共有されたIT側の対応力をもとに、各現場部門がランサムウェア攻撃を受けシステムが停止した際の「個別業務継続手順」の検討に入ります。現場が代替手段を検討する過程で、「システムは止まっていても、業務を回すためには『顧客リスト』と『在庫データ』だけは絶対に必要だ」といった、具体的な「重要データ」が特定されます。
もし、現状のIT側の計画ではそのデータがすぐに取り出せない場合、ビジネス部門とIT部門の間で調整（ギャップの解消）を行います。具体的には、ビジネス側では、業務の縮退レベルを下げることや代替手段の見直しを行い、全社BCPを修正します。IT側は、業務継続上の要求に応えるための対策の実施や復旧手順の見直しなどを行い、IT-BCPを修正します。具体化のプロセスで判明した要件を双方の計画へフィードバックし、実態に合わせて改訂・ブラッシュアップしていくことが重要です。

Phase 3：システム点検・対策と業務復旧手順整備

計画を作って終わりではありません。ここからが実質的なレジリエンス強化のフェーズです。
策定されたIT-BCPには、「RTO（目標復旧時間）24時間」「バックアップは改ざん不可」といった具体的な「要件」が定義されているはずです。この要件を基準として既存システムを改めて点検し、「システム対策」と「手順」の両面から具体化を進めます。
「システム対策」では、現状システムとのギャップを技術的に検証します。「現在のバックアップ構成で、本当に定義したRTOを守れるか？」「バックアップデータはネットワークから論理的に切り離されているか？」といった観点から点検し、必要な機器の導入や設定変更といった具体的な対策を行っていきます。ランサムウェア被害へのシステム対策としては、イミュータブルバックアップ（書き換え不可能なバックアップ）などが挙げられますが、そもそもシステムの作りが悪く、抜本的なシステムの再構築が必要となるケースも出てくる場合もあります。比較的軽微な対策はすぐに実行に移し、軽微ではない対策はシステム更改時に対応するなど、企業の体力に応じて計画を立てて対策を推進します。
「手順」は、IT-BCPの方針に基づき、システムごとの「個別システム復旧手順書」を整備します。「どのサーバから順に起動するか」「リストアには具体的にどのコマンドを使うか」といった、システム運用担当者が迷わず作業できるレベルの手順に落とし込みます。

このように、攻撃に耐えうるシステムと、それを動かす具体的な手順が揃って初めて、「絵に描いた餅」ではないレジリエンスが獲得できます。

整備範囲の拡大

最初から全業務・全システムを対象としたBCPを完璧に作る必要はありません。前述の通り、スモールスタートによる段階的な整備も有効です。まずは事業影響度が極めて高い「最重要業務・システム」に絞ってPhase 1～3を回し、初版を完成させることが一般的です。
最重要業務・システムに関わる整備について一通りの整備が完了したら、次は準主要業務へと対象範囲を拡大し、計画の具体性と網羅性を高めていきます。また世の中の脅威動向を考慮して、前提となる被害シナリオや被害想定のパターンの修正や追加を行い、関連する計画・手順の改訂を行います。このアジャイル型アプローチこそが、変化の速いサイバー攻撃の脅威に対応する現実的な手段です。

今回ご紹介したように、業務BCPとIT-BCPを連携させ、復旧能力のギャップを埋めていく取り組みは、一朝一夕にはいきません。しかし、これを行わずして「想定外でした」では済まされないのが現在の経営環境です。ぜひ、自社のBCPが「サイバー攻撃」という現実の脅威に対してビジネス部門とIT部門が連携して対策できているか、再点検してみてください。

さて、今回ご紹介したのは、企業の業務オペレーションに関わるレジリエンス強化の一例です。しかし、そもそもシステムやサービスそのものが「攻撃を受けやすい」「被害が広がりやすい」作りになっていたとしたらどうでしょうか？
次回、連載の第3回では、サービス設計（仕様）レベルでのレジリエンス強靭化の事例と対策について深掘りしていきます。