Domain · D3
Technical sovereignty & interoperability
„Can the service be switched without prohibitive effort?"
1. Strategic relevance§
Technical sovereignty measures the switchability of a service. As long as a service cannot be replaced by another within an acceptable time and at acceptable cost, the customer is structurally dependent on a single provider — regardless of how secure or transparent that provider may be in detail.
This domain therefore addresses structural bargaining power. It is the domain that makes long-term price, feature and security negotiations possible in the first place.
A high rating in D3 requires both open interfaces and demonstrated migration capability in real scenarios. Asserted portability without a reproducible exit exercise does not count.
2. Core criteria§
- Open standards and open-source components
Share of open standards in interfaces, data formats and core components. Avoidance of proprietary dead ends.
- Fully documented APIs
Versioned, contractually stable, fully documented interfaces for all administrative and data-related functions.
- Data portability in open formats
Exportability of all customer data in open, documented formats — including metadata and relationships.
- SBOM provision
Full software bill of materials for the components in use, regularly updated, machine-readable.
- Exit cost matrix
Documented effort and cost estimate for full migration into comparable target environments.
- Compatibility with competing services
Demonstrated migration paths into at least two competing target architectures — ideally as a reproducible reference implementation.
- Proprietary lock-in elements
Transparent listing of all proprietary databases, functions, ML models or configuration formats that make a switch harder.
3. Audit questions (excerpt)§
- Which data formats used by the service are openly standardised?
- Is a reference migration to a competing target environment documented and reproducible?
- Which proprietary components have no functionally equivalent open counterpart?
- Is there a complete, current SBOM — machine-readable in SPDX or CycloneDX format?
- Which documented exit cost estimate exists for the typical customer configuration?
- Are the APIs versioned and bound to a contractual deprecation period?
- Which data categories are not or only partially exportable?
4. Accepted evidence§
- API specifications (OpenAPI, AsyncAPI) including versioning policy
- SBOM in SPDX or CycloneDX format
- Exit playbook with estimate of duration, cost and data-loss risk
- Reproducible migration example into an alternative target architecture
- List of proprietary components with risk assessment
5. Level thresholds in this domain§
| Level | Minimum requirement in D3 |
|---|---|
| L0 | Closed stack without documented exit paths; data formats undocumented. |
| L1 | APIs and export paths fully documented; data export in open formats available. |
| L2 | Proven exit at acceptable cost and time; full SBOM; limited proprietary lock-in. |
| L3 | Predominantly open-source stack; reproducible migration into at least two competing targets; no material proprietary dead ends. |
6. Relation to existing standards§
| Standard | What is covered | Where EDSO goes further |
|---|---|---|
| ISO/IEC 27001 | Barely substantive reference to portability | EDSO complements in full |
| EUCS | Portability requirements partially included | Demonstrable exit exercise not required |
| EU Data Act | Portability rights enshrined in law | Operationalisability and audit depth open — EDSO concretises |
7. Typical audit findings§
- API completeness only for common functions, critical administration operations only via web UI
- Export in open format but without metadata and permission relationships
- SBOM only on request and without machine-readable format
- Hidden lock-in via proprietary configuration formats
- Exit cost figures with no reference to an actually performed migration