【SCS評価制度★3徹底解説 第8回】「インシデントからの復旧」とは？事業継続に必要な復旧準備を解説

情報セキュリティ

サイバー攻撃への備えというと、「攻撃を防ぐこと」や「攻撃を早期に検知すること」に目が向きがちです。

しかし、どれだけ対策を講じても、サイバー攻撃やセキュリティインシデントの発生可能性を完全にゼロにすることはできません。

万が一、ランサムウェアなどのサイバー攻撃によって重要なシステムが停止した場合、

「バックアップはあるのか」

「どのシステムから復旧するのか」

「システムが使えない間、業務をどう続けるのか」

「どこまで復旧すれば事業を再開できるのか」

といったことを、その場で考え始めていては対応が遅れてしまいます。

そこで重要になるのが、今回取り上げる「インシデントからの復旧」です。

SCS評価制度★3では、攻撃を防ぐための対策だけではなく、インシデントが発生した後に事業を継続し、必要な状態まで復旧するための準備も求められています。

前回の第7回では、セキュリティインシデントが発生した際の対応手順や体制について解説しました。

今回の第8回では、その次の段階となる、

「インシデント発生後、どのように事業を継続し、システムや業務を復旧させるのか」

について、SCS評価制度★3の要求事項をもとに詳しく解説します。

前回までの連載記事

公式資料

IPA公式資料

IPAでは、SCS評価制度の要求事項・評価基準がExcel形式で公開されています。

また、IPAのページでは、★3・★4の要求事項・評価基準に関する解説書は2026年10月頃公開予定とされています。

経済産業省公式資料

経済産業省では、SCS評価制度の制度構築方針とあわせて、★3・★4の要求事項及び評価基準が公開されています。

なお、SCS評価制度は今後も解説書、取得ガイド、申請手続きなどの情報が追加・更新される可能性があります。

実際に★3取得を検討する際は、必ずIPAおよび経済産業省の最新情報を確認してください。

今回解説するSCS評価制度★3の評価項目

今回取り上げるのは、SCS評価制度★3の7つの大分類のうち、最後に位置付けられている「インシデントからの復旧」です。

大分類 中分類 要求事項No. 要求事項
インシデントからの復旧 インシデント復旧計画の実行 7-1-1 事業上重要なシステムについて、事業継続の要件に沿う復旧に必要な準備を行うこと

IPAが公開している★3・★4の要求事項・評価基準では、★3の「インシデントからの復旧」として、このNo.7-1-1が示されています。

今回のポイントを一言で表すと、

「重要なシステムが止まったときに、事業をどう継続し、どう復旧するのかを事前に決めておく」

ということです。

ここで重要なのは、単に、

「バックアップを取っています」

「BCPがあります」

というだけではありません。

SCS評価制度★3で求められているのは、事業上重要なシステムについて、実際に事業継続の要件に沿った復旧ができるよう準備しておくことです。

では、具体的にどのような準備が必要になるのでしょうか。

1．まず「事業上重要なシステム」を明確にする

復旧を考えるためには、最初に、

「自社にとって、止まると事業に重大な影響が出るシステムは何か」

を明確にする必要があります。

企業では、さまざまなシステムやITサービスが利用されています。

例えば、

  • 基幹業務システム
  • 販売管理システム
  • 受発注システム
  • 生産管理システム
  • 会計システム
  • 顧客管理システム
  • ファイルサーバ
  • メール
  • グループウェア
  • クラウドサービス
  • 取引先とのデータ連携システム

などです。

しかし、これらすべてを同じ優先順位で復旧することは現実的ではありません。

例えば、メールが数時間利用できなくても業務を継続できる企業がある一方、受発注システムが1時間停止するだけで大きな影響が出る企業もあります。

そのため、復旧を考える際には、

「どのシステムが停止すると、どの業務が止まるのか」

を整理することが重要です。

重要なシステムを整理する際の確認ポイント

