8 A sovereign data lake is a data lake, or lakehouse, designed so that data stays inside a specific country or jurisdiction and remains under the control of the organization and its national legal framework. For banks, insurers, government agencies, healthcare providers, telcos and critical infrastructure operators, sovereignty is often not a preference but a requirement. Regulators, data protection authorities and national security agencies increasingly ask where data is stored, who can access it, which laws apply to the providers involved and whether the organization can operate independently if a foreign provider becomes unavailable. This article explains what data sovereignty means for a data lake, how requirements differ across major regions and how regulated firms design data lakes that keep data in-country without giving up modern analytics. For the general architecture, see our hub on running a data lakehouse on on-prem object storage. Residency, sovereignty and control Three related ideas often get mixed up: Data residency: where data is physically stored. Data sovereignty: which country’s laws govern the data and who can compel access to it. Operational control: whether the organization can run, access and move its data independently of a particular provider. A data lake can meet residency requirements by using in-country data centers, yet still raise sovereignty concerns if the provider is subject to foreign laws that could compel access. Requirements by region European Union GDPR restricts transfers of personal data outside the European Economic Area unless adequate protections are in place. The EU-US Data Privacy Framework, adopted in 2023, provides one transfer mechanism, but many organizations remain cautious after earlier frameworks were invalidated. Sector rules add further expectations: DORA for financial entities, NIS2 for essential and important entities and national rules for public sector and health data. The EU Data Act, applicable since September 2025, adds requirements around switching between cloud providers and safeguards against unlawful third-country access to non-personal data. France and Germany France’s national cybersecurity agency, ANSSI, operates the SecNumCloud qualification for trusted cloud services, which includes requirements designed to protect against non-European legal access. Germany’s BSI publishes the C5 criteria catalogue for cloud security. Public bodies and regulated firms in both countries often require qualified providers or on-premises infrastructure for sensitive data. United Kingdom UK GDPR governs personal data, with its own transfer rules. Financial regulators and the public sector set expectations for outsourcing, resilience and data location, and national security guidance applies to sensitive government data. United States The US has sector-specific rules rather than a single data localization law. Federal agencies require authorized cloud services and, for some data, US-based infrastructure and personnel. State privacy laws, financial regulators and healthcare rules add obligations. For non-US organizations, the reach of US law over US-headquartered providers is often the sovereignty concern. Japan Japan’s Act on the Protection of Personal Information governs personal data and cross-border transfers. The ISMAP program assesses cloud services for government use, and many organizations keep sensitive data in domestic facilities. Middle East The UAE, Saudi Arabia and other Gulf states have introduced data protection laws and sector rules that, for certain categories such as government, health and financial data, require data to be stored in-country. Architecture options for a sovereign data lake On-premises lakehouse The organization runs S3-compatible object storage, catalogs and query engines in its own data centers. This gives maximum control over location, access and operations, and avoids dependence on foreign providers. Open table formats keep the architecture modern and portable. National or sovereign cloud The data lake runs on a cloud service operated by a domestic provider, or a sovereign offering designed to meet national requirements, such as qualified services in France. This combines cloud operations with national control, but requires careful assessment of the provider’s ownership, operations and legal exposure. Hybrid Sensitive data stays in an on-premises or sovereign environment, while less sensitive workloads use public cloud services. Open formats allow approved data to move between environments. Governance must clearly define which data may go where. Design principles Keep storage in-country Place all copies of data, including backups and replicas, in approved locations. Multi-site replication should stay within the country or approved jurisdictions. Control the keys Encrypt data at rest and manage encryption keys within the jurisdiction, ideally under the organization’s own control. Whoever controls the keys controls access. Control metadata and telemetry Sovereignty applies to metadata, logs and telemetry as well as data. Catalogs, query logs and monitoring data can reveal sensitive information. Keep them in-country too. The scality.com blog covers metadata residency and storage telemetry data boundaries. Restrict remote and administrative access Vendor support access from abroad can undermine sovereignty. Define who can access systems, from where and under what approval. Use open formats Open table and file formats keep data portable, so the organization can change engines or providers without being locked in. That supports both sovereignty and the switching rights promoted by laws such as the EU Data Act. Audit everything Log data access, administrative actions and data movement, and keep logs in-country for regulators and auditors. Resilience within the border Keeping data in-country must not mean accepting a single point of failure. Regulators such as those enforcing DORA expect financial entities to withstand severe disruptions. A sovereign data lake should span at least two sites within the country, with replication or a stretched storage platform between them, and tested recovery procedures. Immutable copies protect against ransomware that could otherwise destroy both sites. Where the country is small or sites would share regional risks, organizations sometimes agree with regulators on approved locations in neighboring jurisdictions with equivalent protection, documented in their outsourcing and resilience plans. Exit and portability Sovereignty also means being able to leave. If a provider changes ownership, pricing or legal exposure, the organization must be able to move its data lake elsewhere without losing data or functionality. Open table formats, standard S3 interfaces and documented export procedures make this realistic. Test an exit plan at least once, for example by restoring a representative dataset into a different environment and running queries against it. Performance does not have to suffer A sovereign data lake can deliver the same analytics capabilities as a public cloud lakehouse. On-premises object storage, modern distributed query and processing engines and open table formats provide high performance when storage and network are sized properly. Governance roles Sovereignty is a cross-functional responsibility. Legal and compliance teams interpret requirements, security teams define access controls, data platform teams implement architecture and procurement teams assess providers. A short, shared register of which datasets are subject to which location rules keeps everyone aligned. AI on sovereign data Organizations increasingly want to train and run AI models on sensitive data without sending it abroad. A sovereign data lake provides the governed foundation for that, with GPU infrastructure placed alongside storage in-country. Checklist: sovereign data lake Identify residency, sovereignty and sector requirements per jurisdiction. Decide which data must stay in-country and which may move. Choose on-premises, national cloud or hybrid architecture. Keep all copies, backups and replicas in approved locations. Manage encryption keys within the jurisdiction. Keep catalogs, logs and telemetry in-country. Control remote administrative and vendor access. Use open table formats for portability. Audit access and data movement. Size storage and network for analytics performance. Putting it together A sovereign data lake keeps data, metadata and keys inside the jurisdiction that governs them, under the organization’s control, while still delivering modern analytics and AI. Requirements differ across the EU, UK, US, Japan and the Middle East, but the design principles are consistent: in-country storage and copies, local key control, restricted access, open formats and full auditability. On-premises S3-compatible object storage with open table formats is a common foundation, often combined with national cloud services for less sensitive workloads. Frequently asked questions What is a sovereign data lake? A data lake designed so that data, metadata and keys stay within a specific jurisdiction and under the organization’s control. Is data residency the same as data sovereignty? No. Residency is about where data is stored; sovereignty is about which laws apply and who can compel access. Can a public cloud region meet sovereignty requirements? Sometimes it meets residency requirements, but foreign laws that apply to the provider may still raise sovereignty concerns. What are SecNumCloud and C5? SecNumCloud is a French qualification for trusted cloud services; C5 is a German cloud security criteria catalogue from the BSI. Does a sovereign data lake limit analytics? No. Modern engines and open table formats on on-premises object storage deliver strong analytics performance. Further reading On-prem data lakehouse Open table formats on on-prem S3 SQL query engine object storage performance HDFS to object storage migration Cloud data sovereignty
