Abb.: Zusammenhang Interoperabilitätsverordnung und Digital Omnibus, eigene Darstellung (CC-BY-SA-4.0)

1. DIREKTE VERBINDUNGEN

1.1 Keine explizite Konsolidierung

Aspekt

Details

Omnibus-Konsolidierung

Interoperabilitätsverordnung 2024/903 wird NICHT im Omnibus konsolidiert

Grund

Zu neu (März 2024), eigenständiger Regelungsbereich (öffentlicher Sektor-fokussiert)

Status

Beide Rechtsakte gelten parallel und unabhängig

ABER: Indirekte Berührungspunkte und gegenseitige Ergänzung bestehen.

2. THEMATISCHE ÜBERSCHNEIDUNGEN

2.1 Single-Entry Point (SEP) und Interoperabilität

Digital Omnibus (NIS-2 Art. 23a)

• Single-Entry Point für Incident-Meldungen (DSGVO, NIS-2, DORA, eIDAS, CER)
• Betrieben von ENISA
• Technische Interoperabilität erforderlich: JSON-Schema, REST API, automatisches Routing

Interoperabilitätsverordnung 2024/903

• Verpflichtende Interoperabilitätsbewertung für neue IT-Systeme des öffentlichen Sektors
• Europäischer Interoperabilitätsrahmen (EIF) als Referenz
• Standards für rechtliche, organisatorische, semantische und technische Interoperabilität

VERBINDUNG:

SEP (Omnibus) MUSS interoperabel sein mit:
├─ Nationalen CSIRT-Systemen (NIS-2)
├─ Datenschutzbehörden-IT (DSGVO)
├─ Finanzaufsichts-IT (DORA)
└─ Vertrauensdienste-IT (eIDAS)

→ Interoperabilitätsverordnung 2024/903 liefert Rahmen:

   - EIF-Standards für SEP-Design

   - Interoperabilitätsbewertung BEVOR SEP live geht

   - Portal für interoperables Europa: SEP-Dokumentation

PRAKTISCHE KONSEQUENZ: ENISA sollte vor SEP Go-Live (T+18 Omnibus) eine Interoperabilitätsbewertung gemäß Verordnung 2024/903 durchführen:

1. Rechtliche Dimension: Sind Meldepflichten harmonisiert?
2. Organisatorische Dimension: Sind Zuständigkeiten klar?
3. Semantische Dimension: Ist JSON-Schema verständlich für alle Behörden?
4. Technische Dimension: Funktioniert API-Integration mit nationalen Systemen?

2.2 Datenportabilität und Open Data

Digital Omnibus (Data Act Art. 23-30)

• Cloud-Wechsel erleichtert
• Maschinenlesbare Formate (JSON, CSV)
• Open Data Directive konsolidiert (Art. 6-7)

Interoperabilitätsverordnung 2024/903

• Open-Source-Prinzip: Öffentliche Stellen sollen quelloffene Lösungen vorrangig nutzen
• Weitergabe von Interoperabilitätslösungen (Quellcodes, Spezifikationen) zwischen Behörden
• Portal für interoperables Europa: Zentrale Plattform für Lösungen

VERBINDUNG:

Data Act fordert maschinenlesbare Formate
↓
Interoperabilitätsverordnung definiert Standards
↓
EIF (Europäischer Interoperabilitätsrahmen)
↓
Konkrete Spezifikationen: DCAT-AP, JSON-Schema, etc.

BEISPIEL - High-Value Datasets:

• Data Act Art. 7: Öffentliche Stellen müssen High-Value Datasets (Geodaten, Mobilität, Statistik) kostenlos und maschinenlesbar bereitstellen
• Interoperabilitätsverordnung: EIF definiert, WELCHE Formate konkret (z.B. GeoJSON für Geodaten, GTFS für Mobilitätsdaten)

2.3 DSGVO-Kohärenz

Digital Omnibus (DSGVO Art. 88a-88c)

• Cookie-Integration
• KI-Entwicklung
• Informationspflichten vereinfacht

Interoperabilitätsverordnung 2024/903

• Reallabore: Dürfen personenbezogene Daten für andere Zwecke verarbeiten (unter strengen Bedingungen)
• DSGVO-Compliance: Verordnung (EU) 2016/679 und (EU) 2018/1725 müssen eingehalten werden

