The question of what the term “sovereign cloud” means in Europe has moved from policy debates to formal European Commission (EC) procurement frameworks and industrial investments. The Cloud Sovereignty Framework (CSF), Sovereignty Effectiveness Assurance Levels (SEAL), and the developing EU Cybersecurity Certification Scheme for Cloud Services (EUCS) are separate initiatives that provide distinct reference points. Alongside strategic capital mobilization under the Strategic Technologies for Europe Platform (STEP), they establish a clearer direction for critical cloud infrastructure. While specific to EU institutional tenders and funding programs rather than acting as universal mandates, this combined momentum offers IT leaders and enterprise architects across regulated sectors a concrete reference point for how sovereignty criteria shape long-term architectural thinking. These developments help illustrate that operating in a regulated market does not mean every workload must remain on-premises; instead, they demonstrate that sovereignty is a spectrum, helping organizations evaluate the specific level of data control their architecture truly requires.
As organizations evaluate these models, the critical question is not just which infrastructure provider can meet tech sovereignty expectations, but whether the rest of the technology stack upholds that sovereignty posture once workloads are deployed. This is where the database layer becomes a critical consideration, and where MongoDB provides key capabilities to define who has operational custody of data and how seamlessly workloads adapt to evolving governance requirements.
In April 2026, the European Commission awarded sovereign-cloud contracts under the Cloud III Dynamic Purchasing System and used SEAL-2 and SEAL-3 as practical reference points in its CSF for that procurement. This provides a concrete example of how sovereignty-related criteria can be evaluated in an EC-level procurement context. It also raises a practical architectural question: if sovereign-cloud requirements are being evaluated against the CSF as a benchmark, what does that mean for the rest of the technology stack, and especially for the database tier?
This overview examines the potential implications of the awarded landscape, the operational relevance of SEAL-2 and SEAL-3*, and how MongoDB deployment models can support different architectural approaches for organizations to evaluate against their own requirements.
Why the new procurement benchmark matters
The Commission selected several European provider groups for this initiative. These included:
Post Telecom (headquartered in Luxembourg), working alongside OVHcloud and CleverCloud (both based in France).
STACKIT, the cloud division of Schwarz Group, based in Germany.
Scaleway, the cloud arm of Iliad Group, based in France.
Proximus, based in Belgium, partnered with S3NS (a joint venture of Thales and Google Cloud in France), Clarence (Luxembourg), and Mistral (France).
As published in the European Commission’s report under reference IP/26/833, three of the four awarded groups achieved the reported assessment level of SEAL-3, while the Proximus consortium attained SEAL-2. The Proximus result of SEAL-2 is an assessed level within the CSF, not a failed outcome; the consortium’s remaining non-EU dependencies distinguished it from the groups assessed at SEAL-3. Together, these results show that the procurement considered a range of sovereignty postures rather than a simple pass-or-fail threshold, and may help inform future market expectations around sovereignty-driven infrastructure and digital resilience.
In environments governed by frameworks such as the General Data Protection Regulation (GDPR), the Digital Operational Resilience Act (DORA), and the Network and Information Systems Directive 2 (NIS2), where requirements vary by organization and industry, engineering teams face concrete design priorities: mitigating ICT third-party concentration risk, establishing tested exit strategies, or enforcing granular boundaries over data access and telemetry. The CSF evaluation offers technical leaders a reference point for examining these operational dependencies, informing technical due diligence across database tiers and multi-cloud strategies without prescribing a single deployment model or replacing organization-specific legal analysis.
The challenge: infrastructure certification does not cover the full stack
Using cloud infrastructure assessed in the European Commission’s procurement event addresses only part of the broader sovereignty discussion and does not automatically answer questions about every layer of the technology stack. The relevant considerations can include data residency, service operation, metadata flows, external control-plane dependencies, encryption, access controls, and workload portability if requirements or risk posture change.
The database tier is particularly important in a broader data-sovereignty assessment because it stores, processes, and governs access to the data itself. An infrastructure-focused assessment such as the CSF evaluation can provide useful information about the underlying cloud environment, but it does not by itself characterize the database service’s data paths, plaintext exposure, key management, backups, logs and metadata, support and control-plane dependencies, or workload portability.
Regulatory frameworks such as the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, enacted in 2018) have heightened enterprise sovereignty concerns over access to data held by providers subject to foreign jurisdiction under applicable legal processes, illustrating why physical data residency alone does not establish operational or jurisdictional control. One practical question is therefore not whether a platform carries a universal “sovereignty” label, but which controls and operating boundaries an organization must evaluate for its own environment. Variables such as control-plane dependencies, cross-region support access, cloud provider corporate jurisdiction, and cryptographic key custody must be individually assessed based on the organization's unique requirements. An organization may adopt cloud infrastructure aligned with SEAL-3 expectations and still find that database-layer telemetry, external support paths, or unencrypted metadata introduce unintended exposures. The infrastructure assessment and the database governance posture remain separate engineering challenges that require independent validation.
MongoDB's three roles in the European sovereign cloud ecosystem
MongoDB serves three distinct roles in the European sovereign cloud ecosystem when viewed through the lens of the European Commission’s CSF. MongoDB’s flexible document model and query API can remain consistent across deployment models, while the operating model, responsibilities, data flows, access controls, and contractual arrangements may differ.
Figure 1. MongoDB deployment modes.
Role one: DBaaS on SEAL-3 sovereign clouds
In this model, a European cloud provider—such as STACKIT, OVHcloud, or Scaleway—operates a MongoDB database service under its own brand, infrastructure, and legal entity. MongoDB supplies the database engine, compatibility guarantees, and technical support framework, while responsibility for operating the service remains with the European provider.
Because the European provider operates the service, it is the entity with operational custody of customer data in this model. MongoDB is a software supplier and does not have operational custody of customer data on the European-operated service. All three provider groups that achieved SEAL 3 for the purposes of the April 2026 EC procurement event include a MongoDB Certified DBaaS partner. For organizations seeking sovereign cloud environments aligned with SEAL-3-style expectations, MongoDB is already available through those partnerships, without workarounds, unsupported deployments, or vendor substitution.
However, architecture teams must carefully evaluate the specific database edition offered by each sovereign cloud provider. Managed offerings in the European ecosystem typically fall into two categories: DBaaS based on MongoDB Community Server and DBaaS powered by MongoDB Enterprise Server, which is the engine underlying Enterprise Advanced. While both editions share the same flexible document model and core query API, they differ significantly in built-in operational capabilities. Community Server provides core database functionality, but achieving enterprise-grade security and operational maturity requires teams to build and manage custom configurations for auditing, access controls, and maintenance. In contrast, DBaaS powered by Enterprise Server delivers turnkey features, including native enterprise auditing, advanced authentication integration, and enhanced operational tooling, representing the closest functional equivalent to MongoDB Atlas in a self-contained or sovereign environment.
Availability of these editions varies across the European market. Currently, European providers like STACKIT and OVHcloud, alongside providers like IONOS, offer DBaaS backed by Enterprise Server, whereas Scaleway provides managed Community Server with enterprise-grade offerings currently in development. Selecting the appropriate provider therefore depends on whether a given workload requires these out-of-the-box enterprise capabilities or can be supported through community-tier deployments.
Role two: MongoDB Atlas with sovereignty controls
MongoDB Atlas is a multi-cloud intelligent data platform with availability across Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Atlas provides data placement controls; Resource Policies can restrict cluster creation to approved EU regions, and zone-based sharding can support regional data placement, subject to the workload’s shard key and application design.
For encryption, MongoDB Atlas supports Bring Your Own Key (BYOK) integration with cloud provider key management services, which can keep encryption keys outside MongoDB’s direct control. Atlas also supports Client-Side Field Level Encryption (CSFLE) and Queryable Encryption (QE), which encrypt sensitive fields on the client side before data reaches the database. MongoDB cannot access plaintext for those protected fields during supported query operations.
BYOK, CSFLE, and Queryable Encryption (QE) can materially reduce data-layer disclosure risks by preventing unauthorized or platform-level access to plaintext data. However, the effective protection boundary depends on the key-management model, query capabilities, and whether sensitive metadata remains exposed.
Certified DBaaS and Enterprise Advanced are alternative deployment models to evaluate for workloads where data sovereignty and encryption considerations are material. The appropriate choice depends on the organization’s technical, contractual, operational, and legal requirements.
Role three: MongoDB Enterprise Advanced for maximum jurisdictional control
MongoDB Enterprise Advanced (EA) is a commercial subscription that grants organizations the right to run MongoDB on their own infrastructure: on-premises, in a private cloud, on a sovereign provider’s dedicated environment, or in an air-gapped facility. MongoDB does not operate the customer’s clusters and, in this model, does not have operational custody of customer data at rest.
The infrastructure operator remains responsible for the environment in which the clusters run. How access to customer data and any legal or regulatory request would be handled depends on the applicable law, contractual arrangements, and the specific operating model; the relevant custody and control analysis therefore focuses on the entity operating that infrastructure rather than treating MongoDB as the infrastructure operator.
Enterprise Advanced preserves the same document model and core query semantics as MongoDB Atlas, supporting strong application-level portability across deployment models. Organizations can typically move regulated workloads from Atlas to EA while preserving the application data layer and most core query logic, which can reduce redesign effort and support portability, exit planning, and concentration-risk evaluation. The relevance of these capabilities to any particular regulatory framework depends on the organization’s specific requirements and legal and operational analysis.
Aligning the deployment model to your sovereignty requirements
The three MongoDB deployment models offer different combinations of deployment location, operational control, data access, encryption, and portability, which organizations can evaluate against their own data or technology sovereignty-related requirements.
For organizations evaluating technical, contractual, operational, or procurement requirements associated with SEAL-3-style sovereign infrastructure, the Certified Database as a Service (DBaaS) path provides MongoDB capability through a European provider, previously assessed at SEAL-3 in the Commission’s April 2026 procurement.
For organizations evaluating a US-operated managed cloud service with technical controls, MongoDB Atlas with Bring Your Own Key (BYOK), Client-Side Field Level Encryption (CSFLE), and Queryable Encryption (QE) can provide data-layer protections relevant to that assessment.
For organizations evaluating greater direct jurisdictional control, air-gapped operation, or self-managed deployment on sovereign or private cloud infrastructure, Enterprise Advanced preserves the same core document model and query semantics as Atlas and supports application portability without requiring MongoDB to operate the customer’s clusters. Depending on the deployment environment, it can also support customer-managed infrastructure and avoid dependency on a public cloud service, with no MongoDB operational custody of customer data at rest.
A practical advantage is that these three models are not mutually exclusive. An enterprise may evaluate a mixed deployment approach, such as using Atlas for standard workloads in EU-approved regions, Certified DBaaS for higher-sensitivity workloads, and Enterprise Advanced for classified or air-gapped workloads, while application-layer portability and governance requirements may vary by tier.
Final thoughts
Europe’s sovereign cloud ecosystem now includes an example of a formal assessment used in the European Commission’s procurement, four Commission-selected reference providers, and other national frameworks applicable in specific member states. These developments may be relevant to how regulated organizations evaluate cloud infrastructure over the coming years.
MongoDB is present at the database tier through Certified DBaaS partnerships with providers that have been assessed at SEAL-3 in the Commission’s April 2026 procurement, available with technical controls on managed cloud through MongoDB Atlas, and deployable in customer-managed environments through Enterprise Advanced. Each deployment model presents different technical, contractual, and operational characteristics for organizations to evaluate against their own requirements. Each preserves the same core document model and query semantics, which may help reduce redesign effort when moving workloads across deployment models.
Next Steps
To explore how MongoDB deployment models can be evaluated against your organization's technical, contractual, operational, and legal requirements, visit the MongoDB Industry Solutions hub.
Get started with MongoDB Atlas and explore its available data-placement and encryption controls, including EU-region Resource Policies, customer-managed encryption keys, and client-side encryption.
*Within the CSF, the SEAL levels range from SEAL-0 to SEAL-4 and describe varying degrees of EU jurisdiction and control over legal, operational, and supply-chain dependencies. At SEAL-2 (Data Sovereignty), EU law is enforceable, though some material non-EU dependencies persist. SEAL-3 (Digital Resilience), assesses whether relevant non-EU dependencies have been reduced to marginal levels under the CSF. SEAL-4 (Full Digital Sovereignty), represents the theoretical goal of complete EU control without critical dependencies on non-EU entities, a standard no provider has reached so far. These descriptions refer to the CSF framework and the assessment made in the Commission’s procurement context; they do not prescribe what any particular organization must do.
Disclaimer
This content is for informational purposes only and does not constitute legal advice. Regulatory requirements vary by jurisdiction and industry. Organizations should consult qualified legal counsel and their internal compliance teams to understand their specific obligations.