The Review Is Not the Verdict

Before the detail — Artifact: the postmortem, pointed at the record’s corrective-action register and never carrying a second one. Status of what follows: the review after a Congressional breach report is binding on the officer it names; postmortem triggers and blameless practice are common baseline everywhere else.

Prompt first: build the postmortem-trigger checklist

Here is our incident record for INC-[id] [paste section 2 Impact and
section 3 Timeline - the impact and timeline, no names beyond role].

Check it against these postmortem triggers and answer yes/no for
each, quoting the record field that decided it:
  - user-visible downtime past [our threshold]
  - data loss of any kind
  - an on-call intervention: rollback or rerouting
  - resolution time past [our threshold]
  - a monitoring failure
  - a stakeholder request (name the stakeholder, if one exists)

If ANY answer is yes, output "REVIEW REQUIRED" and name which
postmortem trigger fired. If a field the check needs is missing from
the record, write MISSING - do not guess a threshold or a duration.

The assistant is scoring a checklist against a record that already exists, not deciding whether the incident mattered — the same discipline 1.3 applied to declaring an incident, now applied to declaring a review.

Blameless is a review discipline, not an outcome

Blameless, in Google’s postmortem culture, means the review’s “focus on identifying the contributing causes… without indicting any individual or team,” on the working assumption that everyone involved had good intentions and acted on the information they had. It is a rule about where attention goes in the room, not a promise that nothing goes wrong: the review still names what happened, in detail, to the people who made the calls — it just never turns a name into a verdict.

NIST SP 800-61r3 (NIST’s April 2025 incident-handling guidance — a community profile, not a binding mandate) rewrites the old idea that learning happens after recovery: “lessons learned… should often be shared as soon as they are identified, not delayed until after recovery concludes.”

The postmortem trigger, written down

“Any stakeholder may request a postmortem” is Google’s last rule, beside five other written postmortem triggers: user-visible downtime past a threshold, data loss of any kind, an on-call intervention such as rollback or rerouting, resolution time past a threshold, and a monitoring failure. Run that list against sections 2 and 3 so the answer comes from the record rather than from a judgment about severity.

The postmortem itself keeps one rule worth stating here because it governs the whole module: it points at the incident record’s corrective-action register and never keeps a second list of its own, because two lists means one of them is wrong and it is always the one somebody is reading.

The after-action report runs on someone else’s clock

The rule from Grounded Answers 6.3 (a separate training in this series) — the account you can defend — is one example worth carrying here, not a template to reinvent: a wrong answer, walked through the artifacts that already exist, produces a defensible account instead of “we’re looking into it.” An after-action report or external investigation does the same thing for an incident, on a schedule the organization does not set and aimed at a determination the blameless review was never built to make.

M-17-12 (OMB’s 2017 breach-response memo, still the operative guidance — OMB being the White House budget office) is explicit about what that review owes once a breach reaches Congress: the SAOP (the official M-17-12 names to convene this review — an agency’s senior privacy officer) “shall convene… identify any lessons learned… If there are specific challenges preventing agencies from instituting remedial measures, agencies shall also document those challenges.” That last clause is the leadership sentence worth keeping whole: document the challenge you will not fund. Writing down the challenge turns a vague resourcing gap into a named, dated line the next reviewer reads as candor — an audit finding avoided, instead of one an assessor discovers on their own and asks why nobody wrote it down the first time.

The seam: from blameless review to after-action report

The commercial starting practice is the blameless internal review, aimed at contributing causes, run by people who will still be on the rota next month. The federal delta is the after-action report or external investigation, run on someone else’s schedule and aimed at a determination — did this meet the harm test, does a clause apply, is a remedial measure funded. The handoff artifact is the incident record itself: the same timeline, the same timestamped decisions, the same preserved evidence and signatures, read by both processes rather than reconstructed twice. What is not equivalent: blamelessness is a norm an organization grants its own people; an external investigation makes findings, and one document cannot serve both purposes by trying to be gentle and adversarial in the same paragraph.

The same tension appears a size class above Meridian. The Cyber Safety Review Board — the federal body built to review major incidents across an entire sector — had its members dismissed in January 2025, mid-review, while it was still investigating the Salt Typhoon intrusion. The lesson is not about that body’s politics: post-incident learning survives only if someone funds and protects the body that does it. For Meridian, that someone is whoever signs the check for the review process itself; leave it unfunded for a quarter and the corrective-action register in the next lesson has nowhere to land, which is a contract-renewal risk the vendor carries into its own next review.

Stop and escalate when a postmortem trigger fires and the only available facilitator is the incident commander who ran the response, or when a corrective action shows up with no owner willing to fund it and no documented reason why — escalate to whoever signs the incident record’s move to reviewed, because a self-facilitated review is not blameless, and an unfunded gap with no documentation is the finding an outside assessor writes for you if you do not write it first.

Practice status — among organizations that run named incidents to a written record, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

A postmortem trigger written down in advance — user-visible downtime, data loss, an on-call intervention, resolution time past a threshold, a monitoring failure, or any stakeholder’s request — turns “should we review this” into a record-backed check instead of a judgment call made by whoever is tired. The blameless internal review and the after-action report or external investigation are two documents for two audiences, both pointed at the same incident record rather than inventing their own. Where a determination reaches Congress or a regulator, M-17-12 requires the review to name, in writing, the challenges the organization will not fund — the leadership sentence that keeps next quarter’s incident from repeating a known, unfunded gap. Lesson 5.2 turns to what the review actually reads: the timeline reconstructed from logs, traces, and chat.

LEADERSHIP DECISION   adopt a written postmortem-trigger list and
                      name who protects the after-action process's
                      funding past this budget cycle
PRACTITIONER ACTION   run every incident against the postmortem
                      trigger list, facilitate with someone who was
                      not mitigating, and write the unfunded
                      challenge down instead of leaving it unsaid
SUCCESS MEASURE       zero incidents that met a postmortem trigger
                      and skipped review, and zero unfunded remedial
                      measures missing from the record - an audit
                      finding avoided before an assessor writes it