作成日: 2026-06-29
はじめに
「インシデントが起きたとき、あなたの会社は動けますか？」
まだ大きなサイバー攻撃を受けていない会社の方から、「実際にインシデントが起きたら対応できるか不安」という声を何度も聞いたことがあります。その気持ちはよくわかります。経験がないと、何から手をつければいいかイメージができないからです。
私はCSIRTリーダーとして、実際のサイバー攻撃の事後対応を経験しています。インシデントレスポンス（IR）と呼ばれる対応の現場を実際に経験してきたことが、このテーマを書く上での強みだと思っています。今回は、その経験をもとに「インシデントへの対応」の要求事項を解説していきます。
今回は大分類「インシデントへの対応」から、1つの要求事項・6つの評価基準を確認します。
「インシデントへの対応」今回の全体像
今回確認するのは、1つの要求事項・6つの評価基準です。
| NO | 要求事項 | 評価基準の数 |
|---|---|---|
| 6-1-1 | インシデント対応手順 | 6つ |
| 合計 | 6 |
1. 6-1-1 インシデント対応手順（評価基準6つ）
6-1-1は、セキュリティインシデントが発生したときに組織として適切に動けるよう、手順・体制・役割・共有の仕組みを整えることを求める要求事項です。6つの評価基準を整理すると以下の通りです。
- 6-1-1-1： 発見・報告、初動、調査・対応、復旧、最終報告の5つの手順を含んだセキュリティインシデントへの対応手順を定めること
- 6-1-1-2： インシデント発生時の社内外組織（関係当局・所管省庁を含む）の連絡先および報告・情報共有ルートを定めること
- 6-1-1-3： セキュリティを統括する役員（CISOなど）およびセキュリティ担当部署の役割・責任を定めること
- 6-1-1-4： 年1回以上の頻度で6-1-1-2・6-1-1-3で定めた体制を点検すること
- 6-1-1-5： セキュリティインシデントの報告フォーマットを整備すること
- 6-1-1-6： 年1回以上および社内外で重大なインシデントが発生した際に、インシデント事例とその対応策を社内部署へ共有すること
見ていただくとわかる通り、「手順を定める」「体制を決める」「報告フォーマットを作る」「共有する」という、組織として動くための基本の整備が求められています。
実践的に整備するなら：JPCERT/CCのCSIRT構築マテリアル
6つの評価基準を1つずつ確認していく前に、インシデント対応を本格的に整備したい方に強くお勧めしたいリソースを紹介します。
JPCERT/CCが公開しているCSIRT構築マテリアルです。プロジェクト憲章・スコープ記述書などのドキュメントを一通り作成するためのガイドが揃っています。
→ JPCERT/CC CSIRT構築フェーズ https://www.jpcert.or.jp/csirt_material/build_phase.html
私の会社はこの手順で進め、体制・役割・責任、必要な作業、インシデントの重大度の基準と初期対応手順、何が自分たちでできて何を外部に依頼しなければならないか——こういったことを非常にしっかり整理することができました。手間はかかりますが、一度やり切るとインシデントが起きたときに「どう動くか」のイメージが全員に揃います。
6つの評価基準をかいつまんで
時間が取れない方向けに、各評価基準を具体的なリソースと合わせて説明します。
6-1-1-1（対応手順）：
インシデント対応の手順書として、JPCERT/CCが公開しているマニュアルの「項番2」の部分が参考になります。対応部門を自社向けにカスタマイズして使えると思います。
→ JPCERT/CC インシデントハンドリングマニュアル
https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20211130.pdf
さらに詳細なマニュアルを作りたい方はこちらも参考にしてください。
→ JPCERT/CC インシデントレスポンスマニュアル
https://www.jpcert.or.jp/csirt_material/files/13_incident_response_manual_20211130.pdf
6-1-1-2（連絡先・情報共有ルート）：
上記のJPCERT/CCの資料の中に、関係者の連絡先と連絡方法を定義する部分があります。「誰に・何を・どの順番で連絡するか」を事前に決めておくことが大切です。
6-1-1-3（役員・担当部署の役割・責任）：
第6回で確認したガバナンスの要求事項（1-2-1-1）で「セキュリティの役割・責任を定める」ことがすでに求められていました。それができていれば、この評価基準はほぼカバーできているはずです。
第6回：SCS★3の要求事項を読む①――「ガバナンスの整備」8つの評価基準
6-1-1-4（年1回以上の点検）：
体制が変わっていないか、連絡先が古くなっていないかを年1回確認します。人事異動が多い時期の後に点検するのが実用的です。
6-1-1-5（報告フォーマット）：
報告フォーマットのサンプルはJPCERT/CCの資料では見つけられませんでしたが、IPAの資料の23ページに記載されているものが参考になります。
→ IPA 情報漏洩発生時の対応ポイント集
https://www.ipa.go.jp/security/guide/ps6vr70000007pkg-att/rouei_taiou.pdf
6-1-1-6（インシデント事例の社内共有）：
社内で「セキュリティの日」のような機会を作り、できれば経営層レベルで情報を共有してもらい、全社に発信してもらうのが理想的です。セキュリティ担当者には、わかりやすく自分事になるような説明資料を作ることが求められます。
大事なのは「自分たちが運用できるレベル」にすること
インシデント管理については、すでに高度なレベルで実践できている会社が多くあります。ただ、そういった会社のやり方をそのまままねしようとすると、自分たちでは到底運用できないルールになってしまうことがあります。
大企業のCSIRTが持っているような24時間体制・専任チーム・高度なツールを、人手も予算も限られた中でいきなり目指す必要はありません。まず「発生したらどう動くかの基本の流れが決まっている」「誰に連絡するかがわかる」「報告書を書くフォーマットがある」——この3点を押さえることから始めてみてください。
最後にもう一つだけ。ガイドラインや資料を読むのは大変だという方に、私が参考にした本を紹介します。ある企業のセキュリティ体制を立ち上げるときの経験を伝記風にまとめた本で、難しい用語なしに「実際にどう動いたか」が読めます。Noteに書いたので、気になる方はぜひ。
→ けいのNote：セキュリティ体制の立ち上げ本レビュー
https://note.com/kei_scs/n/nd260c15145c2
まとめ
インシデントが起きたときに動けるかどうかは、事前の準備で決まります。手順・体制・フォーマット・共有の仕組みを今のうちに整えておくことが、いざというときの差になります。
このブログが目指していること
私はグローバルな製造業グループのCSIRTリーダーとして働いており、セキュリティ製品を売る立場ではありません。自動車部品メーカーに勤めているため、取引先にセキュリティ要件を「求める側」であり、完成車メーカーから要件を「求められる側」でもあります。
その立場から、「このブログを読んだ担当者が、経営者を動かすための言葉と資料を手に入れられる」ことを目指して書いています。
「要求される側の現場目線」を込めようとしています。難しい言葉をわかりやすく言い換えるだけでなく、「現場では実際にどう判断するか」という視点を大事にします。
次回の予告
次回は「インシデントからの復旧」を確認します。SCS★3の要求事項の解説としては最終回になります。
相談してみませんか？
「ちょっと聞いてみたい」という段階でも構いません。私の経歴・支援内容の詳細は「このブログについて」をご覧ください。
なお、SCSへの関心が高まる中、制度に便乗した不審な勧誘も出てきています。私のことも含め、見知らぬ相手を安易に信用しすぎないようご注意ください。経産省も注意喚起を出しています。
→ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に係る不適切な勧誘に御注意ください https://www.meti.go.jp/policy/netsecurity/20260427_scs.html
CISSP・情報処理安全確保支援士 ｜ けい
コメント