Business continuity starts with portability

Business continuity planning has a quiet assumption built into most of it: that the infrastructure the plan runs on will cooperate. Backup systems will be accessible. Recovery procedures will work as documented. The provider whose services underpin the critical path will be available, or at least recoverable within the window the plan specifies.

That assumption is tested every time a major provider has an outage, a regional failure, or a service disruption that cascades across dependent workloads. And when it fails, it tends to fail in a specific way. Not because the plan was wrong, but because the architecture couldn't execute it.

The gap between having a plan and having one that works

Key takeaway: Most organizations have documented continuity strategies and are confident in them. The data on actual recovery outcomes tells a different story.

According to the Veeam Data Trust and Resilience Report 2026, based on insights from more than 900 senior IT, security, and risk leaders worldwide, 90% of organizations express confidence in their ability to recover from a cyber incident within their recovery time objectives. Only 69% say those RTOs are fully aligned with business continuity goals. 

That gap, between confidence in the plan and alignment between the plan and what the business actually needs, is where most continuity failures live.

The financial stakes of that gap are not abstract. A Cisco study estimates the average cost of IT downtime at $15,000 per minute for enterprise organizations. An outage lasting one hour costs over half a million dollars before reputational impact, customer SLA penalties, or regulatory consequences are factored in. 

According to Uptime Institute's Annual Outage Analysis 2026, 57% of respondents report their most recent major outage cost more than $100,000, with one in five exceeding $1 million. For most organizations, outage cost isn't a theoretical risk. It's a recurring line item.

Why architecture is the continuity variable most plans underestimate

Key takeaway: Recovery time objectives fail not because of bad planning but because the underlying architecture can't execute the plan. Portability is the architectural property that makes continuity commitments credible.

When an outage hits a single cloud provider, the organizations that recover fastest share one characteristic: their workloads weren't entirely dependent on that provider to function. They had the architectural flexibility to route around the failure, spin up in an alternative environment, or execute a failover that wasn't contingent on the failing system coming back online.

The organizations that struggle share a different characteristic: their recovery plan required the provider to participate in its own recovery. Restoring from backups stored in the same provider's infrastructure. Rebuilding environments using that provider's provisioning tools. Waiting for the provider's incident to resolve before the recovery process could even begin.

This is the portability gap in practice, and it's widespread. According to the Flexera 2026 State of the Cloud Report, 78% of organizations cite workload portability as a top-three cloud priority. Only 22% have achieved a genuinely provider-agnostic architecture. The gap between aspiration and reality is where most RTO failures originate. Organizations know portability matters. Most haven't built it.

Read the guide to standardizing app delivery across AWS, Azure, and GCP.

When continuity becomes a compliance obligation

Key takeaway: For financial entities and critical infrastructure operators in the EU, provider portability is no longer a best practice. The Digital Operational Resilience Act makes concentration risk a legal obligation to manage and demonstrate.

The business case for portability has always been clear. The regulatory case is now becoming explicit.

The EU's Digital Operational Resilience Act (DORA) mandates that financial entities actively manage concentration risk around critical third-party providers, including cloud hyperscalers. Organizations subject to DORA cannot simply rely on a single provider's SLAs as their continuity posture. They are required to demonstrate that they have assessed the risk of provider concentration, understand the implications of a provider failure on their operations, and have taken steps to manage that dependency.

DORA currently applies to financial entities operating in the EU, but it represents a regulatory direction that is spreading. The UK's Financial Conduct Authority has published similar operational resilience requirements. The NIS2 Directive extends resilience obligations to a broader set of critical infrastructure operators across the EU. The pattern is consistent: regulators are treating cloud provider concentration as a systemic risk, and the organizations subject to these frameworks can no longer treat portability as an optional architectural preference.

For ITMMs in regulated industries, this reframes the portability conversation entirely. It is not a question of whether a more portable architecture would be operationally beneficial. It is a question of whether the current architecture meets a compliance obligation, and what the exposure is if it doesn't.

What portability actually looks like in practice

Key takeaway: Portability isn't about running identical workloads on every provider simultaneously. It's about ensuring the delivery layer is decoupled from any single provider's infrastructure, so continuity doesn't depend on one vendor's uptime or cooperation.

The common misread of portability is that it requires running everything everywhere all the time. That's expensive, complex, and unnecessary for most workloads. What continuity actually requires is more targeted: the ability to move critical workloads when the decision is made, without the migration being blocked by architectural dependencies on a single provider's proprietary services.

That distinction matters because it changes where the investment goes. Portability at the delivery layer (how environments are defined, how applications connect to dependencies, how pipelines are structured) is achievable without rewriting applications or abandoning provider-specific services where they offer genuine advantage. It means making deliberate choices about which services create recoverable dependencies and which create exits that cost more than the service is worth.

In practice, the organizations that execute continuity plans successfully tend to have made three decisions early: infrastructure defined in code rather than assembled manually in provider consoles; environment provisioning decoupled from provider-specific tooling; and deployment pipelines built on open standards rather than proprietary abstractions. None of these prevent the use of provider-specific services where they add value. All of them preserve the ability to move when staying becomes untenable.

The business continuity plan that works is the one that doesn't require the failing system to recover itself. Building that capability is an architectural decision, made at the delivery layer, long before the incident that tests it.

Read the migration playbook for escaping lock-in without disruption.

Frequently asked questions (FAQ)

How is portability different from having a multicloud strategy? 

A multicloud strategy means running workloads across more than one provider. Portability means those workloads can actually move between providers when needed. Many organizations have multicloud deployments where individual workloads are still deeply embedded in a single provider's proprietary services. That's multicloud billing without multicloud resilience. Portability requires architectural decisions at the workload level, not just provider diversification at the portfolio level.

Does DORA apply to organizations outside the EU financial sector? 

Directly, no. DORA applies specifically to financial entities operating in the EU, including banks, insurers, investment firms, and their critical third-party service providers. However, its framework for thinking about concentration risk (identifying critical dependencies, assessing the impact of provider failure, demonstrating managed resilience) is increasingly being adopted by regulators in other sectors and jurisdictions. ITMMs outside the EU financial sector should treat DORA as a leading indicator of where regulatory expectations are heading rather than as a current obligation.

What's the difference between RTO and actual recovery capability? 

Recovery Time Objective is the maximum acceptable time to restore a system after a failure, a target set during continuity planning. Actual recovery capability is what happens during a real incident with real architectural constraints. The confidence-to-alignment gap in the Veeam 2026 report reflects exactly this: organizations believe they can recover within their RTOs, but a significant proportion acknowledge those RTOs don't fully reflect what the business actually needs. The most common causes are dependencies on the failing provider's infrastructure for recovery, undocumented configuration changes that make documented recovery procedures inaccurate, and manual steps that take longer under incident pressure than they did in testing.

How do we test continuity without disrupting production? 

The standard approach is tabletop exercises, structured walkthroughs of incident scenarios that test whether the plan's assumptions hold without executing the actual recovery. Beyond tabletops, the most valuable test is a controlled failover exercise in a non-production environment that mirrors production architecture closely enough to surface real constraints. Organizations with infrastructure defined in code and ephemeral environment provisioning can run these exercises significantly more easily than those with manually configured environments, because the test environment is reproducible by definition.

At what point should portability become a board-level conversation? 

When infrastructure dependency creates material financial or regulatory exposure that the board isn't currently accounting for. For most enterprises, that means quantifying two numbers: the cost of an outage lasting the expected provider recovery time for a major incident, and the estimated cost of migrating away from the current primary provider if the relationship became untenable. If either number is significant relative to the organization's risk tolerance, the conversation is overdue.