The Eight SOV Criteria: A Reflection on Cloud Sovereignty
"Cloud sovereignty" has been used loosely for a long time. The European Commission's Cloud Sovereignty Framework (EU CSF) gives the term a structure: eight sovereignty objectives, labelled SOV-1 through SOV-8. The German Federal Office for Information Security (BSI) has since turned six of them into a catalogue of verifiable criteria — the Criteria enabling Cloud Computing Autonomy (C3A) — which presupposes C5 compliance and leaves the remaining two domains to other frameworks.
What follows is not a summary of that catalogue. It is a walk through the eight criteria themselves — what each one actually asks — with a reflection on how each reads for a platform like openEduSuite: a self-hosted, open-source stack operated by the institution that uses it. Reading the criteria against a vendor is procurement; reading them against yourself is more interesting.
| # | Domain | Core question |
|---|---|---|
| SOV-1 | Strategic sovereignty | Who controls the provider's strategic decisions? |
| SOV-2 | Legal & jurisdictional sovereignty | Under whose law does the service effectively operate? |
| SOV-3 | Data & AI sovereignty | Who holds the keys, and where does the data actually live? |
| SOV-4 | Operational sovereignty | Can the service run without its non-EU lifelines? |
| SOV-5 | Supply chain sovereignty | Do we know what the service is made of? |
| SOV-6 | Technology sovereignty | Can we build, patch, and change the system ourselves? |
| SOV-7 | Security & compliance sovereignty | Does it meet the recognised security baseline? |
| SOV-8 | Environmental sustainability | Can it be run this way for decades? |
SOV-1 — Strategic Sovereignty
The first criterion asks whether the provider is established in the EU and effectively controlled from within: ownership structure, governance, and strategic decision-making must sit where European customers can, in the last resort, influence them. The C3A operationalise this with requirements on registered office, control, and advance notice of ownership changes.
Reflection. For a self-hosted platform, SOV-1 inverts: the institution is the provider. The criterion does not disappear — it becomes a governance question. Who decides the platform's roadmap? Whose priorities steer it? An open-source project with a public repository and a community of contributors makes that control legible in a way a corporate hierarchy cannot; but it also means the institution must actually exercise the control it has. Sovereignty you do not use is sovereignty you do not have.
SOV-2 — Legal & Jurisdictional Sovereignty
The second criterion asks under whose law the service effectively operates. The practical test is extraterritorial exposure: a provider subject to a non-EU legal regime can be compelled to hand over data regardless of where the servers stand. The C3A require an annual, structured assessment of such exposure, plus audit rights for national authorities — and, for the constitutional defence case, the ability to hand over operations to federal authorities, including material and personnel.
Reflection. This is the domain where self-hosting is strongest: an infrastructure operated by a German university under German and EU law has no foreign parent company through which obligations can arrive. But the reflection should not stop at satisfaction. Data itself is indifferent to jurisdiction — what matters is every path that leads to it. Identity federation (DFN-AAI), support contracts, monitoring services, even a neglected subprocessor in a privacy policy: each is a small opening. Jurisdictional sovereignty is less a state than a discipline of keeping those paths short.
SOV-3 — Data & AI Sovereignty
The third criterion asks whether customers retain control over their data in a technical sense: traceable storage and processing locations, encryption keys held outside the provider's environment, integration of external identity providers via open standards, and client-side encryption where needed. The "AI" in the domain name is not decoration — training and inference on institutional data raise the same question of who decides what happens to it.
Reflection. openEduSuite answers this structurally. The data never leaves the institution's storage; the keys live in the institution's own secret management; the identity provider (Keycloak, federated via DFN-AAI) is the institution's own. There is no negotiation about export or subprocessing because there is no counterparty. The honest caveat: traceability is work. Knowing where every service stores its state — MariaDB volumes, object storage buckets, backups — is an ongoing mapping exercise, and the criterion quietly demands that the map stays current.
SOV-4 — Operational Sovereignty
The fourth criterion is the one the C3A make most concrete: the service must be operable within the EU — by personnel with EU residence, with EU-based security operations and connectivity — and, in criterion SOV-4-09-C, it must survive a disconnect from non-European infrastructure without loss of availability, integrity, authenticity, or confidentiality, tested at least annually.
Reflection. A self-hosted platform does not depend on a foreign operator cloud, so the literal disconnect test is trivial. The meaningful translation of the criterion is upstream: the stack still pulls container images, security patches, and upstream releases from a global ecosystem. Disconnect, for open source, means being able to run — securely — on what is already on disk, for an extended period. That is a harder test than any vendor audit, and it is where practices matter more than declarations: mirrored images, vendored dependencies, a documented freeze-and-operate procedure. The honest answer is that openEduSuite could pass a bounded version of this test today and should not claim the unbounded one.
SOV-5 — Supply Chain Sovereignty
The fifth criterion asks whether the operator knows what the service is made of: software and hardware components, their countries of origin, ideally documented as a software bill of materials (SBOM), with mitigation strategies for critical dependencies.
Reflection. Here the open-source model is not automatically superior — it is merely auditable. A proprietary platform's supply chain is a contract question; an open one's is a file you can read. openEduSuite's Nix-based build makes the dependency graph deterministic and inspectable by construction, which is most of the way to an SBOM. The reflection that remains is about concentration: much of the open-source world converges on a small number of upstream projects and registries. Transparency about dependencies is not yet independence from them — but it is the precondition for ever getting there.
SOV-6 — Technology Sovereignty
The sixth criterion asks whether the operator can build, patch, and further develop the system independently: the C3A require source code and documentation backed up in the EU, kept current within 24 hours, with independent patching capability in an emergency.
Reflection. This is the domain where open source stops being an argument and becomes a fact. The source code is not merely available; the build system that turns it into a running platform is part of the repository. A security patch does not require a vendor's release cycle — it requires a maintainer and a pipeline, both of which exist. The criterion's 24-hour backup requirement reads almost ironically from this side: the harder part is not keeping the code, but keeping the knowledge — runbooks, architecture decisions, the reasons behind configuration choices. Technology sovereignty fails quietly when the person who understood the system leaves.
SOV-7 — Security & Compliance Sovereignty
The seventh criterion asks whether the service meets recognised European security requirements — certification frameworks such as NIS2, DORA, and the emerging EUCS. The C3A deliberately do not cover this domain: it is already served by established BSI instruments, above all C5:2026 and IT-Grundschutz.
Reflection. The exclusion is a useful reminder that sovereignty and security are different axes. A sovereign service that is insecure is a liability with better rhetoric; a secure service under foreign jurisdiction is a service you may one day lose. openEduSuite treats this domain through its ZKI IT-Grundschutz alignment — the higher-education reading of the BSI baseline, enforced as policy code. The reflection worth keeping: the EU CSF places SOV-7 in a list of sovereignty criteria, but it is really the entry ticket. Everything above it assumes it.
SOV-8 — Environmental Sustainability
The eighth criterion asks about the long term: energy-efficient infrastructure, circular-economy hardware practices, and transparent measurement of emissions and resource use. It is the domain the C3A explicitly leave out — not because it does not matter, but because it falls outside a cybersecurity authority's remit.
Reflection. Its exclusion from the catalogue says something about how sovereignty is usually framed: as a property of legal and technical relationships, not of physical resources. Yet the long-term view is the same view. A platform that cannot be sustained energetically or materially for decades is not sovereign, whatever its contract says — dependence merely arrives as cost and hardware scarcity instead of as a letter from a foreign court. Consolidating a campus's services onto a modest, well-utilised Kubernetes cluster is, among other things, an answer to this criterion that no procurement document lists.
What Reading the Criteria Against Yourself Reveals
Three observations survive the walk through all eight:
- The criteria form a ladder, and most "sovereign" offers stop at the first rung. Data residency answers SOV-3 partially and nothing else. The domains build on each other — legal protection (SOV-2) is worth little without operational independence (SOV-4), and operational independence is fragile without supply chain and technology sovereignty (SOV-5, SOV-6).
- For a self-hosted platform, the criteria are not a filter but a mirror. Asked of a vendor, they are procurement questions with audit answers. Asked of ourselves, they become uncomfortable and useful: can we really operate disconnected from upstream (SOV-4)? Do we know our supply chain (SOV-5)? Will the knowledge survive its maintainers (SOV-6)? The honest answers are mostly "increasingly yes, provably no" — which is a better position to argue from than a compliance badge for a service we do not control.
- The two excluded domains are the interesting ones. SOV-7 shows that sovereignty without security is posturing; SOV-8 shows that sovereignty without sustainability is temporary. The catalogue's boundaries are worth as much as its content.
The eight SOV criteria will likely matter most where they enter tenders and law — but their quieter value is as a vocabulary. They let an institution say precisely what it means by sovereignty, and then measure whether its platform — bought or built — actually does it.
Contribute
If your institution has worked through C5 audits, EU CSF assessments, or its own disconnect and SBOM practices, the openEduSuite community would value your perspective — especially the uncomfortable findings.
Visit openedu.graphwiz.ai for architecture documentation and deployment guides
Sovereignty read against a vendor is procurement. Read against yourself, it is a mirror — the eight SOV criteria are simply the frame that holds it steady.
Notes and Sources
- Frameworks discussed: EU Cloud Sovereignty Framework (European Commission) — source of the SOV-1 to SOV-8 structure and procurement weighting; BSI C3A — Criteria enabling Cloud Computing Autonomy (catalogue PDF; announcement) — source of the concrete criteria (SOV-4-09-C, SOV-4-01-C1/C2, and others) and of the deliberate exclusion of SOV-7 and SOV-8.
- Interpretation: The reflections on openEduSuite are the project team's self-assessments, not audit findings. Claims about what the C3A catalogue requires follow the published criteria; where reporting (heise online, Computer Weekly, April 2026) informed the reading, it is credited here.
- Not affiliated: openEduSuite is not affiliated with the BSI, the European Commission, or any cloud provider. This article is not legal advice.
- Trademark notice: All product and standards names mentioned (C5, C3A, IT-Grundschutz, NIS2, DORA, EUCS, Kubernetes, Keycloak, DFN-AAI, Nix, MariaDB) are used for identification and informational purposes only.
