Vorbereitung auf den EU Cyber Solidarity Act mit ISO 27001

Der Vorfall um 03:17 Uhr, der EU-Zusammenarbeit zu Ihrem Auditproblem macht

Um 03:17 Uhr an einem Dienstagmorgen blickt Maria, CISO von InnovateCloud, auf einen Bildschirm voller Warnmeldungen. Ihr Unternehmen ist ein mittelgroßer europäischer SaaS-Anbieter, der Logistikkunden in Deutschland, Frankreich und Polen betreut. Die erste Warnmeldung deutet auf verdächtigen privilegierten Zugriff in einem Produktions-Tenant hin. Zehn Minuten später meldet der Managed Security Service Provider ähnliche Aktivitäten bei zwei weiteren Kunden. Um 04:00 Uhr sieht das SOC API-Aufrufe aus einer Infrastruktur, die zuvor mit Ransomware-Vorbereitung in Verbindung gebracht wurde.

InnovateCloud war nicht das ursprüngliche Ziel. Ein zentraler Infrastrukturanbieter scheint im Wirkungsbereich des Angriffs zu liegen. Die Auswirkungen sind nun jedoch Marias Problem.

Ein betroffener Kunde ist eine deutsche Bank, die Antworten nach DORA verlangt. Ein anderer ist ein kritischer Lieferant im Energiesektor, der bereits nach nationalen NIS2-Vorgaben klassifiziert ist. Die Umgebung kann personenbezogene Daten enthalten, eine Exfiltration ist jedoch noch nicht bestätigt. Das Sicherheitsteam will die Bedrohung sofort eindämmen. Die Rechtsabteilung möchte wissen, ob die 24-Stunden-Frist für die NIS2-Frühwarnung bereits läuft. Die Datenschutzbeauftragte fragt, ob eine Meldung einer Verletzung des Schutzes personenbezogener Daten nach GDPR erforderlich sein könnte. Das Leitungsorgan will wissen, ob sich der Ausfall über mehrere Mitgliedstaaten ausbreiten könnte.

Im Jahr 2026 ist dies nicht mehr nur eine interne Krise.

Der EU Cyber Solidarity Act verändert die operative Realität für großflächige und grenzüberschreitende Cybervorfälle. Er führt Mechanismen zur Erkennung, Vorbereitung und Reaktion auf EU-Ebene ein, darunter das Europäische Cybersicherheitswarnsystem, den Cybersicherheits-Notfallmechanismus und die EU-Cybersicherheitsreserve. Selbst wenn eine Organisation nie direkt Unterstützung aus der Reserve anfordert, können ihre Nachweise, Behördenkontakte, Lieferantenverträge, Vorfallszeitachsen und Kundenkommunikation Teil einer umfassenderen europäischen Reaktionskette werden.

Die Lücke zeigt sich schnell. Viele Organisationen verfügen über Tools, Tickets und Richtlinien, aber nicht über Nachweise, die einer regulatorischen Prüfung standhalten. Sie können sagen: „Wir haben die Aufsichtsbehörde kontaktiert“, können aber nicht belegen, wer dazu befugt war, welcher Schwellenwert den Kontakt ausgelöst hat, was kommuniziert wurde, ob Logs gesichert wurden, ob ein Lieferant vertraglich zur Unterstützung verpflichtet war oder ob ein Abschlussbericht aus zeitnah dokumentierten Entscheidungen rekonstruiert werden kann.

Die Antwort ist kein weiterer isolierter „Cyber-Solidarity-Act-Ordner“. Die Antwort ist ein Informationssicherheitsmanagementsystem nach ISO/IEC 27001:2022, das Nachweise einmal erzeugt und sie für Erwartungen aus NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019 wiederverwendet.

Diese Nachweise entstehen vor dem Vorfall.

Warum der EU Cyber Solidarity Act den Nachweisstandard erhöht

Der Cyber Solidarity Act ist auf Cybererkennung, Vorbereitung und Krisenreaktion auf EU-Ebene ausgerichtet. Seine praktische Wirkung für CISOs, Auditoren und Compliance-Manager ist eindeutig: Die Koordination großflächiger Vorfälle erfordert Nachweise, die schneller verfügbar, sauberer strukturiert, konsistenter und leichter mit vertrauenswürdigen Stakeholdern teilbar sind.

Wenn grenzüberschreitende Auswirkungen möglich sind, muss eine Organisation gegebenenfalls mit nationalen CSIRTs, zuständigen Behörden, sektoralen Aufsichtsbehörden, Datenschutzbehörden, Finanzaufsichten, Strafverfolgungsbehörden, Kunden, Auftragsverarbeitern, Lieferanten und externen Incident-Response-Anbietern koordinieren. Die EU-Cybersicherheitsreserve ergänzt eine weitere Dimension, weil vorab geprüfte private Anbieter Vorbereitung, Reaktion und Wiederherstellung unterstützen können. Dadurch werden Lieferanten-Governance, rechtliche Befugnisse, Datenverarbeitung und Beweissicherung noch wichtiger.

