【SCS評価制度★3徹底解説 第7回】SCS評価制度★3「インシデントへの対応」とは？対応手順・連絡体制・報告方法を実務目線で解説

情報セキュリティ

サイバー攻撃への対策では、攻撃を「防ぐこと」や「検知すること」が重要です。

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

そのため企業には、

「インシデントが発生したときに、誰が、何を、どのような順番で行うのか」

をあらかじめ決めておくことが求められます。

前回の連載第6回では、SCS評価制度★3の「攻撃等の検知」について解説しました。

攻撃や不審な事象を検知できたとしても、

  • 誰に報告すればよいのか分からない
  • 初動対応が決まっていない
  • 経営層へいつ報告するのか分からない
  • 外部のどこへ連絡すればよいのか分からない

という状態では、被害を拡大させてしまう可能性があります。

そこで連載第7回となる今回は、SCS評価制度★3の7つの大分類のうち、6番目となる「インシデントへの対応」について解説します。

IPAが2026年4月21日に公開した★3・★4の要求事項・評価基準では、「インシデントへの対応」の★3評価として、インシデント対応手順、社内外の連絡体制、役割・責任、体制の点検、報告フォーマット、事例共有に関する6つの評価基準が示されています。

この記事では、公式の要求事項・評価基準を確認しながら、

  • 何が求められているのか
  • 企業は実際に何をすればよいのか
  • どのような文書や記録を準備しておけばよいのか
  • ★3評価に向けてどのような点に注意すべきか

を、企業の経営者・情報システム担当者・セキュリティ担当者向けに分かりやすく解説します。

前回までの連載記事

公式資料

IPA公式資料

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

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

経済産業省公式資料

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

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

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

SCS評価制度★3「インシデントへの対応」とは

SCS評価制度★3では、大分類6として「インシデントへの対応」が設定されています。

その中の要求事項は次のとおりです。

大分類 中分類 評価項目 要求事項
6 インシデントへの対応 6-1 インシデント管理 6-1-1 インシデント対応手順 セキュリティインシデントへの対応手順、対応体制等を定めること

つまり、この分野で求められているのは、

「セキュリティインシデントが起きたときに、組織として対応できる準備をしておくこと」

です。

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

「誰に連絡するのか」

「何をすればよいのか」

「誰が判断するのか」

を考え始めるのでは、対応が遅れる可能性があります。

例えば、従業員から、

「パソコンのファイルが突然開けなくなった」

「不審な添付ファイルを開いてしまった」

「身に覚えのないログイン通知が届いた」

という報告があったとします。

このとき、

  • 誰が最初に報告を受けるのか
  • 端末をネットワークから切り離すのか
  • 電源を切ってよいのか
  • 他の端末への影響を誰が確認するのか
  • 経営層へいつ報告するのか
  • 外部の専門事業者へ連絡するのか

といったことが決まっていなければ、現場は混乱します。

SCS評価制度★3では、このような事態に備えて、6つの具体的な評価基準が定められています。

「インシデントへの対応」で求められる6つの評価基準

SCS評価制度★3の「6-1-1 インシデント対応手順」では、次の6つの評価基準が示されています。

評価基準No 概要
6-1-1-1 インシデント対応手順を定める
6-1-1-2 社内外の連絡先と報告・情報共有ルートを定める
6-1-1-3 経営層とセキュリティ担当部署の役割・責任を定める
6-1-1-4 年1回以上、インシデント発生時の体制を点検する
6-1-1-5 インシデント報告フォーマットを整備する
6-1-1-6 インシデント事例と対応策を社内へ共有する

ここからは、それぞれの評価基準について詳しく見ていきます。

6-1-1-1　インシデント対応手順を定める

求められていること

SCS評価制度★3では、セキュリティインシデントへの対応手順として、少なくとも次の5つの段階を含む手順を定めることが求められています。

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

これは、インシデント発生時の対応を、その場の担当者の判断だけに任せないためのものです。

①発見報告

異常を発見した人が、誰に、どのような方法で報告するのかを決めます。

