Anwendungsfälle für den öffentlichen Sektor – Bund & Länderfeedback
Erstellt am: 20. März 2026 | Autor: Matthias, Enrico (GitLab)
Dieses Dokument übersetzt die Vorgaben der Hauptseite Digitale Souveränität und die Stufen des Digital Sovereignty Maturity Model in konkrete Anwendungsfälle für den öffentlichen Sektor. Jeder Anwendungsfall wird einer SEAL-Stufe zugeordnet und mit den relevanten Regulierungsquellen verknüpft.
1. Systematik der Anwendungsfällefeedback
Verwaltungsebenen und Souveränitätsbedarffeedback
Die deutsche Verwaltungslandschaft ist föderal strukturiert. Der Souveränitätsbedarf variiert erheblich zwischen den Ebenen; er steigt mit der Sensibilität der verarbeiteten Daten und der strategischen Bedeutung der IT-Systeme. Das folgende Diagramm zeigt die drei Verwaltungsebenen mit ihren typischen Akteuren und der jeweils geforderten Mindest-SEAL-Stufe.
Lesehinweis: Auf Bundesebene verarbeiten Ministerien und Behörden hochsensible Strategie- und Sicherheitsdaten, weshalb mindestens SEAL-3 (oft SEAL-4) gilt. Länder bewegen sich je nach Ressort zwischen SEAL-2 und SEAL-3; sicherheitsrelevante Bereiche wie Polizei und Justiz erfordern SEAL-4. Kommunen können für öffentliche Dienste mit SEAL-1 einsteigen, benötigen aber für Fachanwendungen mit Bürgerdaten mindestens SEAL-2.
Kategorisierungfeedback
Alle Anwendungsfälle werden nach zwei Achsen eingeordnet:
| Achse | Ausprägungen |
|---|---|
| Verwaltungsebene | Bund · Land · Kommune · Ebenen-übergreifend |
| Systemtyp | Fachanwendung · Plattform-Dienst · Infrastruktur · Querschnittsdienst |
2. Anwendungsfälle auf Bundesebenefeedback
Die Bundesebene umfasst Ministerien, nachgeordnete Behörden und bundeseigene Unternehmen, die strategische und sicherheitsrelevante IT-Systeme betreiben. Aufgrund der hohen Datenklassifikation und der geopolitischen Exposition gilt hier SEAL-3 als Regelstandard; für Identitäts- und Verschlusssachensysteme ist SEAL-4 (vollständige Autonomie) zwingend. Die folgenden fünf Anwendungsfälle decken die zentralen Handlungsfelder des Bundes ab.
AF-B1: EAM-Portal der Bundesverwaltungfeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Zentrales Enterprise Architecture Management für die Bundesverwaltung: IT-Landkarten, Capability-Modelle, strategische Zielarchitekturen, Technologie-Radar |
| Datenklassifikation | Hochsensibel: strategische IT-Planungen, Abhängigkeitsanalysen, Sicherheitsarchitekturen |
| SEAL-Minimum | SEAL-3 |
| Verwaltungsebene | Bund (BMDS, ITZBund) |
| Systemtyp | Fachanwendung (SaaS) |
Souveränitätsanforderungen:
- Datensouveränität: Customer Managed Keys über HSM/KMS beim ITZBund; BSI TR-02102-konforme Verschlüsselung; striktes EU/DE-Hosting
- Betriebssouveränität: BSI C5 Typ-2 Testat; NIS2-Meldeprozesse; unveränderliche Audit Logs
- Technologische Unabhängigkeit: Vollständiger Export in ArchiMate/BPMN/TOGAF; Self-Service-Export ohne Anbietermitwirkung; dokumentierte Migrationsstrategie
- Regulatorische Basis: EU Data Act (Exit-Pflicht), DVC-Reifegradmodell, IT-PLR Beschluss 17.3.2026
AF-B2: Marktplatz Deutschland Digital (MDD)feedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Zentraler Beschaffungsmarktplatz für Cloud-Services der öffentlichen Verwaltung; Katalog, Bestellprozesse, Vertragsmanagement, Abrechnungsintegration |
| Datenklassifikation | Hoch: Vertragsdaten, Transaktionsmetadaten, Preismodelle, Nutzungsstatistiken |
| SEAL-Minimum | SEAL-3 |
| Verwaltungsebene | Bund / Ebenen-übergreifend (FITKO, govdigital) |
| Systemtyp | Plattform-Dienst |
Souveränitätsanforderungen:
- Daten: Dezentrale Datenhaltung (Eclipse EDC-Prinzip „Data Stays at Source"); automatisierte Policy-Durchsetzung (ODRL); EU/DE-Datenresidenz für Transaktionsdaten
- Betrieb: BSI C5 Typ-2 für die Plattform-Infrastruktur; DVC-Reifegradmodell als Listungsvoraussetzung für alle Anbieter
- Technologie: Gaia-X Verifiable Credentials als Trust Anchor; föderale IAM-Anbindung (BundID); Open-Source-Kernkomponenten
- Regulatorische Basis: DVC-Strategie (IT-PLR 2025/15), MDD Produktivbetrieb (FITKO)
AF-B3: NOOTS – Nationales Once-Only Technical Systemfeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Technisches System für den behördenübergreifenden Datenabruf nach dem Once-Only-Prinzip: Registerabruf mit Einwilligung, Datenvermittlung, Nachweisabruf |
| Datenklassifikation | Sehr hoch: personenbezogene Registerdaten (Meldedaten, Steuerdaten, KFZ-Register) |
| SEAL-Minimum | SEAL-3 (Kernsystem), tendenz SEAL-4 für Registerschnittstellen |
| Verwaltungsebene | Bund (ITZBund) / Ebenen-übergreifend |
| Systemtyp | Plattform-Dienst (PaaS) |
Souveränitätsanforderungen:
- Daten: Strikt dezentrale Architektur, Registerdaten verlassen die Quellregister nie permanent; Verschlüsselung End-to-End; kundengesteuerte Schlüssel für jedes Register
- Betrieb: Betrieb durch ITZBund auf BSI C5 Typ-2 Infrastruktur; vollständige Auditierbarkeit jedes Datenabrufs (wer, wann, welches Datum, Rechtsgrundlage)
- Technologie: Offene Protokollschicht (Eclipse EDC / Dataspace-Standards); keine zentrale Datenkopie; Open-Source-Referenzimplementierung
- Regulatorische Basis: Registermodernisierungsgesetz (RegMoG), DSGVO, IT-PLR Beschluss 17.3.2026
AF-B4: BundID & föderales Identitätsmanagementfeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Zentrales Bürgerkonto (BundID) und föderiertes IAM für Verwaltungsmitarbeiter; Authentifizierung, Autorisierung, eID-Integration, EUDI-Wallet-Anbindung |
| Datenklassifikation | Sehr hoch: Identitätsdaten, Authentifizierungstokens, biometrische Referenzdaten |
| SEAL-Minimum | SEAL-4 |
| Verwaltungsebene | Bund (ITZBund, Bundesdruckerei) |
| Systemtyp | Querschnittsdienst |
Souveränitätsanforderungen:
- Daten: Keinerlei Anbieter-Zugriff auf Identitätsdaten; vollständige Schlüsselhoheit bei der Bundesdruckerei (PKI, QES); keine Drittstaatsverarbeitung
- Betrieb: Souveräne Infrastruktur (eigene Rechenzentren des ITZBund); kein Remote-Zugang durch externe Anbieter; BSI-Zulassung für VS-NfD
- Technologie: eIDAS 2.0 (EUDI Wallet) als europäische Schnittstelle; Open-Source-Komponenten (AusweisApp); vollständig autonomer Betrieb
- Regulatorische Basis: eIDAS 2.0 (EU 2024/1183), OZG 2.0, IT-PLR Beschlüsse
AF-B5: Souveräne Bürokommunikation (openDesk / Sovereign Workplace)feedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Open-Source-basierte Produktivitätssuite für die Bundesverwaltung: E-Mail, Kalender, Videokonferenz, Dokumentenbearbeitung, Messenger |
| Datenklassifikation | Hoch: interne Kommunikation, Dokumente, Kalenderdaten |
| SEAL-Minimum | SEAL-3 |
| Verwaltungsebene | Bund (ZenDiS, ITZBund) |
| Systemtyp | Fachanwendung (SaaS) |
Souveränitätsanforderungen:
- Daten: EU/DE-Hosting; Ende-zu-Ende-Verschlüsselung für Messaging; Customer Managed Keys für gespeicherte Dokumente
- Betrieb: BSI C5 Typ-2 für die Hosting-Infrastruktur; NIS2-konforme Meldeprozesse
- Technologie: Vollständig Open Source (ZenDiS/OpenCoDE); kein Vendor-Lock-in; Community-getriebene Weiterentwicklung; SCS-kompatible Infrastruktur
- Regulatorische Basis: IT-PLR Beschluss 2021/09 (Strategie Digitale Souveränität), DVC-Strategie
3. Anwendungsfälle auf Landesebenefeedback
Die 16 Länder betreiben eigene IT-Infrastrukturen und Fachverfahren, häufig über spezialisierte Landes-IT-Dienstleister wie Dataport, AKDB oder ekom21. Der Souveränitätsbedarf variiert stark zwischen den Ressorts: Während allgemeine Verwaltungsanwendungen mit SEAL-2 auskommen, erfordern polizeiliche und justizielle Systeme die höchste Stufe SEAL-4. Die folgenden drei Anwendungsfälle zeigen das Spektrum von IT-Portfoliomanagement bis hin zu hochsensiblen Vorgangsbearbeitungssystemen.
AF-L1: Landes-EAM und IT-Portfoliomanagementfeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Enterprise Architecture Management auf Landesebene: IT-Landkarten der Landesverwaltung, Anwendungsportfolio, Technologie-Lifecycle-Management |
| Datenklassifikation | Hoch: Landesweite IT-Strategie, Abhängigkeitsanalysen, Investitionspläne |
| SEAL-Minimum | SEAL-2 (mit Tendenz zu SEAL-3 bei sicherheitsrelevanten Ressorts) |
| Verwaltungsebene | Land |
| Systemtyp | Fachanwendung (SaaS) |
Souveränitätsanforderungen:
- Daten: EU/DE-Datenresidenz vertraglich gesichert; AVV nach DSGVO Art. 28; bei sicherheitsrelevanten Ressorts (Polizei, Justiz): Customer Managed Keys
- Betrieb: Mindestens BSI C5 Typ-1; ISMS (ISO 27001); Hosting bevorzugt beim Landes-IT-Dienstleister (Dataport, AKDB, ekom21)
- Technologie: Exit-Plan dokumentiert; Export in offenen Formaten; bevorzugt Open-Source-Lösungen aus OpenCoDE
- Regulatorische Basis: Landesdatenschutzgesetze (LDSG), IT-PLR Beschluss 17.3.2026, jeweiliges Landes-E-Government-Gesetz
AF-L2: Landesweite Fachverfahren (z.B. Meldewesen, KFZ-Zulassung)feedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | EfA-Fachanwendungen für den kommunalen Vollzug: z.B. elektronisches Meldewesen, KFZ-Zulassung, Gewerberegister; mandantenfähig für alle Kommunen eines Landes |
| Datenklassifikation | Hoch bis sehr hoch: personenbezogene Daten (Meldedaten, Fahrzeughalter) |
| SEAL-Minimum | SEAL-3 |
| Verwaltungsebene | Land / Kommune (EfA-Prinzip) |
| Systemtyp | Fachanwendung (SaaS), mandantenfähig |
Souveränitätsanforderungen:
- Daten: Mandantentrennung auf Infrastrukturebene; Customer Managed Keys pro Mandant/Kommune; DSGVO-Compliance mit klarem Auftragsverarbeitungsmodell
- Betrieb: BSI C5 Typ-2 für den Hosting-Dienstleister; NIS2-Registrierung (Fachanwendung mit >100.000 Nutzern); Betrieb durch kommunale IT-Dienstleister (govdigital-Ökosystem)
- Technologie: DVC-Reifegradmodell als Ziel-Nachweis; Integration in NOOTS für Registerabrufe; XÖV-Standards für Datenformate
- Regulatorische Basis: OZG 2.0, RegMoG, EfA-Prinzip (IT-PLR)
AF-L3: Polizeiliche Vorgangsbearbeitungssystemefeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Vorgangsbearbeitungssysteme (VBS) der Landespolizeien: Ermittlungsakten, Fahndungsdaten, Einsatzprotokolle, Asservatenverwaltung |
| Datenklassifikation | Sehr hoch bis VS-NfD: Ermittlungsdaten, personenbezogene Verdächtigendaten, nachrichtendienstlich relevante Informationen |
| SEAL-Minimum | SEAL-4 |
| Verwaltungsebene | Land (Innenministerien) |
| Systemtyp | Fachanwendung (On-Premise oder Sovereign Cloud) |
Souveränitätsanforderungen:
- Daten: Keinerlei Anbieter-Zugriff; eigene PKI für Verschlüsselung; Air-Gap oder strikt segmentierte Netzwerke; keine Cloud-Dienste aus Drittstaaten
- Betrieb: Vollständig autonomer Betrieb durch Landes-IT; BSI IT-Grundschutz (Kern-Absicherung); BSI-Zulassung für VS-NfD
- Technologie: Quellcode verfügbar (Open Source oder Escrow); betreiberseitig kompilierbar; keine Abhängigkeit von nicht-EU-lizenzierten Kernkomponenten
- Regulatorische Basis: Polizeigesetze der Länder, KRITIS-DachG, Verschlusssachenanweisung (VSA)
4. Ebenen-übergreifende Anwendungsfällefeedback
Die folgenden Anwendungsfälle betreffen alle Verwaltungsebenen gleichzeitig und bilden das föderale Rückgrat der digitalen Verwaltungstransformation. Ob Cloud-Infrastruktur, Datenräume oder KI-Dienste, sie verbinden Bund, Länder und Kommunen technisch und regulatorisch. Gerade weil hier unterschiedliche Verwaltungsebenen mit verschiedenen SEAL-Anforderungen aufeinandertreffen, sind klare Schnittstellen und durchgängige Standards besonders kritisch.
AF-Ü1: Deutsche Verwaltungscloud (DVC) – Infrastrukturebenefeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Föderierte Cloud-Infrastruktur für alle Verwaltungsebenen: IaaS/CaaS auf Basis Sovereign Cloud Stack (SCS); DVC-Rechenzentrumsverbund der kommunalen und Bundes-IT-Dienstleister |
| Datenklassifikation | Variabel (abhängig von der gehosteten Anwendung) |
| SEAL-Minimum | SEAL-3 (Infrastruktur selbst), SEAL-2 bis SEAL-4 für gehostete Workloads |
| Verwaltungsebene | Ebenen-übergreifend |
| Systemtyp | Infrastruktur (IaaS/CaaS) |
Souveränitätsanforderungen:
- Daten: Garantierte EU/DE-Datenresidenz auf Infrastrukturebene; technische Isolation der Mandanten (Kubernetes Namespaces + Network Policies reichen nicht; dedizierte Cluster oder Hardware-Isolation für VS-NfD)
- Betrieb: Alle DVC-Betreiber müssen BSI C5 Typ-2 nachweisen; NIS2-Registrierung als kritische Einrichtung
- Technologie: SCS als Open-Source-Referenzimplementierung; Gaia-X-kompatibel; vollständige Portabilität zwischen DVC-Betreibern; OpenCoDE-zertifizierte Basis-Images
- Regulatorische Basis: DVC-Strategie (IT-PLR 2025/15), IT-PLR Beschluss 17.3.2026
AF-Ü2: Föderierte Datenräume (Data Spaces)feedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | Souveräne Datenräume für den Austausch zwischen Bund, Ländern und Kommunen: z.B. Geodaten, Umweltdaten, Mobilitätsdaten, Gesundheitsdaten (Forschung) |
| Datenklassifikation | Variabel: offene Daten bis personenbezogene Gesundheitsdaten |
| SEAL-Minimum | SEAL-2 (offene Daten) bis SEAL-3 (personenbezogene Daten) |
| Verwaltungsebene | Ebenen-übergreifend |
| Systemtyp | Plattform-Dienst |
Souveränitätsanforderungen:
- Daten: Dezentrale Datenhaltung (Data Stays at Source); keine zentrale Datenkopie; maschinenlesbare Nutzungsverträge (ODRL)
- Betrieb: Gaia-X Verifiable Credentials für alle Teilnehmer; automatisierte Policy-Durchsetzung; Audit-Trail für jeden Datenabruf
- Technologie: Eclipse Dataspace Connector (EDC) als Referenzimplementierung; IDS-RAM als Architekturstandard; Interoperabilität mit europäischen Data Spaces (z.B. European Health Data Space)
- Regulatorische Basis: EU Data Governance Act (EU 2022/868), EU Data Act (EU 2023/2854)
AF-Ü3: KI-Dienste für die Verwaltungfeedback
| Eigenschaft | Ausprägung |
|---|---|
| Beschreibung | KI-basierte Dienste für die öffentliche Verwaltung: Dokumentenanalyse, automatisierte Bescheidprüfung, Chatbots für Bürgeranfragen, Anomalieerkennung in Registerdaten |
| Datenklassifikation | Variabel bis sehr hoch (abhängig von Trainingsdaten und Anwendungskontext) |
| SEAL-Minimum | SEAL-3 (bei personenbezogenen Daten oder Hochrisiko-KI) |
| Verwaltungsebene | Bund / Land / Ebenen-übergreifend |
| Systemtyp | Querschnittsdienst (PaaS/SaaS) |
Souveränitätsanforderungen:
- Daten: Trainingsdaten und Inferenzdaten verbleiben auf EU/DE-Infrastruktur; kein Transfer an nicht-EU-Anbieter; Customer Managed Keys für Modell-Artefakte
- Betrieb: Transparenz über Modellentscheidungen (Explainability); EU AI Act-Konformität: Risikobewertung, Dokumentation, menschliche Aufsicht bei Hochrisiko-KI
- Technologie: Open-Source-Modelle bevorzugt (z.B. aus OpenCoDE oder Hugging Face-kompatibel); keine proprietäre API-Abhängigkeit (kein Vendor-Lock-in bei GPT-4 o.ä.); SBOM für KI-Pipelines nach CRA
- Regulatorische Basis: EU AI Act (EU 2024/1689), DSGVO (Art. 22 automatisierte Einzelentscheidungen)
5. Zusammenfassung: Anwendungsfall-Matrixfeedback
Die folgende Matrix bietet eine kompakte Gegenüberstellung aller elf Anwendungsfälle nach SEAL-Minimum, Schlüsselhoheit, BSI-C5-Anforderung und Open-Source-Grad. Sie dient als Schnellreferenz für Architektur- und Beschaffungsentscheidungen und zeigt auf einen Blick, welche Souveränitätskriterien für welchen Systemtyp gelten.
| ID | Anwendungsfall | Ebene | SEAL-Min. | Schlüsselhoheit | BSI C5 | Open Source |
|---|---|---|---|---|---|---|
| AF-B1 | EAM-Portal Bund | Bund | 3 | CMK (HSM) | Typ-2 | Bevorzugt |
| AF-B2 | MDD-Marktplatz | Bund/Übergreifend | 3 | CMK | Typ-2 | Kernkomponenten |
| AF-B3 | NOOTS | Bund/Übergreifend | 3–4 | CMK pro Register | Typ-2 | Referenz-Impl. |
| AF-B4 | BundID / IAM | Bund | 4 | Eigene PKI | BSI-Zulassung | AusweisApp: ja |
| AF-B5 | openDesk | Bund | 3 | CMK | Typ-2 | Vollständig |
| AF-L1 | Landes-EAM | Land | 2–3 | AVV / CMK bei Polizei/Justiz | Typ-1/Typ-2 | Bevorzugt |
| AF-L2 | EfA-Fachverfahren | Land/Kommune | 3 | CMK pro Mandant | Typ-2 | Empfohlen |
| AF-L3 | Polizei-VBS | Land | 4 | Eigene PKI | BSI-Zulassung | Escrow/Open Source |
| AF-Ü1 | DVC-Infrastruktur | Übergreifend | 3 | Plattform-CMK | Typ-2 | SCS (vollständig) |
| AF-Ü2 | Data Spaces | Übergreifend | 2–3 | Je nach Datenart | Typ-1/Typ-2 | EDC (vollständig) |
| AF-Ü3 | KI-Dienste | Übergreifend | 3 | CMK für Modelle | Typ-2 | Bevorzugt |
6. Handlungsempfehlungen nach Verwaltungsebenefeedback
Aus den konkreten Anwendungsfällen lassen sich für jede Verwaltungsebene praxisnahe Mindeststandards ableiten. Die folgenden Empfehlungen priorisieren nach Dringlichkeit und Umsetzbarkeit; sie gelten sowohl für neue Beschaffungen als auch für die Migration bestehender Systeme.
Bundfeedback
- SEAL-3 als Standard: Alle neuen Bundesanwendungen sind mindestens auf SEAL-3 auszulegen (CMK, BSI C5 Typ-2, vollständige Exit-Strategie)
- SEAL-4 für Identität und VS-NfD: BundID, eID-Infrastruktur und VS-NfD-Systeme erfordern SEAL-4 (vollständige Autonomie)
- MDD-Listung ab Tag 1: Neue Bundesdienstleistungen sind so zu konzipieren, dass sie das DVC-Reifegradmodell vollständig erfüllen
Länderfeedback
- SEAL-2 als Mindeststandard: Alle Landesanwendungen müssen mindestens SEAL-2 erfüllen (vertragliche Kontrolle, ISMS, Exit-Plan)
- SEAL-3 für sensible Ressorts: Polizei, Justiz, Finanzverwaltung und Fachanwendungen mit personenbezogenen Daten benötigen SEAL-3
- Landes-IT-Dienstleister als Betreiber: Bevorzugter Betrieb bei Dataport, AKDB, ekom21 oder vergleichbaren öffentlichen IT-Dienstleistern
Kommunenfeedback
- SEAL-1 als Einstieg: Öffentliche Informationsportale und Open-Data-Angebote können mit SEAL-1 betrieben werden
- SEAL-2 für Fachverfahren: Alle kommunalen Fachanwendungen mit Bürgerdaten erfordern mindestens SEAL-2
- EfA nutzen: Bevorzugt EfA-Dienste (Einer für Alle) nutzen, die bereits auf SEAL-3 zertifiziert sind, statt eigene Insellösungen zu betreiben
7. Weiterführende Seitenfeedback
- Digital Sovereignty Maturity Model – Detailliertes Reifegradmodell mit Self-Assessment-Checkliste
- Digitale Souveränität – Vorgaben und Kriterien (Hauptseite)
- Sicherheit und Compliance
- Gesetzlicher und organisatorischer Rahmen