Private Unternehmen stehen im Zentrum dieser Realität. Cloud-Anbieter, Rechenzentren, Managed Service Provider, Managed Security Service Provider, Betreiber digitaler Infrastrukturen, Fintechs und SaaS-Plattformen halten häufig die Telemetrie, Logs, Daten zu Kundenauswirkungen und technischen Fakten, die Behörden benötigen, um einen schwerwiegenden Vorfall zu verstehen.

NIS2 weist bereits in diese Richtung. Die Richtlinie gilt für viele mittlere und große Einrichtungen in den Sektoren von Anhang I und Anhang II, die Dienstleistungen erbringen oder Tätigkeiten in der EU ausüben. Zudem erfasst sie bestimmte Einrichtungen unabhängig von ihrer Größe, einschließlich Vertrauensdiensteanbieter, DNS-Diensteanbieter, Register für Domänen oberster Stufe und Anbieter von Diensten zur Registrierung von Domänennamen. Anhang I umfasst digitale Infrastruktur wie Cloud-Computing-Dienste, Rechenzentrumsdienste, Content Delivery Networks, DNS-Anbieter, Vertrauensdiensteanbieter und TLD-Register. Ebenfalls erfasst ist das IKT-Servicemanagement im B2B-Bereich, einschließlich Managed Service Provider und Managed Security Service Provider. Anhang II umfasst digitale Anbieter wie Online-Marktplätze, Online-Suchmaschinen und Plattformen sozialer Netzwerkdienste.

DORA fügt für den Finanzsektor eine zweite Ebene hinzu. Seit dem 17. Januar 2025 gilt DORA für ein breites Spektrum von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Dienstleistungen, Handelsplätze, Versicherungs- und Rückversicherungsunternehmen, Ratingagenturen, Schwarmfinanzierungsdienstleister und weitere. Zugleich entstehen erhebliche Erwartungen an IKT-Drittdienstleister, weil Finanzunternehmen für ausgelagerte IKT-Dienste verantwortlich bleiben.

Ein Fintech-Vorfall im Jahr 2026 kann daher über DORA-Aufsichtskanäle koordiniert werden, während der SaaS-Anbieter oder MSSP, der dieses Fintech unterstützt, unter NIS2 fallen kann. Dasselbe technische Ereignis kann für unterschiedliche Akteure verschiedene Berichtspflichten, Nachweiserwartungen und vertragliche Verpflichtungen auslösen.

ISO/IEC 27001:2022 gibt Organisationen das Betriebssystem, um diese Komplexität zu steuern. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation das ISMS in ihrem Geschäftskontext definiert, interessierte Parteien und deren gesetzliche, regulatorische und vertragliche Anforderungen identifiziert, Grenzen und Abhängigkeiten festlegt und das Managementsystem etabliert. Die Klauseln 5.1 bis 5.3 machen die Leitung für Richtlinie, Ressourcen, Integration und Rollenzuweisung verantwortlich. Die Klauseln 6.1.1 bis 6.1.3 verlangen wiederholbare Risikobeurteilung, Risikobehandlung und eine Anwendbarkeitserklärung. Klausel 8.1 verlangt operative Steuerung, einschließlich der Steuerung extern bereitgestellter Prozesse, Produkte und Dienstleistungen.

Das ist der Kern der Vorbereitung auf den Cyber Solidarity Act: nachweisen, dass Krisenreaktion gesteuert, getestet und auditierbar ist – nicht improvisiert.

Das Clarysec-Nachweismodell: ein Vorfall, viele Verpflichtungen

Ein grenzüberschreitender Vorfall wartet nicht, bis Rechtsteams ihn klassifiziert haben. Nachweise müssen ab der ersten Warnmeldung erfasst und anschließend den richtigen Melde- und Koordinationspfaden zugeordnet werden.

Der Ansatz von Clarysec verbindet drei Assets:

1. Zenith Blueprint: 30-Schritte-Roadmap für Auditoren Zenith Blueprint, der die Umsetzung von ISO/IEC 27001:2022 in eine sequenzierte, auditbereite Umsetzung überführt.
2. Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls, der ISO/IEC 27002:2022-Kontrollen verwandten Kontrollen, Attributen, operativen Fähigkeiten, Sicherheitsdomänen und Nachweiserwartungen über Frameworks hinweg zuordnet.
3. Clarysec-Richtlinienvorlagen für Vorfallsreaktion, Beweissicherung, Lieferantensicherheit, Protokollierung, Überwachung und Geschäftskontinuität, angepasst an Enterprise- und KMU-Umgebungen.

Im Zenith Blueprint, Phase „Kontrollen in der Praxis“, behandelt Schritt 22 die ISO/IEC 27002:2022-Kontrolle 5.5, Kontakt mit Behörden. Dort heißt es:

Kontrolle 5.5 stellt sicher, dass eine Organisation darauf vorbereitet ist, bei Bedarf mit externen Behörden zu interagieren – nicht reaktiv oder in Panik, sondern über vordefinierte, strukturierte und gut verstandene Kanäle.

Derselbe Abschnitt stellt die Frage, die jeder CISO vor der Krise beantworten sollte:

Wenn Ihre Organisation Ziel eines Cyberangriffs wäre, in eine Datenpanne verwickelt wäre oder Gegenstand einer Untersuchung würde: Wer würde den Kontakt zu den Behörden herstellen? Woher wüsste diese Person, was zu sagen ist? Unter welchen Bedingungen würde ein solcher Kontakt eingeleitet?