②初動

被害拡大を防止するため、端末の隔離、アカウントの停止、関係者への第一報などを行います。

③調査・対応

何が起きたのか、どこまで影響が広がっているのかを確認し、必要な対応を行います。

④復旧

原因を取り除き、安全性を確認したうえで、システムや業務を復旧します。

⑤最終報告

発生原因、影響範囲、実施した対応、再発防止策などを整理します。

SCS評価制度の公式評価基準でも、この5段階を含むインシデント対応手順を定めることが明示されています。

実務ではどのように対応すればよいのか

まず、自社で想定されるセキュリティインシデントを整理します。

例えば、

  • マルウェア感染
  • ランサムウェア感染
  • フィッシングメール
  • アカウントの不正利用
  • 情報漏えい
  • Webサイトの改ざん
  • 不審な外部通信
  • USBメモリやPCの紛失
  • 取引先からのインシデント連絡

などです。

すべての事象について詳細なマニュアルを作成する必要はありませんが、少なくとも、

「異常を発見してから、誰がどのように動くのか」

という基本的な流れは整理しておく必要があります。

特に重要なのは、一般の従業員にインシデントかどうかを判断させないことです。

従業員が、

「大したことではないだろう」

「再起動すれば直るだろう」

と自己判断してしまえば、報告が遅れる可能性があります。

そのため、

「インシデントかどうか分からなくても、異常を感じたら報告する」

というルールを作ることが重要です。

また、初動対応についても、

  • 誰が端末を確認するのか
  • 誰がネットワーク隔離を判断するのか
  • 何を記録するのか
  • どの段階で外部事業者へ連絡するのか

を可能な範囲で決めておきましょう。

作成・整備しておきたい文書や記録

  • インシデント対応規程
  • インシデント対応フロー
  • 初動対応手順書
  • 従業員向け異常発見時の報告手順
  • インシデント対応記録

長いマニュアルだけでなく、緊急時にすぐ確認できる1枚程度の初動対応フローを用意しておくことも有効です。

よくある不備

  • インシデント対応マニュアルはあるが内容が古い
  • 文書が長すぎて緊急時に確認できない
  • 従業員が報告方法を知らない
  • 担当者しか手順を知らない
  • 「ウイルス感染時」など一部の事象しか想定していない
  • 初動対応の判断者が明確になっていない

重要なのは、文書を作ることではありません。

実際にインシデントが発生したときに、その手順を使える状態になっていることです。

6-1-1-2　社内外の連絡先と報告・情報共有ルートを定める

求められていること

セキュリティインシデント発生時における、

  • 社内の関係者
  • 社外の関係組織
  • 関係当局
  • 所管省庁

などの連絡先と、報告・情報共有のルートを定めることが求められています。

インシデント発生時に、

「誰に連絡すればよいか分からない」

「ベンダーの連絡先を探している」

という状態では、初動対応が遅れてしまいます。

実務ではどのように対応すればよいのか

まず、社内の報告ルートを明確にします。

例えば、

異常を発見した従業員
↓
所属長または情報システム担当者
↓
セキュリティ責任者
↓
経営層

といった流れです。

ただし、企業規模によって体制は異なります。

中小企業では、

  • IT担当者が1人しかいない
  • セキュリティ専任者がいない
  • 総務担当者がITを兼任している

ということも珍しくありません。

その場合でも、新しい部署を作ることが必須なのではなく、

現在の組織の中で誰が第一報を受け、誰が判断するのかを決めること

が重要です。

社外の連絡先としては、自社の状況に応じて、

  • IT保守事業者
  • セキュリティ事業者
  • クラウドサービス事業者
  • システムベンダー
  • サイバー保険会社
  • 顧問弁護士
  • 警察
  • 関係当局
  • 所管省庁
  • 重要な取引先

などを整理します。

作成・整備しておきたい文書や記録

  • 緊急連絡先一覧
  • 社内報告ルート図
  • 社外連絡先一覧
  • インシデント発生時のエスカレーションルール
  • 関係当局・所管省庁の連絡先一覧

