ランサムウェアは、いまや「いつか被害に遭う前提」で備える脅威になりました。中堅・大企業の被害事例が増え続け、業務停止期間が数日〜数週間に及ぶケースも珍しくありません。製造ラインの停止、医療機関の診療停止、自治体サービスの停止。事業継続そのものが揺らぐ状況に陥った組織は数多くあります。IPA「情報セキュリティ10大脅威 2026」でも、組織向けの脅威の第1位は「ランサム攻撃による被害」でした。

被害を受けたあとに「どう復旧するか」を決めるのでは遅すぎます。攻撃発生前に、業務影響の評価、復旧優先順位、バックアップ戦略、対応プロセスを整理しておくBCP（事業継続計画）の整備こそが、被害規模を左右する分水嶺になります。

本記事では、ランサムウェア被害を想定した事業継続計画の整え方を、情シスと経営層の双方の視点で解説します。被害発生から完全復旧までの標準フェーズ、復旧優先順位の設計、バックアップ戦略、訓練の実施方法まで、実務で活用できる形で整理しました。あわせて、「ランサムウェア被害後の事業継続に優れたソフトウェアはどれか」という選定の問いにも、BCPのフェーズごとに求められる要件を分解する形で答えます。復旧までの標準タイムライン表と、ツール選定のチェック項目も用意しています。

ランサムウェアとBCPの関係性

ランサムウェアとは、ファイルを暗号化し、復号と引き換えに身代金を要求するマルウェアです。近年は暗号化に加えてデータ流出を脅す二重恐喝、業務妨害を含む三重恐喝へと進化しており、被害は技術的な復旧だけでなく、事業継続全体に及びます。

BCP（Business Continuity Plan）は、災害・事故・システム障害等の重大事象が発生した際に、優先業務を継続または早期復旧するための計画です。地震・火災対策のBCPは整備されている企業が多い一方、サイバー攻撃を想定したBCPは未整備のケースが目立ちます。

ランサムウェア被害をBCPに組み込むべき理由は、3つあります。第1に、業務システム全停止という事業継続の根幹に関わる影響があるため。第2に、復旧期間が数日〜数週間に及び、災害BCPと同等以上の準備が必要なため。第3に、対応判断に経営層の関与が不可欠（身代金支払い判断、対外コミュニケーション等）なため。

警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月公表）によれば、令和7年に警察へ報告されたランサムウェア被害は226件で、依然として高い水準にあります。データを暗号化せず、窃取した情報の公開をちらつかせて金銭を要求する「ノーウェアランサム」も17件報告されました。同資料では、調査・復旧に1か月以上を要した組織が約半数、調査・復旧費用が1,000万円以上に達した組織が5割を超えたことも示されています。BCPの観点では、件数よりも1件あたりの停止期間と費用の重さが重要です。

サイバーBCPと災害BCPは何が違うか

「サイバーBCP」という言葉が使われるのは、既存の災害BCPをそのまま流用すると機能しない領域があるからです。両者の違いを整理すると、追加で準備すべき項目が見えてきます。

災害BCPをすでに持っている企業であれば、ゼロから作り直す必要はありません。既存のBCPにサイバー事象を発動事由として追加し、上表の差分だけを別紙で補うという進め方が現実的です。

警察庁「サイバー空間をめぐる脅威の情勢等について」によれば、ランサムウェア被害は近年高水準で推移しており、業務停止期間は数日〜数週間に及ぶケースや、復旧費用が数千万〜数億円規模に達するケースが報告されています。

参考：サイバー空間をめぐる脅威の情勢等について（警察庁）

ランサムウェア被害の影響と特徴

ランサムウェアBCPを設計する前提として、被害の構造と特徴を理解しておく必要があります。一般的な災害・事故対応とは異なる、サイバー攻撃特有の困難さがあります。

被害の3層構造

• 直接被害: ファイル暗号化・データ流出による業務停止、復旧費用、身代金要求
• 二次被害: 取引先への影響、契約解除、訴訟、株価下落、行政処分
• 三次被害: 信頼喪失、人材流出、事業機会の損失

サイバー攻撃BCP特有の困難さ

地震・火災BCPと比較して、ランサムウェアには以下の困難さがあります。

