英語でセキュリティインシデントの対応文書を書くよう求められたとき、何をどの順序で記録すればいいか迷った経験はないだろうか。
セキュリティインシデント対応（Security Incident Response）は検知から復旧・報告までを構造化する文書だ。初動・封じ込め・根絶・復旧・事後レビューの5フェーズさえ押さえれば、英語でも問題なく対応できる。
この記事では、英語セキュリティインシデント対応に必要な5つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のインシデント対応で活用できる。
セキュリティインシデント対応に必要な5つの構成要素
セキュリティインシデント対応（Security Incident Response）はNISTのCSF（Cybersecurity Framework）やSANSのPICERL（Preparation・Identification・Containment・Eradication・Recovery・Lessons Learned）が標準的な枠組みだ。以下の5つが実務で使いやすい構成要素になる。
- インシデント概要（Incident Overview）
- 検知・初動対応（Detection & Initial Response）
- 封じ込め（Containment）
- 根絶・復旧（Eradication & Recovery）
- 事後レビュー・報告（Post-Incident Review & Reporting）
セキュリティインシデントとシステム障害の違い
システム障害（Outage）はインフラ・ソフトウェアの問題で発生する。セキュリティインシデントは「意図的な攻撃・不正アクセス・データ侵害」を含む点が異なる。セキュリティインシデントは証跡保全・法的報告義務・規制対応が加わるため、別の対応フローが必要だ。
セキュリティポリシーとの連携は英語セキュリティポリシーの書き方でも確認してほしい。
なぜ英語で書くのか
グローバルチームのセキュリティインシデント対応では、CERT・CSIRT・外部セキュリティベンダー・法務・コンプライアンスチームが英語で連携する。特に規制報告（GDPR・SOC2・PCI DSS）は英語での文書化が求められる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
インシデント概要
| 項目 | 内容 |
|---|---|
| インシデントID | （例：SEC-2026-0815） |
| 重要度 | （例：P1 / Critical） |
| インシデントタイプ | （例：不正アクセス / データ侵害 / マルウェア感染 / フィッシング） |
| 検知日時 | （例：2026年8月15日 02:35 JST） |
| 影響範囲 | （例：本番DBサーバー / ユーザーPII（個人識別情報）50万件） |
| インシデントマネージャー | （例：山田（セキュリティリード）） |
| ステータス | （例：対応中 / 封じ込め完了 / クローズ） |
検知・初動対応
| 項目 | 内容 |
|---|---|
| 検知方法 | （例：SIEMアラート。本番DBへの異常なクエリパターンを検知） |
| 検知者 | （例：田中（オンコール担当）） |
| 初動対応日時 | （例：2026年8月15日 02:40 JST） |
| 初動で確認したこと | （例：1. アラートの内容確認 → 2. 影響範囲の初期評価 → 3. インシデントマネージャーへのエスカレーション） |
| 初期判断 | （例：不正アクセスの可能性が高い。P1インシデントとして対応を開始） |
封じ込め（Containment）
| 項目 | 内容 |
|---|---|
| 封じ込め開始日時 | （例：2026年8月15日 03:00 JST） |
| 短期封じ込め措置 | （例：1. 影響を受けたDBサーバーをネットワークから切り離し → 2. 当該APIエンドポイントを503に変更 → 3. 攻撃元IPをWAFでブロック） |
| 証跡保全 | （例：DBサーバーのメモリダンプ・ネットワークログ・アクセスログを保全） |
| 長期封じ込め措置 | （例：全管理者アカウントのパスワードをリセット。MFAを強制適用） |
| 封じ込め完了日時 | （例：2026年8月15日 04:30 JST） |
根絶・復旧（Eradication & Recovery）
| 項目 | 内容 |
|---|---|
| 根本原因 | （例：管理コンソールの旧バージョン認証バイパスの脆弱性（CVE-XXXX-YYYY）が悪用された） |
| 根絶措置 | （例：1. 脆弱なバージョンをパッチ適用済みバージョンに更新 → 2. 不正に作成されたアカウントを削除 → 3. 侵害されたトークンをすべて無効化） |
| 復旧手順 | （例：1. クリーンなバックアップからDBを復元 → 2. データ整合性を確認 → 3. サービスを段階的に再開） |
| サービス復旧日時 | （例：2026年8月15日 08:00 JST） |
| データ侵害の確認 | （例：ユーザーPII 50万件へのアクセスが確認された。氏名・メールアドレス・ハッシュ化パスワード） |
事後レビュー・報告
| 項目 | 内容 |
|---|---|
| ポストモーテム実施日 | （例：2026年8月20日） |
| タイムライン | （例：攻撃開始 01:50 → 検知 02:35 → 封じ込め完了 04:30 → 復旧 08:00） |
| 根本原因分析 | （例：脆弱性スキャンの頻度が不十分で、CVEの適用が3ヶ月遅延していた） |
| 改善アクション | （例：1. 月次脆弱性スキャンを週次に変更 → 2. CVEアラートの自動チケット化 → 3. 管理コンソールのMFA強制化） |
| 規制報告 | （例：GDPR第33条に基づき、72時間以内に監督機関へ報告済み） |
英語版テンプレート（コピペOK）
Incident Overview
| Item | Details |
|---|---|
| Incident ID | (e.g., SEC-2026-0815) |
| Severity | (e.g., P1 / Critical) |
| Incident Type | (e.g., Unauthorized Access / Data Breach / Malware / Phishing) |
| Detected At | (e.g., August 15, 2026 at 02:35 JST) |
| Impact Scope | (e.g., Production DB server / 500K user PII records) |
| Incident Manager | (e.g., Yamada (Security Lead)) |
| Status | (e.g., In Progress / Contained / Closed) |
Detection & Initial Response
| Item | Details |
|---|---|
| Detection Method | (e.g., SIEM alert. Detected anomalous query patterns on the production DB.) |
| Detected By | (e.g., Tanaka (On-Call Engineer)) |
| Initial Response Time | (e.g., August 15, 2026 at 02:40 JST) |
| Initial Actions Taken | (e.g., 1. Reviewed alert details → 2. Assessed initial blast radius → 3. Escalated to Incident Manager) |
| Initial Assessment | (e.g., High likelihood of unauthorized access. Declared P1 incident.) |
Containment
| Item | Details |
|---|---|
| Containment Start | (e.g., August 15, 2026 at 03:00 JST) |
| Short-Term Containment | (e.g., 1. Isolated the affected DB server from the network → 2. Set the API endpoint to return 503 → 3. Blocked attacker IP in WAF) |
| Evidence Preservation | (e.g., Preserved memory dump, network logs, and access logs from the DB server.) |
| Long-Term Containment | (e.g., Reset passwords for all admin accounts. Enforced MFA.) |
| Containment Completed | (e.g., August 15, 2026 at 04:30 JST) |
Eradication & Recovery
| Item | Details |
|---|---|
| Root Cause | (e.g., Authentication bypass vulnerability (CVE-XXXX-YYYY) in an outdated version of the admin console was exploited.) |
| Eradication Actions | (e.g., 1. Patched the vulnerable component → 2. Deleted unauthorized accounts → 3. Revoked all compromised tokens) |
| Recovery Steps | (e.g., 1. Restored DB from a clean backup → 2. Verified data integrity → 3. Gradually restored service) |
| Service Restored At | (e.g., August 15, 2026 at 08:00 JST) |
| Data Breach Confirmed | (e.g., Confirmed unauthorized access to 500K user PII records: name, email, hashed password.) |
Post-Incident Review & Reporting
| Item | Details |
|---|---|
| Post-Mortem Date | (e.g., August 20, 2026) |
| Timeline | (e.g., Attack began 01:50 → Detected 02:35 → Contained 04:30 → Service restored 08:00) |
| Root Cause Analysis | (e.g., Vulnerability scanning frequency was insufficient. CVE patches were delayed by 3 months.) |
| Action Items | (e.g., 1. Change vuln scanning from monthly to weekly → 2. Auto-create tickets for CVE alerts → 3. Enforce MFA on admin console) |
| Regulatory Reporting | (e.g., Notified supervisory authority within 72 hours per GDPR Article 33.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
封じ込め措置の書き方（短期と長期を分ける）
封じ込めは「短期（今すぐ止める）」と「長期（再発を防ぐ）」を分けて書く。短期措置でサービスを止めても、長期措置がなければ再侵害が起きる。
| 日本語 | 英語 |
|---|---|
| ネットワークから切り離す | Isolate from the network. |
| アクセスをブロックする | Block access to [component]. |
| アカウントを無効化する | Disable the account. |
| トークンを無効化する | Revoke the token. |
| パスワードをリセットする | Reset the password. |
| MFAを強制適用する | Enforce MFA. |
事後レビューの書き方（タイムラインと改善アクション）
タイムラインは「攻撃開始〜検知〜封じ込め〜復旧」の時刻を分単位で記録する。MTTD（平均検知時間）・MTTR（平均復旧時間）の計算にも使える。
| 日本語 | 英語 |
|---|---|
| 平均検知時間 | MTTD (Mean Time to Detect) |
| 平均復旧時間 | MTTR (Mean Time to Recover) |
| 攻撃開始 | Attack initiated |
| 検知 | Detected |
| 封じ込め完了 | Contained |
| サービス復旧 | Service restored |
障害復旧計画との連携は英語障害復旧計画書の書き方でも確認してほしい。
セキュリティインシデント対応でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
セキュリティ対応の基本用語
| 日本語 | 英語 |
|---|---|
| セキュリティインシデント | Security Incident |
| 不正アクセス | Unauthorized Access |
| データ侵害 | Data Breach |
| 脆弱性 | Vulnerability / CVE |
| 封じ込め | Containment |
| 根絶 | Eradication |
| 証跡保全 | Evidence Preservation |
| インシデントマネージャー | Incident Manager |
| フォレンジック調査 | Forensic Investigation |
| 規制報告 | Regulatory Reporting |
インシデント対応中のコミュニケーションフレーズ
| 日本語 | 英語 |
|---|---|
| セキュリティインシデントを検知しました | We have detected a security incident. |
| P1インシデントを宣言します | Declaring a P1 security incident. |
| 封じ込め措置を実施しています | We are implementing containment measures. |
| 影響範囲を調査中です | We are investigating the scope of impact. |
| データ侵害が確認されました | A data breach has been confirmed. |
| サービスが復旧しました | Service has been restored. |
| 詳細はポストモーテムで報告します | Full details will be reported in the post-mortem. |
ポストモーテムの書き方は英語ポストモーテムの書き方でも確認してほしい。
まとめ：英語セキュリティインシデント対応は5つのフェーズで完成する
英語セキュリティインシデント対応に必要な構成要素を整理した。
- 検知と初動は「何を・誰が・いつ・どう判断したか」を時刻付きで記録する
- 封じ込めは短期（今すぐ止める）と長期（再発防止）を分けて書く
- 根絶・復旧では根本原因と対策をセットで記録し、次の脆弱性対応に活かす
- 事後レビューではMTTD・MTTRを計測し、改善アクションを担当者・期限付きで定義する
テンプレートをコピーして、まず「インシデント概要」の重要度とインシデントタイプから書き始めてほしい。最初の5行が埋まれば、対応チームが何をすべきかが即座に共有できる。
コメント