連絡先には、可能であれば、

  • 組織名
  • 担当部署
  • 担当者
  • 電話番号
  • メールアドレス
  • 受付時間
  • 契約番号や顧客番号

などを記載しておくとよいでしょう。

よくある不備

  • 担当者が退職している
  • 電話番号が古い
  • ベンダーの通常窓口しか記載されていない
  • 休日・夜間の連絡方法が分からない
  • 誰がどこへ連絡するのか決まっていない
  • 連絡先一覧を作成してから一度も更新していない

インシデントが起きてから連絡先を探すのではなく、平時に整理しておくことが重要です。

6-1-1-3　経営層とセキュリティ担当部署の役割・責任を定める

求められていること

インシデント発生時における、

  • セキュリティを統括する役員
  • セキュリティ担当部署

の役割と責任を定めることが求められています。

公式の評価基準では、CISOを設置している企業の場合はCISOなど、セキュリティを統括する役員とセキュリティ担当部署の役割・責任を明確にすることが示されています。

実務ではどのように対応すればよいのか

インシデント対応では、技術的な判断だけでなく、経営判断が必要になることがあります。

例えば、

  • システムを停止するのか
  • 業務を継続するのか
  • 顧客や取引先へ報告するのか
  • 外部へ公表するのか
  • 緊急で外部専門家へ調査を依頼するのか

といった判断です。

これらを情報システム担当者だけに任せるべきではありません。

例えば、次のように役割を整理します。

従業員・現場

  • 異常の発見
  • 速やかな報告
  • 指示に従った初動対応

情報システム・セキュリティ担当者

  • 状況確認
  • 技術的な初動対応
  • 被害範囲の確認
  • 経営層への情報提供

セキュリティ責任者

  • インシデント対応全体の統括
  • 関係部署との調整
  • 対応方針の整理

経営層

  • 重大な業務判断
  • 業務停止・再開の判断
  • 経営資源投入の判断
  • 対外説明に関する判断

企業規模によっては、同じ人物が複数の役割を担当することもあります。

重要なのは、

誰が何を担当し、最終的に誰が判断するのかが分かる状態にすること

です。

作成・整備しておきたい文書や記録

  • インシデント対応体制図
  • 役割・責任分担表
  • インシデント対応規程
  • エスカレーション基準
  • 経営層への報告基準

よくある不備

  • 情報システム担当者にすべての責任が集中している
  • 最終判断者が決まっていない
  • 経営層へ報告する基準がない
  • 担当者不在時の代替者が決まっていない
  • 文書上の役割と実際の組織体制が一致していない

特に中小企業では、

「ITのことは○○さんに聞けばよい」

という属人的な体制になりがちです。

しかし、その担当者が不在の場合や、その担当者自身が被害を受けた場合にも対応できる体制を考えておく必要があります。

6-1-1-4　年1回以上、インシデント発生時の体制を点検する

求められていること

SCS評価制度★3では、6-1-1-2で定めた連絡体制と、6-1-1-3で定めた役割・責任について、年1回以上の頻度で点検することが求められています。

一度体制を作ったとしても、企業の状況は変化します。

  • 人事異動
  • 退職
  • 組織変更
  • ベンダー変更
  • システム変更
  • クラウドサービスの追加

などにより、以前作成した体制が使えなくなっている可能性があります。

実務ではどのように対応すればよいのか

少なくとも年1回、

  • 連絡先は正しいか
  • 担当者は在籍しているか
  • 役割分担は現在の組織と合っているか
  • 外部ベンダーとの契約は継続しているか
  • 新しいシステムが追加されていないか

を確認します。

また、当社としては、単に文書を見直すだけでなく、可能であれば机上訓練を実施することを推奨します。

例えば、

月曜日の午前9時、従業員から「パソコンのファイルが突然開けなくなった」という連絡があった。

という状況を設定します。

