🔐 Writing Security Incident Postmortems With AI Without Overstating Exposure

A security incident is an incident, so it’s tempting to reach for your standard postmortem template, swap “the deploy failed” for “an attacker got in,” and call it done. That instinct produces a bad document, because a security postmortem answers different questions than a reliability one, and the cost of getting them wrong is higher. “What was actually accessed?” is not the same question as “what was the root cause,” and confusing “possibly accessed” with “confirmed accessed” can drive a disclosure decision in the wrong direction — either crying wolf to customers over exposure that never happened, or staying quiet about a breach you were obligated to report.

The structure a security writeup needs — exposure scope, dwell time, containment versus eradication, disclosure considerations — is exactly what a general template skips. AI can draft against that structure quickly, but only under a discipline that keeps confirmed and suspected rigidly separate. Here’s how to make it useful without making it dangerous.

The questions a security postmortem actually has to answer

A reliability postmortem cares about cause and recurrence. A security postmortem cares about all of that plus a set of questions that don’t exist for a bad deploy:

• Exposure scope. What was confirmed accessed, versus what was reachable but unconfirmed? These are different and must never blur.
• Dwell time. How long was the activity present before detection? This is the headline metric of a security incident the way MTTR is for an outage.
• Containment vs eradication vs recovery. Did you stop the bleeding, remove the cause, or restore service? They’re three distinct states and a postmortem needs to say which you’ve reached.
• Disclosure considerations. Do the confirmed facts touch a customer or regulatory notification obligation?

A model can draft each section, but the prompt has to encode the security-specific structure and the security-specific guardrails.

Draft a security incident postmortem. Audience: <internal / may
inform customer or regulatory disclosure>.

Sections:
1. Summary: what happened, CONFIRMED impact, current status
   (contained / monitoring / resolved). Plain language.
2. Detection & containment timeline: activity began, detected,
   contained — and the gap between each.
3. Exposure assessment: CONFIRMED accessed vs POTENTIALLY in scope
   but unconfirmed. Mark every unconfirmed item — never present
   "possible" as "did."
4. Root cause & contributing factors (blameless).
5. Containment, eradication, recovery actions taken.
6. Follow-ups: hardening, detection, process.
7. Disclosure considerations: a NOTE (not a decision) on whether
   confirmed facts may be relevant to notification, flagged for
   legal/security leadership.

Output a clearly labeled list of every [UNCONFIRMED] claim that
must be verified before this leaves the security team.

Rules: Never overstate exposure. "Potentially accessed" and
"confirmed accessed" stay separate. Stay blameless about whoever
introduced the vulnerability. Do NOT assert any legal obligation.

Facts: <confirmed vs suspected, the vector, scope signals>

The most dangerous error: “possible” dressed as “did”

If you take one thing from this, take this. The single most damaging mistake in a security postmortem is conflating what was reachable with what was accessed. An attacker who had a foothold that could theoretically reach a customer database is a very different fact from an attacker who did exfiltrate it, and the writeup must keep them apart on every line. Get this wrong in the alarmist direction and you notify customers of a breach that didn’t touch them, burning trust and possibly triggering obligations that didn’t apply. Get it wrong in the reassuring direction and you underreport real exposure, which is worse.

The prompt forces every unconfirmed claim to be labeled and collected into a verification list, so the exposure assessment reads like this:

Exposure assessment

Confirmed accessed: application logs for the auth service (contained PII: email addresses for ~[NEEDED: count] accounts, no passwords or tokens — passwords are hashed and stored separately, which access logs confirm was not reached).

Potentially in scope, NOT confirmed accessed: the session store was network-reachable from the compromised host during the window. Access logs for the session store show no queries from the attacker’s identifiers, so we currently assess this as in-scope-but-not-accessed. [UNCONFIRMED — pending review of session-store audit logs for the full window]

Out of scope: the payments service runs in a separate VPC with no path from the compromised host. [UNCONFIRMED — confirm network segmentation as configured during the incident, not just current state]

Notice that even the reassuring claims carry [UNCONFIRMED] flags. “Out of scope” is a conclusion that has to be verified, because network segmentation as documented and as actually configured during the incident are not guaranteed to match. The model drafts the structure and flags every claim; a human with the logs confirms or downgrades each one before the doc moves.

Dwell time is the headline

The detection-and-containment timeline carries the metric that defines a security incident’s severity: how long the activity ran before anyone noticed. A reliability incident is judged on how fast you recovered; a security incident is judged heavily on how long you were compromised without knowing. The follow-up hardening is usually aimed squarely at shrinking that dwell time — better detection on the access paths that stayed silent. Drafting this timeline explicitly, with the gap between “activity began” and “detected” called out as a number, keeps the most important security metric from getting buried in prose.

Disclosure is a note, never a verdict

The prompt is allowed to flag that confirmed facts might be relevant to a customer or regulatory notification. It is explicitly forbidden from asserting that an obligation exists or drafting an external statement as settled. That boundary is not caution for its own sake — disclosure and regulatory questions are legal determinations that depend on jurisdiction, contract terms, and facts the model doesn’t have, and a confidently-worded “this requires notification under [regulation]” in a draft can either trigger a premature disclosure or create a paper trail asserting an obligation that legal hasn’t assessed. The model’s job is to surface that the facts may be relevant and route the question to the people with the authority to answer it.

Blameless still applies, even to the breach

It’s tempting to abandon blamelessness for a security incident — surely someone is at fault for the vulnerability. But the same logic holds: the engineer who wrote the vulnerable code was working in a system that lacked the control that would have caught it (the dependency scan, the auth review, the segmentation that wasn’t enforced). Naming a scapegoat doesn’t harden anything; finding the missing control does. The prompt keeps the root-cause analysis on the system that allowed the vulnerability to be introduced and reached, not on the person who introduced it.

The human owns verification, disclosure, and the doc

The model produces a structured draft with every uncertain claim flagged. A human with the logs verifies each [UNCONFIRMED] item, leadership with legal authority makes the disclosure call, and the security team owns the final document before it goes anywhere. The AI accelerates the writeup; it does not get to decide what was accessed or what you’re obligated to say about it.

The security postmortem prompt is in the prompts library, and it builds on the general incident postmortem drafting work with the exposure, dwell-time, and disclosure structure that security incidents specifically need. For the blameless framing it inherits, the blameless postmortem guide covers the foundation.

Draft fast, but keep “possible” and “confirmed” on opposite sides of the page. In a security postmortem, that line is the document.