インシデント対応報告書の書き方|現場で使えるテンプレートと記載のポイント

インシデント対応・監視

「とりあえず時系列でまとめました」——インシデント発生後、若手エンジニアが提出した報告書を見ると、このパターンが多いです。何時に何が起きたかは書いてある。でも「なぜ起きたのか」「再発をどう防ぐのか」が抜けている。

報告書は記録ではなく、次のアクションを引き出すための文書です。

この記事では、経営層にも技術者にも伝わるインシデント対応報告書の構成・書き方・テンプレートを解説します。

インシデント対応報告書とは——何のために書くのか

インシデント対応報告書 セキュリティインシデント発生時に、対応の経緯・原因・影響範囲・再発防止策をまとめた文書。社内の経営層・関係部門への説明資料になるほか、将来の対応手順改善や監査対応の記録としても機能する。

報告書を書く目的は大きく3つあります。

目的 内容
説明責任 何が起きたかを正確に関係者・経営層に伝える
再発防止 根本原因を特定し、同じインシデントを繰り返さない
組織学習 対応の良否を振り返り、次回の対応品質を上げる

「記録を残す」ことは目的ではありません。報告書を読んだ人が次のアクションを取れる状態にすることが報告書の本質です。

インシデント対応の全体フローについては「セキュリティインシデント対応入門|若手エンジニアが最初に知っておくべき対応フローと考え方」を参照してください。

報告書に必ず含めるべき7つの要素

どんなインシデントの報告書でも、以下の7つの要素は必ず含めます。

要素 内容 よくある抜け漏れ
① インシデント概要 何が起きたかを3行以内で要約 長すぎて要点が見えない
② 発生日時・検知日時 いつ起きて、いつ気づいたか 検知までの時間が抜けている
③ 影響範囲 影響を受けたシステム・ユーザー・データ 「調査中」のまま放置される
④ 対応経緯(タイムライン) 時系列での対応内容 誰が何をしたかが抜けている
⑤ 根本原因 なぜ発生したか 「不正アクセスのため」で終わっている
⑥ 再発防止策 具体的な対策と担当・期限 抽象的な対策で終わっている
⑦ 添付資料 ログ・スクリーンショット・証跡 本文と証跡が紐づいていない

この7つのうち、⑤根本原因と⑥再発防止策が最も重要です。この2つが曖昧な報告書は「記録」にはなっても「報告書」にはなりません。

読み手別の書き分け——経営層向けと技術者向けの違い

インシデント報告書には2種類の読み手がいます。それぞれが知りたいことは異なります。

経営層・管理職 技術担当者・情シス
知りたいこと 事業への影響・対応状況・再発防止の見通し 技術的な原因・対応手順・設定変更の詳細
求める粒度 概要・要点のみ 詳細なログ・コマンド・設定値
文体 平易な日本語・専門用語を避ける 技術用語OK・具体的な数値や手順

解決策:2部構成にする

1つの報告書を「エグゼクティブサマリー(概要部)」と「技術詳細部」の2部構成にすることで、両方の読み手に対応できます。

【報告書の構成】
第1部:エグゼクティブサマリー(1〜2ページ)
 → 経営層・管理職向け。専門用語なし・要点のみ

第2部:技術詳細
 → 技術担当者向け。ログ・手順・設定値を詳細に記載

経営層は第1部だけ読めば判断できる、技術者は第2部で詳細を確認できる、という構成です。

各セクションの書き方とポイント

① インシデント概要——3行でまとめる

概要は「何が・いつ・どんな影響を与えたか」を3行以内で書きます。

【良い例】
2026年6月1日(月)午前2時頃、社内ADサーバーへの不正アクセスが発生した。
攻撃者はドメイン管理者権限を取得し、社内ファイルサーバーにアクセスした可能性がある。
同日午前9時に封じ込めを完了し、現在は影響範囲の調査を継続中。

