Cybersicherheit im EHDS: Sicherheits- und Protokollierungsanforderungen, Vorkommnis-Meldungen und die Brücken zu CRA und NIS2

Problem in der Praxis

Die häufigste Fehlzuordnung in der Praxis ist, die Sicherheitsanforderungen des Anhangs II als Betreiberpflichten eines Krankenhauses zu lesen. Das gibt der Text nicht her: Die grundlegenden Anforderungen adressieren die harmonisierten Softwarekomponenten über die Herstellerpflichten des Art. 30 Abs. 1. Was ein Betreiber davon merkt, ist mittelbar: Er beschafft künftig Systeme, die Identifizierung, Authentifizierung und patientenbezogene Zugriffsprotokollierung als Produkteigenschaft mitbringen müssen, und seine eigenen Sicherheitspflichten laufen weiter über die bestehenden Regime (Art. 32 DSGVO, NIS2-Umsetzung, deutsche Sektorpflichten wie Paragraf 391 SGB V und B3S im health-Track).

Die zweite Praxisfrage ist die Meldewege-Kollision. Ein Sicherheitsvorfall bei einem EHR-System kann gleichzeitig eine Vorkommnis-Meldung des Herstellers nach Art. 44 Abs. 7, eine Meldung nach der NIS2-Umsetzung des betroffenen Betreibers oder Herstellers und eine Datenschutz-Meldung nach Art. 33 DSGVO auslösen. Die Verordnung entschärft das nicht durch Zusammenführung, sondern stellt die Wege ausdrücklich nebeneinander (Art. 44 Abs. 7: "unbeschadet der Pflicht zur Meldung von Sicherheitsvorfällen gemäß der Richtlinie (EU) 2022/2555"); betrifft ein Vorkommnis den Schutz personenbezogener Daten, unterrichtet die Marktüberwachungsbehörde zudem die DSGVO-Aufsicht (Art. 44 Abs. 6). Wer Incident-Response-Prozesse pflegt, muss die Wege also parallel bedienen können.

CISO-Einordnung

Zum Sicherheitsgehalt des Produktregimes, auf Ebene der Gegenstandsbeschreibung: Anhang II Abschnitt 3 verlangt von EHR-Systemen für Gesundheitsberufe zuverlässige Identifizierungs- und Authentifizierungsmechanismen, von der europäischen Protokollierungssoftwarekomponente die Aufzeichnung definierter Mindestangaben zu jedem Zugriffsereignis (wer zugegriffen hat, wessen Daten, welche Kategorien, Zeitpunkt, Datenherkunft), dazu Werkzeuge oder Anschlussmöglichkeiten für die Protokollauswertung und die Unterstützung differenzierter Aufbewahrungsfristen und Zugriffsrechte. Das Protokollformat der Komponente definiert die Verordnung über Anhang II Nummer 3.2 (Art. 2 Abs. 2 Buchst. o). Die Einzelheiten stehen im Anhang selbst und künftig in den gemeinsamen Spezifikationen nach Art. 36, die die Kommission bis zum 26.03.2027 erlassen soll; dieser Artikel gibt sie bewusst nicht als Anforderungsliste wieder.

Zum Nachmarkt: Ein schwerwiegendes Vorkommnis ist weit definiert und umfasst neben Tod und schwerer Gesundheitsschädigung auch die schwere Beeinträchtigung der Rechte einer natürlichen Person und die schwerwiegende Störung von Verwaltung und Betrieb kritischer Infrastrukturen im Gesundheitswesen (Art. 2 Abs. 2 Buchst. r). Hersteller melden solche Vorkommnisse den Marktüberwachungsbehörden der Mitgliedstaaten, in denen das Vorkommnis aufgetreten ist und in denen das System auf dem Markt ist, samt Beschreibung der Korrekturmaßnahmen; die Meldung erfolgt unverzüglich nach Feststellung des Kausalzusammenhangs oder seiner hinreichenden Wahrscheinlichkeit, spätestens drei Tage nach Kenntnis (Art. 44 Abs. 7). Die Mitgliedstaaten können zusätzlich Nutzermeldungen vorsehen (Art. 44 Abs. 7). Bei Risiken für Patientensicherheit oder Informationssicherheit können die Behörden sofortige Korrekturmaßnahmen verlangen (Art. 44 Abs. 10).