そのうえで、

  • 誰が第一報を受けるのか
  • 誰が端末を確認するのか
  • 誰がネットワークからの隔離を判断するのか
  • 他の端末への影響をどう確認するのか
  • いつ経営層へ報告するのか
  • どの段階で外部事業者へ連絡するのか

を実際に確認します。

すると、

「担当者が休みの場合が決まっていない」

「経営層への連絡方法が分からない」

「外部ベンダーの緊急連絡先が分からない」

といった問題が見つかることがあります。

訓練は、完璧に対応できることを確認するためだけのものではありません。

本当のインシデントが起きる前に、

「現在の体制では対応できない部分を見つけること」

にも大きな意味があります。

作成・整備しておきたい文書や記録

  • 年次点検チェックリスト
  • 体制見直し記録
  • 連絡先確認記録
  • 机上訓練実施記録
  • 訓練結果報告書
  • 改善計画

よくある不備

  • 体制を作成しただけで見直していない
  • 点検した記録が残っていない
  • 担当者名だけ変更し、実際の対応方法を確認していない
  • 訓練を一度も行っていない
  • 訓練で見つかった課題を改善していない

★3への対応では、単に「現在の文書があるか」だけでなく、継続して運用していることを示せる状態を意識することが重要です。

6-1-1-5　インシデント報告フォーマットを整備する

求められていること

SCS評価制度★3では、セキュリティインシデントの報告フォーマットを整備することが求められています。

インシデントが発生すると、多くの情報が短時間に集まります。

その情報が、

  • 口頭
  • メール
  • チャット
  • 個人のメモ

などに分散すると、後から事実関係を整理することが難しくなります。

実務ではどのように対応すればよいのか

少なくとも、次のような情報を記録できるフォーマットを用意しておきます。

基本情報

  • 発見日時
  • 発見者
  • 対象端末・システム
  • 発生した事象

初動対応

  • 対応日時
  • 対応者
  • 実施した内容

影響

  • 業務への影響
  • 対象となるシステム
  • 情報漏えいの可能性
  • 他の端末やシステムへの影響

対応状況

  • 現在の状況
  • 実施済みの対応
  • 今後実施する対応
  • 対応責任者
  • 現在の状況
  • 実施済みの対応
  • 今後実施する対応
  • 対応責任者

特に重要なのが、時系列で記録を残すことです。

例えば、

時刻 内容 対応者
9:05 従業員から異常の報告 総務部○○
9:10 情報システム担当へ連絡 総務部○○
9:15 対象端末をネットワークから隔離 情報システム部○○
9:30 経営層へ第一報 セキュリティ責任者

という形で記録します。

インシデント対応が長期化するほど、

「いつ、誰が、何を確認し、何を判断したのか」

という記録が重要になります。

作成・整備しておきたい文書や記録

  • インシデント第一報フォーマット
  • インシデント管理票
  • 対応時系列記録
  • 経営層向け報告書
  • 最終報告書

最初から複雑な様式を作る必要はありません。

むしろ、緊急時に入力項目が多すぎると使われなくなる可能性があります。

自社で実際に使えるシンプルなフォーマットから始めることが重要です。

よくある不備

  • 報告書の様式はあるが誰も存在を知らない
  • 項目が多すぎて緊急時に使えない
  • 最終報告書しかなく初動時の記録様式がない
  • 時系列の記録が残らない
  • チャットや口頭で対応が進み、後から経緯を確認できない

6-1-1-6　インシデント事例と対応策を社内へ共有する

求められていること

SCS評価制度★3では、

年1回以上、さらに社内外で重大なセキュリティインシデントが発生した際に、インシデント事例とその対応策を社内部署へ共有すること

が求められています。

ここで重要なのは、インシデントを一部の担当者だけの経験で終わらせないことです。

実務ではどのように対応すればよいのか

自社で発生した事例については、

  • 何が起きたのか
  • 原因は何だったのか
  • どのような対応をしたのか
  • 今後どのように防ぐのか

を整理し、必要な範囲で社内共有します。

例えば、従業員がフィッシングメールを受信したものの、不審だと気づいて報告し、被害を防げたとします。