【悪い例】
6月1日に不正アクセスが発生しました。現在調査中です。

悪い例は「何が起きたか」「影響は何か」「今どの状態か」が一切わかりません。

② 発生日時・検知日時——ギャップを明示する

発生日時と検知日時のギャップ(検知までにかかった時間)を必ず記載します。このギャップが長いほど、監視体制の課題として再発防止策に直結します。

発生日時:2026年6月1日 02:17(推定)
検知日時:2026年6月1日 08:45
報告日時:2026年6月1日 09:30
検知までの時間:約6時間28分

③ 影響範囲——「調査中」で終わらせない

影響範囲は「調査中」のまま報告書を出さざるを得ない場合もありますが、その時点でわかっている範囲と、わかっていない範囲を明示してください。

【確認済み】
・影響を受けたサーバー:ファイルサーバー(FS01)
・アクセスされたフォルダ:/共有/営業部/顧客データ
・影響ユーザー数:営業部全員(45名)

【調査中】
・データの外部持ち出しの有無(ログ解析中・6月3日完了予定)
・他サーバーへの横移動の有無(フォレンジック調査中)

④ 対応経緯(タイムライン)——誰が何をしたかを記録する

タイムラインは「何時に何が起きたか」だけでなく、「誰が判断・実施したか」を必ず記載します。後から責任の所在を確認するためだけでなく、対応の意思決定プロセスを評価するためにも必要です。

08:45  情シス担当・田中がSIEMアラートを確認、不審なログインを検知
08:52  上長(情シス課長・佐藤)にエスカレーション
09:05  対象アカウントをADで無効化(実施者:田中)
09:15  影響範囲の初期調査開始
09:30  経営層へ第一報を報告
10:00  外部セキュリティベンダーへ支援要請

⑤ 根本原因——「なぜ」を3回繰り返す

根本原因の分析が浅いと、再発防止策も表面的になります。「なぜ?」を繰り返して根本に迫ってください。

【表面的な原因】
不審なIPアドレスからの不正ログインが成功した

【なぜ①】
なぜ不正ログインが成功したのか?
→ 管理者アカウントにMFAが設定されていなかった

【なぜ②】
なぜMFAが設定されていなかったのか?
→ 管理者アカウントのセキュリティ要件がポリシーとして定義されていなかった

【なぜ③】
なぜポリシーが定義されていなかったのか?
→ 特権アカウント管理の責任者が明確でなく、定期レビューが行われていなかった

【根本原因】
特権アカウント管理のガバナンスが未整備だった

⑥ 再発防止策——具体的・期限付き・担当者付き

再発防止策は「強化する」「見直す」では不十分です。何を・誰が・いつまでにやるかを明記します。

【悪い例】
・セキュリティ設定を強化する
・監視体制を見直す

【良い例】
・管理者アカウント全員にMFAを設定する
 担当:情シス担当・田中 期限:2026年6月15日

・特権アカウント管理ポリシーを策定する
 担当:情シス課長・佐藤 期限:2026年7月31日

・SIEMのアラート確認を1日2回の定例作業として追加する
 担当:情シスチーム全員 開始:2026年6月8日

やりがちな失敗パターン4選

① 時系列の羅列で終わる

「08:45 アラート検知、09:05 アカウント無効化、09:30 報告」という時系列だけで終わっている報告書です。何が起きたかは伝わりますが、なぜ起きたか・どう防ぐかが抜けているため再発防止につながりません。タイムラインはあくまで「根本原因分析」と「再発防止策」を導くための素材です。

② 根本原因が「不正アクセスのため」で終わる

「原因:外部からの不正アクセス」という記載は原因ではなく「何が起きたか」の繰り返しです。「なぜ不正アクセスが成功したのか」「なぜ検知が遅れたのか」を掘り下げることが根本原因分析です。

③ 再発防止策が抽象的

