Here is a question worth sitting with: if your primary office became inaccessible tomorrow morning — fire, flood, infrastructure failure, it does not matter why — how long would it take your organization to resume its most critical operations? Not get back to normal. Just resume the things that, if they stopped, would cause serious harm to customers, employees, or the business itself.
For most organizations, the honest answer is: longer than we'd like to admit. Business continuity planning has a reputation problem. It is the thing that gets done once, filed somewhere, and never looked at again until an auditor asks for it. Then it gets dusted off, updated with the right dates, and filed again. This is not business continuity. This is compliance theater.
Why Most BCPs Fail When They Are Actually Needed
The plans that fail tend to share a few characteristics: they were written by one person without input from the people who will actually have to execute them; they assume resources — people, systems, suppliers — that may not be available during the incident; and they have never been tested in conditions that remotely resemble a real disruption.
A desktop exercise where everyone sits in a conference room and talks through a scenario is better than nothing. It is not the same as pulling the plug on a system and seeing if your recovery procedure works. Organizations that find this out during an actual incident often discover their documented recovery time is three times longer than the plan says, because the plan was written by someone who had never actually done the recovery.
What ISO 22301 Actually Requires
ISO 22301 is the international standard for Business Continuity Management Systems. Like other ISO management standards, it tells you what outcomes to achieve but largely leaves the how up to you. The core analytical requirement is the Business Impact Analysis (BIA): a structured process for identifying which activities are critical, how long you can survive without them (Maximum Tolerable Period of Disruption), and what resources they depend on.
- Business Impact Analysis — identify critical activities, time tolerances, and resource dependencies
- Risk assessment — what threats could cause disruption, how likely, how severe
- Business continuity strategies — how will you maintain or recover critical activities under different scenarios
- Business continuity plans — documented procedures, roles, and contact trees for responding to disruptions
- Exercise program — test your plans; document results; update based on what you find
- Management system requirements — leadership commitment, internal audits, continual improvement
The BIA is where most implementations go wrong. Teams either do it too broadly (trying to document every process in the organization) or too shallowly (asking department heads what they think is critical rather than analyzing actual financial and operational impacts). Start with the activities that, if disrupted for 24 hours, would cause direct customer impact or regulatory breach. Everything else can wait.
The Things Worth Doing That Most Plans Skip
Call trees that are actually maintained. This sounds basic, but you would be astonished how many organizations have a contact list in their BCP that is two reorganizations out of date. If the people on that list are no longer in those roles, the plan starts failing before anyone has done anything wrong.
Supplier dependencies mapped honestly. A significant proportion of business disruptions in recent years have started with a third party — a cloud provider outage, a key software vendor going down, a logistics partner failing. Your BCP needs to account for the fact that your critical activities probably depend on suppliers who have no obligation to prioritize your recovery.
A real exercise schedule, not a theoretical one. Run a tabletop exercise once a year. Run a partial failover test once a year. These are not fun. They are often embarrassing — they reveal gaps, outdated procedures, and assumptions that do not hold. That embarrassment during a controlled exercise is precisely the point. The alternative is finding out during an actual incident.
Finally: leadership has to own this. Not the IT team, not the risk manager, not the person who wrote the document. The CEO and executive team need to understand the organization's recovery time objectives and have personally committed to the resources needed to meet them. A BCP without executive ownership is a document. A BCP with executive ownership is a capability.