• 被害範囲の即時把握が困難: 影響を受けたシステム・データの特定に時間を要する
• 復旧前提のリスク: 再感染リスクから、安易な復旧ができない
• 法務・倫理判断: 身代金支払いの可否、警察・規制当局への通報判断

復旧までにかかる期間の実態

「サイバー攻撃を受けてから復旧までどれくらいかかるのか」は、経営層から必ず問われる論点です。警察庁の同資料では、調査・復旧に1か月以上を要した組織が約半数を占めています。

注意すべきは、この「復旧」が業務の完全再開を指す点です。実務では、重要業務の暫定再開（数日）、主要システムの復旧（数週間）、完全復旧（1か月以上）という3段階で進みます。経営層と情シスの間で「復旧」の定義がずれると報告のたびに齟齬が起きるため、BCPの文書には3つを別々の目標として書き分けておくことを推奨します。

被害発覚から復旧までの標準タイムライン

BCPの実効性を上げるには、時間軸ごとに「誰が何を判断するか」を先に決めておくことが有効です。標準的な進行を時間軸で整理すると、次のようになります。

この表を1枚で社内に共有しておくだけでも、初動の意思決定速度は変わります。特に「0〜1時間」と「1〜24時間」の判断者を事前に明記しておくことが、被害拡大を抑える最大の要因になります。

業務停止期間の典型パターン（目安例）

被害発覚から完全復旧までの期間は、組織のBCP整備状況や自社システム構成・バックアップ状態で大きく変動します。以下は報告事例をもとにした目安です。

• 完全未整備: 1〜3か月（業務全停止を含む）
• 基本対策あり: 2〜4週間（部分復旧から段階的に再開）
• BCP整備済み: 1〜2週間（重要業務は数日で再開）
• 高度なBCP・訓練あり: 数日〜1週間（重要業務は当日〜翌日に再開）

事前準備の差が、被害規模を直接的に左右する構造です。

参考：ランサムウェア対策特設ページ（IPA）

 参考：情報セキュリティ10大脅威 2026（IPA）

ランサムウェアBCP設計の全体構造

被害発覚から完全復旧までの期間は、BCPの整備状況とシステム構成、バックアップの状態で大きく変動します。以下は報告事例をもとにした目安です。

この5フェーズは、NISTのサイバーセキュリティフレームワーク（CSF）2.0が定める6つの機能（統治・識別・防御・検知・対応・復旧）とおおむね対応します。CSF 2.0では2024年2月に「統治（Govern）」が追加されました。自社のBCPを外部に説明する場面では、5フェーズをCSF 2.0の機能名に読み替えておくと、監査や取引先審査での説明がしやすくなります。

フェーズ1: 予防

侵入を未然に防ぐ対策と、被害が発生しても影響を最小化する仕掛けを準備するフェーズです。

• バックアップ戦略の整備（3-2-1ルール、オフライン保管、不変性）
• ネットワーク分離（業務系・OT系・バックアップ系の分離）
• アクセス制御の最小化（最小権限、特権アクセス管理）
• パッチ管理、脆弱性スキャン、エンドポイント保護

侵入経路として報告が多いのはVPN機器の脆弱性です。予防フェーズの優先度を決める際は、まず境界機器の棚卸しから着手すると効果が出やすくなります。

関連記事：ランサムウェアとVPN脆弱性の対策

フェーズ2: 検知

侵入を早期に発見し、被害拡大を防ぐ仕組みです。

• EDR/XDR/SIEMによる継続監視
• 異常通信、暗号化操作の検知
• バックアップ削除・改ざんの検知
• 24/7監視体制（自社SOCまたはMDR）

フェーズ3: 対応（インシデントレスポンス）

被害発生時の初動対応を体系化します。

• インシデント対応チーム（CSIRT）の設置と権限明確化
• 初動対応プレイブック（隔離、調査、関係者通知）
• 経営層への報告経路と判断プロセス
• 法務・広報・人事との連携

フェーズ4: 復旧

業務再開のための技術的・組織的な復旧プロセスです。

• 業務影響分析（BIA）に基づく復旧優先順位
• バックアップからの復旧手順
• 段階的な業務再開計画
• 再感染防止策の確認

フェーズ5: 学習

