What ISO 22301 Actually Requires
ISO 22301 specifies a Business Continuity Management System (BCMS) — a management system, not a plan. The distinction matters, because certification and internal audit both test the system rather than the document.
The standard's substantive demands are:
- Context and scope — which parts of the organisation and which products or services the BCMS covers, and the interested parties whose requirements it must satisfy.
- Business impact analysis and risk assessment — a documented, repeatable methodology, not a one-off workshop.
- Business continuity strategy — recovery options chosen and justified against the RTOs the BIA produced.
- Documented procedures — response structure, incident communications, recovery plans.
- Exercising and testing — on a defined programme, with results retained.
- Evaluation — performance measurement, internal audit, and management review.
- Improvement — nonconformities and corrective actions tracked to closure.
Most organisations have the plans. What they usually lack is the evidence trail connecting a BIA to the RTO, the RTO to the chosen strategy, the strategy to a tested procedure, and the test findings to closed actions. That chain is what an auditor follows.
The Business Impact Analysis
The BIA is the foundation of everything else, and its output is not a document — it is a set of numbers that drive investment decisions.
For each activity in scope, the BIA establishes:
- Impact over time. How consequences accumulate during an outage — at one hour, four hours, a day, three days, a week. Impact is rarely linear, and the shape of that curve is the point of the exercise.
- MTPD — the Maximum Tolerable Period of Disruption, where impact becomes unacceptable.
- RTO — the Recovery Time Objective, set below MTPD with margin so that a recovery that goes imperfectly still lands inside tolerance.
- RPO — the Recovery Point Objective: maximum tolerable data loss, expressed as time. This is a separate question from RTO, answered by how much work the business can reconstruct.
- Minimum resources — the people, systems, facilities, information and suppliers needed to run the activity at a reduced but acceptable level.
- Dependencies — upstream and downstream, internal and external.
RTO and RPO Are Business Decisions
Both belong to the business, not to IT. RTO comes from consequence over time; RPO comes from data-loss tolerance. Only once both exist does the technical conversation make sense, because together they determine the recovery architecture and its cost — a 15-minute RPO implies near-synchronous replication, a 24-hour RPO implies nightly backup.
Choosing the technology first and then documenting whatever it happens to deliver inverts the exercise. It is also the most common finding in BCMS audits.
Dependency Mapping
A BIA that stops at process criticality is only half finished, because recovery order is determined by dependencies rather than by importance.
The failure that catches organisations out is the dependency chain longer than its weakest link: a process with a four-hour RTO that depends on an application with an eight-hour RTO does not have a four-hour RTO. It has an eight-hour one, and the plan is documenting a fiction. The same applies to suppliers — a third party with a 72-hour recovery commitment caps every activity that depends on them, whatever your own plan says.
Surfacing these conflicts requires holding every BIA in one structure so the chain can be traversed: which activities depend on this supplier, what is the true achievable RTO once the chain is resolved, and where do the stated and achievable numbers disagree. Per-department spreadsheets cannot answer that, because each one only sees its own process.
Exercising the Plan
Exercise types, in increasing order of cost and of what they actually prove:
| Type | Proves |
|---|---|
| Plan walkthrough | The document is current and the owners recognise it |
| Tabletop | Decision authority is clear; contacts and assumptions hold |
| Functional test | One component genuinely recovers, in the time claimed |
| Full simulation | End-to-end recovery works under realistic conditions |
The output that matters is the gap list, and gaps must become tracked actions with owners and due dates. An exercise whose findings are not closed is evidence of a weakness, not evidence of resilience — and an auditor will read it that way.
Interested Parties
ISO 22301 requires you to identify interested parties and their requirements. In practice this means contractual recovery commitments to customers, regulatory expectations for your sector, supplier obligations flowing the other way, and internal stakeholder expectations.
These frequently conflict with what the BIA says is achievable. Discovering that a customer contract promises a four-hour recovery for a process with an eight-hour achievable RTO is precisely the kind of finding the standard is designed to surface — before an incident does.
How ActiveERM Supports ISO 22301
The Business Continuity module holds BIAs under one methodology with consistent scales, records RTO/RPO with the impact analysis that justifies them, maps dependencies across processes, applications and suppliers so achievable recovery times roll up automatically, and tracks exercises with their findings through to closure.
Because it sits on the same platform as the risk register and the GRC control library, continuity stops being a parallel system with its own vocabulary. Continuity risks are risks; continuity controls are controls; the evidence lives where the auditor already looks.
For the practical method behind the analysis, see our BIA guide and our guide to building a dynamic BCP.