ISO 22301 and business continuity: from the plan to the real drill

A business continuity plan that no one has tested is almost as dangerous as having none at all, because it creates a false sense of security. The ISO 22301 standard exists precisely to avoid that: it turns continuity into a living management system, not a document that sleeps in a drawer until the day of the disaster.

What ISO 22301 is

ISO 22301 is the international standard for business continuity management systems. It defines how an organisation should prepare to respond to and recover from disruptive incidents, from a cyberattack to a physical catastrophe. Its logic is continuous improvement: plan, test, learn and adjust.

What sets it apart from a simple plan is the requirement to demonstrate that it works. Having procedures is not enough: you have to exercise them and improve them with the evidence that drills provide.

From impact analysis to the plan

The business impact analysis

Everything starts with the impact analysis, which identifies which processes are critical and how long the organisation can survive without them. Without this analysis, continuity plans protect what does not matter and neglect the essential.

Recovery strategies and plans

With priorities clear, recovery strategies are defined that are realistic and proportionate to the risk. This ties in with cybersecurity risk management: continuity and security are two sides of the same resilience.

ISO 22301, DORA and NIS2

In regulated sectors, ISO 22301 fits naturally with other requirements. The DORA regulation demands operational resilience in the financial sector and NIS2 requires continuity in essential services. Implementing the standard helps demonstrate compliance with both, taking advantage of common controls instead of duplicating them.

The drill: the acid test

The part most neglected and most valuable is the drill. Rehearsing a real scenario reveals the gaps that no document shows: outdated contacts, forgotten dependencies, decisions with no owner. Each drill is an investment that pays off handsomely the day a real incident occurs.

Mistakes that ruin a continuity plan

I have seen continuity plans that are impeccable on paper fail on the day they were really needed. The most common mistake is writing the plan and filing it away in a drawer without touching it again. The company changes, systems evolve and contacts expire, so a plan from three years ago is usually full of phone numbers that no longer exist and procedures pointing to servers that are switched off. A continuity plan is only worth anything if it is kept alive.

The second mistake is setting unrealistic recovery objectives. Promising that everything will be back in an hour sounds good in a meeting, but if the infrastructure does not allow it, that objective only breeds frustration and recrimination when the incident arrives. I prefer honest, achievable objectives, agreed with the business and with technology, over pretty figures that are impossible to meet.

Continuity and incident notification go hand in hand

A continuity plan does not operate in a vacuum. When a serious disruption occurs, there are often also legal obligations to notify regulators or customers within very tight deadlines. That is why I always connect business continuity with the notification process, as I explain in my article on 72-hour incident notification. Restoring the service and communicating the incident are two sides of the same response, and it is worth rehearsing them together.

In practice, during a drill I check not only whether the systems come back, but whether people know who to alert and in what order. That coordination between the technical and the regulatory is where I detect the most failures, and also where the most is gained when it is rehearsed seriously.

My conclusion is that business continuity is not measured by the thickness of the document, but by the quality of the last drill. An organisation that rehearses discovers its weak points in a controlled environment, not in the middle of a crisis. That, in the end, is the whole philosophy of ISO 22301: resilience is not declared, it is demonstrated.

Something I learned managing continuity is that a plan no one has tested is not a plan, it is a document. That is why I place so much importance on recovery exercises: drills where the plan is activated under realistic conditions and where you time how long the organisation really takes to get back up and running. Those tests almost always reveal mistaken assumptions —a backup that did not restore, an outdated contact— that on paper seemed resolved. Repeating them regularly is what turns the ISO 22301 standard into real resilience and not a file that is signed and forgotten.

It is also worth reviewing the plan whenever something relevant changes in the organisation: a new critical supplier, a technology migration or a change of premises. An outdated continuity plan gives a false sense of security that, when the critical moment comes, can prove very costly.

Conclusion: continuity that is demonstrated

ISO 22301 transforms business continuity from good intention into demonstrable capability. My experience is emphatic: the difference between surviving a crisis and sinking in it is not having a plan, but having tested it. The standard requires, with good reason, that you test it.

Frequently asked questions about ISO 22301