例えば、次のような観点で確認します。

  • システムが停止すると売上に影響するか
  • 顧客や取引先へのサービス提供が停止するか
  • 生産や出荷が停止するか
  • 法令や契約上の問題が発生するか
  • 他の業務やシステムにも影響が広がるか
  • 人手による代替が可能か
  • どの程度の停止時間まで許容できるか

ここで注意したいのは、

「重要なシステム＝高額なシステム」ではない

ということです。

システム自体の価格が安くても、そのシステムが停止することで事業全体が止まるのであれば、事業継続上は非常に重要です。

反対に、高額なシステムであっても、数日間停止しても事業への影響が限定的であれば、復旧の優先順位は必ずしも最上位とは限りません。

復旧計画を考える際には、システムの価格や規模ではなく、

「停止した場合の事業への影響」

を基準に考える必要があります。

2．「どこまで復旧すれば業務を再開できるのか」を決める

復旧というと、

「すべてのシステムを元通りにすること」

をイメージするかもしれません。

しかし、重大なサイバー攻撃が発生した場合、すべてのシステムを短時間で完全に元の状態へ戻せるとは限りません。

例えばランサムウェアによって複数のサーバや端末が利用できなくなった場合、

  • 原因の調査
  • 感染範囲の確認
  • 攻撃者の排除
  • 脆弱性の修正
  • アカウントの再設定
  • サーバの再構築
  • データの復元
  • 安全性の確認

など、多くの作業が必要になる可能性があります。

そのため、

「完全復旧するまで何もできない」

という状態では、事業への影響が非常に大きくなります。

重要なのは、

「最低限、どの業務をどの程度まで再開すれば事業を継続できるのか」

を事前に考えておくことです。

例えば、

通常時：100％の業務
↓
インシデント発生：一時的に業務停止
↓
暫定復旧：最重要業務を30％程度で再開
↓
部分復旧：主要業務を70％程度まで回復
↓
完全復旧：通常業務へ復帰

というように、段階的な復旧を考える方法があります。

必ずしも最初から100％の状態へ戻す必要はありません。

まずは、

  • 顧客対応
  • 受発注
  • 生産
  • 出荷
  • 決済

など、事業継続に不可欠な業務を優先して再開し、その後に通常状態へ戻していくという考え方です。

復旧を考える際には、

「システムを元に戻すこと」だけではなく、「事業を必要な水準まで戻すこと」

を意識する必要があります。

3．システムが利用できない場合の代替手段を考える

復旧準備では、

「システムをどう復旧するか」

だけではなく、

「システムが復旧するまでの間、どうやって業務を続けるか」

も重要です。

サイバー攻撃の規模によっては、システムの復旧に時間がかかる可能性があります。

その間、すべての業務を停止するわけにはいきません。

そこで、

  • 予備の端末を使用する
  • 代替システムを使用する
  • クラウド環境へ切り替える
  • 別拠点から業務を行う
  • 電話やFAXを利用する
  • 紙による運用へ切り替える
  • 手作業で最低限の業務を継続する

といった代替手段を事前に考えておく必要があります。

受発注システムが停止した場合

例えば、受発注システムが利用できなくなった場合、

  • 電話で注文を受ける
  • FAXで注文書を受け取る
  • 一時的に紙やオフラインの表で管理する
  • 復旧後にシステムへ入力する

という方法が考えられます。

メールが利用できない場合

メールが利用できなくなった場合には、

  • 電話
  • 別の連絡手段
  • 事前に定めた緊急連絡先

を使用する方法があります。

重要なのは、

「普段と同じ方法で業務を行うこと」ではありません。

インシデント発生時には、一時的に効率が落ちたとしても、

「事業を完全に停止させないこと」

が優先される場合があります。

4．緊急時の連絡手段を準備する

重大なサイバー攻撃が発生すると、普段使用している連絡手段そのものが利用できなくなる可能性があります。

例えば、

  • メールサーバが停止する
  • グループウェアが利用できなくなる
  • 社内ネットワークへ接続できなくなる
  • ファイルサーバ上の連絡先一覧を確認できなくなる