「セキュリティ意識を高める」「監視を強化する」という再発防止策は実行できません。担当者・期限・具体的なアクションが伴わない対策は、次のレビューまでに忘れられます。1つの対策につき「誰が・何を・いつまでに」を必ずセットで書いてください

④ 技術用語を経営層向け報告書に使う

「Kerberoastingによりサービスアカウントのハッシュが取得され、Pass-the-Hashで横移動が発生」という記載は技術者には伝わりますが、経営層には伝わりません。エグゼクティブサマリーでは「攻撃者が管理者と同等の権限を不正に取得し、社内システムに侵入した」という表現に置き換えてください

報告書テンプレート

以下のテンプレートをそのまま使用してください。

■ インシデント対応報告書

作成日:  年 月 日
作成者:
承認者:
文書番号:

━━━━━━━━━━━━━━━━━━━━
第1部:エグゼクティブサマリー(経営層・管理職向け)
━━━━━━━━━━━━━━━━━━━━

【インシデント概要】
(何が・いつ・どんな影響を与えたかを3行以内で記載)

【現在の状況】
□ 封じ込め完了 □ 調査継続中 □ 復旧完了 □ 再発防止策実施中

【事業への影響】
・影響を受けたシステム:
・影響を受けたユーザー数:
・業務停止時間:
・データ流出の有無:

【今後の対応方針】
(経営判断が必要な事項・対外的な対応方針を記載)

━━━━━━━━━━━━━━━━━━━━
第2部:技術詳細(技術担当者・情シス向け)
━━━━━━━━━━━━━━━━━━━━

【1. 発生・検知日時】
発生日時:
検知日時:
報告日時:
検知までの時間:

【2. 影響範囲】
確認済み:
調査中:

【3. 対応経緯(タイムライン)】
日時    担当者    対応内容
---------- ---------- ----------

【4. 根本原因】
直接原因:
根本原因:
(なぜ①→なぜ②→なぜ③で掘り下げた分析を記載)

【5. 再発防止策】
No. | 対策内容 | 担当者 | 期限 | 状況
----|---------|-------|------|----
1   |         |       |      |
2   |         |       |      |
3   |         |       |      |

【6. 添付資料】
□ 関連ログ(抜粋)
□ スクリーンショット
□ フォレンジック調査結果
□ その他:

チェックリスト

内容の確認

  • [ ] インシデント概要を3行以内でまとめた
  • [ ] 発生日時・検知日時・検知までのギャップを記載した
  • [ ] 影響範囲を「確認済み」と「調査中」に分けて記載した
  • [ ] タイムラインに「誰が」実施・判断したかを記載した
  • [ ] 根本原因を「なぜ?」を繰り返して掘り下げた
  • [ ] 再発防止策に担当者・期限・具体的なアクションを記載した
  • [ ] 証跡(ログ・スクリーンショット)を添付した

読み手への配慮

  • [ ] エグゼクティブサマリーに技術用語を使っていない
  • [ ] 経営層が判断すべき事項を明示した
  • [ ] 技術詳細部に具体的な設定値・コマンド・ログを記載した

提出前の確認

  • [ ] 事実と推定を明確に区別して記載した
  • [ ] 「調査中」の項目に完了予定日を記載した
  • [ ] 上長・承認者のレビューを受けた

まとめ

今日確認すべきことは1つです。

過去に作成したインシデント報告書に「再発防止策」と「担当者・期限」が記載されているか確認してください。

この2つが抜けている報告書は、形式上は完成していても機能しない文書です。今後新たに作成する報告書から、必ずこの2つをセットで記載するようにしてください。

インシデント対応報告書はインシデントが起きてから初めて書くのではなく、テンプレートを事前に用意しておくことが重要です。今日のテンプレートをそのまま社内の共有フォルダに保存し、いつでも使える状態にしておいてください。

次はフェーズ3の「不正アクセス対策の基本設計」へ進みます。

 

あわせてご覧ください

コメント

タイトルとURLをコピーしました