SCS評価制度での変化ーインシデント対策は「起こす前」より「起きた後」で評価される

この記事の著者：代表取締役社長CEO 金築 敬晃

はじめに

2026年3月、経済産業省と内閣官房国家サイバー統括室が「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」を公表し、これに基づきIPAが運営する「SCS評価制度」の詳細が明らかになりつつあります。取引先からの要請で★3・★4の取得を検討し始めた企業も多いのではないでしょうか。

公開された要求事項・評価基準を読み込むと、この制度のひとつの明確なメッセージが見えてきます。それは、「攻撃を防げるか」だけでなく「攻撃を受けた後に復帰できるか」が、最低ラインの★3の段階から正面から問われているということです。

本記事では、SCS評価制度の要求事項をもとに、なぜ「復帰」が重要なのか、そして企業は何を準備すべきなのかを整理します。

SCS評価制度の基本構造

SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策水準を★の数で段階的に評価する制度です。

注目すべきは、要求事項の大分類の構成です。要求事項は次の7つの大分類で構成されており、これはNIST CSF（サイバーセキュリティフレームワーク）の6機能（統治・識別・防御・検知・対応・復旧）に対応づけられています。

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

つまり制度設計の時点で、「防御」は7分類のうちの1つにすぎず、「対応」と「復旧」がそれぞれ独立した大分類として立てられているのです。防御一辺倒の対策では、この制度の要求水準を満たすことはできません。

なぜ「起こす前」だけでは足りないのか

背景にあるのは、「侵入を100%防ぐことはできない」という現実的な前提への転換です。

★3が想定する脅威は「広く認知された脆弱性を悪用する一般的なサイバー攻撃」です。VPN機器やルータの既知脆弱性を突く攻撃、メール経由のランサムウェア感染などは、パッチ適用や多要素認証といった防御策で確率を下げることはできても、ゼロにはできません。取引先の立場から見れば、知りたいのは「御社は攻撃されないか」ではなく、「攻撃されたとき、うちへの被害拡大を防ぎ、供給をどれだけ早く回復できるか」です。

実際、★3の達成水準のイメージには「インシデント発生時に、取引先を含む社内外関係各所への報告・共有に必要な最低限の手順が定義、実施されている」ことが明記され、★4では「事業継続に向けた取組」を含むサプライチェーン強靭化策が水準として掲げられています。サプライチェーン全体の視点に立てば、1社の停止は連鎖的な供給停止につながるため、復旧力（レジリエンス）こそが評価の中心的関心事になるのは必然といえます。

★3の時点で求められる「復帰」の準備

「復旧まで求められるのは上位の★4からだろう」と考えると、足元をすくわれます。★3の要求事項をひもとくと、インシデント対応・復旧に関して具体的な準備が求められています。

(1) 5段階のインシデント対応手順の整備（No.6-1-1-1）

★3では、以下の5つの手順を含むインシデント対応手順の策定が求められます。

①発見報告 → ②初動 → ③調査・対応 → ④復旧 → ⑤最終報告

注目したいのは、手順の中に「④復旧」が明示的に組み込まれている点です。封じ込めて終わり、ではなく、業務を元に戻すところまでが「インシデント対応」として定義されています。

(2) 報告・連絡体制の整備（No.6-1-1-2〜6-1-1-6）

• 関係当局・所管省庁を含む社内外の連絡先と報告・情報共有ルートの策定
• インシデント発生時のCISO等・セキュリティ担当部署の役割・責任の明確化
• 体制の年1回以上の点検
• 報告フォーマットの整備
• インシデント事例と対応策の社内共有（年1回以上、および重大インシデント発生時）

さらに取引先管理の分類でも、機密情報を共有する取引先との間で「インシデント発生時の自社と取引先の役割及び責任」を定めること（No.2-1-4-1）が★3要求です。復帰は自社だけで完結せず、サプライチェーン上の連携を前提に設計する必要があります。

(3) 復旧の土台となるバックアップ（No.4-3-4）

防御の分類に置かれてはいますが、実質的に復旧のための要求といえるのがバックアップです。★3で求められるのは次の3点です。

• 取得対象・取得頻度・保管期間を定めたバックアップの取得
• 重要な機密情報についての遠隔地バックアップ
• バックアップ対象ごとのリストア手順書の整備

「取っているだけ」のバックアップでは足りず、戻すための手順書までが★3の必須要件です。ランサムウェア被害からの復旧で最も問題になるのは「バックアップはあったが戻し方が確立していなかった」「バックアップごと暗号化された」というケースであり、遠隔地保管と手順書整備はまさにその教訓を反映した要求といえます。

(4) 目標復旧レベルの設定（No.7-1-1-1）

大分類7「インシデントからの復旧」では、事業継続上重要なシステムについて、サイバー攻撃を念頭に業務の目標復旧レベルを定めた上で、そのレベルまで業務を回復するための対策整備が★3で求められます。評価基準には対策の例として次の2つが挙げられています。

• システムによる業務継続：予備機やクラウド環境等による待機系の整備
• 人手による業務継続：電話・FAX等による連絡や業務実施に備えた、取引先の連絡先および複数の連絡手段の整備

「人手による業務継続」が正面から例示されているのは示唆的です。システムが完全復旧するまでの間、アナログ手段ででも供給や連絡を止めない──これがサプライチェーンの文脈における「復帰」の実像です。

(5) 全員参加の教育・訓練（No.4-2-2）

