Crisis Management Playbook: From First Alert to Post-Incident Review

Crisis management is where every other part of the BCM programme is tested. The BIA matters because it tells you what to protect. The BCPs matter because they tell you how. But the crisis-management surface — the moment between "something has gone wrong" and "we are back to normal" — is what auditors, regulators, customers and boards actually judge you on.

This pillar is the cornerstone of our crisis management series. It walks through the command structure, the activation handshake, the communications discipline that distinguishes credible responses from chaotic ones, and the post-incident lifecycle that turns every event into programme improvement. It pairs closely with our ISO 22301 implementation guide — crisis management is the operational expression of ISO 22301 §8.5.

What "crisis" means in a BCM context

The terminology varies by organisation, but the operational distinctions matter. We use three tiers:

• Incident — an unplanned event that disrupts a service or function. Handled inside normal operational structures (NOC, SOC, ops team). Most incidents never escalate.
• Major incident — an incident that breaches a defined threshold (duration, customer impact, regulatory exposure) and warrants formal escalation. The first BCP-activation candidates live here.
• Crisis — a major incident with strategic, reputational or regulatory dimensions that require executive-level decisions. The crisis-management team is engaged; the crisis-comms protocol activates.

These are not academic distinctions. They drive the escalation matrix, the call-tree, the comms approval chain and the regulator-notification timeline. A vague threshold model is one of the most common sources of decision paralysis in real events.

The command structure

A credible crisis-management programme has three layers of decision-making, each with explicit scope:

Strategic layer — the Crisis Management Team (CMT). Executive-level. Decides whether to invoke business continuity plans, whether and how to communicate externally, whether to engage regulators, and how to allocate scarce resources between competing recovery priorities. Typically the CEO or COO chairs, with CRO, CISO, GC, Head of Operations, Head of Communications and the BCM lead. Meets in extraordinary session within minutes of activation, not hours.

Tactical layer — Incident Commanders. Service- or function-level. Decides how to execute recovery within their domain. Owns the operational response to a specific disruption — the IT recovery plan, the branch fallback procedure, the call-centre redirect. Reports status upward to the CMT on a defined cadence.

Operational layer — Response Teams. The hands-on work. Engineers running runbooks. Branch staff executing fallback procedures. Comms team drafting customer messages. Operates inside the boundaries set by the tactical layer.

Each layer should know what it owns, what the layer above expects from it, and what the layer below needs from it. Drawing the structure on paper is the easy part; rehearsing it in exercises is the work.

Activation criteria

The single biggest cause of weak crisis responses is unclear activation criteria. People hesitate to escalate because the threshold is fuzzy. Plans get invoked too late, or — almost as bad — formal activation never happens, and the response runs in the grey zone between BAU and crisis.

A credible activation matrix is specific. For each plan type, define:

• Quantitative thresholds. Number of customers affected, financial loss per hour, duration exceeded, geographic scope, regulatory deadline at risk.
• Qualitative triggers. Media inquiry received, regulator notification triggered, life-safety concern, cyber incident classified as significant.
• Decision rights. Who has authority to activate — and who has authority to escalate to crisis status.
• Notification chain. Who is informed, in what order, on what channels, with what initial brief.

Make the criteria explicit enough that any duty manager can apply them at 3 a.m. without consulting a senior. The criteria live in the BCP itself, per ISO 22301 §8.4.4, and are re-tested in every exercise.

The communications discipline

Communications is where most crises are won or lost from a reputational standpoint. The technical recovery may be excellent, but if the customer-facing narrative is incoherent, the institution still takes the hit.

A credible comms playbook covers five audiences, each with its own approval chain and template set:

• Customers. Acknowledgement of impact, what we are doing, when to expect the next update. Honest about uncertainty. Approved by the comms lead in coordination with the CMT.
• Staff. What is happening, what is expected of them, where to direct customer questions. Cascaded through line management, not blasted to all-staff distribution lists.
• Regulators. Notifications driven by reporting obligations — SAMA, central banks, sector regulators. Timing rules vary; some are within 1 hour of confirmed impact, others within 24 hours. The trigger list lives in the playbook, not in someone's memory.
• Media and analysts. A holding statement is prepared in advance, not drafted at 2 a.m. The crisis-comms lead is the single voice; everyone else declines to comment.
• Internal leadership and board. Cadence-driven updates: every 30 minutes for the first 2 hours, then hourly, with structured content (status, actions, next decision point, ETA).

The discipline that distinguishes mature programmes is pre-approval: templates for each audience and each likely incident type, drafted in calm time, signed off by legal and comms, ready to fill in. Drafting from scratch in the middle of a crisis is how organisations end up apologising for an apology.

The BCP handshake

When a major incident is declared, the crisis-management team has to decide which BCPs to invoke. The BIA-to-BCP linkage we cover in the BIA pillar guide is what makes this decision tractable: the BIA tells you which services are critical and which dependencies they rest on; the BCPs say what recovery procedures exist for each scenario.