被害事案を組織の学習につなげるフェーズです。

• 振り返り（ポストモーテム）の実施
• 再発防止策の策定と展開
• BCP・対応プロセスの更新
• 業界・法執行機関との情報共有

参考：ISO 22301 事業継続マネジメントシステム（JIPDEC）

参考：Cybersecurity Framework（NIST）

復旧優先順位の設計（業務影響分析）

ランサムウェア発生時、すべてのシステムを同時に復旧することは不可能です。事前に業務影響分析（BIA: Business Impact Analysis）を行い、復旧優先順位を決定しておくことが、迅速な事業継続の鍵となります。

BIAの実施ステップ

• ステップ1: 業務プロセスの棚卸し（営業、製造、物流、経理、人事、IT等）
• ステップ2: 各業務の停止時影響評価（収益、顧客、信頼、法令）
• ステップ3: 復旧目標の設定（RTO: 復旧時間目標、RPO: 復旧時点目標）
• ステップ4: 業務とITシステムの紐づけ
• ステップ5: 復旧優先順位リストの確定

実務でつまずきやすいのはステップ4です。業務とシステムの対応表を作ろうとして初めて、「誰がどのSaaSを使っているか把握できていない」という事実に直面する組織は少なくありません。BIAの精度は、平時のIT資産台帳・SaaS台帳の精度を超えられません。BCP整備の着手は、台帳を点検する好機でもあります。

優先順位の階層化

実務的には、以下の3層で整理するのが現実的です。

• 最優先（24時間以内）: 顧客サービス継続、法令遵守、安全管理に直結する業務
• 高優先（72時間以内）: 売上に直結する業務、サプライチェーン維持
• 中優先（1〜2週間以内）: 内部管理、間接業務、戦略立案

業務継続のための代替手段

完全復旧までの間、以下の代替手段で業務を継続できる準備を整えます。

• 紙・手作業での代替プロセス
• 別環境（クラウド・別リージョン）での暫定運用
• 外部委託先・関連会社への業務移管
• 取引先との連絡手段の代替（メール→電話、FAX）

各業務について「ITシステムが使えない場合の代替手段」を文書化しておくことが、被害発生時の混乱を抑えるうえで重要です。

参考：サイバーセキュリティ経営ガイドライン Ver3.0（経済産業省）

バックアップ戦略：3-2-1ルールと不変性

ランサムウェア対策におけるバックアップは、災害対策のバックアップとは異なる設計が必要です。攻撃者はバックアップそのものを狙ってくるため、複数の保護層を組み合わせる必要があります。

3-2-1ルール

• 3つのデータコピー: 本番データに加え、2つのバックアップを保持
• 2種類の媒体: ディスク、テープ、クラウドストレージ等の異なる媒体に分散
• 1つはオフサイト: 物理的または論理的に隔離された場所に保管

3-2-1-1-0への進化

近年の高度化したランサムウェアに対応するため、バックアップ製品ベンダー等で広く使われる追加層が推奨されています。

• 1つはオフライン: ネットワーク接続を切ったオフライン媒体に保管
• 0個のエラー: 復元検証でエラーがないことを確認

不変性（Immutability）の確保

バックアップが攻撃者に削除・改ざんされないため、不変性を確保する技術を活用します。

• WORM（Write Once Read Many）ストレージ: 一度書き込んだら変更不可
• イミュータブルバックアップ機能: バックアップ製品の機能で改ざん防止
• バージョン管理付きクラウドストレージ: 過去バージョンへの復元
• エアギャップ環境: ネットワークから物理的に切り離された保管

復元テストの定期実施

「バックアップを取っている」だけでは復元できない事例が後を絶ちません。以下を定期実施します。

• 月次〜四半期: ランダムに選定したファイル・データベースの復元テスト
• 年次: 主要システム全体のリストア訓練
• 重要更新時: バックアップ仕様変更後の復元検証
• 訓練結果の記録と是正

バックアップシステムのセキュリティ強化

バックアップ環境自体が攻撃対象です。以下の対策が必要です。

• バックアップ管理者アカウントのMFA・PAM適用
• 本番環境とは異なる認証ドメイン
• バックアップトラフィックの暗号化
• 監査ログの取得と継続監視

