Almost every organisation has backups. Very few know how long it would actually take them to resume operations after a serious disruption, or which processes to bring back first. That gap, between having backups and having continuity, is exactly what ISO 22301 puts in order. In this article I explain what the standard requires, how to run an impact analysis that is actually useful for deciding, what RTO and RPO mean when money is on the line, why a plan that has never been tested does not count, and how all of this fits with what ISO 27001, NIS2 and DORA already ask of you.
What ISO 22301 is and the problem it solves
ISO 22301:2019 is the international standard for business continuity management systems. It is not an IT recovery manual: it is a framework for an organisation to identify which activities it cannot afford to lose, for how long, and what it has ready to sustain them when something fails.
The difference from a disaster recovery plan is one of scope and purpose. Recovery looks at systems; continuity looks at the business: people, premises, suppliers, processes and data. A replicated data centre is worth nothing if the team running the critical process cannot work and nobody has decided who declares the crisis.
Like the other management system standards, it follows the Annex SL high level structure, with its clauses on context, leadership, planning, support, operation, performance evaluation and improvement. If your organisation already works with ISO 27001, the skeleton will feel familiar and much of the system can be reused.
The BIA: where everything else is decided
The business impact analysis, or BIA, is the piece that holds up the rest of the standard. It is where you answer an uncomfortable question: if this activity stops, what happens and from when does it start to hurt.
A BIA that is useful for deciding measures impact over time, not at a single moment. The same outage of an invoicing service may be irrelevant for two hours, awkward at eight, and serious after three days, when payment deadlines land. That time profile is what then sets priorities and budget.
A well run BIA produces three things you will use everywhere else: the prioritised activities, the maximum tolerable period of disruption for each, and the minimum resources needed to sustain them, including the suppliers you depend on without ever having written it down.
The most common mistake I see on projects is running the BIA by department instead of by activity. A department does not get interrupted: a process does, and it almost always crosses several departments and an external supplier.
RTO and RPO, explained through a case
These are the two numbers that govern the investment, and they are confused constantly. It helps to pin them down with an example.
Picture a payroll bureau. The RTO, recovery time objective, is how long the service can be down before the damage becomes unacceptable: say eight working hours. The RPO, recovery point objective, is how much data you can afford to lose, measured in time: if the backup runs overnight, the RPO is twenty four hours, and that means a failure at six in the evening wipes out a full day of work that will have to be redone by hand.
The practical consequence is direct: lowering the RPO costs technology (replication, more frequent backups) and lowering the RTO costs preparation (standby environments, rehearsed procedures, trained people). Setting both to zero is an expensive fantasy, and setting them without a BIA is guesswork.
There is a third number that gets forgotten and decides whether the other two are credible: the maximum tolerable period of disruption. If the RTO you have set exceeds it, the plan protects nothing: it merely documents when it will fail.
From strategy to a plan someone actually runs
With the objectives set, the standard asks you to choose continuity strategies and turn them into concrete procedures. The usual options are to sustain the activity elsewhere, degrade it to an agreed manual mode, transfer it to a third party, or accept the risk explicitly and in writing.
Accepting the risk is a legitimate answer, and it is worth saying so, because the fear of writing it down leads to inventing plans nobody will ever run. What is not legitimate is not having decided.
On the plan side, what separates a useful one from a decorative one is that it answers four questions without anyone having to interpret anything: who decides to activate it, who gets told and through which channel when corporate email is precisely what is down, what happens in the first two hours, and how you return to normal, which is the part that is almost always missing.
Looking to certify as an ISO 22301 Lead Implementer?
Official PECB training with a working consultant, at your own pace or with one to one coaching.
An untested plan is not a plan
This is where management systems that work part company with those that only exist in a folder. The standard requires a programme of exercises and testing, and not as a formality: a plan that has never been executed contains, without exception, false assumptions.
Exercises go from light to heavy and you do not need to start with the most expensive: desk review, tabletop exercise with the real owners, simulation of a specific component, and finally a test with a real failover. Each level uncovers different things.
The value of the exercise is not passing it. It is the list of what went wrong, with an owner and a date behind each line.
Continuity is not proven on the day of the incident: it is proven on the day of the exercise. Whoever has only the document discovers their false assumptions at the worst possible moment, and with clients watching.
How it fits with ISO 27001, NIS2 and DORA
This is the part that matters most to anyone already inside a compliance programme, because it avoids paying twice for the same work.
With ISO/IEC 27001 the overlap is substantial: shared high level structure, context analysis, documented information, internal audit and management review. What ISO 27001 treats as a single control, continuity, ISO 22301 develops as a complete system.
NIS2 requires it explicitly: among the measures in its Article 21 is business continuity, including backup management, disaster recovery and crisis management. A system conforming to ISO 22301 is the most orderly way to evidence that block to an authority.
And for financial entities, DORA goes further still: it requires an ICT business continuity policy, response and recovery plans, and periodic testing with documented results. The concepts are the same and the work is almost entirely reusable.
In a real project this means the BIA you run for ISO 22301 will support decisions across the other three frameworks. It is worth doing properly once.
Training and certification
If you want to move to official PECB certification, there are three levels depending on what you need. ISO 22301 Foundation to master the framework and the vocabulary. Lead Implementer if you are going to build the management system. Lead Auditor if you are going to audit it, on your own account or for a certification body.
All three can be taken as self study, with the official PECB material and at your own pace, or with coaching in one to one sessions with me if you would rather work through your own case than a textbook example.