A working handshake looks like this:

1. Incident is declared. Affected service(s) identified.
2. CMT looks up the BIA records for the affected services — criticality tier, MTPD, current RTO commitment.
3. CMT identifies the BCP(s) whose scope covers the incident scenario.
4. Activation decision is taken and logged with timestamp, authoriser and scope.
5. Plan-specific incident commanders are engaged. Their first action is to read the plan and confirm activation steps are still valid.
6. Activation is recorded in the §8.5 activation log — every plan invoked, the trigger event, the start time.
7. Plan-by-plan stand-down decision is taken as recovery completes; deactivation is logged.

Without that data linkage, the CMT spends the first hour figuring out which plans are in scope, which is exactly when the response should be moving fastest. See our crisis events module for how this surface is operationalised inside BCMStack.

The §8.5 activation log

ISO 22301 §8.5 specifies that activations — both exercises and real-world invocations — must be logged. The log is one of the artefacts auditors and SAMA examiners sample most often, because it is the single best evidence that the BCM programme is operational rather than aspirational.

A minimum-viable activation log captures, per entry:

• The plan invoked (with version)
• The event that triggered activation (incident or exercise)
• Start and end timestamps
• Authoriser
• Outcome — successful recovery, partial recovery, failed recovery
• Link to the AAR (after-action report) generated

A complete log over twelve months tells a story — which plans are in active use, which have been exercised, which have never been touched. Plans in the third category are red flags. Either they are protecting something that no longer exists, or they will not work when needed.

The post-incident lifecycle

The crisis ends when normal operations resume, but the BCM lifecycle continues. A credible post-incident process has three phases:

Immediate (within 48 hours). Hot wash. The response team and incident commanders convene while memories are fresh. Capture what happened, what worked, what didn't. The output is raw notes, not a polished document.

Short-term (within two weeks). After-Action Report. Structured document covering the timeline, the response, the decisions taken, the lessons learned, and the named improvement actions with owners and due dates. The AAR is approved by the CMT and feeds into the improvement-action register.

Medium-term (within ninety days). Improvement-action closeout. Every named action is tracked to completion. Some are quick (update a phone number); some are programme-level (restructure the call tree, replace a vendor). Open actions ageing past their due date are a programme health signal.

Long-term (next BIA / BCP cycle). The AAR feeds back into the next BIA refresh and the next BCP version cycle. If the incident exposed dependencies the BIA missed, the BIA gets updated. If the activation criteria were wrong, the BCP gets updated. The loop closes.

Common crisis-management failure modes

Across the engagements we have visibility into, four patterns recur:

Failure 1: No formal activation. The team responds to the incident but never declares formal BCP activation. The §8.5 log is empty. The AAR never gets written. The lesson never feeds back.

Failure 2: Comms drift. Different parts of the organisation tell customers, staff and regulators different versions of the story. The reputational damage outlasts the technical incident.

Failure 3: AAR theatre. The AAR is written, but improvement actions are vague, ownerless, or quietly de-prioritised. Twelve months later the same gap causes the next incident.

Failure 4: Plan-reality drift. Plans are activated, but the team finds the BCP procedures are out of date — contact numbers changed, systems renamed, decision rights moved. The plan slows the response down. The fix is the BCP-currency cadence, not faster ad-hoc decisions.

Crisis management in regulated contexts

For SAMA-regulated institutions, crisis management overlaps materially with SAMA's incident-reporting obligations and the SAMA BCM Framework. The §8.5 activation log is one of the artefacts examiners sample for evidence of operational discipline. For cyber-centric crises, the NCA ECC and SAMA's cyber-resilience expectations layer on top.

For ISO 22301 certification, crisis management is the operational expression of §8.4.5 (response and recovery procedures) and §8.5 (exercising and testing). The ISO 22301 pillar guide covers the clause structure.

Where to start

If you are building or rebuilding a crisis-management capability, the highest-leverage moves in the first ninety days are:

1. Define the three tiers — incident, major incident, crisis — and the thresholds between them.
2. Charter the CMT. Named roles, deputies, escalation routes, meeting rhythm during a real event.
3. Write the activation criteria for every critical BCP. Specific. Threshold-based.
4. Pre-approve comms templates for the top five incident types and the five audiences.
5. Run a tabletop. The first one will be uncomfortable. The lessons are the point.

The cluster articles in this series go deeper into each move:

• Writing activation criteria that hold up at 3 a.m. (article)
• The crisis comms playbook — five audiences, five approval chains (article)
• After-action reports that actually drive improvement (article)

If you want to see how all this looks operationalised, the BCMStack crisis events module covers declared incidents, the §8.5 activation log, the comms record and the AAR lifecycle in one connected dataset.