Zur CRA-Brücke: Art. 104 ändert die Verordnung (EU) 2024/2847 an drei Stellen. In Art. 32 wird Absatz 5a eingefügt: Hersteller von Produkten mit digitalen Elementen, die als EHR-Systeme eingestuft sind, weisen die Konformität mit den grundlegenden Anforderungen des Anhangs I der Verordnung (EU) 2024/2847 nach, indem sie das einschlägige Konformitätsbewertungsverfahren nach Kapitel III der Verordnung (EU) 2025/327 anwenden. Art. 13 Abs. 4 und Art. 31 Abs. 3 der Verordnung (EU) 2024/2847 werden so ersetzt, dass die Cybersicherheits-Risikobewertung Teil der Risikobewertungen anderer anwendbarer Rechtsakte sein kann und eine einzige technische Dokumentation genügt. Die EUR-Lex-Beziehungsdaten datieren die Wirkung dieser Änderungen auf den 26.03.2027. Materiell heißt das: Die CRA-Anforderungen an solche Produkte bleiben bestehen, der Nachweisweg wird in das EHDS-Verfahren integriert; die CRA-Melde- und Produktpflichten im Übrigen erklärt der cra-Track.

Zur NIS2-Schnittstelle: Die Verordnung nennt die Richtlinie (EU) 2022/2555 an genau drei Stellen: im Unbeschadet-Vorbehalt der Vorkommnis-Meldung (Art. 44 Abs. 7), im Kooperationsauftrag der Stellen für digitale Gesundheit mit den Aufsichtsbehörden nach den Verordnungen (EU) Nr. 910/2014 und (EU) 2016/679 sowie der Richtlinie (EU) 2022/2555 (Art. 19 Abs. 2 Buchst. m) und in der zugehörigen Fußnote. Governance- und Meldepflichten der Einrichtungen des Gesundheitswesens aus der NIS2-Umsetzung bleiben unverändert; sie stehen im nis2-Track.

Abgrenzung zu den Nachbar-Tracks: Der health-Track behandelt die operativen Sicherheitspflichten deutscher Leistungserbringer (Paragraf 391 SGB V, B3S Krankenhaus) und die Medizinprodukte-Cybersicherheit; hier steht der produkt- und infrastrukturbezogene Sicherheitsgehalt des EU-Gesundheitsdatenraums. Der dsgvo-Track behandelt die technisch-organisatorischen Maßnahmen und Meldepflichten des Verantwortlichen (Art. 32, 33 DSGVO); die EHDS-Sicherheitsanforderungen sind Produkteigenschaften und Infrastrukturvorgaben, die diese Betreiberpflichten ergänzen, nicht ersetzen. Der cra-Track erklärt die grundlegenden Anforderungen und Prozesse der Verordnung (EU) 2024/2847; hier steht nur die Brücke des Art. 104. Der nis2-Track erklärt Melde- und Governance-Pflichten der Richtlinie (EU) 2022/2555; hier stehen nur Unbeschadet-Vorbehalt und Kooperationsauftrag.

Umsetzungsperspektive

Für Hersteller wird der Sicherheitsteil des Anhangs II erst mit den gemeinsamen Spezifikationen nach Art. 36 (vorgesehen bis 26.03.2027) operationalisierbar; bis dahin lassen sich Architekturentscheidungen treffen (getrennte Protokollierungskomponente, Authentifizierungsmechanismen, Auswertungsschnittstellen), aber keine abschließenden Testkriterien ableiten. Wer zugleich CRA-pflichtige Produkte baut, sollte die Nachweisführung von Anfang an auf die einheitliche technische Dokumentation ausrichten, die Art. 104 in der Verordnung (EU) 2024/2847 verankert. Der Bestand an Durchführungsrechtsakten war am 05.08.2026 an den hier geprüften Quellen nicht erhoben.

Für Betreiber gilt: Die eigene Sicherheits-Compliance ändert sich durch den EHDS zunächst nicht; NIS2-Umsetzung, Art. 32 DSGVO und die deutschen Sektorpflichten laufen unverändert. Neu hinzu kommt die Erwartung, dass beschaffte EHR-Systeme die Sicherheits- und Protokollierungseigenschaften des Anhangs II als Produktmerkmal mitbringen, und im Incident-Fall die Koordination mit dem Hersteller, dessen Meldepflicht nach Art. 44 Abs. 7 eigene Fristen hat.