この場合、

「被害がなかったので終了」

とするのではなく、

  • どのようなメールだったのか
  • どの部分が不審だったのか
  • どのように報告したのか

を共有すれば、他の従業員が同様の攻撃を受けた際の参考になります。

また、他社で発生した重大なインシデントも重要です。

例えば、

  • VPN機器の脆弱性から侵入された
  • 委託先から侵入された
  • 管理者アカウントを悪用された
  • バックアップまで暗号化された

という事例があれば、

「自社でも同じことが起きないか」

という視点で確認します。

他社のインシデントを単なるニュースとして読むのではなく、自社の対策改善につなげることが重要です。

作成・整備しておきたい文書や記録

  • インシデント事例共有資料
  • 社内周知メール
  • セキュリティ教育資料
  • 定期的なセキュリティ情報共有記録
  • インシデント後の再発防止策
  • 改善実施記録

よくある不備

  • インシデント情報をシステム担当者だけで保有している
  • 被害がなかった事例を記録していない
  • 他社事例をニュースとして紹介するだけで終わっている
  • 共有した記録が残っていない
  • 再発防止策を決めても実施状況を確認していない

インシデントから得た情報は、企業にとって重要なセキュリティ上の知見です。

同じ問題を繰り返さない仕組みを作ることが重要です。

SCS評価制度★3「インシデントへの対応」で重要なのは、マニュアルの存在ではない

ここまで6つの評価基準を確認してきました。

この分野で特に注意したいのが、

「インシデント対応マニュアルを作れば終わり」

と考えてしまうことです。

例えば、マニュアルが存在していても、

  • どこに保存されているか分からない
  • 担当者が内容を知らない
  • 何年も更新されていない
  • 100ページ以上あり緊急時に確認できない
  • 現在の組織やシステム構成と合っていない

のであれば、実際のインシデント発生時に役立たない可能性があります。

SCS評価制度★3への対応を進める際には、

「文書があるか」

だけではなく、

「明日インシデントが発生しても、この体制で本当に動けるか」

という視点で確認することが重要です。

中小企業では「すべて自社で対応する」必要はない

中小企業では、

  • セキュリティ専任者がいない
  • 情報システム担当者が少ない
  • 高度なインシデント調査ができない

ということも珍しくありません。

だからといって、すべての対応を自社だけで完結できる体制を作る必要はありません。

重要なのは、

自社で対応する範囲と、外部へ依頼する範囲を事前に整理しておくこと

です。

例えば、

自社で行うこと

  • 異常の発見と報告
  • 対象端末の特定
  • 決められた範囲での初動対応
  • 経営層への報告
  • 業務影響の確認

外部へ依頼すること

  • 高度なログ分析
  • フォレンジック調査
  • マルウェア解析
  • 侵入経路の特定
  • 専門的な復旧支援

といった役割分担が考えられます。

インシデントが起きてから支援先を探すのではなく、

「困ったときに誰へ相談するのか」

を平時から決めておくことが重要です。

SCS評価制度★3「インシデントへの対応」チェックリスト

自社の現在の対応状況を確認してみましょう。

インシデント対応手順

□ 発見報告から最終報告までの手順を定めている
□ 従業員が異常発見時の報告方法を知っている
□ 初動対応の基本的な手順を定めている
□ 誰が対応を開始するのか明確になっている

連絡体制

□ 社内の報告ルートを定めている
□ 外部の緊急連絡先を整理している
□ 関係当局や所管省庁への連絡先を確認している
□ 休日や夜間の連絡方法を確認している

役割・責任

□ セキュリティ責任者を明確にしている
□ 経営層の役割を定めている
□ 情報システム・セキュリティ担当者の役割を定めている
□ 担当者不在時の対応を考えている

定期点検

□ 年1回以上、対応体制を確認している
□ 連絡先を最新の状態に更新している
□ 点検した記録を残している
□ 必要に応じて机上訓練を実施している

報告

