How to Use AI in Incident Response (Without Making It Worse)
Incidents are where compliance programs get tested for real. ISO 27001 dedicates five controls to incident management and PCI DSS requirement 12.10 demands a tested plan with 24/7 responders.
AI helps most before and after the incident, and in a narrow set of jobs during it: summarising, drafting comms, and keeping the timeline. It must never be the decision-maker mid-incident.
Step by step
- 1
Write the plan with AI, test it with humans
AI drafts the IR plan, severity matrix, and per-scenario runbooks (ransomware, account takeover, data leak, payment-page skimming for PCI). Humans tabletop them at least annually; the exercise is the control.
- 2
Let AI triage the noise, not declare incidents
AI and SIEM tooling summarise and correlate alerts so a human sees five candidate events, not five hundred. The classification of event versus incident stays with the on-call human, per your criteria.
- 3
Make AI the scribe during the incident
One responder pastes updates into the channel; AI maintains the running timeline, decision log, and current-status summary. This is the highest-value, lowest-risk AI job in an incident.
- 4
Draft communications with AI, send with approval
Status-page updates, customer notices, internal briefs, and regulator notifications all start as AI drafts from the timeline. Legal or the incident manager approves every external word.
- 5
Mind the notification clocks
Know your deadlines in advance: card brands and acquirer for card-data incidents, privacy regulators for personal data (72 hours under GDPR; the Australian NDB scheme has its own test), cyber insurance, and for Australian entities the ransomware payment reporting obligation. AI tracks which clocks an incident starts, your plan names who calls.
- 6
Run the post-incident review with AI
AI turns the timeline into a draft post-mortem: sequence, contributing causes, what worked, action items with owners. Feed the actions back into the risk register and control improvements (A.5.27).
Where AI helps
- Runbook drafting: AI writes scenario runbooks and severity matrices for humans to tabletop.
- Alert triage: AI summarises and correlates alerts so humans decide on signal, not noise.
- Timeline keeping: AI maintains the live timeline, decision log, and status summary.
- Comms and post-mortems: AI drafts notifications and the post-incident review from the timeline.
Tips
- ›Pre-write the first customer notification with blanks. At 2am you want to fill blanks, not compose.
- ›If systems are compromised, assume your AI tooling on those systems is too. Keep an out-of-band channel.
Skills and templates
Copy-paste these into your AI assistant (as a custom skill, project instruction, or system prompt) or your repo. Replace the [bracketed] placeholders with your details.
Incident scribe skill
The during-incident AI role, scoped hard: timeline, decision log, status summaries, draft comms. Nothing else.
incident-scribe.SKILL.md--- name: incident-scribe description: Maintains the incident timeline, decision log, and draft communications during a security incident. Never makes response decisions. --- You are the incident scribe for [Company]. An incident channel will be pasted to you in fragments. Your only jobs: 1. TIMELINE: maintain a chronological log: timestamp, event or action, actor. Append, never rewrite history. 2. DECISIONS: keep a separate decision log: timestamp, decision, decider, rationale if stated. 3. STATUS: on request, produce a five-line status: what happened, current impact, what is being done, next checkpoint time, open decisions. 4. COMMS DRAFTS: on request, draft status-page updates, customer notices, or internal briefs from the timeline only. Mark every draft [REQUIRES APPROVAL: incident manager / legal]. Never invent facts not in the timeline. 5. CLOCKS: when first told data types involved, list which notification clocks may have started (card brands, privacy regulator, insurer, ransomware payment reporting if a payment is contemplated) and their deadlines from the IR plan. Hard rules: - You do not recommend containment or remediation actions. - You do not speculate about cause in any comms draft. - If asked to decide anything, reply: that is a human decision, and name the role who owns it.
Post-incident review template
The A.5.27 lessons-learned write-up, ready to fill from the scribe timeline.
post-incident-review.md# Post-incident review, [INC-ID], [title] - Severity: [SEV] | Detected: [date/time] | Resolved: [date/time] | Duration: [h] - Incident manager: [name] | Scribe: [name/AI] ## Summary (3 sentences max) [What happened, impact, how it ended.] ## Timeline [Paste the scribe timeline.] ## Impact - Systems and data affected: - Customers affected and notified: - Notification clocks triggered and met? [card brands / regulator / insurer / other] ## Analysis - Direct cause: - Contributing causes: - What worked: - What failed or was slow: - Did detection come from our monitoring or externally? ## Actions (every row needs an owner and date) | Action | Type (fix/control/process) | Owner | Due | Feeds into | |---|---|---|---|---| | | | | | risk register / control / runbook | ## Sign-off Reviewed by: [name, role] Date: [date]
Run this with Drata
Automated, continuous compliance with deep integrations.
FAQ
- Can AI declare or close an incident?
- No. Event-to-incident classification and closure are human decisions under your documented criteria (ISO A.5.25). AI prepares the information those decisions need.
- What does PCI DSS 12.10 actually require?
- A written plan covering roles, comms, containment, and recovery, referencing card brand procedures, tested at least annually, with 24/7 designated responders and procedures for specific alerts like payment-page tampering.