SaaS上のデータをどう守るか

オンプレミス環境のバックアップ設計は整っていても、SaaS上のデータが抜け落ちている組織は多く見られます。20種類以上のSaaSを利用している企業では、業務データの相当部分がSaaS側に存在します。SaaS事業者はインフラの可用性を保証しますが、利用者側の操作による削除や、認証情報を奪われた状態での改ざんまでは保証しません。

主要SaaSについて、データの保持期間、エクスポート手段、復元手順の3点を台帳化しておきましょう。BIAで「最優先」に分類した業務がSaaSに依存している場合は、SaaSデータのバックアップも復旧計画の対象に含める必要があります。

関連記事：SaaS管理におけるデータバックアップの重要性

参考：NIST SP 800-209 Storage Infrastructure Security（NIST）

ランサムウェア被害後の事業継続を支えるソフトウェア・ツールの選び方

「ランサムウェア被害後の事業継続に優れたソフトウェアはどれか」という問いに、単一の製品で答えることはできません。バックアップ製品だけを高機能にしても、感染を検知できなければ暗号化済みのデータをバックアップし続けることになりますし、復旧対象の台帳がなければ、どこから戻すべきかを決められないからです。

選定は、製品カテゴリを横並びで比較するのではなく、BCPの5フェーズのどこを埋める道具なのかを先に決めるのが近道です。フェーズごとに求められる要件が異なるため、評価軸も変わります。

BCPの5フェーズとツールカテゴリの対応

自社に何が足りないかを見極めるための対応表です。

この表で空欄になるフェーズが、自社のBCPで最も脆い部分です。予算配分では、最も高機能な製品を1つ導入するよりも、空欄のフェーズを埋めるほうが事業継続の効果は大きくなります。

バックアップ・データ保護製品に求める5つの要件

事業継続の成否を最も直接的に左右するカテゴリです。次の5点を確認します。

1. 不変性の実装方式: ストレージ側のWORM（一度書き込むと変更できない方式）か製品独自のロックか。管理者権限でも解除できない設計かを確認します
2. 管理系の認証分離: 管理コンソールが本番の認証基盤と同じ場合、管理者権限を奪われた時点でバックアップも失われます
3. 復元速度: 「取得できるか」ではなく「RTO内に戻せるか」で評価します。一括復元の実測値をベンダーに確認します
4. 取得粒度: RPOに対して取得間隔が足りているか。日次取得なら最大1日分の業務データを失う前提になります
5. 復元検証の自動化: 人手で回す復元テストは形骸化します。自動で復元し整合性を検証する機能の有無を確認します

検知・対応系（EDR／XDR／MDR）の選定ポイント

暗号化が完了してからでは、選べる手は復旧だけになります。検知系への投資は、事業停止期間を短くするための投資です。

• ランサムウェア特有の振る舞い（大量のファイル改名・暗号化・シャドーコピー削除）を検知できるか
• 検知後に自動で端末を隔離できるか。人手対応では夜間・休日の被害が止まりません
• 自社でSOCを持てない場合、24時間365日の監視を代行するMDRが提供されているか
• 保護対象にサーバー、ハイパーバイザー、バックアップサーバーが含まれるか

復旧の前提になるIT資産・アイデンティティ管理

見落とされやすいのがこのカテゴリです。復旧作業は「何を、どの順番で、誰のアカウントで戻すか」の3点が決まって初めて動き出します。

• 何を: デバイス台帳・SaaS台帳がそのまま復旧対象リストになります
• どの順番で: BIAの優先順位と台帳が紐づいていなければ、順序を決められません
• 誰のアカウントで: 認証基盤が停止した場合の代替アクセス手段が必要です

平時のIT資産・SaaS・アカウントの一元管理は、セキュリティ対策であると同時に、復旧を実行可能にするための準備でもあります。

関連記事：アクセス権限管理の実践ガイド

選定前に確認する7つのチェック項目

製品比較表を作る前に、自社側の前提を固めておきます。

1. 対象業務のRTO・RPOが数値で決まっているか
2. 復旧対象システムの一覧（台帳）が最新か
3. 認証基盤が停止した場合の代替アクセス手段があるか
4. 既存製品と機能が重複していないか（同じ機能に二重投資していないか）
5. 導入後の運用工数を誰が負担するか
6. 24時間対応が必要な範囲はどこまでか
7. 年1回の復元訓練を実施できる体制と時間を確保できるか