VERBINDUNG:

Interoperabilitäts-Reallabore (Art. 11/12 der VO 2024/903)
↓
Verarbeiten personenbezogene Daten für Innovation
↓
MÜSSEN DSGVO einhalten (in der durch Omnibus geänderten Fassung)
↓
Insbesondere:

  - Art. 9(2)(k) DSGVO (besondere Kategorien für Forschung)

  - Art. 88c DSGVO (KI-Entwicklung als berechtigtes Interesse)

  - Art. 35 DSGVO (DSFA-Listen, neu harmonisiert)

PRAKTISCHE KONSEQUENZ: Ein Interoperabilitäts-Reallabor (z.B. für grenzüberschreitenden Gesundheitsdatenaustausch) kann:

1. Gesundheitsdaten für Interoperabilitätstests nutzen (Verordnung 2024/903 erlaubt)
2. OHNE Einzeleinwilligung, wenn "unverhältnismäßiger Aufwand" (DSGVO Art. 9(2)(k) durch Omnibus)
3. ABER mit strengen Safeguards (DPIA, Pseudonymisierung, etc.)

3. GOVERNANCE-ÜBERSCHNEIDUNGEN

3.1 EU-Agenturen

EU-Agentur

Rolle im Omnibus

Rolle in Verordnung 2024/903

ENISA

Betreibt Single-Entry Point (NIS-2 Art. 23a)

Keine direkte Rolle, ABER: SEP muss interoperabel sein → nutzt EIF

EDPB

Erstellt DSGVO-Leitlinien (Art. 35, 33, 41a)

Keine direkte Rolle

Kommission

Erlässt Durchführungsrechtsakte (DSGVO, Data Act)

Betreibt Portal für interoperables Europa

KOORDINATIONSBEDARF:

• Kommission sollte sicherstellen, dass Portal für interoperables Europa auch SEP-Dokumentation enthält
• ENISA sollte bei Beirat für ein interoperables Europa mitarbeiten (Cybersecurity-Perspektive)

3.2 Nationale Behörden

Omnibus

• Deutschland: BfDI, LfDI, BSI, Bundeskartellamt, Landesmedienanstalten
• Rheinland-Pfalz: LfDI RLP, Medienanstalt RLP

Interoperabilitätsverordnung 2024/903

• Jeder Mitgliedstaat muss zuständige Behörden und einheitliche Anlaufstelle benennen (ab 12. Januar 2025)
• In Deutschland Bundesministerium für Digitales und Staatsmodernisierung [BMDS](Bundesministerium für Digitales und Staatsmodernisierung )

ÜBERSCHNEIDUNG:

LfDI RLP (Omnibus-Rolle):

├─ Empfängt DSGVO-Meldungen über SEP
├─ Cookie-Aufsicht (Art. 88a-88b)
└─ KI-Compliance (Art. 88c)

LfDI RLP (Interoperabilitäts-Rolle):

├─ Könnte Teil der nationalen Anlaufstelle sein
├─ Muss Interoperabilitätsbewertung durchführen, wenn:
│  └─ RLP-spezifische IT-Systeme eingeführt werden, die
│     grenzüberschreitende DSGVO-Meldungen betreffen
└─ Beispiel: RLP entwickelt eigenes "Datenpannen-Management-System"

   → Muss interoperabel mit SEP sein

   → Interoperabilitätsbewertung erforderlich

4. ZEITLICHE WECHSELWIRKUNGEN

4.1 Parallelität der Anwendung

Zeitpunkt

Omnibus

Interoperabilitätsverordnung 2024/903

März 2024

Noch nicht vorgeschlagen

Verordnung tritt in Kraft

Jan 2025

Noch nicht vorgeschlagen

Interoperabilitätsbewertung wird verpflichtend

Nov 2025

Kommissionsvorschlag veröffentlicht

Läuft bereits (Bewertungen laufen)

Jan 2027

Voraussichtlich Inkrafttreten (T+0)

Läuft seit 2 Jahren

Juli 2028

SEP geht live (T+18)

KRITISCH: SEP muss Interoperabilitätsbewertung bestanden haben!

