Digital Sovereignty Maturity Modelfeedback
Erstellt am: 20. März 2026 | Autor: Matthias, Enrico (GitLab)
Dieses Dokument beschreibt ein integriertes Reifegradmodell für digitale Souveränität, das die Bewertungsrahmen der EU-Kommission (CSF), des DVC-Reifegradmodells und des 3-Säulen-Modells zusammenführt. Es dient als Selbstbewertungsinstrument für Behörden, IT-Dienstleister und Softwarelieferanten im D-Stack-Umfeld.
1. Zweck und Einordnungfeedback
Warum ein Maturity Model?feedback
Souveränität ist kein binärer Zustand („souverän" vs. „nicht souverän"), sondern ein Spektrum mit messbaren Abstufungen. Der konkrete Bedarf an Souveränitätsmaßnahmen hängt ab von:
- Schutzbedarf der verarbeiteten Daten (z.B. VS-NfD, personenbezogene Daten, Architekturdaten)
- Regulatorischen Anforderungen der jeweiligen Verwaltungsebene (Bund, Land, Kommune)
- Risikoakzeptanz gegenüber geopolitischen und Lieferantenrisiken
- Wirtschaftlichkeit: Höhere Souveränitätsstufen erfordern höhere Investitionen
Dieses Modell macht den IST-Stand und den SOLL-Zustand quantifizierbar und steuerbar.
Verhältnis zu bestehenden Frameworksfeedback
2. Die fünf Reifegradstufen (SEAL-0 bis SEAL-4)feedback
Das EU Cloud Sovereignty Framework (CSF) definiert fünf Stufen, die den Grad der Kontrolle über Daten, Betrieb und Technologie abbilden. Jede höhere Stufe subsumiert die Anforderungen der vorherigen.
2.1 Stufenübersichtfeedback
2.2 Detaillierte Stufenbeschreibungfeedback
SEAL-0: Keine Souveränitätsmaßnahmenfeedback
| Dimension | Ausprägung |
|---|
| Datensouveränität | Keine Kontrolle über Speicherort oder Zugriff; Daten können in Drittstaaten verarbeitet werden |
| Betriebssouveränität | Keine Transparenz über Betriebsprozesse; kein ISMS nachgewiesen |
| Technologische Unabhängigkeit | Vollständige Abhängigkeit von einem Anbieter; kein standardisierter Export möglich |
| Typischer Einsatz | Unkritische öffentliche Informationen ohne Schutzbedarf |
| DVC-Listung | ❌ Nicht listungsfähig |
SEAL-1: Transparenz & Dokumentationfeedback
| Dimension | Ausprägung |
|---|
| Datensouveränität | Speicherort dokumentiert; Datenlokalisierung (EU/DE) vertraglich zugesichert, aber nicht technisch erzwungen |
| Betriebssouveränität | Betriebsprozesse dokumentiert; grundlegendes Audit-Logging vorhanden |
| Technologische Unabhängigkeit | Export theoretisch möglich; keine standardisierten Formate garantiert |
| CSF-Anforderungen | Transparenz über Subprozessoren; Dokumentation der Datenflüsse; Privacy Impact Assessment (PIA) durchgeführt |
| Typischer Einsatz | Allgemeine Verwaltungsdaten mit normalem Schutzbedarf |
| DVC-Listung | ⚠️ Nur Basis-Kriterien erfüllt |
SEAL-2: Vertragliche & operative Kontrollefeedback
| Dimension | Ausprägung |
|---|
| Datensouveränität | EU/DE-Datenresidenz vertraglich und organisatorisch gesichert; Auftragsverarbeitungsvertrag (AVV) nach DSGVO Art. 28; kein Zugriff aus Drittstaaten ohne Genehmigung |
| Betriebssouveränität | ISMS nachgewiesen (ISO 27001); Incident-Meldeprozesse nach NIS2 (24h/72h) implementiert; regelmäßige Audits |
| Technologische Unabhängigkeit | Exit-Plan dokumentiert; Datenexport in mindestens einem offenen Format verfügbar; Wechselkosten transparent |
| CSF-Anforderungen | Vollständige Zugriffsprotokollierung; Compliance-Reporting; SLA mit definierten Souveränitätsgarantien; BSI C5 Typ-1 oder äquivalent |
| Typischer Einsatz | Standard-Fachanwendungen; Bürokommunikation; nicht-sensible Register |
| DVC-Listung | ✅ Listungsfähig (Basis + Sicherheits-Dimension) |
SEAL-3: Technische Datenkontrollefeedback
| Dimension | Ausprägung |
|---|
| Datensouveränität | Customer Managed Keys (CMK): Schlüsselmaterial liegt ausschließlich beim Auftraggeber (HSM/KMS); BSI TR-02102-konforme Kryptografie; technisch erzwungene Datenresidenz |
| Betriebssouveränität | BSI C5 Typ-2 Testat; Confidential Computing für sensible Workloads; unveränderliche Audit Logs |
| Technologische Unabhängigkeit | Vollständiger Datenexport in offenen Standardformaten (z.B. ArchiMate, BPMN, OCI Images); automatisierter Export ohne Anbietermitwirkung; dokumentierte Migrationsschritte |
| CSF-Anforderungen | Keine Offshore-Datenverarbeitung; Betreiber-Personal ausschließlich EU-Staatsbürger oder sicherheitsüberprüft; technische Mandantentrennung; verschlüsselte Backups mit kundengesteuertem Schlüssel |
| Typischer Einsatz | EAM-Portale, Registeranwendungen, KRITIS-Fachanwendungen, Personalverwaltungssysteme |
| DVC-Listung | ✅ Vollständig listungsfähig (alle Dimensionen) |
SEAL-4: Vollständige technologische Unabhängigkeitfeedback
| Dimension | Ausprägung |
|---|
| Datensouveränität | Geschlossene Datenhaltung auf souveräner Infrastruktur; keinerlei Anbieter-Zugriff (Air-Gap oder strikt kontrollierte Netzwerksegmentierung); Verschlüsselung mit deutschen/EU-Zertifikaten |
| Betriebssouveränität | Vollständig autonomer Betrieb: eigene Administratoren, eigene Monitoring-Systeme; der Anbieter hat keinen Remote-Zugang; Betriebshandbuch liegt vollständig beim Auftraggeber |
| Technologische Unabhängigkeit | Quellcode verfügbar (Open Source oder Escrow); die komplette Anwendung kann ohne den Originalanbieter betrieben werden; vollständige Portabilität auf alternative Infrastruktur |
| CSF-Anforderungen | Souveräne oder nationale Cloud-Infrastruktur; keine Abhängigkeit von nicht-EU-lizenzierten Software-Komponenten in der Kernfunktionalität; vollständige Software-Lieferkettentransparenz (CRA/SBOM); betreiberseitige Kompilierung |
| Typischer Einsatz | VS-NfD-Anwendungen, nachrichtendienstliche Systeme, militärische Infrastrukturen, kritischste KRITIS-Systeme |
| DVC-Listung | ✅ Höchste Stufe; für SCS-basierte oder gleichwertige souveräne Infrastruktur vorgesehen |
rate_review 3. Bewertungsdimensionen im Detailfeedback
Das Maturity Model bewertet Cloud-Dienste und IT-Systeme entlang von sechs Dimensionen, die sich aus dem 3-Säulen-Modell und den regulatorischen Anforderungen ableiten:
3.1 Dimension: Datenresidenz & Lokalisierungfeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Speicherort dokumentiert | Verzeichnis der Verarbeitungstätigkeiten |
| 2 | EU/DE-Datenresidenz vertraglich gesichert | AVV, SLA mit Lokalisierungsklausel |
| 3 | Technisch erzwungene Datenresidenz; keine Offshore-Replikation | Technische Konfiguration, Azure Policy / Kubernetes Admission Controller |
| 4 | Air-Gap oder strikt segmentierte souveräne Infrastruktur | Netzwerkarchitektur-Dokumentation, Penetrationstest |
3.2 Dimension: Schlüsselmanagement & Kryptografiefeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Verschlüsselung at-rest und in-transit aktiv | Audit-Bericht |
| 2 | Anbieter-Managed Keys; Algorithmen dokumentiert | SLA, Krypto-Konzept |
| 3 | Customer Managed Keys (CMK): HSM/KMS beim Auftraggeber; BSI TR-02102-Konformität | HSM-Zertifikat, Krypto-Audit |
| 4 | Vollständig betreiberkontrollierte Kryptografie; eigene Zertifikatshierarchie (PKI) | PKI-Dokumentation, Sicherheitskonzept |
3.3 Dimension: Zertifizierung & Compliancefeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Selbstauskunft zu Sicherheitsmaßnahmen | DVC-Fragebogen |
| 2 | ISO 27001 Zertifizierung; BSI C5 Typ-1 | Zertifikat, Testat-Bericht |
| 3 | BSI C5 Typ-2 Testat; NIS2-Registrierung; Meldeprozesse implementiert | Testat, BSI-Registrierung |
| 4 | BSI IT-Grundschutz (Kern-Absicherung); EUCS High oder BSI-Zulassung | Grundschutz-Zertifikat, BSI-Zulassung |
3.4 Dimension: Transparenz & Auditierbarkeitfeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Basis-Audit-Logging vorhanden | Log-Architektur-Dokument |
| 2 | Vollständiges Audit-Logging; regelmäßige Berichte an Auftraggeber | Audit-Reports, SIEM-Konfiguration |
| 3 | Unveränderliche Audit Logs (Append-Only / WORM); Echtzeit-Überwachung; Auftraggeber hat direkten Log-Zugriff | SIEM-Dashboard, Log-Integrity-Proof |
| 4 | Betreiber-eigenes Monitoring; vollständige Einsicht ohne Anbieter-Vermittlung; forensische Analysefähigkeit | Betriebshandbuch, SOC-Architektur |
3.5 Dimension: Portabilität & Exit-Fähigkeitfeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Exit grundsätzlich möglich; nicht dokumentiert | — |
| 2 | Exit-Plan dokumentiert; mindestens ein offenes Exportformat | Exit-Konzept, EU Data Act-Konformitätserklärung |
| 3 | Vollständiger Export in offenen Standardformaten (ArchiMate, BPMN, OCI, SQL); automatisierter Self-Service-Export; Wechselkosten transparent | Export-Testprotokoll, Preisliste |
| 4 | Vollständige Portabilität; die Anwendung kann auf jeder SCS-kompatiblen oder gleichwertigen Infrastruktur betrieben werden; Container-Images ohne proprietäre Abhängigkeiten | Migrations-Testprotokoll, SBOM-Analyse |
3.6 Dimension: Offenheit & Software-Lieferkettefeedback
| SEAL | Anforderung | Nachweis |
|---|
| 1 | Offene Schnittstellen (APIs) dokumentiert | API-Dokumentation |
| 2 | SBOM vorhanden; Open-Source-Anteil dokumentiert | SBOM-Export, CRA-Konformitätsnachweis |
| 3 | Open-Source-first bei Kernkomponenten; OpenCoDE-Listung angestrebt; SBOM in CI/CD automatisiert | CI-Pipeline-Konfiguration, OpenCoDE-Profil |
| 4 | Quellcode vollständig einsehbar (Open Source oder Escrow); betreiberseitig kompilierbar; keine proprietären Laufzeitabhängigkeiten | Repository/Escrow-Vertrag, Build-Dokumentation |
4. Zuordnung zu deutschen Verwaltungsebenenfeedback
Nicht jede Verwaltungsebene benötigt SEAL-4. Das Modell empfiehlt Mindest-SEAL-Stufen nach Schutzbedarf und Verwaltungsebene:
| Anwendungskategorie | Typische Daten | Empfohlenes SEAL-Minimum | Begründung |
|---|
| Öffentliche Informationsportale | Offene Daten, Pressemitteilungen | SEAL-1 | Geringer Schutzbedarf; Transparenz ausreichend |
| Standard-Fachanwendungen (Kommune) | Meldedaten, Gebühren | SEAL-2 | DSGVO-Compliance + NIS2 |
| EAM-Portal (Bund/Land) | Architekturmodelle, IT-Landkarten, strategische Planung | SEAL-3 | Hochsensible Metadaten; Schlüsselhoheit zwingend |
| Registeranwendungen (NOOTS) | Personenbezogene Registerdaten | SEAL-3 | RegMoG, Once-Only-Prinzip |
| MDD-Marktplatz-Kern | Transaktionsdaten, Vertragsmetadaten | SEAL-3 | DVC-Reifegradmodell (vollständig) |
| VS-NfD / Hochsicherheit | Verschlusssachen, nachrichtendienstlich | SEAL-4 | BSI-Zulassung erforderlich; Air-Gap |
5. Self-Assessment-Checklistefeedback
Die folgende Checkliste ermöglicht eine schnelle Einordnung. Für jede Dimension wird die höchste erfüllte Stufe ermittelt; das Gesamtergebnis entspricht der niedrigsten Einzeldimension (schwächstes Glied bestimmt den Reifegrad):
| # | Prüffrage | SEAL |
|---|
| 1 | Ist der Daten-Speicherort dokumentiert? | ≥ 1 |
| 2 | Ist EU/DE-Datenresidenz vertraglich gesichert (AVV, SLA)? | ≥ 2 |
| 3 | Liegt ein gültiges ISO 27001-Zertifikat oder BSI C5 Typ-1-Testat vor? | ≥ 2 |
| 4 | Ist ein Exit-Plan mit mindestens einem offenen Exportformat dokumentiert? | ≥ 2 |
| 5 | Werden NIS2-Meldeprozesse (24h/72h) nachweisbar umgesetzt? | ≥ 2 |
| 6 | Wird ein BSI C5 Typ-2-Testat vorgewiesen? | ≥ 3 |
| 7 | Liegen die Verschlüsselungs-Schlüssel (CMK) beim Auftraggeber? | ≥ 3 |
| 8 | Ist die Datenresidenz technisch erzwungen (nicht nur vertraglich)? | ≥ 3 |
| 9 | Ist ein vollständiger Export in offenen Standardformaten als Self-Service verfügbar? | ≥ 3 |
| 10 | Sind Audit Logs unveränderlich (Append-Only/WORM)? | ≥ 3 |
| 11 | Kann die Anwendung ohne den Originalanbieter betrieben werden? | ≥ 4 |
| 12 | Ist der Quellcode vollständig verfügbar und betreiberseitig kompilierbar? | ≥ 4 |
| 13 | Ist eine Air-Gap- oder strikt segmentierte Betriebsumgebung aktiv? | ≥ 4 |
sync 6. Zusammenspiel mit dem DVC-Reifegradmodellfeedback
Das DVC-Reifegradmodell (IT-PLR 2025/15) bewertet für die MDD-Listung drei Dimensionen: Basis-Kriterien (Pflicht), Sicherheit und Souveränität. Die SEAL-Stufen lassen sich wie folgt zuordnen:
| DVC-Dimension | DVC-Kriterium | SEAL-Zuordnung |
|---|
| Basis | DSGVO-konforme AVV | SEAL ≥ 1 |
| Basis | Vergaberechtskonformität | SEAL ≥ 1 |
| Sicherheit | BSI HV-Benchmark (Verfügbarkeit) | SEAL ≥ 2 |
| Sicherheit | BSI C5 Typ-1 oder äquivalent | SEAL ≥ 2 |
| Sicherheit | BSI C5 Typ-2 | SEAL ≥ 3 |
| Souveränität | Open-Source-Anteil dokumentiert | SEAL ≥ 2 |
| Souveränität | EU/DE-Datenresidenz vertraglich | SEAL ≥ 2 |
| Souveränität | Schlüsselhoheit beim Auftraggeber (CMK) | SEAL ≥ 3 |
| Souveränität | Vollständige Portabilität / Exit | SEAL ≥ 3 |
| Souveränität | Open-Source-Quellcode / Escrow | SEAL ≥ 4 |
Fazit: Für eine vollständige MDD-Listung mit der Souveränitäts-Dimension ist mindestens SEAL-3 erforderlich. SEAL-2 genügt nur für die Basis- und Sicherheits-Dimensionen.
arrow_forward 7. Weiterführende Seitenfeedback