Das ist kein administrativer Papierkram. In einer Cyber-Solidarity-Act-Umgebung ist es der Unterschied zwischen einer ruhigen Frühwarnung und widersprüchlichen Botschaften über mehrere Rechtsräume hinweg.

Zenith Controls behandelt ISO/IEC 27002:2022-Kontrolle 5.5, Kontakt mit Behörden, als präventiv und korrektiv, verbunden mit Vertraulichkeit, Integrität und Verfügbarkeit sowie ausgerichtet an den Funktionen Identifizieren, Schützen, Reagieren und Wiederherstellen. Die Kontrolle 5.5 wird mit Planung und Vorbereitung des Vorfallmanagements, Ereignismeldung, Bedrohungsinformationen, Special Interest Groups und Reaktion auf Vorfälle verknüpft.

Derselbe Leitfaden behandelt ISO/IEC 27002:2022-Kontrolle 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, als korrektive Kontrolle, verbunden mit Reaktion und Wiederherstellung. Ihre Bezüge zu Ereignisbewertung, Vorfallsreaktion, Lessons Learned, Protokollierung, Überwachung, Sicherheit während Störungen und Kontinuität zeigen, was Auditoren häufig prüfen: ob Ihr Plan Erkennung, Klassifizierung, Eskalation, Nachweise, Wiederherstellung und Lernen miteinander verbindet.

Für die Beweissicherung ist ISO/IEC 27002:2022-Kontrolle 5.28, Sammlung von Beweismitteln, besonders wichtig. Zenith Controls verknüpft sie mit Vorfallsreaktion, Protokollierung, Überwachung und Ereignismeldung. Bei einem schwerwiegenden grenzüberschreitenden Vorfall wird hier aus der technischen Untersuchung eine belastbare Untersuchung.

Zuordnung der Cyber-Solidarity-Act-Vorbereitung zu ISO 27001-Nachweisen

Der EU Cyber Solidarity Act schafft ein Umfeld für Vorbereitung und Koordination. ISO/IEC 27001:2022 liefert die Nachweismaschine. NIS2, DORA und GDPR definieren viele spezifische Erwartungen an Meldung, Governance und Schutz.

Auffällig ist, was fehlt: ein separates Compliance-Silo. Dieselben Nachweise, die eine Zertifizierung nach ISO/IEC 27001:2022 unterstützen, können auch Managementverantwortung nach NIS2, IKT-Risikomanagement nach DORA, Sicherheits-Rechenschaftspflicht nach GDPR, Kommunikationsergebnisse nach NIST CSF und Assurance-Erwartungen nach COBIT 2019 unterstützen.

NIS2: Die Meldefrist beginnt mit der Kenntniserlangung

NIS2 ist zentral für die Vorbereitung im Jahr 2026, weil die Richtlinie einen gestuften Workflow zur Meldung von Vorfällen definiert.

Article 23 verlangt von wesentlichen und wichtigen Einrichtungen, ihren CSIRT oder die zuständige Behörde unverzüglich über erhebliche Vorfälle zu informieren, die die Erbringung von Diensten beeinträchtigen. Die Frühwarnung muss unverzüglich und spätestens 24 Stunden nach Kenntniserlangung vom erheblichen Vorfall übermittelt werden. Sie sollte, soweit zutreffend, angeben, ob ein Verdacht auf böswillige oder rechtswidrige Handlungen besteht und ob grenzüberschreitende Auswirkungen möglich sind.

Eine Vorfallmeldung folgt unverzüglich und spätestens 72 Stunden nach Kenntniserlangung; sie aktualisiert die Frühwarnung und enthält eine erste Bewertung von Schweregrad, Auswirkungen und verfügbaren Indikatoren einer Kompromittierung. Ein Abschlussbericht ist innerhalb eines Monats nach der Vorfallmeldung fällig und enthält Schweregrad, Auswirkungen, wahrscheinliche Bedrohungsart oder Ursache, Risikominderungsmaßnahmen und grenzüberschreitende Auswirkungen.

Deshalb darf Vorfallsreaktion nicht mit einem leeren Dokument beginnen.

Die Enterprise-Incident Response Policy Incident Response Policy stellt fest:

NIS2 Article 23 (Meldung innerhalb von 24 Stunden nach Kenntniserlangung des Vorfalls)

Die KMU-Incident Response Policy - SME Incident Response Policy - SME überführt dieselbe Zeitlogik in praktikable Governance:

„Reaktionsfristen, einschließlich Datenwiederherstellung und Meldepflichten, müssen dokumentiert und an rechtlichen Anforderungen ausgerichtet sein, etwa an der GDPR-Anforderung zur Meldung einer Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden.“

Aus Incident Response Policy - SME, Abschnitt „Governance-Anforderungen“, Klausel 5.3.2.

Sie erzwingt außerdem die Bewertung über mehrere Regime hinweg im Vorfallsprozess:

„Wenn Kundendaten betroffen sind, muss der Geschäftsführer rechtliche Meldepflichten auf Grundlage der Anwendbarkeit von GDPR, NIS2 oder DORA bewerten.“