Typische Fehler

1. Anhang II als unmittelbaren Pflichtenkatalog für Krankenhäuser oder Praxen behandeln; die grundlegenden Anforderungen adressieren die harmonisierten Softwarekomponenten über die Herstellerpflichten des Art. 30 Abs. 1.
2. Aus der EHDS-Vorkommnis-Meldung schließen, NIS2- oder DSGVO-Meldungen würden entfallen; Art. 44 Abs. 7 gilt ausdrücklich unbeschadet der NIS2-Meldepflichten, und Datenschutzbezüge gehen an die DSGVO-Aufsicht (Art. 44 Abs. 6).
3. Die Melde-Adressaten verwechseln: Die Art.-44-Meldung des Herstellers geht an Marktüberwachungsbehörden, nicht an CSIRTs oder Datenschutzbehörden.
4. Den Vorkommnisbegriff auf Personenschäden verengen; erfasst ist auch die schwerwiegende Störung von Verwaltung und Betrieb kritischer Infrastrukturen im Gesundheitswesen (Art. 2 Abs. 2 Buchst. r).
5. Für EHR-Systeme mit digitalen Elementen eine doppelte CRA- und EHDS-Konformitätsbewertung aufsetzen; Art. 104 führt den CRA-Nachweis über das Kapitel-III-Verfahren des EHDS zusammen.
6. Aus dem EHDS konkrete Betreiber-Kontrollen ableiten oder ein Mapping der EHDS-Anforderungen auf CRA-, NIS2- oder ISO-Controls erwarten; solche Zuordnungen gibt der Rechtstext nicht her und dieser Korpus liefert sie nicht.
7. Die Drei-Tages-Frist des Art. 44 Abs. 7 auf Betreiber anwenden; die Meldepflicht trifft den Hersteller, Nutzermeldungen sind mitgliedstaatliche Option.

Risiken und Trade-offs

Für Hersteller liegt das Hauptrisiko in der Parallelität der Regime während der Übergangsjahre: CRA-Pflichten und EHDS-Pflichten werden zu unterschiedlichen Terminen wirksam, und die Integration des Nachweiswegs über Art. 104 greift nach den EUR-Lex-Beziehungsdaten ab dem 26.03.2027, während die Konformitätsvorschriften der Art. 25 bis 27 je nach Datenkategorie erst 2029 oder 2031 gelten (Art. 105 Abs. 3 und 4). Die Vorkommnis-Meldung des Art. 44 steht dagegen nicht auf der Aufschubliste und gilt ab dem 26.03.2027 (fuer Systeme nach Art. 26 Abs. 2 nach Art. 105 Abs. 4 erst ab dem 26.03.2031), also zeitgleich mit der CRA-Nachweisintegration. Wer die Dokumentations- und Meldeprozesse getrennt aufbaut, zahlt doppelt; wer sie zusammenlegt, muss die unterschiedlichen Fristen und Adressaten sauber auseinanderhalten.

Für Betreiber besteht der Trade-off in der Beschaffungsstrategie: Sicherheitsanforderungen an EHR-Systeme heute vertraglich über eigene Kataloge zu erzwingen kostet Verhandlungsmacht und kann mit den späteren gemeinsamen Spezifikationen kollidieren; ganz auf den EHDS zu warten heißt, bis 2029 Systeme ohne belastbare Protokollierungs- und Authentifizierungszusagen zu betreiben. Ein gangbarer Mittelweg ist, die Themen des Anhangs II Abschnitt 3 als Vertragsgegenstand zu benennen und die Detailtiefe an die kommenden Spezifikationen zu koppeln.

Entscheidungspunkte

