In a nutshell: Sovereignty must be planned architecturally from the outset, not as a post-migration target, and requires backup infrastructure independent from hyperscaler ecosystems.
European organizations have long treated sovereignty as a post-migration concern. Yet operational dependence on US-based hyperscalers is now a direct business risk under NIS2, DORA and GDPR.
The widespread practice of operating backup infrastructure within the same cloud ecosystem – such as on Azure or within the same Microsoft Entra tenant – creates a single point of failure: a ransomware attack or accidental deletion jeopardizes both live data and recovery point simultaneously. Digital sovereignty is therefore primarily an architectural question, not a procurement one. Storing data physically in Germany does not automatically make it sovereign; what matters is control over the underlying infrastructure, access through subprocessors, and logical as well as physical separation of the backup environment from the systems it is meant to protect.
For CTOs and data protection officers under regulatory pressure, the problem becomes concrete: shared responsibility models such as Microsoft 365 transfer data protection responsibility to the customer – but within a centralized vendor ecosystem. True vendor independence means that backup infrastructure does not run on the same hyperscaler whose services are being backed up, that no subprocessors process data behind the scenes, and that immutable backups protect against encryption by attackers who have already breached the system. For NIS2, DORA and GDPR compliance, this structure is not optional but a compliance foundation.