“Sovereign cloud” has become a label that vendors attach to very different things: a data-centre address, a contractual promise, or a genuinely separate operation. For a public body in Slovakia deciding where a register, a case-management system or an analytics platform may live, the label is not enough. What matters is what is technically enforced, what is contractually guaranteed, and how it lines up with the rules you are actually bound by.
This article takes Oracle EU Sovereign Cloud apart along those three lines — and then maps it onto the Slovak government cloud categories, NIS2 and GDPR, so you can tell quickly whether it is a candidate for a given workload.
What “sovereign” means in Oracle’s case
Oracle launched EU Sovereign Cloud in June 2023 as a separate realm of Oracle Cloud Infrastructure: two regions, in Frankfurt and Madrid, that replicate to each other over a network that does not leave EU territory. The isolation is not only a matter of where the racks stand. The sovereign realm has its own networking, its own control plane and its own identity service, with no cross-realm access to or from the global commercial regions. A tenancy in the commercial cloud cannot see, peer with, or administer a tenancy in the sovereign one, and vice versa.
The operational side is what distinguishes it from a plain EU region. The regions are owned and run by EU-incorporated Oracle legal entities — Oracle states seven dedicated entities and more than 1,500 EU-resident staff as of early 2026 — and operations, support and access are restricted to EU-resident personnel. That is the substance behind the word: not a promise that data stays in Europe, but an organisational and technical structure in which nobody outside the EU has an operational path to it.
The certification set is what you would expect of a regulated-grade environment: SOC 1/2/3, ISO 27001, 27017, 27018 and 27701, PCI DSS, Germany’s C5 and Spain’s ENS, among others. Those matter less as trophies than as evidence you can hand to an auditor or a supervisory authority instead of a vendor brochure.
Same cloud, same price
The part that surprises most people: it is the same OCI. More than 150 services are available in the sovereign regions — compute, block and object storage, Autonomous Database, Exadata, APEX, Kubernetes, Vault, analytics — with the same SLAs and the same price list as the commercial regions. There is no sovereignty premium. That is unusual; the sovereign offerings that competitors have launched in Europe have generally carried a surcharge or a reduced catalogue.
Two honest caveats. First, service parity is real but not instantaneous: the newest services tend to arrive in the sovereign realm some months after the global regions. If your architecture depends on a service announced last quarter, check the sovereign catalogue before you commit. Second, “same price” applies to the list price; the commercial terms you negotiate — support rewards, commitments, BYOL — need to be written to cover the sovereign realm explicitly, because it is a distinct realm with its own tenancy.
What it does not solve
It is worth being precise about the limits, because the limits are where procurement and legal review will focus.
Corporate ownership. The operating entities are EU companies, but Oracle Corporation is their ultimate parent. EU Sovereign Cloud removes the operational path for extra-EU access; it does not change who owns the operator. Whether the residual legal exposure under the US CLOUD Act or similar instruments is acceptable for a particular dataset is a question for your lawyers and, where relevant, your regulator — the same question you should be asking of any US-parented provider, sovereign label or not.
Classification is yours. No cloud, sovereign or otherwise, decides for you which category your system belongs to. That decision, and the responsibility for it, stays with the public body.
Contracts, not slides. Data location, personnel residency, breach notification, audit rights and exit assistance are only guarantees if they are in the contract you sign. Ask for them in writing; the good news is that for this service they are available.
Mapping it to the Slovak rules
For a Slovak public body, three frameworks decide whether a cloud is usable for a given system.
The government cloud (vládny cloud). Under Act No. 95/2019 Coll. on public administration information technologies and the MIRRI methodology, each information system is classified from its confidentiality, integrity and availability parameters (C1–3, I1–3, A1–3) into a category — U1 for public data, U2 for internal operational data, U3 for data governed by special legal regimes (registers, personnel records, statistical and economic data), and U3+ for critical infrastructure and core state registers. The rule of thumb that follows from the methodology: U3+ and systems rated C3/I3/A3 belong in the state-operated private part of the government cloud; lower categories may use public cloud services, and public cloud is in fact the preferred option for them — provided the service is listed in the MIRRI catalogue of cloud services. A provider that is not in the catalogue cannot simply be procured; listing is a prerequisite, so this is the first thing to verify for any service and any provider you consider.
NIS2. Slovakia transposed NIS2 through Act No. 366/2024 Coll., amending the Cybersecurity Act (No. 69/2018 Coll.), effective 1 January 2025. It widened the circle of regulated entities substantially and makes the operator responsible for security measures across its supply chain, cloud included. A sovereign realm with EU-only operations and a full certification set makes the supplier-assurance part of that easier to document; it does not do your risk analysis for you.
GDPR and, for the financial sector, DORA. Data residency in the EU and the absence of extra-EU operational access address the questions raised by the Schrems II line of cases far more directly than transfer clauses can. Financial entities subject to DORA (Regulation (EU) 2022/2554, applicable since 17 January 2025) will additionally want the ICT third-party risk documentation — audit rights, exit strategy, sub-processor transparency — which is exactly the material the sovereign offering is built to provide.
Where it fits
In practice the sovereign realm is a strong candidate for:
- Oracle Database estates that must leave ageing on-premises hardware but cannot leave the EU — the licensing position on OCI is the most favourable of any cloud, and Exadata and Autonomous Database are available in the sovereign regions.
- APEX and Java applications for public administration where the data is U2 or U3 with moderate C/I/A parameters — low-code, EU-resident, and priced like commercial OCI.
- Analytics and reporting on sensitive datasets — health, social, economic — where the objection to public cloud has been “our data would sit under a non-EU operator”.
- Disaster recovery for on-premises Oracle — a second site in Frankfurt or Madrid, with Data Guard, without a second data centre lease.
It is a poor fit for U3+ and C3/I3/A3 systems, which the framework keeps in the state cloud regardless of provider, and for architectures built around a service that has not yet reached the sovereign catalogue.
How to approach it
- Classify first. Determine the U-category and C/I/A parameters of the system before you talk to any vendor. It decides whether public cloud is permissible at all.
- Check the MIRRI catalogue for the specific service; note what is listed and under which category.
- Plan a separate tenancy. The sovereign realm has its own identity domain and console; you will not extend an existing commercial tenancy into it. Design the landing zone — compartments, IAM, networking, logging — for the sovereign realm from the start.
- Write the guarantees into the contract: data location, EU-resident operations, notification, audit rights, exit and data return.
- Migrate with the same tooling you would use for commercial OCI — Terraform, Data Pump, GoldenGate, ZDM — the APIs are identical.
- Plan the exit before the entry. Sovereignty also means you can leave; document how.
How it compares
Oracle is not the only vendor with a European sovereign offering, but as of 2026 it is the one with the longest operating track record: the regions have run since 2023. AWS opened its European Sovereign Cloud in Brandenburg around the turn of 2025/2026 with a reduced initial catalogue and, according to independent analyses, a price premium over standard regions; Microsoft’s and Google’s European sovereign options are delivered through partner-operated structures (Bleu in France, S3NS in France) rather than the vendors’ own regions. The comparison worth making for your case is not “who is most sovereign” but which offering covers the services you need, under a contract you can sign, at a price that does not penalise sovereignty — and on the last point Oracle’s parity pricing is a genuine differentiator.
Common questions
Is EU Sovereign Cloud more expensive than regular OCI? No — same price list, same SLAs. The costs to plan for are a separate tenancy and landing zone, and the possibility that a brand-new service lands a few months later.
Can a Slovak public body use a public cloud at all? Yes, for systems in the lower government-cloud categories, using services listed in the MIRRI catalogue. U3+ and C3/I3/A3 systems stay in the state-operated private cloud.
Does it eliminate US CLOUD Act exposure? It removes the operational path for extra-EU access, which is what most assessments care about. The parent company remains American; the residual legal question belongs to your legal review.
Nevdom helps public bodies and regulated organisations classify their systems, check the procurement path, and design and migrate Oracle workloads to OCI — including the EU Sovereign Cloud realm. Get in touch for an independent assessment.
Related reading: OCI vs AWS for Oracle workloads · Which OCI database service is right for you? · High availability and disaster recovery for Oracle on OCI.
Facts about the service reflect Oracle’s published materials as of September 2026; the mapping to Slovak rules is general information, not legal advice. Verify the current MIRRI catalogue and your own classification before procurement.