Domain · D2
Operational transparency & data control
„Who has operational access to data and keys — and how is that demonstrable?"
1. Strategic relevance§
Operational transparency and data control decides, in day-to-day operation, whether the customer is in fact the sovereign of their data or merely its formal owner. This domain assesses the demonstrable controllability of the central operational levers.
What matters is not the provider's assurance but the cryptographically or organisationally demonstrable separation of data, keys and privileged access. Trust without demonstrability does not count in this domain.
D2 is the domain where sovereignty marketing diverges most strongly from real control. It demands robust technical and procedural evidence.
2. Core criteria§
- Key management model
Clear classification as provider-managed keys, BYOK or HYOK — including a description of which operations are possible without customer involvement.
- Data residency and replication locations
Full list of all primary, secondary and backup locations; contractually assured restrictions.
- Provider-side privileged access management
Who within the provider may access customer data under which conditions? Four-eyes principle, just-in-time access, break-glass procedures.
- Log integrity and tamper resistance
Access logs must be inspectable by the customer, complete and tamper-resistant (e.g. append-only, hash chains, external notarisation).
- Incident-response transparency
Defined reporting deadlines, defined level of detail, contractual obligation to disclose provider-internal incidents affecting customer data.
- Access evidence
Evidence of who accessed which data or keys and when — including by the provider itself and by sub-contractors.
3. Audit questions (excerpt)§
- Which key-management model is contractually agreed, and which operations are possible without customer involvement?
- Can data location and replication targets be contractually limited to the EU?
- Which groups within the provider have read or write access under which conditions?
- Is the access log inspectable by the customer in full, tamper-resistant and in near real time?
- Which reporting deadlines apply to security-relevant events and to provider-internal access incidents?
- How is it ensured that the provider cannot decrypt content without the customer's keys?
- Which procedures exist for break-glass access — and how are they logged?
4. Accepted evidence§
- Technical architecture documentation of key management (HYOK/BYOK)
- Excerpts from PAM logs and configuration evidence
- Append-only log architecture or external log notarisation
- Contractual data-residency clauses and replication restrictions
- Audit reports by independent auditors on access procedures (e.g. ISAE 3000)
5. Level thresholds in this domain§
| Level | Minimum requirement in D2 |
|---|---|
| L0 | Key and access model not transparent; no log inspection for the customer. |
| L1 | Full documentation of all access paths and key roles; read log access for the customer. |
| L2 | Customer holds key sovereignty (HYOK or equivalent), can revoke access and enforce data location. |
| L3 | Provider access to content data technically excluded; access evidence externally notarised; fully EU operation. |
6. Relation to existing standards§
| Standard | What is covered | Where EDSO goes further |
|---|---|---|
| ISO/IEC 27001 | Access control (Annex A.5.15 ff.) covered | Key sovereignty against the provider not required |
| SOC 2 Type II | Operational controls comprehensively documented | Sovereignty against the provider not within audit scope |
| TISAX | Data control partially (esp. prototype protection) | Key sovereignty and provider access not systematically audited |
| BSI C5 | Operational controls covered in detail | Structural separation of provider and customer only indirectly |
7. Typical audit findings§
- BYOK label despite the provider's continued ability to decrypt for operational functions
- Replication into a backup region outside the EU not contractually excluded
- Break-glass procedures without traceable logging
- Audit logs only retrospective and via provider portal — no tamper resistance
- Privileged provider accounts without a four-eyes principle