Aus Incident Response Policy - SME, Abschnitt „Risikobehandlung und Ausnahmen“, Klausel 7.4.1.

In einem Cyber-Solidarity-Act-Szenario wird „grenzüberschreitende Auswirkungen sind möglich“ operativ wichtig. Die Frühwarnung muss noch keine vollständigen Fakten enthalten, aber die Organisation muss zeigen können, warum sie grenzüberschreitende Auswirkungen auf Grundlage verfügbarer Nachweise vermutet oder nicht vermutet hat.

Die Vorfallsaufzeichnung muss erfassen:

• Wann die Organisation Kenntnis erlangt hat.
• Wer das Ereignis als potenziellen Vorfall eingestuft hat.
• Welche Services, Länder, Kunden oder Sektoren potenziell betroffen waren.
• Ob böswillige oder rechtswidrige Aktivitäten vermutet wurden.
• Welche Indikatoren einer Kompromittierung verfügbar waren.
• Welcher Behördenkontaktpfad genutzt wurde.
• Ob Kundenkommunikation erforderlich war.
• Welche Nachweise vor wesentlichen Abhilfemaßnahmen gesichert wurden.

Der beste Zeitpunkt, diese Felder zu gestalten, ist vor 03:17 Uhr.

DORA: Wenn der Kunde reguliert ist, der Lieferant aber die Logs hält

DORA verändert das Lieferantengespräch. Finanzunternehmen müssen IKT-Drittparteienrisiken als Teil ihres IKT-Risikomanagementrahmens steuern. Die Auslagerung von IKT-Diensten verlagert die regulatorische Verantwortung nicht vom Finanzunternehmen weg.

DORA verlangt Strategien für IKT-Drittparteienrisiken, Register der IKT-Dienstleistungsverträge, angemessene Sorgfalt, Audit- und Inspektionsplanung, Kündigungsrechte und getestete Ausstiegsstrategien für kritische oder wichtige IKT-Dienste. Article 30 verlangt vertragliche Klarheit, einschließlich Leistungsbeschreibungen, Standorten, Datenverarbeitung, Vertraulichkeit, Integrität, Verfügbarkeit, Service Levels, Unterstützung bei IKT-Vorfällen, Zusammenarbeit mit Behörden und Kündigungsrechten. Für kritische oder wichtige Funktionen gelten strengere Bedingungen.

Zurück zu Marias Vorfall. Die deutsche Bank ist nach DORA reguliert. InnovateCloud erbringt SaaS-Dienste. Der MSSP erkennt verdächtige Aktivitäten. Der Cloud-Infrastrukturanbieter verfügt über einige der zentralen Audit-Protokolle. Ein Unterauftragnehmer betreibt einen Teil der Telemetriepipeline. Die Bank bleibt verantwortlich, kann aber ohne Lieferantennachweise nicht sauber klassifizieren und berichten.

Clarysec adressiert dies über Lieferantenklassifizierung und vertragliche Nachweise. Die Enterprise-Third party and supplier security policy Third party and supplier security policy verlangt:

Verträge mit Lieferanten müssen Folgendes enthalten:

Die KMU-Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME nutzt dieselbe Compliance-Logik in einem schlankeren Betriebsmodell:

Verträge müssen verbindliche Klauseln enthalten zu:

Der Wert liegt im Anhang hinter diesen Worten: Pflichten zur Vorfallmeldung, Log-Zugriff, Auditrechte, Vertraulichkeit, Datenstandort, Kontrollen für Unterauftragnehmer, Zusammenarbeit mit Behörden, Unterstützung bei der Wiederherstellung und Exit-Verpflichtungen.

Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 23, gibt den Umsetzungsweg vor:

Erstellen Sie eine vollständige Liste der aktuellen Lieferanten und Serviceanbieter (5.19) und klassifizieren Sie diese nach Zugriff auf Systeme, Daten oder operative Steuerung. Prüfen Sie für jeden klassifizierten Lieferanten, dass Sicherheitserwartungen eindeutig in Verträgen verankert sind (5.20), einschließlich Vertraulichkeit, Zugriff, Vorfallmeldung und Compliance-Verpflichtungen.

Er fährt mit nachgelagerten Risiken fort:

Ermitteln Sie für jeden kritischen Lieferanten, ob er Unterauftragnehmer oder Unterauftragsverarbeiter einsetzt, die auf Ihre Daten oder Systeme zugreifen können. Dokumentieren Sie, wie Ihre Informationssicherheitsanforderungen an diese Parteien weitergegeben werden, entweder über die Vertragsbedingungen Ihres Lieferanten oder über eigene direkte Klauseln.

Das ist zugleich Vorbereitung auf die EU-Cybersicherheitsreserve. Wenn ein externer Response-Anbieter während eines Notfalls Ihre Umgebung betritt, müssen Rechtsgrundlage, Zugriffsumfang, Beweisregeln, Datenumgangspflichten, Koordinationspfad mit Behörden und Exit-Bedingungen bekannt sein. DORA macht dies für Finanzunternehmen ausdrücklich. NIS2 macht es für wesentliche und wichtige Einrichtungen relevant. ISO/IEC 27001:2022 macht es auditierbar.