□ インシデント報告フォーマットがある
□ 初動時の情報を記録できる
□ 対応の時系列を記録できる
□ 最終報告を作成できる

情報共有

□ 年1回以上、インシデント事例を社内共有している
□ 重大な社内外の事例を必要な部署へ共有している
□ 事例から自社の対策を見直している
□ 再発防止策の実施状況を確認している

チェックが付かなかった項目については、今後の改善項目として整理していきましょう。

まとめ｜SCS評価制度★3では「インシデント発生後に組織として動けるか」が問われる

今回は、SCS評価制度★3の7つの大分類のうち、6番目となる「インシデントへの対応」について解説しました。

SCS評価制度★3では、次の6つの評価基準が示されています。

  1. インシデント対応手順を定める
  2. 社内外の連絡先と報告・情報共有ルートを定める
  3. 経営層とセキュリティ担当部署の役割・責任を定める
  4. 年1回以上、インシデント発生時の体制を点検する
  5. インシデント報告フォーマットを整備する
  6. インシデント事例と対応策を社内へ共有する

重要なのは、単に規程やマニュアルを作成することではありません。

実際にインシデントが発生したとき、その手順と体制を使って組織が迅速に動けること

が重要です。

これまでの連載では、

  • 組織としてセキュリティ対策を管理する
  • 取引先を管理する
  • リスクを特定する
  • 攻撃を防御する
  • 攻撃を検知する

という対策を見てきました。

今回の「インシデントへの対応」は、

「攻撃や異常を検知した後、実際にどう動くのか」

を決める分野です。

SCS評価制度★3への対応を進める際には、

「要求事項を満たす文書があるか」

だけではなく、

「明日サイバー攻撃を受けたとして、自社は本当に迅速に適切に対応できるか」

という視点で現在の体制を確認してみてください。

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

SCS評価制度★3への対応では、要求事項を読んだだけでは、

「自社はどこまでできているのか」

「どのような文書を作ればよいのか」

「現在の運用で評価基準を満たせるのか」

「何から優先して改善すればよいのか」

が分かりにくい場合があります。

特にインシデント対応については、他社のマニュアルや一般的なひな形をそのまま利用しても、自社の組織体制やシステム環境と合わなければ、実際のインシデント発生時に機能しない可能性があります。

株式会社クロイツでは、企業の現在の状況を確認したうえで、

  • SCS評価制度★3の要求事項に対する現状確認
  • 不足している対策の整理
  • インシデント対応フローの整備
  • 初動対応手順の作成
  • 社内外の連絡体制の整理
  • 経営層・担当者の役割分担の整理
  • インシデント報告フォーマットの整備
  • サイバーBCPの策定
  • 机上訓練の実施
  • 訓練結果を踏まえた改善
  • ★3の専門家確認を見据えた準備

などをご支援しています。

当社には、情報処理安全確保支援士Pの資格を持ち、攻撃者の視点を踏まえたセキュリティ支援を行う専門家が在籍しています。

単に評価項目を満たすための書類を作るのではなく、

「実際にサイバー攻撃を受けたときに機能する対策になっているか」

という視点を重視しています。

「SCS評価制度★3について相談したい」

「自社の現在の対策状況を確認したい」

「インシデント対応マニュアルはあるが、本当に使えるのか不安」

「社内にセキュリティの専門家がおらず、対応方法が分からない」

という企業様は、お気軽に株式会社クロイツまでご相談ください。

お問い合わせ

次回予告｜SCS評価制度★3「インシデントからの復旧」

インシデントへの対応によって攻撃を封じ込めても、それだけで企業の業務が元に戻るとは限りません。

サイバー攻撃によってシステムが停止した場合には、

  • どの業務を優先して復旧するのか
  • どのレベルまで業務を戻すのか
  • システムが利用できない間、どのように業務を継続するのか
  • バックアップから本当に復旧できるのか

といった準備が必要になります。

次回の連載第8回では、SCS評価制度★3の7つの大分類の最後となる、

「インシデントからの復旧」

について詳しく解説します。