There is an assumption embedded in the resilience strategies of most organisations that almost nobody states explicitly, because it is so widely held it has ceased to feel like an assumption at all. That assumption is this: the cloud will be there when you need it.
It is worth sitting with that for a moment. Not the question of whether a specific service might experience an outage, or whether a configuration error might cause an incident. Those risks are well understood and regularly rehearsed. The deeper question is whether the infrastructure your organisation has come to depend upon for its operational continuity is truly within your control, and whether the threat landscape has shifted to a point where that dependency requires urgent reassessment. The answer, increasingly, is yes.
When Infrastructure Becomes a Target
For years, those of us who counselled caution about wholesale migration to cloud infrastructure were characterised as resistant to change, wedded to legacy thinking, or simply failing to grasp the economic and operational benefits on offer. The resistance, in most cases, was nothing of the sort. It was the application of basic risk assessment: identifying a genuine need, weighing the benefits against the real negatives, and asking questions that the migration roadmap had not accounted for.
One of those questions was physical. The consolidation of vast quantities of critical data and operational infrastructure into a relatively small number of hyperscale datacentre facilities creates, from a certain angle, high-value targets. A practitioner thinking about physical attack rather than purely cyber threat could see that concentration as a vulnerability in its own right. The cloud providers could invest enormously in cyber defence; they could not make a building invisible.
This was, at the time, treated as an extreme and rather theoretical concern. It is no longer theoretical. The kinetic targeting of cloud datacentre infrastructure in conflict zones has demonstrated that physical attack on digital infrastructure is not only conceivable but has occurred. Unlike cyber threats, where providers have significant capability and resource to respond, a kinetic strike is not a domain in which technology companies hold any particular advantage.
"The cloud providers could invest enormously in cyber defence. They could not make a building invisible."
The Political Dimension Nobody Is Mapping
The major cloud providers are, first and foremost, corporations subject to the laws and political pressures of the jurisdictions in which they operate. That was always true. What has changed is the willingness of state actors to exert that pressure in ways that would once have seemed unthinkable in the western democratic context.
We have seen technology companies face sustained governmental pressure for decisions that were, by any reasonable measure, in the public interest. We have seen regulatory and legislative mechanisms used as instruments of economic coercion. The question that business continuity professionals need to be asking is not whether a major cloud provider might be subject to state pressure to restrict, degrade, or disrupt services to organisations in a particular country or sector. The question is whether their organisation has mapped that as a risk and planned accordingly.
Most have not. The risk register may note dependency on third-party providers. It is unlikely to contain a scenario in which that provider is instructed, by a government with leverage over it, to withdraw or degrade services as part of an economic or political pressure campaign. Yet that scenario, in the current environment, is not paranoid. It is a logical extension of tools that are already being deployed.
"The risk register may note dependency on third-party providers. It is unlikely to contain a scenario in which that provider acts under state direction."
The Sovereignty Problem: Your Data, Their Terms
There is a way of expressing the core problem of cloud dependency that tends to cut through: when you lose the connection, your data is no longer yours.
On-premises infrastructure, for all its costs and limitations, has an important property: in almost any recovery scenario short of complete physical destruction, you retain access to your data. You own the hardware. You control the connection path to it. The recovery may be complex, but the data is yours to recover.
Cloud infrastructure inverts this. Your data may be perfectly intact, replicated across multiple availability zones, subject to rigorous backup processes. But if the service is unavailable — whether through technical failure, deliberate restriction, or the withdrawal of access — you cannot reach it. A backup strategy that lives entirely within the same provider ecosystem as the primary system does not constitute resilience. It constitutes redundancy within a single point of failure.
Any organisation with material cloud dependency should maintain at minimum a current backup of critical data to on-premises storage, with a defined and tested fallback mechanism for accessing that data independently of the cloud environment. Even a direct database access route, available to ICT professionals under controlled conditions, is preferable to no route at all.
The Forced Change Problem: Provider Decisions, Your Risk
There is a further dimension of cloud dependency that receives less attention than outage risk but is, in practice, encountered far more frequently. Providers make decisions. Those decisions affect your systems. You had no part in making them.
The deprecation of TLS 1.0 and 1.1 by AWS is a useful illustration. The decision was, on security grounds, entirely defensible. The effect on organisations running software built on older framework versions was, in some cases, immediate and severe. Software developed using older versions of the .NET framework defaulted to TLS 1.0 or 1.1 as a matter of convention: when the provider restricted support, that software was broken at a stroke. For organisations running third-party legacy applications with no available update path, there was no straightforward remedy.
"The provider made a decision. The customer carried the operational risk."
This is not an argument against security improvements. It is an argument that business continuity planning in cloud environments must account for the risk of provider-driven change imposed on a timeline and at a pace not of the organisation's choosing.
A Balanced Assessment, Not a Rejection
None of this is a case against cloud infrastructure. The pandemic demonstrated, comprehensively, the value of distributed, cloud-accessible systems for maintaining operational continuity when physical access to workplaces is lost. Productivity was maintained at scale, and rapidly, because organisations had cloud infrastructure in place. That is a genuine resilience benefit.
The problem is not the cloud. The problem is the unexamined assumption that cloud adoption is itself a resilience strategy, rather than an operational choice with its own resilience implications that need to be mapped, planned for, and tested. The industry absorbed the benefits of cloud migration and, in many cases, stopped asking the critical questions. The people who kept asking them were characterised as resistant to change. In retrospect, they were performing proper risk assessment.
The Question Every Organisation Should Be Able to Answer
Every organisation with material cloud dependency should be able to answer the following question clearly: what is our resilience posture if our primary cloud provider is unavailable for 72 hours, not due to a technical fault on their part, but due to a decision made in a boardroom or a government building that we have no relationship with and no influence over?
If the honest answer is that the organisation would be unable to function, the business continuity programme has a gap. If the answer is that the backup strategy would cover it, the follow-up question is whether that backup strategy is hosted on the same provider. If it is, the gap remains.
Closing that gap does not require abandoning cloud infrastructure. It requires treating cloud providers as what they are: third-party dependencies with their own risk profiles, political exposures, and operational vulnerabilities, subject to the same rigorous dependency analysis that would be applied to any other critical supplier. The fact that they are large, well-resourced, and widely used does not make them immune to the threats that the current environment is generating.
"Resilience is not a parallel process, activated when something goes wrong. It is a discipline embedded in ordinary decisions — including the decision of where and how you store the data your organisation depends upon."