Skip to content

Incident After-Action Review

Classification: CONFIDENTIAL — Internal Use Only Document: response-plans/incident-after-action-review.md · v1.0 · 2026-03-14 · GPUS-IT


Purpose

The Incident After-Action Review (IAR) is completed within 5 business days of closing any P1 or P2 security incident, and optionally for P3 incidents with notable findings. It captures what happened, what worked, what didn't, and what changes are required to prevent recurrence.

This template is completed by the Incident Commander with input from all responders, then reviewed by the IT Manager.

Compliance alignment: CIS 17.4 CIS 17.7 NIST IR-4 NIST IR-5 PCI 12.10.2


Incident After-Action Report

Section 1 — Incident Identification

Field Value
Incident ID INC-YYYY-NNN
Severity P1 / P2 / P3 / P4
Incident Title Brief description
Incident Commander Name
Report Author Name
Report Date YYYY-MM-DD
Report Status Draft / Final

Section 2 — Incident Timeline

Time (UTC) Event Actor
HH:MM Incident detected Source (Fail2ban / AIDE / Grafana / Manual)
HH:MM Incident Commander notified
HH:MM IRP activated — severity declared Incident Commander
HH:MM Containment initiated Responder
HH:MM Containment complete Responder
HH:MM Eradication complete Responder
HH:MM Recovery initiated Responder
HH:MM Services verified restored Incident Commander
HH:MM Incident closed Incident Commander

Total duration: HH hours MM minutes MTTD (Mean Time to Detect): X minutes from event to detection MTTR (Mean Time to Respond): X minutes from detection to containment


Section 3 — Incident Summary

3.1 What Happened

Provide a clear, factual narrative of the incident. Describe the sequence of events from initial trigger to resolution. Avoid blame — focus on system and process behavior.

[FILL IN]

3.2 Systems Affected

Server / Service Affected Impact
SKY Yes / No Description
RAIN Yes / No Description
SUN Yes / No Description
WIND Yes / No Description
GCP Yes / No Description
VPN Tunnel Yes / No Description

3.3 Root Cause

Identify the technical root cause and any contributing factors.

[FILL IN]

3.4 Detection Source

  • [ ] Fail2ban alert
  • [ ] AIDE integrity check
  • [ ] Prometheus / Grafana threshold alert
  • [ ] Elasticsearch / Kibana correlation
  • [ ] NTA cron anomaly
  • [ ] Admin manual observation
  • [ ] External notification
  • [ ] User report

Section 4 — Response Assessment

4.1 What Worked Well

List actions, tools, or procedures that were effective.

Item Why it Worked

4.2 What Didn't Work / Gaps Identified

List failures, delays, missing tools, unclear procedures, or communication breakdowns.

Gap Impact Root Cause

4.3 Detection Effectiveness

Question Answer
Was the detection timely? Yes / No — explain
Could detection have been faster? Yes / No — how
Were the right alerts in place? Yes / No — what was missing
Did AIDE / Fail2ban / Grafana fire as expected? Yes / No — details

4.4 Containment Effectiveness

Question Answer
Was containment achieved within target time? Yes / No — actual vs target
Was evidence preserved before remediation? Yes / No
Was network isolation appropriate? Yes / No
Were any containment actions excessive or insufficient? Details

Section 5 — Action Items

All action items must have an owner and due date. Track completion in the change log.

ID Action Item Owner Due Date Status
AI-001 Open
AI-002 Open
AI-003 Open

Action item categories to consider:

  • Detection improvements (new Fail2ban rules, Grafana alerts, AIDE tuning)
  • Runbook updates (IRP / DRP procedure gaps)
  • Configuration hardening (firewall rules, SSH config, DNSSEC)
  • Training or awareness gaps
  • Tooling gaps (missing visibility, missing automation)
  • Policy updates required

Section 6 — Compliance & Risk Register Update

6.1 Regulatory Assessment

Question Answer
Was cardholder data potentially exposed? Yes / No
Was supporter PII potentially exposed? Yes / No
Was legal / compliance notified? Yes / No — Date:
Is external notification required? Yes / No — Regulatory body:

6.2 Risk Register Impact

Risk Register Item Updated? New Risk Score Notes
Yes / No

6.3 Asset Inventory

Question Answer
Were any systems added/removed/changed during response? Yes / No
Was wdc-hostregistry.csv updated? Yes / No
Was /var/log/asset-inventory.log updated on all affected servers? Yes / No

Section 7 — Post-Recovery Verification

Confirm each step was completed on all affected servers:

Step SKY RAIN SUN WIND
AIDE baseline updated / — ✓ / — / — ✓ / —
Recovery logged to /var/log/asset-inventory.log / — ✓ / — / — ✓ / —
DNSSEC re-signed (if applicable) / — ✓ / — N/A N/A
Services verified operational / — ✓ / — / — ✓ / —
48-hour intensive monitoring complete / — ✓ / — / — ✓ / —

Section 8 — Sign-Off

Role Name Date Signature
Incident Commander
IT Manager
DNS/DHCP Responder (if involved)
Monitoring/Logging Responder (if involved)
Security Operations (if involved)

IAR Log — Completed Reviews

All completed IARs are logged here. Full reports are archived to GCS.

IAR ID Incident ID Severity Date Closed Title Report Link
IAR-2026-001 (No incidents recorded)

Metrics — IR Performance Over Time

Updated after each IAR. Used to track improvement in detection and response capability.

Metric Target Last Incident 90-Day Average
MTTD (Mean Time to Detect) < 15 min (P1), < 1 hr (P2)
MTTR (Mean Time to Respond) < 15 min (P1), < 1 hr (P2)
Incidents this quarter
Open action items 0
Action items closed on time 100% target

Document version: v1.0 · 2026-03-14 · GPUS-IT · Classification: CONFIDENTIAL — Internal Use Only