Last week we discussed how the Google Cloud outage and PHP2Shell vulnerabilities provided a practical warning: business continuity plans need to become more operational, more technology-aware and more closely connected to digital and data sovereignty.
The response should not be to eliminate every third-party dependency. That would be unrealistic and commercially inefficient. The objective is to understand which dependencies matter most, reduce unnecessary concentration and ensure that critical services can continue when a provider, region, platform or software component fails.
With that in mind, we have detailed 10-steps you can take to ensure your organisation is prepared for the next major global incident.
1. Map critical dependencies
Start with the services that are most critical to your organisation functioning. The aim is to identify the complete chain behind each business capability. For each critical business capability, document:
• The application and its supporting infrastructure.
• Cloud regions, zones and managed services.
• Identity and access-management dependencies.
• Databases, storage and backup locations.
• DNS, networking and content-delivery providers.
• Open-source runtimes and frameworks.
• Third-party APIs and integrations.
• External support and operational suppliers.
• The people and credentials required to recover the service.
A service should not be considered resilient simply because its primary application is backed up. Its identity systems, data stores, deployment tools, monitoring platforms and operational documentation must also be available or recoverable.
2. Classify workloads by consequence
Not every workload requires the same level of protection. You should look to classify services according to the consequences of disruption, considering:
• Revenue impact.
• Customer and public impact.
• Legal and regulatory obligations.
• Safety implications.
• Data sensitivity.
• Recovery time requirements.
• Tolerance for manual workarounds.
• Dependence on a particular supplier or jurisdiction.
This creates a more practical basis for investment. For example, a public marketing site may require a different recovery design from a payment system, legal case-management platform or healthcare application. The highest-priority workloads will require stronger controls around portability, geographic diversity, encryption and operational access.
3. Define the minimum viable service
For every one of your critical business functions, define what must continue during a disruption. This should include:
• The essential customer or stakeholder service.
• The minimum data required.
• The people needed to operate it.
• The systems that must remain available.
• The processes that can be performed manually.
• The activities that can be suspended.
• The decisions that require executive approval.
• The communication channels to use if normal tools fail.
The result should be a practical minimum viable operating model. For example, a law firm may not need every platform to remain operational during a major outage. It may, however, need secure access to active matter files, client contact details, calendars, billing records and court deadlines.
4. Build software and vulnerability visibility
The PHP2Shell incident reinforced the need for organisations to know where vulnerable software is installed, including where it exists within third-party applications or components. You should maintain:
• A current asset inventory.
• A software bill of materials for critical applications.
• Version and configuration data.
• Internet-facing asset visibility.
• Emergency patching procedures.
• Compensating controls where immediate patching is not possible.
• Post-patch validation and monitoring.
• Clear ownership for each critical component.
The inventory must cover technology managed by internal teams, suppliers and third-party application providers.
5. Design for cloud failure
Cloud resilience should be designed around actual failure scenarios. Your organisation should determine:
• What happens if a cloud zone becomes unavailable?
• What happens if an entire region is affected?
• Which services can fail over automatically?
• Which services require manual intervention?
• Can administrators still authenticate?
• Can DNS be redirected?
• Can data be restored elsewhere?
• Can the workload run on another provider?
• How long would recovery actually take?
• What skills and credentials are required?
A second region is not automatically a recovery environment. It must contain the necessary data, configuration, permissions, deployment processes and operational knowledge.
Similarly, a multi-cloud strategy is not automatically resilient. If your organisation cannot move workloads, access its data or operate the alternative environment under pressure, it may have diversity without practical resilience.
6. Improve portability and reversibility
Digital sovereignty should be translated into specific technical and contractual capabilities. Your organisation should consider:
• Open data formats.
• Documented application architectures.
• Infrastructure-as-code.
• Portable containers where appropriate.
• Exportable databases and configurations.
• Customer-controlled encryption keys.
• Independent backups.
• Clear exit and migration provisions.
• Defined recovery responsibilities between suppliers.
• Regular testing of data export and restoration.
The goal is not to avoid cloud services. The goal is to avoid being unable to act when a cloud service becomes unavailable or unsuitable. A workload is more sovereign when the organisation can understand it, access it, move it, secure it and recover it without relying entirely on the original provider.
7. Establish independent operational access
One of the most overlooked continuity risks is dependence on the same platform that has failed. You should look to ensure that you can access essential operational capabilities through independent channels, including:
• Break-glass administrative accounts.
• Offline or separately hosted contact directories.
• Independent monitoring.
• Secondary communications.
• Copies of recovery documentation.
• Secure access to credentials and keys.
• Alternative remote-access arrangements.
• Supplier escalation contacts outside the affected platform.
Recovery documentation stored only in the unavailable collaboration system is not useful during an outage. Neither is a recovery process that depends on an identity provider that cannot be reached.
8. Test decisions, not just technology
Testing should include the difficult decisions that occur during real incidents. For example:
• When should a vulnerable system be taken offline?
• Who accepts the business impact of doing so?
• Can customers be moved to a degraded service?
• Which data must be prioritised?
• When should the organisation invoke an alternative provider?
• What information should be shared publicly?
• How will the organisation operate if senior decision-makers are unavailable?
Technical testing should be combined with executive exercises, supplier participation and communications testing. The purpose is to expose ambiguity before a real incident creates pressure.
9. Review contracts and supplier concentration
Technical resilience also cannot compensate for weak supplier arrangements. As a minimum your supplier contracts should address:
• Service availability and incident notification.
• Data access and export.
• Assistance during migration.
• Recovery responsibilities.
• Subcontractor dependencies.
• Data location and jurisdiction.
• Encryption and key management.
• Audit and assurance rights.
• Termination and exit support.
• Retention and deletion obligations.
You should also constantly be reviewing how many critical services depend on the same provider, region or technology ecosystem. Quantiva recommends this is conducted once per quarter. A supplier may perform well individually while still creating unacceptable concentration risk across the wider organisation.
10. Make continuity continuous
Business continuity plans should be updated when the technology environment changes. Far too often it is left as an after thought. A review should be triggered by:
• A new cloud platform.
• A new SaaS application.
• A new AI model or agent.
• A change of identity provider.
• A major software release.
• A new third-party integration.
• A change in data residency.
• A new regulatory requirement.
• A material supplier change.
• A change in the organisation’s critical services.
Continuity should be part of architecture reviews, procurement, security governance and board-level risk management.
A practical 90-day agenda
To help you on this journey, we have detailed an immediate starting point, structured around the next 90 days:
Days 1–30: Establish visibility
• Identify the organisation’s most critical services.
• Map their technology and supplier dependencies.
• Identify internet-facing assets and vulnerable software.
• Confirm data locations, recovery points and administrative access.
• Define the minimum viable service for each critical function.
Days 31–60: Reduce exposure
• Prioritise critical patches and remediation.
• Remove unnecessary single points of failure.
• Confirm independent backups and administrative access.
• Review supplier contracts and exit provisions.
• Document manual workarounds and emergency decision rights.
Days 61–90: Test and improve
• Run a cloud-region outage exercise.
• Run a critical-vulnerability response exercise.
• Test data export and restoration.
• Test communications outside normal collaboration tools.
• Update recovery objectives based on observed performance.
• Report material gaps to executive leadership or the board.
The objective is control
The aim of a relevant and up to date business continuity plan is not to guarantee that nothing will fail, this is an inevitability. The objective is to ensure that any digital failure does not remove the organisation’s ability to operate. To achieve this it requires visibility, alternatives, tested processes and control over critical data and technology. This is especially true where your organisation relies on cloud infrastructure, concentrated vendors and complex supply chains.
The real practical test is simple:
If a critical supplier, region or technology component became unavailable tomorrow, could you prove to your organisation that it could continue its most important activities safely?
If the answer is uncertain, the continuity plan needs rethinking.