といった状況です。

このとき、

「取引先へ連絡しなければならないが、連絡先が分からない」

「システムベンダーへ連絡したいが、連絡先一覧がファイルサーバの中にある」

という事態になれば、対応がさらに遅れてしまいます。

そのため、

  • 主要取引先
  • 重要な顧客
  • システムベンダー
  • クラウドサービス事業者
  • セキュリティ支援会社
  • サイバー保険会社
  • 関係機関

などの緊急連絡先については、

通常の社内システムが利用できなくても確認できる状態

にしておく必要があります。

連絡先一覧を作成していても、その一覧が停止したシステムの中にしか存在しなければ、緊急時には利用できません。

「情報を持っているか」だけではなく、

「インシデント発生時でも、その情報を利用できるか」

まで考えることが重要です。

5．バックアップがあるだけでは「復旧できる」とは限らない

復旧対策というと、多くの企業が最初に思い浮かべるのがバックアップです。

もちろん、バックアップは非常に重要です。

しかし、

「バックアップを取得していること」と「実際に復旧できること」は同じではありません。

例えば、

  • バックアップ自体がランサムウェアによって暗号化された
  • バックアップデータが破損していた
  • 必要なデータがバックアップ対象に含まれていなかった
  • 復元方法を担当者しか知らなかった
  • 復旧に必要なIDやパスワードが分からなかった
  • 復元に想定以上の時間がかかった
  • 復元先となる機器を準備できなかった

といった問題が起こる可能性があります。

そのため、バックアップについては、

「取得しているか」ではなく、「必要なときに本当に使えるか」

という視点が必要です。

少なくとも、

  1. 何をバックアップしているのか
  2. どこに保管しているのか
  3. どの程度の頻度で取得しているのか
  4. 誰が復元するのか
  5. どの手順で復元するのか
  6. どのシステムから復元するのか

を確認しておく必要があります。

SCS評価制度★3では、バックアップそのものは「攻撃等の防御」の評価項目でも扱われますが、今回の「インシデントからの復旧」では、そのバックアップを含めて事業継続のために実際に復旧できる準備が整っているかという視点が重要になります。IPAの★3取得支援に関する資料でも、「適切なバックアップ」「リストア手順書」と「事業継続要件に沿った復旧準備」「事業継続プラン」は、それぞれ必要な準備として整理されています。

6．復旧の優先順位を決めておく

重大なインシデントが発生した際、すべてのシステムを同時に復旧できるとは限りません。

限られた人員や時間の中で、

「何から復旧するのか」

を判断する必要があります。

例えば、

優先度A

停止すると事業継続に重大な影響があるシステム

優先度B

一定期間は代替手段で対応できるシステム

優先度C

復旧が遅れても事業への影響が限定的なシステム

という形で整理する方法があります。

ここで重要なのは、

復旧の優先順位を情報システム担当者だけで決めないこと

です。

技術的には重要に見えるシステムでも、実際の事業への影響は限定的な場合があります。

反対に、技術的には単純なシステムでも、現場業務では絶対に停止できない場合があります。

そのため、

  • 経営層
  • 情報システム部門
  • 各業務部門
  • 必要に応じて委託先

などと連携して、

「どの業務を優先して再開するのか」

を決めておくことが重要です。

7．既存のBCPを「サイバー攻撃の視点」で見直す

すでにBCP、つまり事業継続計画を作成している企業もあるでしょう。

しかし、そのBCPが、

  • 地震
  • 台風
  • 火災
  • 停電

など、自然災害だけを想定している場合には注意が必要です。

サイバー攻撃によるシステム停止には、自然災害とは異なる特徴があります。

例えば、地震であれば、

「壊れた機器を交換する」

「別の拠点へ移動する」

ことで復旧できる場合があります。

一方、サイバー攻撃では、

  • 攻撃者がまだ環境内に残っている可能性がある
  • バックアップも侵害されている可能性がある
  • アカウント情報が窃取されている可能性がある
  • 復旧したシステムへ再侵入される可能性がある

