If you read only one sub-clause of ISO 22301:2019 closely, read §8.4.4. It is the sub-clause that specifies the required content of a business continuity plan, and it is the single most-sampled item in a Stage 2 audit. Plans that miss its fields fail. Plans that bury them inside free-text paragraphs still fail, just more politely. This article walks through each field, what auditors look for, and the patterns we see in plans that pass cleanly.
The parent topic is our ISO 22301 implementation pillar. Read that first if you need the broader certification context.
The fields, one by one
Purpose
A single-paragraph statement of why this plan exists and what business outcome it protects. "Restore card authorisation services within RTO during disruption of the primary payment-processing platform." Specific. Outcome-oriented. Not "to ensure business continuity" — every plan would say that and it tells the auditor nothing.
Scope
What the plan covers — and crucially, what it does not. Processes, services, locations, customer segments, time-of-day applicability. Scope is where most plans hide ambiguity. A good scope statement makes it unambiguous whether the plan applies to a specific incident; a vague one forces real-time interpretation under stress.
Activation criteria
The threshold conditions under which the plan is invoked. Quantitative wherever possible — duration exceeded, customers affected, financial-impact threshold breached, regulatory notification triggered. Qualitative criteria are fine as backup, but the auditor will probe for the numeric thresholds first. See our crisis management pillar for the deeper treatment.
Deactivation criteria
When the plan stands down. Often forgotten. Without explicit deactivation criteria, plans linger in "activated" status long after the underlying disruption is resolved, distorting the §8.5 log and confusing post-incident review. Specify the state the organisation must reach before formal stand-down.
Classification
Public, internal, confidential, restricted — with handling rules. A plan that contains call-tree contact details, vendor failover credentials or recovery-site addresses cannot be "internal" with unrestricted circulation. Classification drives access control, redaction rules and distribution lists.
Responsibilities and authorities
Named roles, not named individuals. Plans tied to a specific person break the moment that person leaves, takes leave or is unavailable. Define the role ("Incident Commander — Payments"), the decision rights ("authorised to invoke the recovery procedure without further escalation up to 6 hours"), and the chain of deputies.
Procedures
The actual recovery steps. The most-sampled portion of the plan. Each step should be specific enough to execute under stress — system names, exact commands, expected outputs, decision points. Procedures should ideally be phased per §8.4.5 (immediate response, stabilisation, recovery, return to normal). Step-numbering matters; auditors trace the steps end to end.
Target RTO and RPO
Derived from the BIA, not invented at planning time. The BCP commits to deliver against these numbers; the recovery infrastructure must be evidenced to support them. An RTO promised in the plan but not achievable by the recovery infrastructure is the kind of inconsistency that surfaces in Stage 2 audits. Read our BIA pillar for how RTO and RPO are derived defensibly.
References
Other plans this plan depends on or hands off to. IT disaster-recovery runbooks, vendor escalation procedures, regulator notification templates, communications playbooks. Make the references explicit and version-pinned. A plan that says "see DR runbook" without specifying which one is doing half the work it should.
Common failure modes
Three patterns appear in the majority of §8.4.4 reviews:
Free-text fields. All nine field categories are present, but they are scattered through narrative paragraphs in a Word document. Aggregating across plans — "show me activation criteria for every Tier-1 plan" — is impossible without re-reading each one. The fix: structured records with each field as a discrete column or property.
Named individuals, not roles. Plans say "Ahmed Al-Otaibi is the incident commander." When Ahmed leaves, the plan is silently broken. The fix: roles with documented deputies, refreshed on the standard annual cycle.
Procedures that assume calm. Steps assume the responder has time to read context, look up references and make judgement calls. In a real activation at 3 a.m. they do not. The fix: procedures written for the stressed, sleep-deprived responder. Specific. Sequential. Decision points called out.
How auditors sample
A Stage 2 auditor picks two or three critical plans and traces them. For each, they verify each §8.4.4 field is present, specific and current. They check that the RTO and RPO match the BIA. They check that the most recent activation (real or exercise) was logged. They check that any improvement actions from the last AAR are reflected in the current plan version.
The pattern that passes cleanly: every §8.4.4 field is a discrete, queryable property of the plan record. The plan exports show the fields in structured form. The platform — or the spreadsheet, if you are still on spreadsheets — can answer "show me the activation criteria for every Tier-1 plan" in seconds, not days.
That is the surface BCMStack's BCP module is built around. Every §8.4.4 field is a native, typed record on the plan. Audits move faster because there is no narrative archaeology to do.
Where this fits in the wider standard
§8.4.4 is one of several sub-clauses that together define the operational core of ISO 22301. It pairs with §8.4.5 (phased recovery procedures), §8.5 (exercising and testing — including the activation log), and the BIA in §8.3. The full clause structure is in the ISO 22301 pillar.
If your next audit is more than ninety days out, the highest-leverage move is to take one Tier-1 plan, rewrite it to §8.4.4 quality, and use it as the template for the rest. Resist the temptation to refresh every plan at once. Quality on one, then propagate the pattern.