ZEITLICHE ABHÄNGIGKEIT:

TIMELINE-KONFLIKT:

T-21 (März 2024): Interoperabilitätsverordnung tritt in Kraft

T-12 (Jan 2025): Interoperabilitätsbewertung verpflichtend

T+0 (ab Jan 2027): Omnibus tritt in Kraft
↓
[ENISA beginnt SEP-Entwicklung]
↓
T+12 (ab Jan 2028): ENISA sollte Interoperabilitätsbewertung für SEP durchführen
↓
FRAGE: Hat ENISA Interoperabilitätsbewertung gemacht?
↓
T+18 (ab Juli 2028): SEP MUSS live gehen (Omnibus-Deadline)
↓
PROBLEM: Wenn Interoperabilitätsbewertung negativ

                  → SEP nicht interoperabel

                  → Go-Live gefährdet!

EMPFEHLUNG: Omnibus sollte explizit verlangen, dass SEP vor Go-Live eine Interoperabilitätsbewertung gemäß Verordnung 2024/903 besteht.

AMENDMENT-VORSCHLAG für NIS-2 Art. 23a Omnibus:

"Artikel 23a - Single-Entry Point

(4a) Die Agentur der Europäischen Union für Cybersicherheit (ENISA) führt

vor Inbetriebnahme des Single-Entry Point eine Interoperabilitätsbewertung

gemäß Artikel 12 der Verordnung (EU) 2024/903 durch. Die Bewertung umfasst

alle vier Dimensionen der Interoperabilität (rechtlich, organisatorisch,

semantisch, technisch) und wird dem Beirat für ein interoperables Europa

zur Stellungnahme vorgelegt.

(4b) Der Single-Entry Point wird nur in Betrieb genommen, wenn die

Interoperabilitätsbewertung positiv ausgefallen ist und die vom Beirat

empfohlenen Interoperabilitätslösungen berücksichtigt wurden."

5. FEHLENDE KOHÄRENZ (GAP ANALYSIS)

5.1 Keine Lex-Specialis-Hierarchie

PROBLEM:

• Omnibus regelt Verhältnis zu DSA/DMA/AI Act NICHT (Amendment empfohlen: Art. 2(5) Data Act)
• Interoperabilitätsverordnung 2024/903 wird NIRGENDS erwähnt
• Unklar: Was, wenn Interoperabilitätsbewertung WIDERSPRICHT Omnibus-Anforderungen?

BEISPIEL-KONFLIKT:

SZENARIO: Deutschland entwickelt "DSGVO-Meldeplattform 2.0"

Omnibus (NIS-2 Art. 23a):
└─ "Alle Meldungen über SEP"
→ Deutsche Plattform sollte NICHT existieren, nur SEP

Interoperabilitätsverordnung 2024/903:
└─ "Nationale IT-Systeme dürfen existieren, wenn interoperabel"
→ Deutsche Plattform OK, wenn interoperabel mit SEP

FRAGE: Wer hat Vorrang?

LÖSUNG: Omnibus sollte explizit anerkennen:

• Nationale IT-Systeme für Incident-Meldung dürfen ergänzend zu SEP existieren
• ABER: Müssen interoperabel mit SEP sein (gemäß Verordnung 2024/903)
• Interoperabilitätsbewertung VERPFLICHTEND vor Inbetriebnahme

5.2 Keine gemeinsame Leitlinien-Strategie

PROBLEM:

• Omnibus: Kommission/EDPB erstellen Leitlinien (DSGVO, Data Act)
• Interoperabilitätsverordnung: Beirat erstellt EIF
• Keine Koordination zwischen beiden!

BEISPIEL:

DSGVO Art. 33(6) neu (Omnibus):
└─ "Kommission erstellt harmonisiertes Datenpannen-Template"
→ Welches Format? JSON? XML?

EIF (Verordnung 2024/903):
└─ "Beirat empfiehlt Standards für maschinenlesbare Formate"
→ Könnte ANDERE Standards empfehlen als Kommission!

KONFLIKT: Zwei parallele Standard-Entwicklungen

LÖSUNG:

• Verwaltungsabkommen zwischen Kommission und Beirat
• Kommission konsultiert Beirat bei allen IT-bezogenen Leitlinien (SEP, DSFA-Listen, Breach-Templates)
• EIF wird Referenzdokument für Omnibus-Durchführungsrechtsakte

6. SYNERGIEN UND BEST PRACTICES

6.1 Once-Only-Prinzip

Interoperabilitätsverordnung 2024/903

• Fördert "Once-Only"-Prinzip: Bürger/Unternehmen müssen Daten nur EINMAL angeben
• Grenzüberschreitender Datenaustausch zwischen Behörden

Digital Omnibus

• Single-Entry Point = Once-Only für Incident-Meldungen
• Unternehmen melden EINMAL über SEP, statt an 5 verschiedene Behörden

SYNERGIE:

GEMEINSAMES ZIEL: Verwaltungsaufwand reduzieren (insbesondere für KMU)

6.2 Open-Source und digitale Souveränität

Interoperabilitätsverordnung 2024/903

• Art. 28: Öffentliche Stellen sollen quelloffene Lösungen vorrangig nutzen
• Weitergabe von Quellcodes zwischen Behörden

Digital Omnibus (indirekt)

• Keine explizite Open-Source-Pflicht
• ABER: Trade Secret Protection (Data Act Art. 4(8)) schützt vor Drittland-Zugriff
• INTERPRETATION: EU sollte eigene, offene Standards entwickeln statt US-/China-Abhängigkeit

SYNERGIE:

BEISPIEL - SEP:

• ENISA sollte SEP als Open-Source-Projekt entwickeln (GitHub)
• Ermöglicht: Nationale Behörden können Code auditieren (Sicherheit)
• Ermöglicht: Nationale Behörden können eigene Forks betreiben (wenn interoperabel)
• Schützt: Vor Vendor Lock-in (kein Microsoft/AWS/Oracle-Monopol)

7. AUSWIRKUNGEN AUF DEUTSCHLAND UND RHEINLAND-PFALZ

7.1 Bundesebene

Behörde

Omnibus-Rolle

Interoperabilitäts-Rolle

Koordinationsbedarf

BMDS

Koordination NIS-2-Umsetzung

Wahrscheinlich "einheitliche Anlaufstelle" für VO 2024/903

BMDS muss BEIDE Verordnungen koordinieren

BSI

Empfängt NIS-2-Meldungen über SEP

IT-Sicherheit von SEP, könnte Interoperabilitätsbewertung durchführen

BSI-SEP-Integration muss interoperabel sein

BfDI

Cookie-Aufsicht, DSFA-Listen

Könnte Interoperabilitätsbewertung für DSGVO-IT durchführen

BfDI-IT muss interoperabel mit SEP

NEUE AUFGABE FÜR BMDS:

• Nationalen Anlaufstelle - (Nationale Kontaktstelle — Digitalcheck)
• Koordination zwischen:
• Omnibus-Umsetzung (SEP-Integration)
• Interoperabilitätsbewertungen (VO 2024/903)
• EIF-Empfehlungen umsetzen

7.2 Rheinland-Pfalz

LfDI RLP

Aufgabe

Rechtsgrundlage

Interoperabilitätsaspekt

Cookie-Aufsicht

DSGVO Art. 88a-88b (Omnibus)

Wenn RLP eigenes Cookie-Audit-Tool entwickelt → Interoperabilitätsbewertung

SEP-Anbindung

NIS-2 Art. 23a (Omnibus)

API-Integration LfDI RLP ↔ SEP muss EIF-Standards folgen

DSFA-Listen

DSGVO Art. 35 (Omnibus)

EU-harmonisiert, aber RLP-spezifische IT muss interoperabel sein

PRAKTISCHE KONSEQUENZ:

BEISPIEL: LfDI RLP entwickelt "Datenpannen-Dashboard RLP", Meldung

SCHRITT 1: Omnibus-Compliance prüfen
├─ Empfängt Meldungen über SEP?
└─ Speichert 5 Jahre?

SCHRITT 2: Interoperabilitätsbewertung (VO 2024/903)
├─ Rechtlich: Kohärent mit DSGVO Art. 33?
├─ Organisatorisch: Zuständigkeit LfDI RLP klar?
├─ Semantisch: JSON-Schema kompatibel mit SEP?
└─ Technisch: API-Schnittstelle zu SEP funktioniert?