インシデント発生時の対応に関する教育・訓練も★3要求です。役員・従業員だけでなく派遣社員・受入出向者まで対象に、新規受入れ時および年1回以上の実施、記録の保管、内容の年次点検が求められます。手順書を作って終わりではなく、「動ける組織」であることの証跡が必要になります。

★4で問われる「復帰できることの実証」

★4では、復帰への要求が「計画」から「実証」へと一段深まります。

RPO・RTOの実証（No.7-1-1-2）

事業継続上重要なシステムについて、以下が求められます。

• 目標復旧時点（RPO）への復旧ができるようにバックアップを保管すること
• リストア手順書どおりに、かつ目標復旧時間（RTO）内でバックアップの復元ができることを確認すること

つまり、机上の計画ではなく「実際に時間内で戻せること」の確認までが要求事項です。リストア訓練を実施していない企業にとっては、これが★4取得の実務上のハードルになるでしょう。

対応・復旧を支える周辺要求

★4では、復帰を支える前提条件も広がります。

• 調査に必要なログの取得・保管（No.4-4-3-1）：ファイアウォール、プロキシサーバ、認証サーバのログを6か月保管。インシデント発生時に「何が起きたか」を特定できなければ、安全な復旧判断はできません。
• インシデントレベルの定義（No.5-2-1）：インシデントのレベルとレベルごとの対象範囲を定めて周知し、アラート受領時にどのレベルに該当するかを分析・判断する。重大度に応じた対応・復旧の優先順位づけの前提です。
• サイバー攻撃の監視・分析体制（No.1-2-2）：予兆の検知から「インシデントが発生した場合の対応が導き出せる体制」の整備。

実地審査の確認対象にも「復旧準備」

見逃せないのが評価プロセスです。★4の実地審査で確認すべき事項の例として、制度構築方針は次の3つを挙げています。

• 脆弱性の管理体制・管理プロセス
• セキュリティインシデント対応手順
• 事業継続要件に沿った復旧準備

3つの例示のうち2つが「起きた後」に関する項目です。審査する側も、防御設定の網羅性より先に「この会社はインシデントから立ち直れるか」を証跡ベースで見に来る、と読むのが自然でしょう。

実務への示唆──「復帰」から逆算する対策整備

SCS評価制度への対応を検討する企業にとって、要求事項リストを上から順に潰していくよりも、「自社が止まったとき、何日で・どのレベルまで戻せれば取引先に迷惑をかけないか」から逆算するアプローチが有効です。具体的には次の順序で考えることをおすすめします。

1. 事業継続上重要なシステムと業務の特定──何が止まるとサプライチェーンに影響するか
2. 目標復旧レベル・RPO・RTOの設定──取引先との関係から許容停止時間を定義する
3. バックアップとリストア手順の整備・実証──定めた目標内で本当に戻せるかを試す
4. 5段階の対応手順と報告ルートの整備──取引先・所管省庁への報告を含めて設計する
5. 教育・訓練による定着──全員が「発見したら誰に報告するか」を言えるか

この順序は、そのまま★3→★4の要求事項の中核をカバーします。防御策（パッチ管理、多要素認証、ネットワーク境界防護など）が不要という意味では決してありませんが、防御は「復帰までの時間を稼ぎ、頻度を下げる」ための手段と位置づけ直すと、投資の優先順位が明確になります。

そこでIncident Lake

ここまで見てきたとおり、SCS評価制度が問うインシデント対応の難所は、発見報告から初動・調査・復旧・最終報告までの5段階を滞りなく回す「速度」、そして取引先・所管省庁を含む社内外へ、矛盾のない報告を期限内に展開していく「記録と伝達の正確さ」です。

検知されたアラートをインシデントレベルに紐づけて判断し、どのシステム・どの取引先に影響が及ぶかを特定し、報告フォーマットに沿った速報・最終報告へと展開しながら、年次点検や評価・審査で示せる証跡として残していく。この一連の流れを人手とチャットの往復だけで回すのは、正直なところ限界があります。

Incident Lakeは、この流れを支えるインシデント管理プラットフォームです。インシデント発生時の報告から復帰までの対応、レポートの作成や管理までを自動化し、担当者が本来集中すべき「被害を止め、サービスを復旧させること」に時間を使えるようにします。対応の記録がそのまま蓄積されるため、★3の専門家確認や★4の実地審査で求められる証跡の整備にもつながります。

SCS評価制度という形で「対応と復旧の実力」が取引先から可視化される今だからこそ、インシデントの報告と記録の仕組みを、人の頑張りに頼らない形に変えておくことをおすすめします。

なお、SCS評価制度のより具体的な実施内容は2026年度に検討・詳細化が進められています。最新の情報は、IPAおよび経済産業省の公表資料でご確認ください。

参考

• IPA「SCS評価制度の詳細情報」
• 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」（2026年3月27日）
• SCS評価制度 ★3・★4要求事項・評価基準

※本記事は2026年8月時点の公開情報に基づきます。

この記事の著者
代表取締役社長CEO 金築 敬晃

株式会社SIGQ 代表取締役
筑波大学大学院修了、専門はデータベースと分散システム。
AI時代に必須となる、運用データという非構造化・リアルタイムな情報を扱うエンジニア。
新卒で株式会社マネーフォワードに入社。ベトナム拠点への出向を含め、海外を含む開発現場でマネジメントや開発に従事。
2022年に株式会社プレイドに入社し、Platform Engineeringを担当。大規模分散データシステムの開発に携わる。
2024年に株式会社SIGQを設立。