といった問題があります。

そのため、

自然災害向けのBCPがあるから、サイバー攻撃にも対応できるとは限りません。

既存のBCPがある場合には、

「この計画はランサムウェアや不正侵入によるシステム停止でも機能するか」

という視点で見直す必要があります。

IPAが公開したSCS評価制度★3を踏まえたセキュリティマネジメント指導の資料でも、既存の地震対応BCPをセキュリティインシデント対応の観点から見直すという改善例が示されています。

8．「元の状態に戻すこと」だけが復旧ではない

インシデント発生後の復旧で特に注意したいのが、

「できるだけ早く元の状態へ戻そうとすること」

です。

もちろん、早期復旧は重要です。

しかし、侵入原因や攻撃者の活動を十分に確認しないまま元の環境へ戻してしまうと、再び侵入される可能性があります。

例えば、

  • 脆弱性が修正されていない
  • 攻撃に利用されたアカウントがそのまま残っている
  • 不正なアカウントが追加されている
  • マルウェアが残っている
  • 攻撃者の接続経路が残っている

状態でシステムを再開すれば、再度被害を受ける可能性があります。

そのため、復旧時には、

  • 侵入経路は確認できているか
  • 脆弱性は修正されているか
  • 不正なアカウントはないか
  • マルウェアは除去できているか
  • 安全なバックアップを使用しているか
  • 復旧後の監視体制は整っているか

といった確認が必要です。

復旧とは、

「インシデント発生前と同じ状態へ戻すこと」ではありません。

「安全に事業を再開できる状態へ戻すこと」

と考えることが重要です。

なぜ「インシデントからの復旧」が最後の評価分野なのか

SCS評価制度★3では、

  1. ガバナンスの整備
  2. 取引先管理
  3. リスクの特定
  4. 攻撃等の防御
  5. 攻撃等の検知
  6. インシデントへの対応
  7. インシデントからの復旧

という流れで対策が整理されています。

これは、セキュリティ対策が、

「攻撃を防ぐことだけでは終わらない」

ことを示しています。

まず、自社のセキュリティを管理する体制を整える。

次に、取引先やリスクを把握する。

その上で攻撃を防ぎ、攻撃を検知する。

インシデントが発生したら適切に対応する。

そして最後に、

事業を継続し、安全な状態へ復旧する。

この一連の流れがあって、初めて組織としてのサイバーセキュリティ対策になります。

SCS評価制度は、サプライチェーンを通じた事業・サービスの提供途絶や情報漏えい、不正侵入などのリスクに対し、適切なセキュリティ対策の実施を促すことを目的としています。

そのため、単に「侵入されない企業」を目指すだけではなく、

「万が一被害を受けても、事業を継続し立て直せる企業」

であることも重要になります。

攻撃者の目線から考える「復旧できない企業」

攻撃者にとって大きな影響を与えやすいのは、単にセキュリティ対策が弱い企業だけではありません。

「一度システムを止めれば、長期間業務を再開できない企業」

も、攻撃による影響を大きくしやすい企業です。

特にランサムウェア攻撃では、システムやデータを利用できなくすることで、被害企業に強い圧力をかけることができます。

一方で、

  • 重要データが適切にバックアップされている
  • 代替手段が準備されている
  • 手作業でも最低限の業務を継続できる
  • 緊急時の連絡手段が準備されている
  • 復旧の優先順位が決まっている

企業であれば、攻撃による事業への影響を抑えることができます。

つまり、復旧対策は、

「被害を受けた後のためだけの対策」ではありません。

攻撃によって企業が受ける影響そのものを小さくする、重要なサイバーセキュリティ対策でもあります。

SCS評価制度★3「インシデントからの復旧」確認チェックリスト

自社の対応状況を、次の項目で確認してみてください。

