The most damaging crisis-response failures we have seen had nothing to do with the recovery procedures. They had to do with hesitation at the activation moment. Should we declare formal activation? Are we sure this meets the threshold? Maybe wait another hour to see if it resolves? Two hours later, the response is two hours late, and the post-incident review will spend most of its time on the hesitation, not the recovery.
This article walks through how to write activation criteria that hold up under stress. The parent topic is our crisis management playbook.
Why vague criteria are dangerous
"Activate when the incident is significant" is not activation criteria. It is a decision asking to be deferred. Under stress, ambiguity defaults to "let's wait and see." That is the wrong default; the right default is "if uncertain, activate."
Specific criteria flip the default. "Activate when more than 50 customers report failed transactions in any 15-minute window" leaves no judgement to apply — count the reports, compare to the threshold, decide. The duty manager who hits that threshold at 3 a.m. activates without hesitation because the criterion has done the thinking in advance.
The threshold types
Activation criteria are mixes of three types:
Quantitative thresholds. Numeric triggers that can be measured at the moment. Examples: customer-impact volume, financial-loss rate, duration of service unavailability, transaction failure rate, latency exceedances. These are the strongest criteria because they leave no judgement to be applied.
Categorical triggers. Events of specific types that trigger activation independent of quantity. Examples: confirmed cyber-incident classified at a specific severity, regulator notification triggered, media inquiry received, life-safety concern raised. Categorical triggers complement quantitative thresholds — some events should trigger activation regardless of measured impact.
Qualitative escalation criteria. Reserved for situations the other two miss. Examples: "anomalous pattern that the duty manager assesses warrants senior involvement." Useful as a backstop but should not be the primary criteria.
A robust activation matrix uses all three layers, weighted towards quantitative wherever measurement is possible.
A working format
For each BCP, capture activation criteria as a structured list:
Plan: Card Authorisation Continuity Plan
Activation Authority: Duty Manager (Payments) or above
QUANTITATIVE TRIGGERS (any one):
- Transaction failure rate > 5% sustained for 10 minutes
- Customer-reported failures > 50 in any 15-minute window
- Authorisation latency > 2 seconds sustained for 5 minutes
- Service unavailable > 5 minutes
CATEGORICAL TRIGGERS (any one):
- Confirmed cyber-incident affecting authorisation infrastructure (severity High or above)
- Primary payment-processing vendor declares outage
- Regulatory notification triggered under SAMA reporting rules
- Major incident declared by IT operations
QUALITATIVE TRIGGER (backstop):
- Duty Manager assesses an anomalous pattern that warrants senior payments
involvement, even if other criteria not met.
ON ANY TRIGGER:
1. Activate BCP within 15 minutes
2. Notify Crisis Management Team within 30 minutes
3. Begin §8.5 activation log entry immediately
The format is short on purpose. A duty manager at 3 a.m. needs to be able to scan the criteria in under a minute.
Calibrating the thresholds
Setting the numeric values is the hardest part. Too tight, and the plan activates for every routine incident — fatigue sets in, real activations are taken less seriously. Too loose, and real crises get under-reacted to.
The calibration method we have seen work:
- Look at historical incidents. Pull the last 12 months of incidents that, in retrospect, should or could have triggered BCP activation. Note the values of measurable metrics at the point activation should have happened.
- Set the threshold at the lower end of the historical range. If past activations happened at 30-80 customer reports, set the threshold at 30 — accept that some borderline cases will activate.
- Validate against an exercise. Tabletop a near-miss scenario; check whether the proposed thresholds would have triggered correctly.
- Review annually. Thresholds drift as business volume changes. A threshold set when the customer base was 100k may be miscalibrated when it reaches 1m.
Authority — who can activate
The activation matrix needs to name who has authority to activate. Two patterns:
Bottom-up activation. Any duty manager or designated incident commander can activate. Escalation to the CMT happens after activation, not before. Pro: faster response. Con: more activations.
Top-down activation. Activation requires senior sign-off. Duty manager flags; senior decides. Pro: fewer false activations. Con: hesitation risk.
For Tier-1 critical-service plans we recommend bottom-up: the cost of waiting for senior sign-off outweighs the cost of occasional over-activation. For lower-tier plans, top-down is acceptable.
In both cases, the deputies must be documented. "Activation requires the Head of Operations" is broken if the Head of Operations is on annual leave. Name the role and deputies; the activation matrix should never have a single point of failure.
Deactivation criteria
Often forgotten. An activation that never formally deactivates pollutes the §8.5 activation log and confuses post-incident review. Define explicit deactivation criteria for every plan:
- Service has been restored to normal operating parameters for [X] minutes
- Quantitative trigger metrics have been below thresholds for [Y] minutes
- The Crisis Management Team has authorised stand-down
Capture the deactivation timestamp alongside the activation timestamp in the §8.5 log.
What auditors and examiners look for
Both ISO 22301 Stage 2 auditors and SAMA examiners sample activation criteria. The patterns they flag:
- Free-text activation criteria ("when the incident is significant")
- Criteria with no quantitative component
- Criteria that refer to named individuals as activation authority
- No documented deactivation criteria
- Activation criteria that don't match the §8.5 log — i.e., real activations happened that should not have under the criteria, or vice versa
The fix is structural: capture activation criteria as structured records per plan, validate them against the activation log, refresh them annually. See our ISO 22301 §8.4.4 article for the field-level requirements.
The exercise dimension
Activation criteria should be exercised, not just documented. The exercise programme should include scenarios that test borderline activation decisions — "the duty manager sees X; should they activate?" Tabletop exercises that focus on the activation moment, rather than skipping to the recovery, expose miscalibrated thresholds before real incidents do.
For the broader crisis-management context, return to the crisis management playbook. For the platform surface that captures activation criteria as structured plan fields, the BCMStack BCP module is built around the §8.4.4 surface.