ツールを導入しても事業が止まる3つの落とし穴

製品を導入したにもかかわらず復旧に失敗する、典型的なパターンです。

• 復元テストを実施していない: 取得はできていたが、いざ戻すと整合性が取れず使えなかったという事例が繰り返し報告されています
• 管理コンソールが本番と同一認証: 管理者権限を奪われた時点で、バックアップの削除まで一手で実行されます
• 台帳がなく復旧順序を決められない: 技術的には戻せるのに、順序の合意形成に数日を要するケースがあります

ツール選定は、この3つの落とし穴を自社が回避できる状態かを確認する作業でもあります。製品の機能一覧よりも、運用に落ちるかどうかを優先して評価してください。

参考：NIST SP 800-184 Guide for Cybersecurity Event Recovery（NIST）

インシデント発生時の対応プレイブック

被害発覚直後の初動が、その後の被害規模を大きく左右します。事前に標準化された対応プレイブックを整備し、訓練で習熟しておくことが重要です。

発覚時の即時対応（最初の1時間）

• 影響範囲の暫定特定
• 感染拡大防止のためのネットワーク分離
• インシデント対応チームの招集
• 経営層への第一報
• 最寄りの警察署または都道府県警察のサイバー犯罪相談窓口への通報準備

拡大防止と調査（最初の24時間）

• 全システムへの感染状況確認
• バックアップ環境の安全性確認
• 影響を受けた業務の特定と代替手段への切替
• 法務・広報・人事との連携
• 個人情報保護委員会への速報（発覚後3〜5日以内）・確報（原則30日以内、不正目的によるおそれがある場合は60日以内）の準備

関係者への通知（24〜72時間）

• 取引先への影響説明
• 個人データの漏えい・滅失・毀損またはそのおそれがある場合の本人への通知
• 監督官庁への報告
• 必要に応じてメディア・株主への公表

復旧と業務再開（1〜2週間）

• 優先順位順の段階的なシステム復旧
• 再感染防止策の確認後の本番再開
• 業務再開のロードマップ共有
• 顧客・取引先への再開通知

完全復旧後の振り返り（1〜3か月）

• インシデントの原因究明
• 再発防止策の策定と展開
• BCPの見直しと更新
• 必要に応じた人材・体制の強化

各フェーズの具体的な手順書の作り方は、インシデント対応の記事で詳しく解説しています。

関連記事：セキュリティインシデントの対応手順

身代金支払いの判断

身代金支払いについては、原則として推奨されない立場が国際的なコンセンサスです。

• JPCERT/CC等の専門機関・関係省庁: 復元保証がないこと、追加被害や攻撃継続助長の可能性から支払いを推奨しない
• 海外規制（米国OFAC等）: 制裁対象国・組織への支払いは法的リスク
• 倫理的観点: 攻撃者の活動継続を助長する
• 実務的観点: 支払っても完全復旧の保証なし

支払い検討は経営層の判断事項です。法務・サイバー保険・専門家の助言を踏まえた慎重な議論が必要です。

参考：サイバー警察局（警察庁）

参考：個人データの漏えい等が発生した場合の対応（個人情報保護委員会）

ランサムウェア対応訓練の実施

書面のBCPだけでは実効性は確保できません。定期的な訓練で組織が動ける状態を維持します。

訓練の種類

• テーブルトップ演習: 仮想シナリオで意思決定を訓練（年1〜2回）
• 部分実機訓練: 一部システムでの隔離・復旧テスト（年2〜4回）
• 全社実機訓練: 主要業務システムの復旧訓練（年1回）

テーブルトップ演習のシナリオ例

• 月曜朝、社員からファイルが開けないと報告。EDRが大量のファイル暗号化を検知。攻撃者からの脅迫メール。バックアップサーバーが応答せず。

このシナリオで以下の判断を経営層・情シスが議論します。

• 業務停止の経営判断（誰がいつ判断するか）
• 警察・規制当局への通報タイミング
• 取引先・顧客への対外コミュニケーション
• バックアップからの復旧の優先順位
• 身代金要求への対応方針