□ 事業上重要なシステムを特定している
□ システム停止時に影響を受ける業務を把握している
□ どの業務を優先して再開するのか決めている
□ 復旧の優先順位を決めている
□ システムが利用できない場合の代替手段を検討している
□ 手作業による業務継続方法を検討している
□ 緊急時の連絡手段を準備している
□ 重要な取引先やベンダーの連絡先を緊急時にも確認できる
□ バックアップから実際に復元できるか確認している
□ リストア手順が整備されている
□ 既存のBCPをサイバー攻撃の観点から確認している
□ 復旧時の担当者や役割を明確にしている
□ 復旧後の安全確認方法を検討している
□ 復旧計画を定期的に見直している

一つでも、

「決まっていない」

「担当者しか分からない」

「実際にできるか確認したことがない」

という項目があれば、見直しが必要です。

まとめ｜復旧はインシデントが起きてから考えるものではない

今回は、SCS評価制度★3の7つ目の評価分野である「インシデントからの復旧」について解説しました。

★3で求められているのは、

事業上重要なシステムについて、事業継続の要件に沿った復旧に必要な準備を行うこと

です。

重要なポイントは、

  • 事業上重要なシステムを明確にする
  • システム停止による事業への影響を把握する
  • どの業務から再開するのか決める
  • システムが利用できない場合の代替手段を準備する
  • 緊急時の連絡手段を準備する
  • バックアップを実際に復旧に使える状態にする
  • 既存のBCPをサイバー攻撃の視点から見直す

ことです。

サイバー攻撃は、いつ発生するか分かりません。

インシデントが発生してから、

「何から復旧するのか」

「取引先にはどう連絡するのか」

「システムが使えない間はどう業務を続けるのか」

を考えていては、対応が遅れてしまいます。

復旧は、インシデントが発生してから考え始めるものではありません。

平常時から必要な準備を行っておくことで、初めて迅速な事業継続と復旧が可能になります。

SCS評価制度★3への対応をきっかけとして、自社がサイバー攻撃を受けた場合でも事業を継続できるのか、一度確認してみてはいかがでしょうか。

SCS評価制度★3への対応でお困りの企業様へ

SCS評価制度★3への対応では、要求事項を確認してチェックを付けるだけでは十分ではありません。

特に今回取り上げた「インシデントからの復旧」では、

  • 自社にとって本当に重要なシステムは何か
  • どの業務を優先して復旧するのか
  • システムが利用できない場合にどう業務を継続するのか
  • 現在のバックアップから本当に復旧できるのか
  • 既存のBCPがサイバー攻撃にも対応できるのか

といった内容を、自社の実際の環境や業務に合わせて整理する必要があります。

株式会社クロイツでは、情報処理安全確保支援士・CISSPの知見と、攻撃者の視点を活かし、企業の実際の環境や運用状況を確認した上で、SCS評価制度★3への対応をご支援しています。

単にチェックリストを埋めるのではなく、

「実際にサイバー攻撃を受けたときに、その対策が本当に機能するのか」

という視点から、

  • 現状のセキュリティ対策の確認
  • SCS評価制度★3要求事項とのギャップ整理
  • 規程・ルール・手順書の整備
  • インシデント対応体制の構築
  • サイバーBCP・復旧計画の策定
  • セキュリティ教育・訓練
  • 継続的なセキュリティ運用

まで、企業の規模や実情に合わせてご支援します。

SCS評価制度★3への対応をどこから始めればよいか分からない場合や、自社だけでの対応に不安がある場合は、お気軽にご相談ください。

お問い合わせ

次回予告

今回の第8回までで、SCS評価制度★3の7つの評価分野について一通り解説してきました。

しかし、実際に★3取得を目指す際には、

「自社が現在どこまで対応できているのか」

を確認し、不足している対策を整理していく必要があります。

次回は、これまで解説してきた要求事項を踏まえ、

「SCS評価制度★3取得に向けた現状確認とギャップ分析」

をテーマに、自社の現在地をどのように確認し、どのような順番で対応を進めていけばよいのかを実務的な視点から解説します。