Postmortems Without Blame

Blameless postmortem culture was built for a world where the only audience for an incident writeup was the team that lived through it. Write down what happened, name the contributing factors instead of the person, and let the retro run as long as it needs to before anyone commits to a root cause. That model works beautifully right up until a regulator's clock starts running the moment your team becomes aware of the incident — and a clock that starts at "aware," not "understood," doesn't wait for your retro to finish. This one's for the engineering team trying to keep both things true at once. 

Two clocks, two documents, two different jobs 

The tension isn't philosophical, it's structural. Blameless postmortem practice, in its SRE-textbook form, exists to protect a specific thing: an engineer's willingness to say "I did this" honestly, without editing the account to protect themselves, because the account is what the team learns from. That only works if nothing bad happens to the person who wrote it — no performance review consequence, no name attached to a document that leaves the team. 

Regulatory incident reporting has a different purpose. Under DORA, a major ICT-related incident triggers an initial notification as soon as possible, and in any case within four hours of classification as major and no later than 24 hours from the moment the financial entity became aware of the incident. That is followed by an intermediate report within 72 hours of the initial notification and a final report no later than one month after the intermediate report or latest updated intermediate report. NIS2's Article 23 establishes a similar reporting sequence for entities in its scope: a 24-hour early warning, a 72-hour incident notification, and a final report within one month. Neither framework is written for a team that has finished figuring out everything that happened. Both require information to be provided while the investigation may still be ongoing. 

That's the actual design problem: a postmortem culture built for one document, unlimited time, and no external reader now has to also produce a document with a fixed deadline, an external reader, and content that may exist long before the internal investigation is finished. Treating these as the same document, written once and reused, is where teams get hurt — either the regulatory filing goes out half-baked because the team was still protecting psychological safety by staying vague, or the blameless retro quietly stops being blameless because everyone knows whatever gets said might end up quoted in a document a supervisor reads. 

The fix is separation, not compromise 

The teams that handle this well don't try to write one document that satisfies both purposes. They build two artifacts, on two tracks, governed by two different rules — and they make that separation explicit in the incident process itself, not something people improvise under pressure at hour three of an outage. 

The regulatory filing is fact-and-timeline, not narrative-and-cause. What DORA requires in the initial stages is specific, supportable information: when the incident was detected, what happened, which services and Member States were affected, how the incident was discovered, what containment or business continuity measures have been taken, and, where available, information about its origin. Root-cause information belongs in the final report, once there is evidence to support it. A provisional classification, clearly marked as provisional, is entirely different from inventing a confident root-cause narrative under four-hour pressure. The acceptance criterion worth writing into the incident process explicitly: while a major incident is classified as active, any regulatory filing SHALL state the incident's known facts and current status, and SHALL NOT assert a root cause beyond what current evidence directly supports. 

The blameless postmortem is cause-and-learning, not just fact-and-timeline. This is the document that takes the time it needs, involves the people who need to speak candidly, and stays internal by design — its value depends on that. It's where "the deploy pipeline let a config change skip review because the emergency-bypass flag doesn't expire" gets written down honestly, in a way nobody would write if they thought a regulator might read it verbatim next week. 

The two documents can, and should, differ in emphasis without disagreeing in fact. The regulatory filing says "a configuration change caused an authentication service outage affecting approximately 40,000 customers for 90 minutes." The postmortem says the same thing, plus the actual chain of contributing factors, plus what's changing about the deploy pipeline as a result. Neither document lies to the other's reader. They just answer different questions, for different reasons, on different clocks. 

Who signs the filing matters more than who wrote the retro 

Blameless culture protects the engineer who describes what happened. It was never meant to protect the organization from having to establish accountability for the regulatory filing itself — those are different roles, and conflating them is where a lot of the psychological-safety erosion actually starts. A named incident commander — a role, not necessarily always the same person — owns or coordinates the classification decision and filing process, is accountable for the submission being accurate and on time, and is explicitly not the same thing as "the person whose commit caused the outage." Separating those roles is what lets the engineer who wrote the honest account in the postmortem stay unnamed in it, while someone with actual authority stands behind what goes to the regulator. 

This distinction also keeps another consideration visible: personal data. Naming an individual engineer, their specific mistake, and their identity in a document that may be shared with a regulator or auditor raises data-protection considerations under GDPR that are separate from DORA or NIS2. The answer isn't necessarily to remove every reference to individuals, but to make sure the regulatory filing contains only the personal data that is actually necessary for its purpose. A filing built primarily around affected systems, facts and process gaps rather than unnecessary identification of individual engineers is more consistent with both data minimisation and the principles behind a blameless culture. 

One nuance worth building the process around explicitly 

For a financial entity in scope of both frameworks, DORA operates as the sector-specific lex specialis for the requirements it covers, meaning the DORA requirements apply instead of the corresponding NIS2 requirements in those areas. That does not mean NIS2 simply disappears from the picture: certain NIS2 provisions can continue to apply, and NIS2 remains directly relevant to entities or activities that fall within its scope outside the requirements displaced by DORA. The practical implication for a spec: don't hard-code "always file under both frameworks" into the incident process. Build the classification step to determine which regime and obligations actually apply to the entity and incident, and let the notification workflow branch from there — the same discipline we've written about before for any requirement that depends on a jurisdictional or regulatory fact that isn't fixed at design time. 

What actually survives contact with a real incident 

None of this works as a policy document nobody's read before 2 a.m. on the night it matters. The classification authority, the filing template, the separation between what goes to the regulator and what goes in the retro — all of it has to be decided and rehearsed before the clock starts, because a four-hour deadline leaves no room to invent a process while also running one. 

Blameless culture and regulatory notification aren't actually in conflict. They just can't be the same document, written for the same purpose, on the same clock — and the moment a team tries to make them one thing is the moment one of the two purposes quietly loses.