訓練後の振り返り

訓練で発見した課題をリスト化し、改善計画を策定します。

• 意思決定の遅延箇所
• 連絡経路の不明確さ
• 役割分担の重複・空白
• 必要な追加準備（ツール、契約、人材）

参考：CSIRTマテリアル（JPCERT/CC）

ランサムウェアBCPに関連する用語集

記事内で頻出する専門用語を整理します。

• BCP: Business Continuity Plan。事業継続計画
• BIA: Business Impact Analysis。業務影響分析
• RTO: Recovery Time Objective。復旧時間目標
• RPO: Recovery Point Objective。復旧時点目標
• CSIRT: Computer Security Incident Response Team。コンピュータセキュリティインシデント対応チーム
• 3-2-1ルール: 3つのコピー・2種類の媒体・1つオフサイトのバックアップ原則
• 不変性: Immutability。バックアップが改ざん・削除されない特性
• エアギャップ: ネットワークから物理的に切り離された環境
• 二重恐喝: 暗号化＋データ流出脅迫
• 三重恐喝: 暗号化＋データ流出脅迫＋業務妨害
• ポストモーテム: 事案後の振り返り分析
• OFAC: 米国財務省外国資産管理局。制裁対象を管理する機関
•  ノーウェアランサム: データを暗号化せず、窃取した情報の公開をちらつかせて金銭を要求する手口
• MDR: Managed Detection and Response。検知と対応を外部に委託するサービス
• クリーンルーム復旧: 隔離した安全な環境でデータを検査してから本番へ戻す復旧手法

ジョーシスを活用した平時のリスク低減

ランサムウェアBCPは「被害発生時」の備えですが、平時のリスク低減も同様に重要です。SaaS・デバイス・人を統合管理することで、攻撃の入口となる脆弱性を継続的に削減できます。

ジョーシスは、SaaS・デバイス・アカウントを一元管理するAI駆動のアイデンティティセキュリティ基盤です。ランサムウェア対策の文脈では、以下の機能が貢献します。

• アカウントライフサイクル: 退職者アカウント残存による侵入経路の解消
• ライセンス管理: 不要アカウントの可視化、攻撃面の縮小
• デバイス管理連携: PCの管理状況、ベースライン適用率の継続監視
• 監査ログ・IdPログの可視化: 不審な操作やアクセス状況の調査を支援
• IDaaS連携: 既存のセキュリティ製品と統合運用

導入企業数は国内外1,000社以上にのぼり、事例によっては、IT工数の最大50%削減、IT管理コストの最大75%削減につながった報告もあります（効果は個社の状況により異なります）。350以上のSaaSアプリと連携可能で、平時の予防と発生時の事業継続の両面で組織を支えます。

BCP文書とツールをつなぐ「3つの台帳」という考え方

BCPの実効性を高めるうえでジョーシスが有効だと考えているのは、メンバー台帳・アプリ台帳・デバイス台帳という3つの台帳を平時から最新に保つ運用です。復旧計画に必要な「誰が」「どのアプリを」「どの端末で」使っているかという情報は、この3つに集約されます。

この考え方は、経済産業省が2026年3月27日に公表したサプライチェーンセキュリティ（SCS）評価制度の評価分類とも整合します。同制度はNIST CSFに対応した7分類（統治・識別・防御・検知・対応・復旧・取引先管理）で構成されており、「識別」と「復旧」の項目は台帳の整備状況を問うものです。ジョーシスでは、★3の25項目と★4固有の16項目を含む計41項目について、3つの台帳とのマッピングを整理しています。

ただし、評価制度への対応はポリシーと製品の2軸で成り立ちます。ツールは製品側の証拠を作りますが、規程・体制の整備は別途必要です。

導入企業数は国内外700社を超え、事例によっては、IT工数の最大50%削減、IT管理コストの最大75%削減につながった報告もあります。350以上のSaaSアプリと連携可能で、平時の予防と発生時の事業継続の両面で組織を支えます。

Josysの製品概要を5分で理解する資料をダウンロードする

Josysの無料デモを予約して、自社の課題に合うかを確認する

ランサムウェアBCPに関するよくある質問