GDPR: Die Frage der Datenschutzverletzung innerhalb der Cyberkrise

Nicht jeder Cybersicherheitsvorfall ist eine Verletzung des Schutzes personenbezogener Daten, aber jeder schwerwiegende Vorfall muss auf diese Möglichkeit hin bewertet werden.

GDPR gilt für Verarbeitung im Kontext einer Niederlassung in der EU und außerdem für nicht in der EU ansässige Verantwortliche oder Auftragsverarbeiter, die Waren oder Dienstleistungen gegenüber Personen in der EU anbieten oder deren Verhalten in der EU beobachten. GDPR definiert personenbezogene Daten, Verarbeitung, Verantwortlicher, Auftragsverarbeiter und Verletzung des Schutzes personenbezogener Daten. Zu den Grundsätzen gehören Integrität, Vertraulichkeit und Rechenschaftspflicht; Verantwortliche müssen daher die Einhaltung nachweisen können.

Während des Vorfalls um 03:17 Uhr muss Marias Team fragen:

• Wurde auf personenbezogene Daten zugegriffen, wurden sie offengelegt, verändert, verloren oder vernichtet?
• Ist InnovateCloud für die betroffenen Daten Verantwortlicher, Auftragsverarbeiter oder beides?
• Sind besondere Kategorien personenbezogener Daten betroffen?
• Welche Kunden oder betroffenen Personen sind betroffen?
• Reichen die Logs aus, um den Umfang zu bewerten?
• Laufen GDPR-Meldepflichten parallel zu NIS2- oder DORA-Pflichten?

Deshalb gehört Datenschutzkoordination in die Vorfalleskalation und nicht in eine späte rechtliche Prüfung, nachdem Systeme neu aufgebaut und Logs rotiert wurden.

Die KMU-Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME stellt fest:

Warnmeldungen mit hoher Priorität müssen innerhalb von 24 Stunden an den Geschäftsführer und den Datenschutzkoordinator eskaliert werden.

Diese Klausel ist einfach, löst aber ein reales Fehlermuster. Datenschutzverantwortliche benötigen Nachweise, solange sie noch frisch genug sind, um festzustellen, ob eine Verletzung des Schutzes personenbezogener Daten eingetreten ist und ob Risiken für betroffene Personen bestehen.

Ein 24-Stunden-Nachweispaket für grenzüberschreitende Vorfälle aufbauen

Eine praktische Bereitschaftsübung sollte die ersten 24 Stunden eines grenzüberschreitenden Vorfalls simulieren. Ziel ist nicht, übermäßig zu melden. Ziel ist der Nachweis, dass die Organisation Fakten zusammenstellen, belastbare Entscheidungen treffen und Kommunikation konsistent halten kann.

Szenario

Ihr MSSP erkennt verdächtigen privilegierten Zugriff aus einer ungewöhnlichen Region auf Ihren Produktions-Tenant. Dieselbe Quellinfrastruktur erscheint in Warnmeldungen, die zwei Kunden in zwei Mitgliedstaaten betreffen. Ein Kunde ist ein Finanzunternehmen. Die betroffene Umgebung enthält personenbezogene Daten, eine Exfiltration ist jedoch nicht bestätigt.

Schritt 1: Vorfallsaufzeichnung eröffnen

Erstellen Sie das Vorfallticket mit genehmigten Klassifizierungsfeldern. Erfassen Sie Zeitpunkt der Kenntniserlangung, Erkennungsquelle, betroffene Assets, betroffene Services, potenziell betroffene Länder, vermutete böswillige Aktivität, initialen Schweregrad und Vorfallsleiter.

Verknüpfen Sie dies mit den ISO/IEC 27002:2022-Kontrollen 5.24, 5.25 und 5.26 sowie mit den ISO/IEC 27001:2022-Anhang-A-Kontrollen A.5.24, A.5.25 und A.5.26.

Schritt 2: Entscheidungsworkflow für Behördenkontakte auslösen

Nutzen Sie die Behördenkontaktmatrix, die Zenith Blueprint Schritt 22 verlangt. Identifizieren Sie, welche Behörden relevant sein können: nationaler CSIRT, Datenschutzbehörde, Finanzaufsicht, Strafverfolgungsbehörde und sektorale Aufsichtsbehörde.

Dokumentieren Sie die Entscheidung und die Begründung. Wenn keine NIS2-Frühwarnung erfolgt, erfassen Sie warum. Wenn grenzüberschreitende Auswirkungen möglich sind, dokumentieren Sie die Nachweise, die diese Schlussfolgerung stützen.

Schritt 3: Nachweise vor wesentlichen Abhilfemaßnahmen sichern

Die Enterprise-Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy stellt fest:

Alle erhobenen Beweismittel müssen eindeutig identifiziert, gekennzeichnet und in einem sicheren Repository gespeichert werden mit:

Die KMU-Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME beschreibt dieselbe Disziplin in einfacherer Form:

„Jedes digitale Beweismittel muss protokolliert werden mit:“

Aus Evidence Collection and Forensics Policy - SME, Abschnitt „Governance-Anforderungen“, Klausel 5.2.1.

