There's a version of this post where I tell you that AI-generated public post-mortems are fine as a starting point and you just need to edit carefully for an external audience. That's not this post.

AI can be a genuinely useful tool for a subset of communication work, but incident post-mortems are one of the places where I see it consistently making things worse, and understanding why starts with knowing what a public post-mortem is supposed to do in the first place.

A public post-mortem isn't merely a record-keeping exercise. It's a communication to people who were affected by something that went wrong at your organization — people who want to know what happened, what it means for them, and whether they can trust you going forward. That communication requires human judgment your AI doesn't have, built on context your AI shouldn't have.

The training data problem

The most widely used AI learns from patterns in existing public documents and most public incident post-mortems are bad. They're written either by technical teams who included everything and organized it for themselves, or by legal teams optimizing for liability rather than clarity and credibility. In both cases, the person who was actually affected can't find what they need, and that’s the corpus AI is currently learning from. When you ask AI to write your post-mortem, you're asking it to write something that looks like the average of what other organizations have published before. The average is not a standard worth emulating. If your goal is to communicate well, to actually maintain trust with the people who matter the most to your organization, then you need to do better than the average, and you need to do something different from the patterns AI has learned to replicate.

Structure is a communication decision, not a formatting preference

How you organize information signals what you think matters and influences how it’s processed by other people. Lead with the timeline, and you're telling your reader that the chronological sequence of your internal investigation is the most important thing for them to understand — and maybe it is, but if it’s not, then leading with customer impact and actions required, demonstrates that you understand what they actually need to know. The point is that the decision matters. 

But AI doesn't make this distinction. It defaults to narrative structure because narrative structure is what appears most often in its training data. The result is a flood of lukewarm post-mortems that read like incident diaries: first this happened, then this happened, then we did this, and here's what we learned. That structure might satisfy a technical audience at a Black Hat talk, but doesn't serve the customer trying to evaluate their potential exposure and what to do next.

Strategic structure — the kind that's organized around what your audience needs rather than what happened to you — requires understanding your audience, their concerns, and what decisions they're trying to make with the information you're giving them. That's not a pattern AI can extract from poorly structured public reports. 

Volume is not thoroughness

AI writes a lot and there’s a specific failure mode I see frequently in AI-generated post-mortems, namely that they're comprehensive in a way that creates noise rather than clarity. The result looks thorough, but it functions as camouflage — the information your reader actually needs is buried somewhere in the middle of a document that took three minutes to generate and will take twenty to read, answering few (if any) of the questions they came to get answers for. 

Good incident communications does the opposite, making the most important information impossible to miss, and deprioritizing everything that doesn't help the reader understand what happened and what to do about it. The editing required to get there is substantive and requires judgment about what matters to your specific stakeholders — something AI genuinely isn't equipped to provide.

If You Have to Use AI Anyway

Unfortuantely, not every organization has communications support for security, let alone incidents. So, if AI is genuinely your best available option, the prompt matters significantly.

If you've read the Template Trap, you already know where this is going. A multi--step AI prompt with a fixed order is a more sophisticated Mad Libs. The blanks are just harder to see. So before you use what follows, I want to acknowledge that it’s a floor, not a ceiling. It's better than asking AI to "write an incident post-mortem" and accepting whatever comes out, but it’s not what good looks like. Good looks like a communicator who understands your customers, your organization's relationship with them, and what this specific incident means for that relationship — making deliberate decisions about structure, tone, and content based on the situation in front of them. No prompt replaces that judgment.

With that said, here's a starting point if you need it:

You are helping write a public incident post-mortem for [COMPANY NAME]. Your goal is to communicate clearly and honestly with customers who were affected by this incident, and to provide clarity for those who weren't. Prioritize their needs, not our CYA.

Use the following incident details:

[PASTE INCIDENT SUMMARY HERE — do not include specific technical details or system architecture information that could be exploited in future attacks]

[CUSTOMER CONTEXT: Describe your primary customer in 2-3 sentences. Who are they? What do they use your product for? What's at stake for them when something goes wrong? Example: "Our customers are small business owners who use our platform to process payments. Downtime or data exposure directly affects their revenue and their relationship with their own customers."]

[IMPACT CONTEXT: What is the realistic worst-case concern for an affected customer reading this? What decision are they trying to make?]

Before you write anything, make structural decisions based on what affected customers most urgently need to know. Do not default to chronological order. Do not lead with what happened to us — lead with what it means for them. Organize every section around a reader who is trying to make a decision, not a reader who is trying to understand our experience.

As you structure and write, apply these principles:

— Lead with impact and action. What happened to customers, and what do they need to do right now? If they don't need to do anything, say so explicitly. Don't make them read to the end to find out.

— Be specific about who was affected. Vague language about "some users" or "certain accounts" makes everyone assume the worst. If you don't know yet, say [PLACEHOLDER: affected population still being determined] rather than hedging.

— Put the timeline last. A chronological account of our investigation is useful context, not the point. It belongs at the end, after customers have everything they need.

— Use an active voice and own the actions. "We failed to detect..." not "The incident went undetected..." Passive voice reads as evasion.

— Cut marketing language entirely. Do not use "we take security seriously," "as soon as we became aware," "we sincerely apologize for any inconvenience," or any variation of these. Do not minimize the impact or use language that suggests affected customers are overreacting.

— Omit operationally sensitive details. Do not include specifics about how the incident was executed, what systems were involved at a technical level, or what detection gaps existed. These details belong in internal documentation, not public communications.

— Use placeholders for unknowns. Where information is still being determined, insert a [PLACEHOLDER] rather than omitting the section or writing around the gap with vague language.

— Write at a tenth-grade reading level. 

The placeholder instruction deserves emphasis regardless of whether you're using AI or writing this yourself because the common temptation when information is incomplete is to omit a section or hedge around the gap. Both usually backfire, so using explicit placeholders forces you to confront what you actually know, identify what still needs to be determined, and make a deliberate decision about what to share and when. A post-mortem full of placeholders also tells you something important about how complete your understanding of the incident actually is before you publish anything publicly.

The best post-mortems I've seen were written by people who understood what their customers needed to know and had the discipline to organize everything else around that. AI can help you get words on a page, but getting them right is still your job.