Q1. 中小企業にもランサムウェアBCPは必要ですか

必要です。むしろ中小企業はサプライチェーン攻撃の踏み台として狙われるケースが増え、被害発生時の復旧体制が事業存続を左右します。完璧なBCPでなくとも、最低限のバックアップ・連絡経路・代替プロセスの整備が必須です。

Q2. クラウドサービス利用時もバックアップは必要ですか

必要です。クラウドサービスはインフラの可用性を提供しますが、データの誤削除・暗号化・流出への対応は利用企業の責任範囲です。SaaSデータの定期エクスポート、別クラウドへのコピー、不変ストレージへの保管が推奨されます。

Q3. 身代金を支払う判断はどう行うべきですか

原則として推奨されません。警察庁・規制当局も「支払わない」が基本方針です。法的リスク（米国OFAC制裁対象への支払い禁止）、倫理的リスク（攻撃継続の助長）、実務リスク（完全復旧の保証なし）を踏まえ、最終手段としても慎重な経営判断が求められます。法務・サイバー保険・専門家への相談を必須とします。

Q4. サイバー保険はランサムウェアBCPの代替になりますか

代替にはなりません。サイバー保険は経済損失の補填手段であり、業務継続を確保する仕組みではありません。両者は補完関係にあり、保険でカバーできない領域（事業機会損失、信頼回復、人材流出）はBCPで備える必要があります。

Q5. BCP訓練の頻度はどの程度が適切ですか

最低限、年1回のテーブルトップ演習が必要です。中堅以上はテーブルトップ年2回＋部分実機訓練年2〜4回が推奨されます。重要業務の変更、システム更新、組織変更があった際は追加訓練を実施します。訓練を経ない書面のBCPは、緊急時には機能しないため、運用ありきで設計します。

Q6. ランサムウェア被害後の事業継続に優れたソフトウェアはどれですか

単一の製品で完結するものではありません。事業継続の観点では、復旧の原資を守るバックアップ・イミュータブルストレージ、暗号化が広がる前に止めるEDR／XDRまたはMDR、復旧対象と権限を把握するIT資産・SaaS・アカウント管理という3層をそろえることが前提です。自社に欠けている層から着手するのが最短になります。個別製品の評価軸は、本記事の「ソフトウェア・ツールの選び方」を参照してください。

Q7. サイバー攻撃を受けてから復旧までどれくらいかかりますか

警察庁の令和7年の統計では、調査・復旧に1か月以上を要した組織が約半数を占めています。ただしこれは完全復旧までの期間であり、重要業務の暫定再開はBCPが整備されていれば数日で実現できるケースもあります。暫定再開・部分復旧・完全復旧の3段階に分けて目標時間を共有しておきましょう。

Q8. サイバーBCPは既存の災害BCPと統合すべきですか

統合を推奨します。BCPを2つ持つと、発動時に指揮系統が割れるためです。ただし、被害範囲の特定に時間がかかる点、再感染リスクがあるため安易に再開できない点、漏えい報告義務が発生する点の3つは、災害BCPにはない要素です。既存のBCPにサイバー事象を発動事由として追加し、この差分だけを別紙で補う形が実務的です。

まとめ

ランサムウェアは「いつか被害に遭う前提」で備えるべき脅威です。攻撃発生後にどう対応するかではなく、攻撃発生前にBCPとして整備しておくことが、被害規模を決定的に左右します。

5フェーズ（予防・検知・対応・復旧・学習）で設計し、業務影響分析に基づく復旧優先順位、3-2-1-1-0のバックアップ戦略、対応プレイブック、定期訓練を組み合わせた多層構造が、現代の標準解です。書面のBCPで終わらせず、訓練と継続改善のサイクルを回すことが、組織が動ける状態を維持する鍵となります。

ソフトウェアの選定は、製品単体の性能比較ではなく、5フェーズのどこが空欄かを埋める作業として進めてください。平時のリスク低減としては、SaaS・デバイス・アカウントを統合管理する基盤の活用も有効です。復旧計画に必要な台帳を平時から維持できているかどうかが、被害発生時の初動速度をそのまま決めます。

Josysの製品概要を5分で理解する資料をダウンロードする

Josysの無料デモを予約して、自社の課題に合うかを確認する