This week demonstrated that business continuity is no longer just about recovering from a power cut, restoring a backup or switching to a secondary data centre. It is about maintaining control when a critical technology dependency becomes unavailable, vulnerable or inaccessible, often with little warning.
On 20th October, a power event affected Google Cloud’s London region, disrupting multiple services and impacting many organisations. At nearly the same time, two critical PHP vulnerabilities known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619) created the risk of unauthorised remote code execution on affected systems. All affected organisations should know now to identify vulnerable installations and apply patches immediately, particularly on internet-facing systems.
These were different incidents, but they exposed the same weakness:
Organisations are often more dependent on their technology ecosystem than their continuity plans acknowledge and the old model is really no longer enough.
Traditional business continuity planning typically asks:
• How quickly can we restore systems?
• Where are our backups?
• Do we have a disaster-recovery environment?
• Who is responsible for activating the plan?
• How long can the business operate without a particular application?
Those questions remain important but they do not fully address the risks created by interconnected cloud platforms, managed services, software supply chains, APIs and third-party infrastructure.
A business may have resilient servers and regular backups, yet still be exposed to:
• A single cloud region.
• A critical identity provider.
• A particular DNS or content-delivery provider.
• A managed database service.
• An unpatched open-source component.
• A supplier’s proprietary recovery process.
• Data stored in a format that is difficult to export.
• A management console that becomes unavailable during the incident.
The real issue is not simply whether you can recover, it is whether you can continue operating safely while recovery is still taking place.
Dependency is the hidden risk
Most organisations understand who their major technology suppliers are. Far fewer understand the complete operational dependency chain behind their critical services.
A customer-facing application may depend on a cloud region, identity platform, database, software runtime, security tool, DNS provider and external support team. If any one of those dependencies fails, the application may become unavailable, even if the infrastructure remains healthy.
Supplier concentration should also be treated like financial or customer concentration. If one provider controls a critical capability, that relationship is a business-continuity dependency.
Previously we would have asked:
“Is this provider reliable? Does it have X number of Nines?”
The question now is:
“What credible options do we have if this provider, region, platform or component becomes unavailable?”
Resilience is broader than recovery
The Google Cloud outage showed that any and all cloud adoption does not automatically create resilience. A workload can be hosted by a highly capable provider while still depending on a single region, zone or service. Equally, the PHP incident showed that resilience also depends on the ability to identify, patch, isolate or temporarily remove vulnerable technology at speed whilst keeping your organisation functioning.
In both cases, you need far more than a disaster-recovery document. As a minimum, you need:
• Accurate visibility of dependencies.
• Clear decision-making authority (and delegation).
• Tested alternatives.
• Access to data and systems.
• The ability to communicate during disruption (this one is often severely under considered).
• A minimum viable operating model for your organisation.
How This Plays Into Digital And Data Sovereignty
Digital sovereignty is often framed as a question of where data is stored and which jurisdiction governs it. This is too overly-simplistic, especially for organisations handling sensitive legal, financial, personal or public-sector information. But sovereignty is broader than data residency.
It also concerns whether your organisation controls:
• Its data and encryption keys.
• Its technology and vendor choices.
• Its operational processes and IP.
• Its ability to move workloads fast.
• Its access to systems during a supplier disruption.
• Its ability to continue operating without external permission.
• Its ability to change providers without unacceptable cost or delay.
The European Commission’s cloud sovereignty framework explicitly connects sovereignty with continuity of operations, skills availability and resilience against external dependencies. Although, ofter the EU is overburdensome, in this case it is spot on.
This is why digital and data sovereignty should be treated as a business-continuity issue. The more control an organisation retains over its data, technology and operating model, the more options it has when something catastrophic happens.
The Minimum Viable Organisation (MVO)
Every organisation should define the smallest set of people, systems, data and processes required to continue delivering essential services during a serious disruption.
For a bank, that may mean maintaining payments and customer access. For a law firm, it may mean accessing matter files, communicating with clients and meeting court deadlines. For a managed-service provider, it may mean keeping identity, monitoring and support channels operational.
Once this minimum viable operating model is defined for your organisation, you can work backwards:
• Which systems are essential?
• Which data must be immediately available?
• Which suppliers are critical?
• What can be performed manually?
• What can be paused?
• Who has authority to make decisions?
• How will customers and stakeholders be informed?
This approach is more effective than trying to make every system equally resilient. It directs investment towards the capabilities whose failure would cause the greatest harm.
Continuity Is Now A Strategic Capability
As we have discussed, these incidents were not isolated technology problems, they were reminders that organisations can be disrupted by failures far beyond their own buildings, networks and servers.
Business continuity must therefore modernise and be looked at on a first principles basis. We now need to address how we can run as an MVO as these incidents are likely to become more common place.
Those best prepared for the next disruption will not necessarily be those with the largest technology budgets. They will be those that understand their dependencies, retain credible alternatives and regularly test that those alternatives work.
Continuity is no longer just about returning to normal after a crisis. It is now about retaining enough control to keep operating while the crisis is still unfolding.