Security Incident Postmortem Drafter Prompt
Draft a postmortem for a security incident with the extra structure that kind needs — exposure scope, containment timeline, and disclosure considerations — without overstating what's confirmed.
- Target user
- Security engineer or SRE writing up an incident with a security dimension
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior security incident responder who writes postmortems for incidents with a security dimension. You know these differ from reliability postmortems: exposure scope, containment, evidence handling, and disclosure all matter, and overstating a finding can be as harmful as understating it. I will paste: [INCIDENT FACTS: confirmed timeline, the vulnerability or vector, and what was and wasn't accessed — clearly separating confirmed from suspected] [SCOPE SIGNALS: logs, access records, and detections that bound what was affected] [AUDIENCE: internal-only, or will inform a customer/regulatory disclosure] Draft a security postmortem with these sections: 1. Summary: what happened, confirmed impact, and current status (contained / monitoring / resolved) — in plain language. 2. Detection and containment timeline: when the activity began, when it was detected, when it was contained, and the gap between each. 3. Exposure assessment: what was confirmed accessed vs what was potentially in scope but unconfirmed. Mark every unconfirmed item explicitly — do not present "possible" as "did." 4. Root cause and contributing factors: the vulnerability, plus the conditions that let it be reached and persist. Stay blameless. 5. Containment, eradication, and recovery actions taken. 6. Follow-ups: hardening, detection, and process items. 7. Disclosure considerations: a note (not a decision) on whether confirmed facts may trigger customer or regulatory notification, flagged for legal/security leadership. Output format: the drafted sections above, with a clearly labeled list of every [UNCONFIRMED] claim that must be verified before this leaves the security team. Guardrails: never overstate exposure — "potentially accessed" and "confirmed accessed" are different and must stay separate. Stay blameless about whoever introduced the vulnerability. This is a draft for security review; disclosure and legal decisions belong to humans with that authority, and you must not assert legal obligations.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
A security incident is an incident, but a security postmortem is not just a reliability postmortem with a CVE in it. The questions are different and the stakes of getting them wrong are higher: what was actually accessed versus what was merely reachable, how long the activity ran before detection, what was contained versus eradicated, and whether the confirmed facts touch a disclosure obligation. A general-purpose postmortem template skips most of this structure, which is exactly why security teams need a tailored one.
This prompt encodes that structure — exposure assessment, containment timeline, eradication, and a disclosure-considerations note — so the draft asks the right questions instead of forcing a security event into a reliability shape. The detection-and-containment timeline in particular matters more here than almost anywhere else, because the dwell time between compromise and detection is the headline metric of a security incident, and it’s the thing follow-up hardening is trying to shrink.
The guardrails address the two errors that make security postmortems actively harmful. The first is conflating “potentially in scope” with “confirmed accessed” — a mistake that drives wrong disclosure decisions in both directions, either crying wolf or underreporting real exposure. The prompt keeps those rigidly separate and labels every unconfirmed claim, so nothing leaves the security team dressed as fact when it’s still a hypothesis. The second is the temptation to assert legal conclusions; the prompt may flag that confirmed facts could be relevant to customer or regulatory notification, but it explicitly cannot assert an obligation or draft an external statement as settled, because those are decisions for humans with legal authority. And as always, it stays blameless about whoever introduced the vulnerability — the goal is a hardened system, not a named scapegoat. The human owns the verification, the disclosure call, and the final document.
Related prompts
-
Incident Postmortem Drafter Prompt
Convert raw incident notes, Slack threads, and timelines into a blameless postmortem draft.
-
Postmortem Assumptions and Unknowns Extractor Prompt
Read a postmortem draft and surface every unstated assumption and open unknown that is being treated as settled fact, so the root-cause analysis and action items don't quietly rest on unverified claims.
-
Postmortem to Game-Day Scenario Generator Prompt
Convert a real incident postmortem into a runnable game-day or chaos-engineering exercise so you can prove the fixes actually work under realistic failure conditions instead of assuming they do.
-
Postmortem Incident Commander Decision Review Prompt
Review the key decisions an incident commander made during a response and evaluate each for local rationality given the information available at the time — blamelessly, focused on decision-support tooling and process.
More Post Mortems with AI prompts & error guides
Browse every Post Mortems with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.