Most organisations have a business continuity plan. Far fewer have properly considered what happens in the first few minutes when that plan actually needs to be activated.
Business continuity planning has become increasingly sophisticated. Organisations identify their critical activities, assess dependencies, establish recovery priorities, document response procedures and regularly review their plans. In regulated industries, expectations around resilience have also moved beyond simply having documented recovery arrangements towards demonstrating that important services can continue through serious disruption.
Yet there is a deceptively simple question that can expose a weakness in even a mature continuity programme:
How would you activate your business continuity plan if the organisation was already experiencing a significant disruption?
It sounds straightforward. In practice, the answer can be surprisingly complicated.
The plan may be stored in a corporate document management system. The people responsible for activating it may normally communicate through Microsoft Teams. Contact information may sit within corporate systems. Access may depend on the organisation's identity provider. The crisis team may expect to meet using the same collaboration environment used every day.
None of these arrangements are inherently wrong. They become a problem when the incident itself affects the environment on which the response depends.
This creates what could be described as the activation gap: the difference between an organisation having a documented plan and having the practical capability to put that plan into operation when conditions are difficult.
There is an important distinction between the two.
A business continuity plan describes what the organisation intends to do. It identifies responsibilities, procedures, priorities and actions. It gives people a framework for responding to disruption.
Activation is different. It is the process of turning that framework into a functioning response.
Someone needs to recognise that the plan should be invoked. Someone needs the authority to make that decision. The right people need to be contacted. Those people need to know what is happening and where they should coordinate. Critical information needs to be accessible. Decisions need to be made and recorded. Instructions may need to be communicated to hundreds or thousands of people outside the immediate response team.
Every one of those activities depends on something.
The strength of the overall capability is therefore determined not simply by how good the written plan is, but by whether those dependencies continue to work under the conditions in which the plan is required.
That is why a plan can be perfectly accurate and still fail operationally.
The document itself hasn't failed. The organisation's ability to activate it has.
Most continuity plans are written in a relatively stable environment.
People have their normal devices. They can access corporate systems. They know their colleagues. Email works. Collaboration platforms work. Authentication works. Information is available.
It is natural for those assumptions to find their way into the continuity process.
The problem is that many of the events that trigger a continuity response are precisely the events that can invalidate those assumptions.
A cyber incident could affect corporate identity and access. A technology outage could make collaboration systems unavailable. A supplier failure could remove access to a critical service. A telecommunications problem could affect normal communications. A physical incident could force people away from their normal workplace and devices.
The more serious the disruption, the less sensible it becomes to assume that the normal operating environment will remain intact.
This doesn't mean every continuity plan needs to abandon the technology used for everyday business. It means organisations need to understand which parts of the response are dependent upon that technology and what happens when those dependencies are unavailable.
That is a very different exercise from simply reviewing whether the latest version of the plan has been uploaded.
Consider the process rather than the document. An incident occurs. Someone decides that the situation has crossed the threshold for formal crisis management. The relevant authority needs to activate the response.
The first requirement is communication. The crisis team needs to know that it has been activated and what is expected of its members. Senior decision-makers need to be brought together. Specialist teams may need to be engaged. People who are not directly involved in the response may need to receive instructions.
The next requirement is coordination. The response team needs somewhere to work. It needs access to the information required to understand the situation and make decisions. It needs to establish priorities and assign actions. It needs a reliable way to communicate as the situation develops.
Then comes the wider response. Employees may need instructions. Customers may need updates. Suppliers may need to be contacted. Regulators may need to be informed. People may need to acknowledge messages or provide information back to the response team.
None of this is particularly unusual. What is often overlooked is that communication connects almost every stage of the process.
If communication fails at the point of activation, the problem doesn't remain a communications problem. It can quickly become a crisis management problem, a decision-making problem and ultimately a business continuity problem.
This is why communications should be considered as part of the continuity capability itself rather than simply as one of the outputs of the plan.
Business continuity teams have traditionally spent considerable effort thinking about alternative facilities, technology recovery, staffing, suppliers and critical processes.
Communications can sometimes be treated differently: something that will happen once the response has been activated.
But communication is required to activate the response in the first place.
It is also required to keep the response functioning.
And it is required to communicate the outcome of decisions to everyone affected by the disruption.
For organisations operating in regulated environments, this is increasingly reflected in operational resilience expectations. The FCA's operational resilience framework, for example, requires firms to maintain internal and external communication strategies that enable them to respond quickly and effectively during operational disruption. It also expects firms to consider how they would communicate where usual channels are unavailable.
That last point is particularly important.
It changes the question from: "Do we have a communications plan?"
to something much more practical: "Can we communicate if the systems we normally use to communicate are unavailable?"
The answer may be yes. But organisations should be able to demonstrate that rather than simply assume it.
One of the most useful exercises a business continuity team can conduct is also one of the simplest.
Don't start by asking people to read the continuity plan. Instead, remove some of the assumptions that make activation easy. Imagine that a significant incident has occurred and the organisation has temporarily lost access to its normal corporate collaboration environment.
Now try to activate the response...and ask yourself these questions
The exercise doesn't need to be elaborate.
In fact, a short activation test can be more revealing than a large annual simulation because it isolates the mechanics of getting the response started.
A useful test might look like this:
| Test | Question |
|---|---|
| Activation | Can the authorised person initiate the continuity response? |
| Contact | Can the crisis team be reached without relying on normal corporate communications? |
| Coordination | Can decision-makers establish a functioning crisis environment? |
| Information | Can critical plans and response information be accessed? |
| Verification | Can participants establish that communications are trusted? |
| Wider communication | Can instructions reach employees and other stakeholders? |
| Continuity | Can the response continue if normal systems remain unavailable? |
The objective isn't to prove that everything works. The objective is to discover what doesn't. That is where the value lies.
This also changes the way organisations should think about business continuity exercises. A conventional exercise might ask whether people understand their roles or whether the documented procedures are accurate.
Those questions remain important. But they should be supplemented with questions about the environment in which those procedures have to operate.
If the continuity plan says that the crisis team will meet virtually, test the virtual meeting arrangement.
If it says that employees will be notified, test the notification process.
If it depends on a particular system for contact information, test what happens if that system cannot be accessed.
If critical documents are stored online, test access from outside the normal corporate environment.
If activation depends on a particular individual, test what happens if that individual is unavailable.
In other words, test the chain of activation, rather than simply testing the plan as a document. This is particularly important because resilience is not created by removing every possible dependency. That is neither realistic nor desirable.
It is created by understanding dependencies and ensuring that the organisation has credible alternatives when those dependencies fail.
This is the role an out-of-band communications capability can play. The purpose isn't to replace the organisation's normal collaboration tools. Email, Teams and other business platforms remain essential to everyday operations.
The purpose is to provide a separate communications layer for circumstances where those normal systems cannot be relied upon. That separation matters.
If the incident affects corporate identity, the organisation shouldn't have to depend entirely on that identity infrastructure to coordinate its response.
If the normal collaboration environment is unavailable, the crisis team needs another place to communicate.
If employees need urgent instructions, there needs to be a reliable route for delivering those messages.
If critical response information needs to be accessed, it needs to be available independently of the systems affected by the incident.
For organisations considering this approach, the important question isn't simply whether a platform offers messaging or video conferencing.
It is whether the platform can actually function as part of the organisation's continuity architecture.
That means considering independence, access, identity, information availability, communications, notification, auditability and the ability to operate during degraded conditions.
YUDU Sentinel is designed around this principle: providing an independent environment for crisis communications and coordination rather than making the crisis response dependent on the same systems used for normal business operations.
Sentinel Spaces can provide dedicated environments for response teams, while secure video conferencing, messaging, mass notification and access to critical information can support different stages of the response. The aim is not to create another everyday collaboration platform. It is to provide a communications capability that can remain available when the normal operating environment cannot be relied upon.
A mature business continuity programme should be able to answer two different questions.
The first is: "Do we know what we would do?"
The second is: "Can we actually do it?"
The first question is answered by the plan. The second is answered through capability, preparation and testing.
That distinction becomes particularly important as organisations become more dependent on cloud platforms, identity providers, interconnected suppliers and digital collaboration environments. The very technology that makes everyday business efficient can also introduce dependencies into the response process.
The answer isn't to remove technology from business continuity planning. It is to stop treating technology availability as an assumption.
Understand what the response depends upon. Identify what would happen if those dependencies disappeared. Establish alternatives where they are needed. Test them under realistic conditions.
Most importantly, don't just test whether people know where the business continuity plan is.
Test whether they can activate it.
Because the moment a serious disruption occurs is not the time to discover that your continuity plan depends on the very environment that has just failed.
A business continuity plan documents how an organisation intends to respond to disruption. A business continuity capability is broader, incorporating the people, processes, technology, information and communications required to execute that plan in practice.
A plan has little practical value if an organisation cannot bring the right people together, access critical information, communicate decisions and begin the required response. Testing activation exposes weaknesses that may not be apparent from reviewing the written plan.
Normal communication systems will often form part of everyday business continuity arrangements. However, organisations should understand what happens if those systems become unavailable or compromised and establish appropriate alternatives for severe disruption scenarios.
An activation test should consider whether the authorised person can initiate the response, whether key personnel can be contacted, whether a crisis team can coordinate, whether critical information can be accessed and whether instructions can be communicated if normal corporate systems are unavailable.
Out-of-band communication provides an alternative communications route that is separate from an organisation's normal communications infrastructure. It can help organisations maintain communication and coordination during incidents affecting primary systems or networks.
Business continuity planning is ultimately about more than documentation.
The quality of the plan matters, but so does the environment in which that plan has to operate.
An organisation that can identify its critical services, understand its dependencies, bring the right people together, access the information it needs and maintain trusted communications during disruption is in a much stronger position than one that simply has a well-written document.
The activation gap sits between those two states.
Closing it doesn't necessarily require a complete redesign of your continuity programme. It starts with asking a more demanding question about the plans you already have:
If we needed to activate this plan tomorrow, under the worst realistic conditions, could we actually do it?
If the answer isn't an immediate yes, that isn't necessarily a failure.
It is an opportunity to test, strengthen and improve the capability before the real incident arrives.
Because a business continuity plan only becomes valuable when someone can activate it.