作成日: 2026-06-29
はじめに
「復旧できなかったら、会社はどうなるのか。」
サイバーセキュリティの「復旧する」という話になると、つかみどころがないというか、想像しづらいかもしれません。何が起こるのか、何から手をつければいいのか、どこまでやれば復旧と言えるのか・・・。会社ごとに事業も違うので他社の対応はあまり参考にならない——そんな感覚を持っている方も多いのではないかと思います。
2025年9月、アサヒグループホールディングスがランサムウェア攻撃を受け、受注・出荷システムが約2ヶ月にわたって停止しました。その間、物流業務は手作業での対応を余儀なくされ、個人情報約11万5000件の漏えいも確認されました。「大手でも2ヶ月止まる」という現実が、復旧計画を事前に整えておくことの重要性を改めて示しています。
ただ、NISTがCSFとは別に公開している「SP800-160 Vol.2 Rev.1」というガイドラインに、1つ重要な考え方が示されています。「攻撃者が防御を突破すること、サプライチェーンを通じて侵入してくることを前提に、サイバーセキュリティの対策を設計しなければならない」というものです。完全には防げない、という前提に立った上で、「侵害を受けても回復できる力（サイバーレジリエンス）」をどう備えるか——それが復旧に共通する考え方です。
今回はSCS★3の要求事項解説の最終回として、大分類「インシデントからの復旧」の1つの要求事項・1つの評価基準を確認します。
「インシデントからの復旧」今回の全体像
今回確認するのは、1つの要求事項・1つの評価基準です。
| NO | 要求事項 | 評価基準の数 |
|---|---|---|
| 7-1-1 | インシデント復旧計画の実行 | 1つ |
1. 7-1-1 インシデント復旧計画の実行（評価基準1つ）
7-1-1は、サイバー攻撃を念頭に、事業継続に必要なシステムを特定し、業務を目標レベルまで回復するための対策を整備することを求める要求事項です。
評価基準はたった1つです。
7-1-1-1： 事業継続上重要なシステムについて、サイバー攻撃を念頭に、業務の目標復旧レベルを定めたうえで、当該レベルまで業務を回復するために必要な対策を整備すること。対策の例として以下が示されています。
- システムによる業務継続： 予備機・クラウド環境等により待機系を整備する
- 人手による業務継続： 電話・FAX等による連絡または業務の実施に備え、影響のある取引先の連絡先および複数の連絡手段を整備する
「重要システム」の定義と対策はIT部門だけではできない
「事業継続上重要なシステム」を定義するというのは、IT部門だけで完結できる作業ではありません。どのシステムが止まったら事業が止まるか、どこまでの停止は許容できるか——これは、経営層や各事業部門の視点なしには判断できません。
私の会社でも、BCM（事業継続管理）委員会という組織が別に存在しており、IT部門が単独で決めるのではなく、事業部門が主導する形でBCPを計画しています。「どのシステムが何日止まったら、どんな影響が出るか」という議論は、経営層・事業部門・IT部門が一体となって進める必要があります。
評価基準では「予備機・待機系」「電話・FAXによる代替」など対策の例が示されています。ただ、ツールのような方法論から考えるより、「事業継続で最も守るべきことは何か」という幹の部分から考えるのが大事だと思っています。例えば、私の会社は製造業なので、顧客に商品を納品することが最も重要なミッションの1つです。在庫と物流が確保できれば最低限の業務は回ります。電話やFAXで受注を受け付けるといった暫定対応ができるなら、システムの復旧には多少時間がかかっても許容できる——そういう判断ができるようになります。同じように各部門から「重要な業務は何か」「システムが止まった場合の代替手段は何か」「復旧まで何日許容できるか」といった情報を整理しておくことが、重要システムと対策の整理につながると考えます。
攻撃だけでなく、インフラ障害・災害にも効果がある
この要求事項はサイバー攻撃を念頭に置いていますが、整備した対策はそれだけに使えるわけではありません。自然災害・電力障害・ハードウェア障害など、IT部門が経験しやすいさまざまな障害場面でも同じ対策が機能します。
「サイバー攻撃に備えて復旧計画を作る」という取り組みは、結果的にBCM全体の底上げにつながります。SCSへの対応を、会社全体の事業継続力を高める機会として捉えてみてください。
連載全体の振り返り：ガバナンスから復旧まで
今回でSCS★3の要求事項解説は最終回になります。第6回から今回まで、要求事項の大分類に沿って順番に確認してきました。最後に全体の流れを振り返っておきます。
| 回 | 大分類 | キーワード |
|---|---|---|
| 第6〜7回 | ガバナンスの整備 | 方針・体制・責任の明確化 |
| 第8〜9回 | 資産・リスクの識別 | 何を守るかを知る |
| 第10〜13回 | 攻撃等の防御 | 防ぐための技術・教育 |
| 第14回 | 攻撃等の検知 | 異常を見つける仕組み |
| 第15回 | インシデントへの対応 | 発生したときに動ける体制 |
| 第16回 | インシデントからの復旧 | 攻撃後に立ち直る力 |
この流れは、NISTサイバーセキュリティフレームワーク（CSF）の「識別→防御→検知→対応→復旧」というサイクルとほぼ対応しています。CSFの考え方については第4回で紹介しているので、まだ読んでいない方はぜひあわせてご覧ください。
第4回：セキュリティ対策の”地図”――NIST サイバーセキュリティフレームワークを知る
まとめ
▪️表を挿入。
今回の「インシデントからの復旧」は、攻撃を受けた後に会社が立ち直るための回復力（レジリエンス）を整備する要求事項です。「必要にならないことが最善」というのはその通りですが、攻撃やサプライチェーンを通じた侵入は発生することを前提に準備しておくことが大切だと思います。
この要求事項はIT部門だけで完結できるものではなく、経営層・事業部門を巻き込んだ取り組みが必要です。SCSへの対応を機会に、「うちの会社はどのシステムが止まったら事業が止まるか」という議論を社内で始めてみるのはいかがでしょうか。
SCS★3要求事項の解説を終えて
第6回から今回まで、SCS★3の要求事項を全大分類にわたって確認してきました。ありがとうございました。
今後も制度の更新情報があれば随時お伝えします。IPAのFAQによると、★3・★4の要求事項への適合・不適合の判断を自身で行うための取得ガイドが2026年10月頃に公表予定とのことです。その際はこのブログでも取り上げる予定です。
→ IPA SCS よくあるご質問（Q3-3） https://www.ipa.go.jp/security/scs/faq.html
なお、SCS制度についてはまだ確定していない部分もあります。制度の詳細や最新情報は公式の情報源を確認するようにしてください。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント