An After-Action Report is the artefact that turns every incident — exercise or real-world — into programme improvement. Done well, the AAR is the most valuable single document the BCM programme produces. Done badly — and most are done badly — it is performative paperwork that ages on a SharePoint folder.
This article walks through an AAR template that works. The parent topic is our crisis management playbook.
Why most AARs fail
Three failure modes recur across organisations:
AAR theatre. The AAR is written because procedure requires it. Improvement actions are vague ("improve communications"), ownerless, or quietly deferred. The next exercise reveals the same gaps. Common in compliance-driven programmes.
Blame theatre. The AAR becomes a defensive document. Team A blames Team B; nothing useful gets captured because everyone is protecting their territory. Common in low-trust environments.
Timeline theatre. The AAR is a minute-by-minute timeline of events with no analysis. The reader learns what happened but not why it happened or what to do differently.
The working AAR avoids all three by being structured, blame-free, and action-oriented.
The structure
A working AAR has six sections. The format below is what we have seen produce real improvement.
Section 1: Event summary
A short, factual paragraph stating what happened, when, what BCPs activated, and the outcome. No analysis, no judgement.
"On 2026-04-12 at 03:14 UTC, the primary card-authorisation service experienced sustained latency exceeding 2 seconds. The Card Authorisation Continuity Plan was activated at 03:42. Service was restored to normal operating parameters at 05:11. Estimated customer impact: 1,200 failed transactions. No regulatory notification was required."
The summary is what the BCM committee sees. Keep it short.
Section 2: Timeline
Sequence of events with timestamps and named actions. Useful as reference, but not the analytical heart of the AAR. Bullet form is fine.
Section 3: What worked
What aspects of the response went well — the patterns the programme should preserve and replicate.
- Activation criteria triggered correctly without hesitation
- Comms team produced customer messaging within 25 minutes of activation
- Fallback to secondary payment processor completed in 18 minutes vs. RTO of 30 minutes
- BCP procedure was usable as written without ad-hoc improvisation
This section is not optional. AARs that only catalogue failures de-motivate the response team and fail to capture institutional knowledge about what to keep doing.
Section 4: What didn't work
The substantive content. What aspects of the response need to change. Specific, not generic.
- Initial customer-facing message went out 35 minutes after activation; target is 15 minutes. Cause: the on-call comms team member could not access the comms template repository.
- Activation criteria did not include a latency-based trigger; the team escalated based on customer reports, which lagged the actual incident by approximately 8 minutes.
- The §8.5 activation log was completed retrospectively by the BCM lead three days later. Timestamps were estimated rather than captured live.
Frame each finding as observation + cause, not as personal blame. The observation is "the message was 35 minutes late"; the cause is "access to the template repository was broken." The improvement action targets the cause.
Section 5: Improvement actions
The output that matters. For each finding in Section 4, name a specific action:
Finding 1: Customer message delayed due to template-repo access.
Action: Grant on-call comms rotation members standing access to template repository.
Owner: Head of Communications
Due: 2026-04-30
Source: AAR §4 item 1
Status: Open
The format matters. Every action needs owner, due date, source (so the action is traceable back to the finding), and status. The action register is the single most-sampled artefact in management review and audit.
Section 6: BIA / BCP feedback
If the incident exposed something the BIA or BCP missed, capture it here as a specific feed into the next refresh cycle.
- Dependency on the comms-template repository was not documented in any BIA. Add to next refresh.
- BCP activation criteria did not include latency-based triggers. Update BCP at next version cycle.
- RTO of 30 minutes was met (18 minutes actual) but margin is thin. Recommend reviewing the recovery infrastructure capability.
This section closes the loop between the AAR and the BIA pillar / BCP §8.4.4 fields.
The hot wash — before the AAR
A working AAR is preceded by a "hot wash" within 48 hours of the event, while memories are fresh. The hot wash is a 60-90 minute meeting with the response team. Output: raw notes, not a polished document.
The hot-wash format:
- What happened? Each participant describes what they observed from their vantage point.
- What worked? Open-floor capture.
- What didn't? Open-floor capture.
- What would you do differently? Each participant.
The hot wash output becomes the input to the AAR, which the BCM lead drafts within two weeks. The AAR is then reviewed by the CMT for approval.
Approval and storage
The AAR is approved by the Crisis Management Team. Storage matters: the AAR, the activation log entry, and the improvement actions should all live in the same dataset as the BCP they relate to, so the audit trail is queryable end-to-end. A platform that ties AARs to BCPs and to the §8.5 log keeps the chain intact; SharePoint folders tend to lose the connections.
For the broader management-review context, see the §9.3 management review article. For the platform surface that ties AARs to plans and activations, the BCMStack crisis events module is built around this lifecycle.
What to avoid
Avoid generic actions. "Improve communications" is not an action. "Grant on-call comms rotation members standing access to template repository" is.
Avoid ownerless actions. Every action has a single accountable role. Multi-owner actions become no-owner actions.
Avoid blame language. "Sara didn't escalate quickly enough" is unhelpful and unfair. "The escalation procedure did not specify a time-based trigger" is useful.
Avoid sandbagging. Stretch due dates kill momentum. If an action is genuinely 90 days of work, set 90 days; if it's a 5-minute fix, set this week.
Avoid AAR-as-archive. The AAR is not done when it's written. It's done when its improvement actions are closed. Track to closure or explicitly retire with rationale.
For the broader crisis-management context, return to the crisis management playbook.