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.
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.