Geopolitical conflict has become a direct threat to your cloud infrastructure. If you are a CTO or CIO responsible for business continuity, your threat model just changed. The question is no longer whether your systems can survive a technical failure. It is whether they can survive a politically motivated attack on the infrastructure they depend on.
This article covers what the new geopolitical threat landscape means for cloud architecture, how to build business continuity plans that account for state-level adversaries, and what practical steps you can take right now to protect your organization’s data, services, and supply chain.
The threat model has changed
For years, business continuity planning focused on predictable scenarios. Hardware failure. Software bugs. Natural disasters. Data center power outages. The assumption was that threats were accidental or criminal, and the response was technical redundancy.
That assumption no longer holds. In November 2024, two submarine telecommunication cables in the Baltic Sea, the BCS East-West Interlink and the C-Lion1 fibre-optic cable connecting Finland to Germany, were damaged near-simultaneously. On December 25, 2024, the Estlink 2 undersea power cable between Finland and Estonia was cut along with four telecoms lines. The repair took until August 2025, over seven months, at a cost of up to 60 million euros. NATO launched Operation Baltic Sentry in January 2025 specifically to deter further attacks on undersea infrastructure.
These are not theoretical risks. They are infrastructure attacks on NATO member states, affecting real connectivity and real power supply. If your cloud architecture routes through the Baltic region, or if your data center depends on cross-border power interconnections, these events belong in your threat model.
According to the World Economic Forum’s Global Cybersecurity Outlook 2026, 64 percent of organizations now factor geopolitically motivated cyberattacks into their risk planning (WEF, 2026). The other 36 percent are behind.
Most business continuity plans were written for a world where threats were accidental. If yours has not been updated for intentional, state-level disruption, now is a good time.
What geopolitical risk means for your cloud architecture
Geopolitical risk shows up in cloud architecture in ways that most technical teams have not planned for.
The first is physical infrastructure dependency. Your cloud services run in data centers that depend on power grids, fibre-optic cables, and network interconnections. These are physical assets that can be physically attacked. The Baltic cable incidents proved that cross-border connectivity is vulnerable, and recovery times are measured in months, not hours.
In the networking world, BGP routing and other mechanisms provide alternative paths, so not every route is equally at risk. Power availability issues are often more about single-zone vulnerabilities than complete regional loss. The real concern is identifying and limiting single points of failure — whether in connectivity, power supply, or critical interconnections — that could disrupt your operations if targeted.
The second is jurisdictional risk. US hyperscalers control more than 70 percent of the EU cloud market. They are subject to US extraterritorial laws, specifically the CLOUD Act and FISA, which allow US authorities to compel data access regardless of where the servers physically sit. If geopolitical relations between the EU and the US deteriorate, or if a specific conflict creates pressure on data access, your cloud provider may face conflicting legal obligations. Your data sits in the middle.
The third is supply chain concentration. Most organizations depend on a small number of providers for critical cloud services. If sanctions, trade restrictions, or political decisions affect a provider’s ability to serve European customers, the impact cascades through every organization that depends on them. The EU Data Act’s cloud switching regime, effective September 2025, acknowledges this risk by giving customers the right to initiate a provider switch on two months’ notice, with transitions completing within 30 days.
The fourth is third-party exposure. Your own cloud architecture might be resilient, but what about your critical vendors? Their cloud providers? Their network dependencies? NIS2 and DORA both require organizations to extend risk management to critical third-party providers, precisely because a chain is only as strong as its weakest link. If your payroll provider runs on a single cloud region, their outage becomes your operational crisis.
Each of these dimensions requires a different response. Redundancy alone does not solve jurisdictional risk. Multi-cloud alone does not solve physical cable dependency. Business continuity in a geopolitical threat environment requires thinking about all four simultaneously.
Building continuity for a geopolitical threat environment
Traditional disaster recovery focuses on restoring services after a failure. Geopolitical threats require a different posture: you need to maintain operations during prolonged, intentional disruption.
Here is what that looks like in practice.
How do you design for physical infrastructure resilience?
Map your actual dependencies. Not the dependencies your cloud provider’s marketing materials show you, but the real ones. Which submarine cables carry your traffic? Which power interconnections supply your data centers? Which network paths does your data actually travel?
Most organizations cannot answer these questions because they have never asked them. Start by requesting detailed infrastructure dependency information from your cloud providers. Then design your architecture so that no single physical route or interconnection is a single point of failure. This means multi-region, multi-path, and in some cases multi-provider configurations that account for physical geography, not just logical redundancy.
“Map your actual dependencies. Not the dependencies your cloud provider’s marketing materials show you, but the real ones.”
The key shift here is thinking about geography as an engineering constraint, not just a compliance checkbox. When you design for availability zones, you think about logical separation. When you design for geopolitical resilience, you think about which countries your traffic crosses, which seabeds your cables rest on, and which power grids feed your compute. That is a fundamentally different design exercise.
How do you address jurisdictional and sovereignty risk?
Know where your data is, where it can be accessed from, and under which legal jurisdictions. For European organizations, this means evaluating whether your cloud provider can guarantee that EU data stays under EU jurisdiction in all circumstances, including under legal pressure from non-EU governments.
AWS has made its European Sovereign Cloud generally available, with infrastructure and operations structured to meet regional legal requirements. Other providers are following with similar offerings. The critical question is not whether a sovereign option exists, but whether your specific workloads actually use it, and whether your contracts reflect the sovereignty guarantees you need. Do not assume that running workloads in an EU region automatically means EU jurisdiction applies in all scenarios. Read the fine print. Understand the legal architecture behind the infrastructure architecture.
How do you extend continuity planning to third parties?
DORA requires financial entities to maintain oversight of critical ICT third-party providers, including concentration risk analysis and exit strategies. NIS2 extends similar supply chain security requirements across a broader set of sectors. Even if your organization is not directly covered by these regulations, the underlying logic applies: your continuity depends on your suppliers’ continuity.
Identify your critical third-party providers. Map their cloud dependencies. Ask them the same questions you ask yourself: where is the data, what are the single points of failure, what is the recovery plan? If they cannot answer, that is a risk finding. And if your procurement process does not include these questions yet, add them. Technology vendor selection is now a geopolitical decision whether you treat it that way or not.
How do you prepare for scenarios that last weeks or months?
The Estlink 2 repair took seven months. Your continuity plan needs to account for disruptions that last weeks or months, not hours. That means tested migration paths, portable data formats, and the ability to operate at reduced capacity without specific infrastructure components.
What you should do this week
If you are reading this and realizing that your business continuity plan was built for a simpler world, here is where to start.
- First, audit your physical infrastructure dependencies. Trace the actual network paths, power sources, and cable routes that your cloud services rely on. Your cloud provider can help with some of this, but independent analysis may be needed. Focus on finding and mitigating single points of failure, ensuring that no single physical route, interconnection, or zone can take down your critical workloads.
- Second, evaluate your jurisdictional exposure. Where is your data? Under which legal regimes? What happens if extraterritorial data access requests affect your provider?
- Third, assess your third-party chain. Identify your top ten critical vendors. Ask them about their cloud architecture, their resilience testing, and their continuity plans. DORA and NIS2 give you regulatory backing to make these requests.
- Fourth, test your recovery under realistic conditions. Not a tabletop exercise where everyone nods. An actual failover test where you simulate loss of a region, a cable, or a provider. See what breaks.
- Fifth, review your contracts. Do they include sovereignty guarantees? Exit clauses? Data portability commitments? The EU Data Act’s switching provisions give you new negotiating power here, but only if your contracts are structured to use them.
Cloud2’s Health Check provides a structured assessment of your cloud architecture against these geopolitical readiness criteria. We map your dependencies, identify concentration risks, evaluate your sovereignty posture, and test whether your continuity plans hold up against scenarios that include state-level adversaries. Because the threat model has changed, and your architecture needs to reflect that.