Für die Tabletop-Übung erfassen Sie beispielhafte Nachweiseinträge: SIEM-Warnmeldungsexport, Logs des Identitätsanbieters, Aufzeichnungen privilegierter Sitzungen, Endpoint-Snapshot, Firewall-Logs, Cloud-Audit-Protokolle, Notizen zu Kundenauswirkungen und Kommunikationsfreigaben.

Schritt 4: Lieferantenunterstützung aktivieren

Prüfen Sie das Lieferantenregister. Identifizieren Sie den MSSP, den Cloud-Anbieter und kritische Unterauftragnehmer. Bestätigen Sie Klauseln zur Vorfallsunterstützung, Eskalationskontakte, Log-Aufbewahrungsfristen, Nachweisformat und Verpflichtungen zur Zusammenarbeit mit Behörden.

Dies unterstützt unmittelbar die Anforderungen von DORA an IKT-Drittparteienrisiken und die Erwartungen von NIS2 an die Sicherheit der Lieferkette.

Schritt 5: Drei Kommunikationen entwerfen

Entwerfen Sie drei Kommunikationen aus derselben Faktenbasis:

Schritt 6: Mit Lessons Learned abschließen

Aktualisieren Sie Risikoregister, Anwendbarkeitserklärung, Lieferantenregister und Incident-Response-Plan. Wenn die Übung fehlende Logs, unklare Behördenkontakte oder schwache Lieferantenklauseln offenlegt, leiten Sie Korrekturmaßnahmen ein.

Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 23, weist Organisationen an, Vorfallsfähigkeiten wie folgt zu validieren:

Wählen Sie ein aktuelles Ereignis aus oder führen Sie eine Tabletop-Übung durch, um Ihren Plan zu validieren. Erfassen und protokollieren Sie alle Entscheidungen, Rollen und Kommunikationen (5.26) und aktualisieren Sie den Plan mit Lessons Learned (5.27). Bestätigen Sie, dass Verfahren zur Sicherung forensischer Nachweise (5.28) vorhanden sind, einschließlich Log-Snapshots, Backups und sicherer Isolation betroffener Systeme.

Dieser Absatz ist eine auditbereite Übungsagenda.

Protokollierung: der Unterschied zwischen Koordination und Spekulation

Die Koordination grenzüberschreitender Vorfälle scheitert, wenn alle Meinungen haben und niemand Zeitstempel.

Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 19, formuliert es klar:

Protokollierung ist das Lebenselixier jeder sicheren IT-Umgebung. Ohne sie bleiben Vorfälle unsichtbar, Rechenschaftspflicht verblasst und Ursache-Wirkungs-Zusammenhänge lösen sich in Luft auf.

Weiter heißt es:

Im Kern geht es bei Protokollierung um Nachvollziehbarkeit. Wenn etwas schiefgeht – sei es ein fehlgeschlagener Anmeldeversuch, das Löschen kritischer Dateien oder ein unerlaubtes Skript auf einem Server –, liefern Logs den forensischen Faden, der hilft, das tatsächliche Geschehen zu entwirren.

Für NIS2 unterstützen Logs die 72-Stunden-Vorfallmeldung mit initialem Schweregrad, Auswirkungen und Indikatoren einer Kompromittierung. Für DORA unterstützen Logs die Klassifizierung schwerwiegender IKT-bezogener Vorfälle, Ursachenanalyse, operative Auswirkungen und Rechenschaftspflicht von Drittparteien. Für GDPR unterstützen Logs die Bewertung, ob auf personenbezogene Daten zugegriffen wurde oder diese offengelegt wurden. Im Kontext des Cyber Solidarity Act unterstützen Logs ein gemeinsames Lagebild, ohne dass Responder auf Spekulation angewiesen sind.

Wenn die Antwort auf eine dieser Fragen „nicht sicher“ lautet, gehört das Thema in den Risikobehandlungsplan.

Geschäftskontinuität und sichere Krisenarbeit

Die Diskussion zum Cyber Solidarity Act konzentriert sich naturgemäß auf Vorfallsreaktion, aber Resilienz bedeutet auch, kritische Services während einer Störung sicher aufrechtzuerhalten.

NIS2 Article 21 verlangt einen All-Gefahren-Ansatz, der Verfahren zum Umgang mit Vorfällen, Geschäftskontinuität, Backup-Management, Disaster Recovery, Krisenmanagement, Sicherheit der Lieferkette, Schwachstellenbehandlung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management, Multi-Faktor-Authentifizierung, sichere Kommunikation und gegebenenfalls gesicherte Notfallkommunikation abdeckt.

DORA verlangt entsprechend Governance, IKT-Risikomanagement, Vorfallmanagement, Resilienztests, Drittparteienrisikomanagement, Kontinuität und Wiederherstellung. Kleinere Einrichtungen können vereinfachte Anforderungen haben, benötigen aber weiterhin dokumentiertes IKT-Risikomanagement, Überwachung, resiliente Systeme, Verfahren zum Umgang mit Vorfällen, Identifizierung von Drittparteienabhängigkeiten, Backups, Wiederherstellung, Tests, Lernen nach Vorfällen und Schulung.

Die Enterprise-Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy beginnt mit einer einfachen Anforderung:

Pläne müssen Folgendes abdecken:

Hinter dieser Formulierung stehen die Kontinuitätsnachweise, die Auditoren erwarten: Wiederherstellungsprioritäten, Wiederherstellungszeitziele, Wiederherstellungspunktziele, Backup-Zeitpläne, Wiederherstellungstests, Krisenrollen, alternative Kommunikation, Lieferantenabhängigkeiten und Verbesserungsmaßnahmen nach Übungen.

ISO/IEC 27002:2022-Kontrollen 5.29 und 5.30 sind hier zentral. Kontrolle 5.29 adressiert Informationssicherheit während Störungen. Kontrolle 5.30 adressiert IKT-Bereitschaft für Business Continuity. In Zenith Controls ist die Vorfallsplanung unter 5.24 mit Sicherheit während Störungen und breiterer Kontinuitätsplanung verknüpft. Dies ist besonders relevant, wenn normale Kanäle nicht verfügbar sind, Identitätssysteme eingeschränkt funktionieren oder Krisenteams über gesicherte Notfallkommunikation mit Behörden koordinieren müssen.

Cross-Compliance-Übersicht: NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019

Ein CISO braucht keine fünf separaten Vorfallsprogramme. Er braucht ein Nachweismodell, das aus fünf Perspektiven betrachtet werden kann.

Die Current-and-Target-Profile-Methode von NIST CSF 2.0 ist besonders nützlich für Organisationen, die noch nicht reif genug für eine vollständig integrierte GRC-Plattform sind. Sie regt Organisationen an, ein Profil abzugrenzen, Eingaben wie Richtlinien, Risikoprioritäten des Unternehmens, Business-Impact-Analysen, Anforderungen, Standards, Verfahren, Schutzmaßnahmen und Rollen zu sammeln, anschließend Lücken zu analysieren und einen priorisierten Maßnahmenplan zu erstellen. Das entspricht einem praktischen Sprint zur Vorbereitung auf den Cyber Solidarity Act: aktuelle Nachweise, Zielverpflichtungen, Lückenplan, Verantwortliche, Termine und Prüfpfad.

COBIT 2019- und ISACA-orientierte Auditoren fragen typischerweise, ob Governance-Ziele verantwortet, gemessen und überwacht werden. Sie werden sich nicht mit „das SOC kümmert sich darum“ zufriedengeben. Sie werden fragen, wie Leitungsorgane Risikomaßnahmen genehmigen, wie Leistung berichtet wird, wie Drittparteienrisiken gesteuert werden, wie Ausnahmen akzeptiert werden und wie Korrekturmaßnahmen nachverfolgt werden.

Wie Auditoren denselben Vorfall prüfen werden

Derselbe Vorfall um 03:17 Uhr erzeugt unterschiedliche Auditfragen, abhängig vom Mandat des Assessors.

Ein ISO/IEC 27001:2022-Auditor beginnt mit dem ISMS. Er wird fragen, ob der Vorfallsprozess im Geltungsbereich liegt, ob Anforderungen interessierter Parteien NIS2, DORA, GDPR und Verträge umfassen, ob die Risikobeurteilung grenzüberschreitende und lieferantenbezogene Szenarien berücksichtigt hat, ob Anhang-A-Kontrollen in der Anwendbarkeitserklärung ausgewählt wurden und ob operative Aufzeichnungen belegen, dass der Prozess eingehalten wurde.

Eine auf NIS2 ausgerichtete Behörde oder ein entsprechender Assessor konzentriert sich auf Managementverantwortung, Article 21-Risikomanagementmaßnahmen und Article 23-Meldung. Sie kann fragen, wann die Organisation Kenntnis erlangt hat, warum der Vorfall erheblich war oder nicht, wie grenzüberschreitende Auswirkungen bewertet wurden, ob Kunden informiert wurden und ob Korrekturmaßnahmen unverzüglich ergriffen wurden.

Eine DORA-Aufsicht oder ein internes Auditteam wird fragen, ob der Vorfall kritische oder wichtige Funktionen betroffen hat, ob IKT-Drittanbieter die Reaktion unterstützt haben, ob das Finanzunternehmen verantwortlich geblieben ist, ob das Informationsregister korrekt war, ob der Vorfall richtig klassifiziert wurde und ob Lessons Learned in Resilienztests und Lieferantenaufsicht zurückgeflossen sind.

Ein GDPR-Auditor oder eine Datenschutzbehörde wird fragen, ob die Organisation genügend Nachweise hatte, um festzustellen, ob personenbezogene Daten verletzt wurden, ob die Rollen von Verantwortlichem und Auftragsverarbeiter klar waren, ob Risiken für betroffene Personen bestanden, ob Vertraulichkeits- und Integritätskontrollen angemessen waren und ob Aufzeichnungen zur Rechenschaftspflicht geführt wurden.

Ein NIST CSF 2.0-Assessor wird das Ereignis in die Ergebnisse von Steuern, Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen übersetzen. Er wird nach Erwartungen von Stakeholdern, rechtlichen Verpflichtungen, Risikobereitschaft, Lieferanten-Governance, Protokollierung, Überwachung, Umsetzung der Reaktion, Kommunikation und Validierung der Wiederherstellung suchen.

