ISO 22301
Security and resilience — Business continuity management systems. Updated: September 29, 2026.
ISO 22301 certifies a business continuity management system: the capability to keep delivering at an acceptable level when something goes badly wrong. For anyone doing infrastructure work it is the standard that most directly overlaps with what we build, because it is the one that insists the plan be tested.
What It Requires
- A business impact analysis. Which activities matter, how long they can be down before the damage is serious, and how much data loss is tolerable. This produces recovery time and recovery point objectives as numbers derived from business consequence rather than from what the infrastructure happens to manage.
- Risk assessment for the disruptions that could realistically occur.
- Continuity strategies proportionate to those objectives — an activity that must resume in fifteen minutes needs a different arrangement from one that can wait two days, and paying for the first where the second would do is the most common waste in this area.
- Documented procedures that someone other than the author can follow, including how the incident is declared and who may declare it.
- Exercises and testing, on a programme, with the results recorded and acted on. This is the clause that makes 22301 useful.
Where It Meets the Infrastructure
Directly. Disaster recovery planning is the technical implementation of what 22301 requires at the business level, and backup and recovery is where the recovery point objective becomes a real number. An organisation that has done that work honestly — with restores actually tested and timed — is much of the way to the evidence 22301 asks for.
The gap for most technical teams is the other direction: 22301 is a business continuity standard, not an IT one. It asks about premises, people, suppliers and communications, not only systems. A perfect DR plan with no answer for “the office is inaccessible and nobody knows who calls the customers” does not satisfy it.
Who Needs It
Financial services, healthcare, utilities, logistics and anyone in a regulated sector where resilience is supervised. Also increasingly requested in supply-chain questionnaires by large customers who have realised their own continuity depends on yours.
What the Auditor Will Ask to See
- The business impact analysis, with recovery time and recovery point objectives derived from business consequence rather than from what the infrastructure happens to achieve.
- Continuity plans that someone other than the author can follow, including who may declare an incident.
- Exercise records — the clause this standard turns on. The plan, the date, who took part, what went wrong, and the actions arising. A plan never exercised is the classic finding, and the one thing here that cannot be produced in a hurry.
- Evidence a recovery objective was actually met: a timed restore or failover, with the elapsed time against the stated target. Our restore testing and DR work produces exactly this.
- The non-technical side, which engineering teams routinely omit: premises, people, suppliers, and how customers are told. A faultless DR plan with no answer for an inaccessible office does not satisfy the standard.
- Supplier continuity — what happens when a dependency is the thing that fails.
What It Does Not Prove
That you will survive the next disruption. It certifies that you worked out which activities matter, how long they can be down, what you would do, and that you rehearsed it — which is substantially more than most organisations have, and still not a guarantee.
The recovery objectives in particular are worth reading rather than assuming. They are set by the organisation being certified, from its own impact analysis. A supplier conformant to ISO 22301 with a 72-hour recovery target is conformant; so is one with fifteen minutes. The certificate tells you they have a tested plan. The objectives tell you whether it is a plan you can live with.
Getting Certified
Same structure as the other management system standards, with one addition worth planning for: you need evidence of exercises having been run before an auditor will certify. That cannot be compressed — a test programme has to have actually happened, which puts a floor under the timeline regardless of how good your documentation is.
Written from an infrastructure perspective. We are not a certification body, an audit firm or a legal adviser, and this is not legal advice. Standards are revised on a cycle — confirm the current edition before you commit.