• Sind wir für eines unserer Produkte Hersteller im Sinne des Kapitels III und damit Träger der Vorkommnis-Meldepflicht (Art. 44 Abs. 7), und ist unser PSIRT darauf eingerichtet?
• Wie integrieren wir EHDS-, CRA-, NIS2- und DSGVO-Meldewege in einem Incident-Prozess mit klaren Zuständigkeiten und Fristen?
• Nutzen wir für CRA-pflichtige EHR-Systeme die einheitliche technische Dokumentation und das zusammengeführte Konformitätsverfahren (Art. 104)?
• Welche Sicherheits- und Protokollierungseigenschaften verlangen wir ab sofort in EHR-Beschaffungen, und wie koppeln wir sie an die kommenden gemeinsamen Spezifikationen?
• Wer beobachtet den Erlass der gemeinsamen Spezifikationen nach Art. 36 und der Durchführungsrechtsakte zur Sicherheit von MyHealth@EU (Art. 23 Abs. 4) und HealthData@EU (Art. 75 Abs. 12)?

Praktische Empfehlungen

1. Legen Sie eine Meldewege-Matrix an: je Szenario (Produktfehler, Sicherheitsvorfall, Datenschutzverletzung) der Auslöser, der Adressat und die Frist nach EHDS (Art. 44 Abs. 7: spätestens drei Tage nach Kenntnis), NIS2-Umsetzung und Art. 33 DSGVO; pflegen Sie die Zuständigkeiten mit Legal.
2. Wenn Sie Hersteller sind: Verankern Sie den Vorkommnisbegriff des Art. 2 Abs. 2 Buchst. r in Ihren PSIRT-Kriterien, einschließlich der Störung kritischer Infrastrukturen im Gesundheitswesen, und üben Sie den Meldefall.
3. Führen Sie für Produkte, die CRA und EHDS unterliegen, eine einzige technische Dokumentation und ein zusammengeführtes Konformitätsverfahren (Art. 104; Wirkung laut EUR-Lex-Beziehungsdaten ab 26.03.2027).
4. Nehmen Sie die Themen des Anhangs II Abschnitt 3 (Authentifizierung, Zugriffsprotokollierung, Protokollauswertung, differenzierte Aufbewahrung und Zugriffsrechte) als benannte Vertragsgegenstände in EHR-Beschaffungen auf, mit Verweis auf die jeweils geltenden gemeinsamen Spezifikationen statt eigener Detailkataloge.
5. Halten Sie die Betreiber-Compliance getrennt sauber: NIS2-Pflichten (nis2-Track), Art. 32 DSGVO (dsgvo-Track) und deutsche Sektorpflichten (health-Track) gelten unabhängig vom EHDS weiter.
6. Setzen Sie eine Wiedervorlage auf den Erlass der gemeinsamen Spezifikationen (Art. 36, vorgesehen bis 26.03.2027) und prüfen Sie dann Produktroadmap und Verträge nach.

Relevante Normreferenzen

• Verordnung (EU) 2025/327: Anhang II (grundlegende Anforderungen, Abschnitt 3 "Sicherheitsanforderungen und Anforderungen an die Protokollierung"; Gegenstandsbeschreibung, keine Wiedergabe), Art. 30 (Herstellerpflichten), Art. 44 (Risiken und schwerwiegende Vorkommnisse), Art. 19 Abs. 2 (Kooperationsauftrag), Art. 73 (sichere Verarbeitungsumgebung, vertieft in ehds-005), Art. 104 (Änderung der Verordnung (EU) 2024/2847); ABl. L, 2025/327, 05.03.2025; EU-Recht mit Quellenangabe frei zitierbar.
• Verordnung (EU) 2024/2847 (Cyber Resilience Act): Anhang I (grundlegende Anforderungen), Art. 13 Abs. 4, Art. 31 Abs. 3, Art. 32 Abs. 5a in der durch Art. 104 der Verordnung (EU) 2025/327 geänderten Fassung; im Korpus der cra-Track.
• Richtlinie (EU) 2022/2555 (NIS2): Meldepflichten und Governance der Einrichtungen; im EHDS nur Unbeschadet-Vorbehalt und Kooperationsauftrag; im Korpus der nis2-Track.
• Verordnung (EU) 2016/679 (DSGVO): Art. 32 und 33 als Betreiber-Basispflichten; im Korpus der dsgvo-Track.
• Paragraf 391 SGB V und B3S Krankenhaus: deutsche operative Sicherheitspflichten der Leistungserbringer; im Korpus der health-Track.