Ein COBIT 2019- oder ISACA-Auditor konzentriert sich auf die Wirksamkeit von Governance und Managementsystem: Verantwortlichkeiten, Entscheidungsbefugnisse, Kennzahlen, Risikoakzeptanz, Prozessleistung, Assurance und kontinuierliche Verbesserung.

Hier ist Zenith Controls als Cross-Compliance-Kompass nützlich. Es benennt offizielle Kontrollen nicht um und schafft kein paralleles Kontrollrahmenwerk. Es zeigt, wie ISO/IEC 27002:2022-Kontrollen wie 5.5, 5.24 und 5.28 mit operativen Fähigkeiten, verwandten Kontrollen und auditrelevanten Nachweisen verbunden sind.

Was CISOs jetzt für die Vorbereitung auf 2026 tun sollten

Wenn Sie sich auf die operative Realität des EU Cyber Solidarity Act vorbereiten, beginnen Sie mit Nachweisen – nicht mit Schlagworten.

Erstens: Aktualisieren Sie Ihren ISMS-Kontext und die Analyse interessierter Parteien. Ermitteln Sie, ob Ihre Organisation, Kunden oder Lieferanten unter NIS2, DORA oder GDPR fallen. Berücksichtigen Sie Präsenz in Mitgliedstaaten, Sektorklassifizierung, kritische Kunden, IKT-Serviceabhängigkeiten und Behördenkontakte.

Zweitens: Führen Sie eine grenzüberschreitende Tabletop-Übung durch. Verwenden Sie ein Szenario mit einem Lieferanten, mehr als einem Mitgliedstaat, möglicher Exposition personenbezogener Daten und einem regulierten Finanzkunden. Begrenzen Sie die ersten 24 Stunden zeitlich.

Drittens: Prüfen Sie Lieferantenverträge. Bestätigen Sie Meldepflichten, Log-Zugriff, forensische Unterstützung, Zusammenarbeit mit Behörden, Weitergabe von Verpflichtungen an Unterauftragnehmer, Datenstandort, Auditrechte, Kontinuitätsunterstützung und Kündigungsrechte.

Viertens: Testen Sie die Beweissicherung. Exportieren Sie Logs, sichern Sie Snapshots, kennzeichnen Sie Beweismittel, dokumentieren Sie die Beweismittelkette und validieren Sie den Zugriff auf das Repository. Wenn Ihre Richtlinie besagt, dass Beweismittel eindeutig identifiziert und sicher gespeichert werden, weisen Sie es nach.

Fünftens: Stimmen Sie die Vorfallkommunikation ab. Ihre NIS2-Frühwarnung, DORA-Eskalation, GDPR-Bewertung der Datenschutzverletzung und Kundenmitteilung dürfen einander nicht widersprechen. Sie können unterschiedliche rechtliche Zwecke haben, müssen aber aus derselben Faktenbasis stammen.

Sechstens: Machen Sie das Leitungsorgan zum Teil der Übung. NIS2 und DORA erhöhen beide die Managementverantwortung. Die Führungsklauseln von ISO/IEC 27001:2022 machen dies auditierbar. Ein Leitungsorgan, das noch nie eine 24-Stunden-Frist für Cybermeldungen gesehen hat, ist nicht bereit für eine grenzüberschreitende Krise.

Nächste Schritte mit Clarysec

Die Zukunft der EU-Cybersicherheit beruht auf Zusammenarbeit und nachgewiesenem Vertrauen. Organisationen, die NIS2 und DORA als isolierte Checklisten behandeln, werden bei grenzüberschreitenden Vorfällen Schwierigkeiten haben. Organisationen, die nachweisgestützte Betriebssysteme nach ISO/IEC 27001:2022 aufbauen, können Aufsichtsbehörden, Kunden, Auditoren und Krisenreaktionsteams verlässlich antworten.

Clarysec unterstützt CISOs, Compliance-Manager, Auditoren und Geschäftsverantwortliche dabei, EU-Cyberregulierung in auditbereite operative Nachweise zu überführen durch:

• Zenith Blueprint: 30-Schritte-Roadmap für Auditoren für strukturierte Umsetzung von ISO/IEC 27001:2022 und Audit-Sequenzierung.
• Zenith Controls: Der Cross-Compliance-Leitfaden zur Zuordnung von Vorfalls-, Behörden-, Lieferanten-, Nachweis-, Protokollierungs- und Kontinuitätskontrollen über Frameworks hinweg.
• Clarysec-Richtlinienvorlagen, einschließlich Incident Response Policy, Evidence Collection and Forensics Policy, Third party and supplier security policy, Business Continuity Policy and Disaster Recovery Policy, sowie KMU-Versionen, wenn Verhältnismäßigkeit entscheidend ist.

Der beste Zeitpunkt, sich auf die Koordination grenzüberschreitender Vorfälle vorzubereiten, ist vor der Warnmeldung um 03:17 Uhr. Der zweitbeste Zeitpunkt ist heute.

Beginnen Sie mit einer Clarysec-Readiness-Prüfung, laden Sie das relevante Richtlinien-Toolkit herunter oder fordern Sie eine Einführung an, wie Zenith Blueprint und Zenith Controls Ihrem ISMS helfen können, die Nachweise zu erzeugen, die Cyberresilienz im Jahr 2026 verlangen wird.