Digitale Souveränität – Vorgaben und Kriterienfeedback
Erstellt am: 19. März 2026 | Autor: Matthias, Enrico (GitLab)
Diese Seite fasst alle maßgeblichen Vorgaben, Standards und Initiativen zur digitalen Souveränität zusammen, geordnet nach Verbindlichkeit und Anwendungsbereich. Der Fokus liegt auf Enterprise Architecture Management und der Teilnahme am Marktplatz Deutschland Digital (MDD) als souveräne Dienste. Alle Anforderungen werden konsequent verlinkt und entlang von drei Säulen kategorisiert, die als roter Faden durch alle regulatorischen Ebenen führen.
Das 3-Säulen-Modell der digitalen Souveränitätfeedback
Digitale Souveränität bedeutet, dass Organisationen und Behörden sicher und selbstbestimmt in der digitalen Wirtschaft agieren können, ohne unkontrollierte Abhängigkeit von einzelnen Anbietern oder fremden Rechtssystemen. Treiber sind 2026 insbesondere geopolitische Spannungen, der US CLOUD Act, stetig steigende Regulierungsdichte und der Live-Gang des Marktplatzes Deutschland Digital (MDD) am 18. März 2026.
Alle Vorgaben in diesem Dokument lassen sich drei Säulen zuordnen:
| Säule | Kernfrage | Typische Anforderungen |
|---|---|---|
| Datensouveränität | Wer kontrolliert Daten, Schlüssel und Zugriff? | Datenresidenz EU/DE, Customer Managed Keys, Policy Enforcement, Schutz vor US CLOUD Act |
| Betriebssouveränität | Wer kontrolliert den Betrieb und kann ihn prüfen? | BSI C5 Typ-2, ISMS, NIS2-Meldeprozesse, unveränderliche Audit Logs |
| Technologische Unabhängigkeit | Wie lässt sich ein Anbieter wechseln? | Exit-Strategie, offene Exportformate, Open-Source-Pflicht, kein Vendor-Lock-in |
1. Maßgebliche Initiativen und Frameworks (2025/2026)feedback
Drei übergeordnete Frameworks definieren 2026 den Handlungsrahmen für Souveränität in der öffentlichen Verwaltung:
1.1 Marktplatz Deutschland Digital (MDD) & DVC-Reifegradmodellfeedback
Der Marktplatz Deutschland Digital (MDD) ist seit dem 18. März 2026 in Produktivbetrieb. Er ist der zentrale Beschaffungshub der öffentlichen Verwaltung für cloudbasierte IT-Services. Für die Listung als Anbieter ist das DVC-Reifegradmodell (IT-PLR Beschluss 2025/15) verbindliche Voraussetzung. Es gliedert sich in:
- Basis-Kriterien (Pflicht): DSGVO-konforme Auftragsverarbeitung, Vergaberechtskonformität
- Sicherheits-Dimension: BSI-HV-Benchmark (Hochverfügbarkeit), BSI C5 oder äquivalente Nachweise
- Souveränitäts-Dimension: Open-Source-Anteil, Portabilität, Schlüsselhoheit, EU/DE-Datenresidenz
Quellen: DVC Grundlagen & Beschlüsse | DVC Leitfaden Softwarelieferant (FITKO)
1.2 Gaia-X Trust Framework 3.0 (Danube) & Eclipse Dataspace Connectorfeedback
Das Gaia-X Trust Framework 3.0 (Version „Danube", 2025) ist der EU-weite Standard für nachweisbare Compliance in Datenökosystemen. Über Gaia-X Verifiable Credentials weisen Anbieter und Dienste ihre Konformität kryptografisch nach.
Der Eclipse Dataspace Connector (EDC) der International Data Spaces Association (IDSA) setzt die IDS-Referenzarchitektur (IDS-RAM) um und ermöglicht souveränen Datenaustausch nach dem Prinzip „Data Stays at Source": Rohdaten verbleiben beim Anbieter; der Marktplatz verwaltet nur Metadaten und orchestriert Transaktionen.
1.3 EU Cloud Sovereignty Framework (CSF v1.2.1)feedback
Die EU-Kommission veröffentlichte im Oktober 2025 das EU Cloud Sovereignty Framework (CSF v1.2.1). Es macht Cloud-Souveränität über acht Sovereignty Objectives (SOV-1 bis SOV-8) und fünf Sovereignty Effective Assurance Levels (SEAL-0 bis SEAL-4) objektiv messbar.
Sovereignty Effective Assurance Levels (SEAL)feedback
| SEAL-Stufe | Bezeichnung | Beschreibung |
|---|---|---|
| SEAL-0 | No Sovereignty | Dienst, Technologie oder Betrieb unter ausschließlicher Kontrolle von Nicht-EU-Drittparteien, vollständig Nicht-EU-Jurisdiktion. |
| SEAL-1 | Jurisdictional Sovereignty | EU-Recht formal anwendbar, aber mit eingeschränkter praktischer Durchsetzbarkeit; Kontrolle durch Nicht-EU-Drittparteien. |
| SEAL-2 | Data Sovereignty | EU-Recht anwendbar und durchsetzbar, jedoch wesentliche Nicht-EU-Abhängigkeiten; indirekte Kontrolle durch Nicht-EU-Drittparteien. |
| SEAL-3 | Digital Resilience | EU-Recht anwendbar und durchsetzbar, EU-Akteure üben bedeutenden, aber nicht vollständigen Einfluss aus; marginale Nicht-EU-Kontrolle. |
| SEAL-4 | Full Digital Sovereignty | Technologie und Betrieb unter vollständiger EU-Kontrolle, ausschließlich EU-Recht, keine kritischen Nicht-EU-Abhängigkeiten. |
Sovereignty Objectives (SOV-1 bis SOV-8)feedback
Das CSF v1.2.1 definiert acht Sovereignty Objectives, die als Bewertungsgrundlage für die SEAL-Stufen dienen. Die gewichtete Gesamtbewertung aller Objectives ergibt den Sovereignty Score:
| # | Objective | Gewicht | Beschreibung |
|---|---|---|---|
| SOV-1 | Strategic Sovereignty | 15 % | Verankerung des Cloud-Anbieters im europäischen Rechts-, Finanz- und Industrieökosystem: Eigentümerstruktur, Governance, Alignment mit EU-Strategieprioritäten. |
| SOV-2 | Legal & Jurisdictional Sovereignty | 10 % | Rechtsrahmen, Exposition gegenüber extraterritorialen Gesetzen (z.B. US CLOUD Act), Durchsetzbarkeit von Rechten innerhalb der EU-Jurisdiktion. |
| SOV-3 | Data & AI Sovereignty | 10 % | Schutz, Kontrolle und Unabhängigkeit von Daten und KI-Diensten innerhalb der EU: Schlüsselhoheit (Customer Managed Keys), Auditierbarkeit, strikte EU-Datenresidenz, EU-Kontrolle über KI-Modelle. |
| SOV-4 | Operational Sovereignty | 15 % | Praktische Fähigkeit von EU-Akteuren, Technologie unabhängig von ausländischer Kontrolle zu betreiben: Portabilität, EU-basierter Support, Fachkräfteverfügbarkeit, vollständige technische Dokumentation. |
| SOV-5 | Supply Chain Sovereignty | 20 % | Geographischer Ursprung, Transparenz und Resilienz der Technologie-Lieferkette: Hardware-Herkunft, Firmware-Jurisdiktion, Software-Provenienz, Audit-Rechte über die gesamte Zulieferkette. |
| SOV-6 | Technology Sovereignty | 15 % | Offenheit, Transparenz und Unabhängigkeit des technologischen Stacks: offene APIs und Standards, Open-Source-Lizenzen, Architektur-Dokumentation, EU-Unabhängigkeit bei HPC. |
| SOV-7 | Security & Compliance Sovereignty | 10 % | Sicherheitsbetrieb, Compliance und Resilienz unter EU-Kontrolle: EU-anerkannte Zertifizierungen (ISO, ENISA, BSI C5), NIS2/DORA-Konformität, EU-basiertes SOC, unabhängige Audit-Fähigkeit, Patch-Autonomie. |
| SOV-8 | Environmental Sustainability | 5 % | Langfristige Autonomie und Resilienz der Cloud-Dienste hinsichtlich Energieverbrauch (PUE), Kreislaufwirtschaft, CO₂-Transparenz und Nutzung erneuerbarer Energien. |
Bedeutung der Sovereignty Objectives für das EAM-Portalfeedback
Ein EAM-Portal speichert hochsensible Architekturdaten, IT-Landschaftspläne und strategische Metadaten öffentlicher Einrichtungen. Die folgende Tabelle zeigt, wie jedes CSF-Objective auf konkrete EAM-Portal-Anforderungen abbildet:
| SOV | EAM-Portal-Relevanz | Konkrete Maßnahme |
|---|---|---|
| SOV-1 | Anbieter muss in EU-Eigentümerstruktur verankert sein | Betreiber-/Herstellerauswahl mit Prüfung auf EU-Holding, keine Nicht-EU-Kontrollmehrheit |
| SOV-2 | Architekturdaten dürfen keiner extraterritorialen Herausgabepflicht unterliegen | Vertragliche und technische Absicherung gegen US CLOUD Act; Hosting ausschließlich unter EU-Jurisdiktion |
| SOV-3 | Volle Datenkontrolle über Architektur- und Metadaten | Customer Managed Keys (HSM/KMS), EU-Datenresidenz, Audit Logs für jeden Datenzugriff, KI-Analysen nur mit EU-kontrollierten Modellen |
| SOV-4 | Betrieb des Portals muss ohne Nicht-EU-Vendor möglich sein | EU-basierter Support und Betrieb, vollständige technische Dokumentation, Migrations-/Exit-Fähigkeit ohne Vendor-Lock-in |
| SOV-5 | Transparenz der gesamten Software- und Infrastruktur-Lieferkette | SBOM-Pflicht (CRA), Nachweis der Hardware-/Software-Herkunft, Audit-Rechte über Sub-Lieferanten |
| SOV-6 | Kein Lock-in durch proprietäre Schnittstellen | Offene Export-Formate (ArchiMate, BPMN, TOGAF), dokumentierte APIs, Open-Source-Vorrang (ZenDiS/OpenCoDE) |
| SOV-7 | Sicherheitsbetrieb vollständig in EU-Jurisdiktion | BSI C5 Typ-2, ISO 27001, NIS2-konforme Meldeprozesse (24h/72h), EU-SOC, unabhängige Audit-Fähigkeit |
| SOV-8 | Nachhaltiger IT-Betrieb als Anforderung der öffentlichen Beschaffung | Energieeffizienz-Nachweis (PUE), Nutzung erneuerbarer Energien, CO₂-Berichterstattung |
Quelle: CSF v1.2.1 Volltext (EU-Kommission)
2. Rechtsrahmen – EU-Ebene (verbindlich)feedback
| Regelung | In Kraft | Kernanforderung für EAM/Marktplatz |
|---|---|---|
| DSGVO (EU 2016/679) | Mai 2018 | Datenschutz-Grundlage; Verarbeitung personenbezogener Daten → Datenschutz |
| EU Data Governance Act – DGA (EU 2022/868) | Sept. 2023 | Regelwerk für Datenmittler, Datenaltruismus und die Weitergabe von Verwaltungsdaten |
| EU Data Act (EU 2023/2854) | Sept. 2025 | Exit-Pflicht: vollständige, standardisierte Datenportabilität; Wechselerleichterung von Cloud-Anbietern |
| NIS2-Richtlinie (EU 2022/2555) | DE: Dez. 2025 | ISMS-Pflicht, Risikomanagement, 24h/72h-Meldepflicht → Sicherheit & Compliance |
| eIDAS 2.0 (EU 2024/1183) | Mai 2024 | EUDI Wallet als europäische digitale Identität; Bundesdruckerei als notifizierter Anbieter |
| EU AI Act (EU 2024/1689) | Aug. 2024 | Regulierung von KI-Komponenten (z.B. KI-gestützte EAM-Analyse); Hochrisiko-KI erfordert Transparenz und Dokumentation |
| Cyber Resilience Act – CRA (EU 2024/2847) | Dez. 2024 | SBOM-Pflicht (Software Bill of Materials) und Produkt-Cybersicherheit für digitale Produkte und Software |
| EUCS (EU Cybersecurity Certification Scheme for Cloud) | ENISA, laufend | Zukünftiger harmonisierter EU-Zertifizierungsrahmen für Cloud-Dienste; baut auf BSI C5 auf |
3. Rechtsrahmen – Deutschland (verbindlich)feedback
| Regelung | In Kraft | Kernanforderung für EAM/Marktplatz |
|---|---|---|
| IT-PLR Beschluss 2021/09 – Strategie Digitale Souveränität | 2021 | Mandat zur Gründung von ZenDiS; Open-Source-First-Verpflichtung für Basiskomponenten → Rechtl. Rahmen |
| DVC-Strategie & Reifegradmodell (IT-PLR Beschluss 2025/15) | 2025 | Verbindlicher Kriterienkatalog für die Listung im MDD; bewertet Sicherheit, Portabilität und Souveränität |
| IT-PLR Beschluss 17. März 2026 – D-Stack verbindlich | März 2026 | D-Stack-Standards für alle föderalen Ebenen verbindlich erklärt → Rechtl. Rahmen |
| NIS2-Umsetzungsgesetz (NIS2UmsuCG / BSIG n.F.) | Dez. 2025 | 24h-Erstmeldepflicht, Registrierungspflicht für kritische und wichtige Einrichtungen; ISMS-Nachweis obligatorisch |
| KRITIS-Dachgesetz (KRITIS-DachG) | Juli 2024 | Sektorübergreifende Mindestresilienzanforderungen für kritische Infrastrukturen |
| BSI Technische Richtlinie TR-02102 | Laufend | Verbindliche Kryptoverfahren für Bundesbehörden; definiert zulässige Algorithmen und Schlüssellängen |
| DVC Leitfaden Softwarelieferant (FITKO) | Laufend | Konkrete Anforderungen für Software im DVC-Ökosystem: Schlüsselhoheit, Datenresidenz, Exit-Fähigkeit |
4. Standards & Zertifizierungenfeedback
| Standard | Herausgeber | Verbindlichkeit | Bedeutung |
|---|---|---|---|
| BSI C5:2020 (Typ-2-Testat) | BSI | Pflicht (DVC) | Cloud-Sicherheitsnachweis für alle DVC-Infrastrukturbetreiber; Typ-2 = geprüfte Wirksamkeit über 6–12 Monate |
| BSI IT-Grundschutz | BSI | Pflicht (Bundesbehörden) | Nationale Sicherheitsnorm; Basis-, Standard- und Kern-Absicherung → Sicherheit & Compliance |
| ISO/IEC 27001 | ISO/IEC | Pflicht (Cloud-Anbieter) | Internationaler ISMS-Standard; Minimalanforderung für Cloud-Dienstleister im DVC-Kontext → Sicherheit & Compliance |
| Gaia-X Trust Framework & Verifiable Credentials | Gaia-X AISBL | Empfohlen (MDD) | Kryptografisch gesicherte Self-Descriptions für den Nachweis der Gaia-X-Compliance in Marktplätzen |
| EUCS (EU Cybersecurity Certification Scheme for Cloud) | ENISA | Zukünftig verbindlich | Harmonisierter EU-Rahmen; zielt auf europaweit gegenseitig anerkannte Cloud-Zertifikate |
5. Strategien, Programme & Technologienfeedback
| Initiative | Betreiber | Funktion |
|---|---|---|
| Sovereign Cloud Stack (SCS) | Open Infrastructure Foundation | Open-Source-Referenzimplementierung für IaaS/CaaS (Kubernetes); Gaia-X- und DVC-kompatibel |
| ZenDiS – Zentrum für Digitale Souveränität | Bund | Kuratiert Open-Source-Bausteine (openDesk, Sovereign Workplace); Mandat aus IT-PLR Beschluss 2021/09 |
| OpenCoDE | ZenDiS / Bund | Kollaborationsplattform für Open-Source-Software der deutschen Verwaltung |
| Gaia-X Association AISBL | EU-weites Konsortium | Definiert das europäische Datenökosystem und den Trust Framework; Grundlage für föderierte Datenräume |
| IDSA – International Data Spaces Association | Industriegetragen | Definiert die IDS-Referenzarchitektur (IDS-RAM) für souveräne Datenräume |
| Eclipse Dataspace Connector (EDC) | Eclipse Foundation | Referenz-Implementierung der IDS-RAM; Kernprotokoll für souveräne Datentransaktionen im MDD |
| ODRL – Open Digital Rights Language (W3C) | W3C | Standard für maschinenlesbare Zugriffs- und Nutzungsrechte (Policy Language) im Dataspace-Protokoll |
6. Souveränitätskriterien für das EAM-Portalfeedback
Ein EAM-Portal speichert hochsensible Architekturdaten, IT-Landschaftspläne und strategische Metadaten öffentlicher Einrichtungen. Die drei Souveränitätssäulen übersetzen sich in folgende verbindliche Anforderungen:
6.1 Datensouveränität: Schlüsselhoheit (Customer Managed Keys)feedback
Das Schlüsselmaterial für die Datenverschlüsselung (z.B. für Datenbanken und Object Storage) muss ausschließlich beim Auftraggeber bzw. Betreiber liegen, nicht beim Softwarelieferanten. Konkret:
- Einsatz eines Hardware Security Module (HSM) oder Key Management Service (KMS) unter Kontrolle des Betreibers
- Verschlüsselungsalgorithmen müssen BSI TR-02102-konform sein
- Quelle: DVC Leitfaden Softwarelieferant (FITKO)
6.2 Betriebssouveränität: BSI C5 Typ-2 & NIS2-Compliancefeedback
Das Hosting des EAM-Portals muss auf einer nach BSI C5:2020 Typ-2 zertifizierten Infrastruktur erfolgen. Zusätzlich sind gemäß NIS2UmsuCG zu erfüllen:
- Nachgewiesenes ISMS (vorzugsweise ISO 27001)
- Implementierter Meldeprozess: 24h-Erstmeldung bei erheblichen Sicherheitsvorfällen, 72h-Detailmeldung
- Vollständige Auditierbarkeit aller administrativen Zugriffe (unveränderliche Audit Logs)
6.3 Technologische Unabhängigkeit: Exit-Fähigkeit (EU Data Act)feedback
Gemäß EU Data Act (EU 2023/2854) muss das EAM-Portal einen vollständigen, standardisierten Datenexport ermöglichen:
- Export aller Architekturdaten in offenen Formaten: TOGAF, ArchiMate, BPMN
- Der Export muss ohne Mitwirkung des Softwarelieferanten auslösbar sein
- Wechselkosten zu einem anderen Anbieter müssen transparent und angemessen sein
6.4 Datenresidenz & Mandantenfähigkeitfeedback
- Striktes Hosting in EU/DE-Rechenzentren ohne Möglichkeit einer Verarbeitung oder eines Zugriffs aus Drittstaaten (Schutz vor dem US CLOUD Act)
- Technische Mandantentrennung: Architekturdaten unterschiedlicher Behörden müssen auf Infrastrukturebene isoliert sein
7. Souveränitätskriterien für den Marktplatz (DVC / Data Space)feedback
Ein souveräner Marktplatz orchestriert den Austausch von Daten, Fachverfahren und Services, ohne selbst die Hoheit über die Assets zu übernehmen. Das Leitprinzip ist Föderierung statt Zentralisierung.
7.1 Dezentrale Datenhaltung (Data Stays at Source)feedback
Im Gegensatz zu zentralen Data Lakes verbleiben Rohdaten beim jeweiligen Anbieter. Der Marktplatz verwaltet ausschließlich Metadaten und orchestriert Transaktionen, technisch realisiert durch den Eclipse Dataspace Connector (EDC) auf Basis der IDS-Referenzarchitektur.
7.2 Automatisierte Policy-Durchsetzungfeedback
Zugriffs- und Nutzungsrechte werden als maschinenlesbare Verträge direkt an Services und Daten gekoppelt und technisch erzwungen:
- Policy-Sprache: ODRL (Open Digital Rights Language) und IDS Policy Language
- Enforcement: Kein manueller Genehmigungsprozess; Policies werden automatisch beim Datenabruf geprüft
7.3 Vertrauensanker (Trust Anchors)feedback
Die Identität von Anbietern und Diensten im Marktplatz muss kryptografisch nachweisbar sein:
- Gaia-X Verifiable Credentials: standardisierter Nachweis der Gaia-X-Compliance
- Alternativ: Anbindung an föderale IAM-Systeme der Verwaltung (z.B. BundID, föderierte Entra-ID-Instanzen)
7.4 DVC-Reifegradmodell als Listungsvoraussetzungfeedback
Um im MDD als Anbieter gelistet zu werden, ist eine Selbstauskunft nach dem DVC-Reifegradmodell (IT-PLR Beschluss 2025/15) verpflichtend. Sie prüft:
- DSGVO-konforme Auftragsverarbeitungsverträge und Vergaberechtskonformität (Basis-Kriterien)
- BSI HV-Benchmark (Organisation) für Verfügbarkeit und Notfallmanagement
- Dimensions-Nachweise: Open-Source-Anteil, Portabilität, Schlüsselhoheit, EU/DE-Datenresidenz
8. Kriterienmatrix: Souveränität im Überblickfeedback
| Säule | Kriterium | Regulatorische / Technische Quelle |
|---|---|---|
| Daten | EU/DE-Datenresidenz, Schutz vor Drittstaat-Zugriff | DSGVO, EU CSF (SEAL), DVC Basis-Kriterium |
| Daten | Daten verbleiben an der Quelle, Policy-Enforcement | IDS-RAM (IDSA), Eclipse EDC, ODRL |
| Daten | Schlüsselhoheit (KMS/HSM) beim Auftraggeber | BSI TR-02102, DVC Leitfaden Softwarelieferant |
| Betrieb | Infrastruktur-Zertifizierung nach BSI C5 Typ-2 | BSI C5:2020, DVC-Reifegradmodell |
| Betrieb | ISMS, Risikomanagement, Vorfallsmeldung (24h/72h) | NIS2UmsuCG / BSIG n.F., ISO 27001 |
| Betrieb | Unveränderliche Audit Logs, vollständige Nachvollziehbarkeit | NIS2-Richtlinie (EU 2022/2555), BSI C5 |
| Technologie | Portierbarkeit, standardisierter Exit (TOGAF / ArchiMate / BPMN) | EU Data Act (EU 2023/2854), DVC-Reifegradmodell |
| Technologie | Open-Source-Vorrang, kein Vendor-Lock-in | IT-PLR Beschluss 2021/09, ZenDiS/OpenCoDE |
| Technologie | SBOM-Pflicht, Software-Lieferkettensicherheit | Cyber Resilience Act (EU 2024/2847) |
| Vertrauen | Nachweisbare Compliance via Verifiable Credentials | Gaia-X Trust Framework 3.0, IDSA |
| Vertrauen | Mandantentrennung, sektorisolierter Betrieb | DSGVO Art. 32, KRITIS-DachG |
9. Industrieleitfäden & Best Practicesfeedback
Die folgenden Leitfäden bieten praxisnahe Orientierung bei der Umsetzung der oben genannten Anforderungen. Sie sind als Implementierungshilfen zu verstehen, nicht als verbindliche Vorgaben.
9.1 Microsoft Cloud for Sovereigntyfeedback
Microsoft Cloud for Sovereignty strukturiert Souveränität entlang der drei Säulen (Daten-, Betriebs- und technologische Kontrolle) und bietet:
- Sovereign Landing Zone: Open-Source-Referenzimplementierung (Bicep/Terraform) für regulierungskonforme Azure-Umgebungen mit Policy-Guardrails nach DSGVO und BSI
- Abgestufte Souveränitätsniveaus (Transparent, Policy, Baseline) inklusive Customer-Managed Keys und Confidential Computing
9.2 ENISA – Cloud Security & EUCSfeedback
Die ENISA (EU-Agentur für Cybersicherheit) publiziert regelmäßig Cloud-Sicherheitsempfehlungen und treibt den EUCS voran, das zukünftige, EU-weit harmonisierte Cloud-Zertifizierungsschema, das BSI C5 als nationalen Vorläufer ergänzt und mittelfristig ablösen soll.
9.3 Google Cloud Sovereignty Solutionsfeedback
Google Cloud Sovereignty Solutions bieten u.a. Sovereign Controls by T-Systems für Deutschland, Assured Workloads und Customer-Managed Encryption Keys (CMEK) als direkten Wettbewerber zum Microsoft-Ansatz und zum SCS.
9.4 AWS European Sovereign Cloudfeedback
AWS European Sovereign Cloud ist Amazons Antwort auf die europäischen Souveränitätsanforderungen: dedizierte Infrastruktur in der EU, operiert ausschließlich durch EU-Mitarbeiter, kein Zugriff durch US-Strukturen.
10. Ableitungen für EAM-Entscheidungenfeedback
Aus diesem Souveränitätsrahmen ergeben sich folgende zwingende Anforderungen für alle Architekturentscheidungen im D-Stack-Umfeld:
- Hosting-Pflicht: EAM-Portal und MDD-Dienste sind ausschließlich auf BSI C5 Typ-2 zertifizierter EU/DE-Infrastruktur zu betreiben. Drittstaat-Zugriff ist technisch auszuschließen.
- Schlüsselhoheit by Design: Customer Managed Keys (CMK) sind bereits in der Architektur vorzusehen. Das Schlüsselmaterial liegt nie beim Softwarelieferanten.
- Exit-Strategie ist Pflicht: Jedes EAM-System muss ab Projektstart einen dokumentierten Ausstiegsplan mit standardisierten, offenen Exportformaten (ArchiMate, BPMN, TOGAF) vorweisen.
- MDD-Listung als Ziel: Neue Dienste und SaaS-Produkte sind von Beginn an auf das DVC-Reifegradmodell auszurichten, um die MDD-Listungsvoraussetzungen zu erfüllen.
- Open Source First: Vor Beschaffung proprietärer Lösungen ist der ZenDiS/OpenCoDE-Katalog zu prüfen. Der Nachweis ist in der Beschaffungsdokumentation festzuhalten.
- Policy as Code: Datenzugriff und Nutzungsrechte sind als maschinenlesbare Policies (ODRL / IDS Policy Language) auszudrücken und technisch durchzusetzen, nicht allein durch vertragliche Regelungen.
Weiterführende Seitenfeedback
- Digital Sovereignty Maturity Model – Reifegradmodell mit SEAL-Stufen (0–4) und Self-Assessment-Checkliste
- Anwendungsfälle für den öffentlichen Sektor (Bund & Länder) – Konkrete Souveränitäts-Use-Cases für EAM-Portal, MDD, NOOTS, BundID, DVC und weitere Systeme