SCHRITT 3: Publikation
├─ Ergebnisse der Bewertung → Portal für interoperables Europa
└─ Übermittlung an Beirat für ein interoperables Europa

SCHRITT 4: Go-Live
└─ NUR wenn Interoperabilitätsbewertung positiv

8. EMPFEHLUNGEN

8.1 Für EU-Gesetzgeber (Omnibus-Amendment)

NEUER ARTIKEL im Omnibus:

"Artikel 11b

Kohärenz mit der Interoperabilitätsverordnung

(1) Bei der Umsetzung dieser Verordnung, insbesondere bei der Entwicklung

des Single-Entry Point gemäß Artikel 23a der Richtlinie (EU) 2022/2555,

ist die Verordnung (EU) 2024/903 über die Interoperabilität des öffentlichen

Sektors zu beachten.

(2) ENISA führt vor Inbetriebnahme des Single-Entry Point eine

Interoperabilitätsbewertung gemäß Artikel 12 der Verordnung (EU) 2024/903

durch. Die Bewertung wird dem Beirat für ein interoperables Europa zur

Stellungnahme vorgelegt.

(3) Die Kommission konsultiert den Beirat für ein interoperables Europa

bei der Entwicklung von Durchführungsrechtsakten zu digitalen Systemen

und maschinenlesbaren Formaten."

8.2 Für ENISA (SEP-Entwicklung)

1. Interoperabilitätsbewertung durchführen (spätestens T+12, Januar 2028)
2. EIF-Standards nutzen (REST API, JSON-Schema, OpenAPI 3.0)
3. Open-Source-Entwicklung (GitHub-Repository für SEP)
4. Beirat konsultieren vor finalen Design-Entscheidungen

8.3 Für Deutschland (BMDS)

1. Nationale Anlaufstelle benennen (falls noch nicht geschehen - Deadline war 12. Jan 2025!)
2. Koordination BMDS ↔ ENISA für SEP-Interoperabilität
3. BSI einbinden in Interoperabilitätsbewertung (Cybersecurity-Aspekt)
4. Leitfaden erstellen für Bundesbehörden: "Omnibus + Interoperabilität"

8.4 Für Rheinland-Pfalz

1. Schulungen LfDI RLP zu Verordnung 2024/903 (zusätzlich zu Omnibus)
2. IT-Strategie aktualisieren: Alle neuen RLP-IT-Systeme müssen interoperabel sein
3. Checkliste erstellen: "Interoperabilitätsbewertung für RLP-Behörden"
4. Budget bereitstellen: EUR 170.000 zusätzlich (siehe 7.3)

9. FAZIT

SYNERGIEN:

1. Once-Only-Prinzip: Beide Verordnungen reduzieren Verwaltungsaufwand
2. Open Source: Interoperabilitätsverordnung fördert, Omnibus profitiert (SEP, Data Act)
3. Digitale Souveränität: Zusammen stärken sie EU-eigene Standards (vs. US/China)

RISIKEN:

1. Zeitliche Koordination: SEP Go-Live (T+18 Omnibus) könnte scheitern, wenn Interoperabilitätsbewertung negativ
2. Fehlende Kohärenz: Keine explizite Verbindung zwischen beiden Rechtsakten
3. Doppelstrukturen: Kommission (Omnibus-Leitlinien) vs. Beirat (EIF) - Koordination fehlt

Kernaussage:

Die EU-Interoperabilitätsverordnung 2024/903 ist das technische Fundament, auf dem der Digital Omnibus aufbaut. Ohne Interoperabilität scheitert der Single-Entry Point. Kohärenz muss aktiv hergestellt werden - durch Amendments, Verwaltungsabkommen und koordinierte Leitlinien-Entwicklung.

Vergleich:

• Interoperabilitätsverordnung 2024/903 = Architektur-Standard (wie ISO-Normen für Bauwesen)
• Digital Omnibus = Konkretes Gebäude (SEP, Data Act, DSGVO-Änderungen)
• Ohne Standard → Gebäude instabil
• Ohne Koordination → Gebäude passt nicht ins Stadtbild (EU-Ökosystem)