Sovereign Cloud
Migration Checklist

You cannot control what you cannot locate. Regulatory auditors will ask for this map. If your answer is "probably EU" rather than a precise list, you have a gap.

GDPR Chapter V restricts international transfers. Cloud providers route data across regions by default, without explicit configuration, your data may already be crossing borders.

The US CLOUD Act allows US authorities to compel US-headquartered companies to hand over data stored anywhere in the world. AWS, Azure and GCP are all subject to it.

A data residency commitment without financial penalties is a marketing statement, not a legal obligation. Penalties are the mechanism that makes the commitment enforceable.

Regulatory audits don't give you weeks to prepare. If producing this map would take days of archaeology across multiple teams, that's a governance failure waiting to become a compliance failure.

Article 30 requires documentation of all processing activities. Many organisations update their RoPA when audited, by which point they're already in breach. Cloud workloads are frequently missing entirely.

NIS2 extends to cloud-dependent critical infrastructure. If you're in banking, energy, telco or healthcare, you need to demonstrate that your cloud setup meets NIS2 incident response and resilience requirements.

DORA requires financial entities to manage ICT third-party risk, including cloud providers. Concentration risk, exit strategies and contractual requirements are all in scope. Non-alignment is a regulatory finding.

Standard cloud contracts are often not sufficient as GDPR DPAs. You need to verify that data processing terms, subprocessor lists and transfer mechanisms meet current regulatory expectations.

Evidence packs cannot be assembled in 48 hours. Banks, insurers and critical infrastructure operators under NIS2 or DORA should maintain inspection-ready documentation as a continuous practice.

Regulators increasingly require exit strategies from critical providers. If the honest answer is "no" or "we've never modelled it", you have a lock-in risk that goes beyond commercial inconvenience.

Proprietary services compound over time. Every Lambda, every DynamoDB, every provider-specific data pipeline adds friction to a future exit. Open-standard alternatives usually exist and should be the default.

Infrastructure-as-code is the enabler of portability. Without it, migration is a manual, error-prone process measured in months. With it, re-provisioning in a new environment becomes a days-long operation.

Single-provider dependency is both a regulatory risk (concentration risk under DORA) and a commercial risk. A deliberate multi-cloud or hybrid strategy reduces both, and improves your negotiating position.

Cloud provider SLAs typically offer service credits, not compensation for business impact. For regulated entities, this may be insufficient. Negotiated enterprise agreements with stronger penalties are achievable.

Even if your data is EU-resident, privileged access from non-EU personnel may constitute a transfer under GDPR. Operational access controls are as important as data location controls.

Perimeter-based security fails in cloud environments. Zero Trust, verify every access, assume breach, is the architecture model required for regulated cloud operations. It's also increasingly an explicit regulatory expectation.

Provider-managed keys mean the provider can theoretically access your data. Customer-managed encryption keys (CMEK) ensure that access to your data requires your keys, and that you can revoke them.

Without explicit network controls, cloud traffic takes the most efficient path, which may cross borders. Segmentation at the network layer is a foundational sovereign cloud control, not an advanced configuration.

NIS2 and GDPR both require breach detection and notification capabilities. Detecting exfiltration attempts, not just successful breaches, is the difference between prevention and incident response.

Without a named owner, sovereignty decisions get made by default, or not at all. Accountability at the individual level is what converts a framework into actual practice.

Engineers make dozens of architectural decisions per week. If they don't know which workloads are subject to sovereignty rules, those rules won't be followed, regardless of what the policy document says.

Sovereignty debt accumulates through procurement decisions. If sovereignty criteria aren't built into vendor evaluation, each new tool you onboard is a potential new gap, and gaps compound.

Resilience that hasn't been tested is assumed resilience. A tabletop exercise reveals whether your exit and continuity plans work in practice, before an actual incident forces the answer.

Regulation evolves. Provider terms change. Architecture drifts. A sovereign cloud strategy that isn't reviewed becomes stale, and stale strategies fail audits and, eventually, real incidents.