Kontinuierliche Compliance-Überwachung für NIS2 und DORA

Die Freitagnachmittagsfrage, die jeder CISO heute beantworten muss

Um 16:40 Uhr an einem Freitag erhält der CISO einer cloudbasierten Zahlungsplattform innerhalb von zehn Minuten drei Nachrichten.

Die erste kommt vom CFO: „Unser Bankpartner verlangt aktualisierte Nachweise dafür, dass wir die DORA-Erwartungen an IKT-Drittparteienrisiken und Vorfallmeldungen erfüllen.“

Die zweite kommt aus der Rechtsabteilung: „Unser Managed Security Service könnte uns nach der nationalen Umsetzung von NIS2 in den Geltungsbereich bringen. Können wir Managementaufsicht und Kontrollwirksamkeit nachweisen?“

Die dritte kommt vom Leiter Engineering: „Wir haben die kritische Schwachstelle gepatcht, aber der Backlog zeigt 38 überfällige mittlere Feststellungen. Müssen wir eskalieren?“

Das ist der Moment, in dem jährliche Compliance zusammenbricht.

Ein Richtlinien-PDF, ein Risikoregister, das zuletzt vor dem vorherigen Audit aktualisiert wurde, und ein Ordner mit Screenshots reichen für NIS2 und DORA nicht aus. Diese Regelwerke erwarten gelebte Governance, Aufsicht durch das Management, Vorfalls-Workflows, Lieferantentransparenz, Resilienztests, Korrekturmaßnahmen und nachweisbare Kontrollwirksamkeit.

Für viele CISOs ist der Druck nicht theoretisch. Die Umsetzung von NIS2 in den EU-Mitgliedstaaten hat Cybersicherheit von einem technischen Programm zu einer Frage der Rechenschaftspflicht des Managements gemacht. DORA gilt seit dem 17. Januar 2025 und stellt Finanzunternehmen ein sektorspezifisches Regelwerk zur digitalen operationalen Resilienz für IKT-Risiken, Vorfallmeldungen, Tests und Drittparteienrisiken bereit. Cloud-, SaaS-, Managed-Service-, Managed-Security-, Rechenzentrums-, Content-Delivery-, Vertrauensdienste- und Anbieter öffentlicher elektronischer Kommunikationsnetze und -dienste können je nach Geltungsbereich, Größe, Sektor, nationaler Einstufung und Kundenverträgen ebenfalls direkten oder indirekten Verpflichtungen unterliegen.

Die praktische Frage lautet nicht mehr: „Haben wir eine Kontrolle?“

Sie lautet: „Wer ist für die Kontrolle verantwortlich, welche Kennzahl belegt ihre Wirksamkeit, wie häufig sammeln wir Nachweise, und was passiert, wenn die Kennzahl verfehlt wird?“

Das ist der Kern der kontinuierlichen Compliance-Überwachung für NIS2 und DORA. In Clarysec-Implementierungen verwenden wir ISO/IEC 27001:2022 als Rückgrat des Managementsystems, ISO/IEC 27002:2022 als Kontrollsprache, Zenith Blueprint: Die 30-Schritte-Roadmap für Auditoren als Implementierungssequenz und Zenith Controls: Der Cross-Compliance-Leitfaden als Kompass für übergreifende Compliance, der ISO/IEC 27001:2022-Nachweise mit NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 und Auditerwartungen verbindet.

Warum NIS2 und DORA periodische Compliance unzureichend machen

NIS2 und DORA unterscheiden sich in Rechtsstruktur, Aufsichtsmodell und Geltungsbereich, erzeugen aber denselben operativen Druck. Cybersicherheit und IKT-Resilienz müssen kontinuierlich gesteuert werden.

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen, geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen auf Basis eines All-Gefahren-Ansatzes umzusetzen. Dazu gehören Risikoanalyse, Richtlinien zur Sicherheit von Informationssystemen, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Krisenmanagement, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Schwachstellenmanagement, Bewertung der Wirksamkeit, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, Multi-Faktor-Authentifizierung. Leitungsorgane müssen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen erhalten.

DORA macht dies für Finanzunternehmen noch ausdrücklicher. Es verlangt interne Governance- und Kontrollregelungen für IKT-Risiken, einen dokumentierten Rahmen für das IKT-Risikomanagement, Verantwortung des Leitungsorgans, Management und Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Management von IKT-Drittparteienrisiken, Audit-Folgemaßnahmen, Schulungen und Kommunikationsregelungen. DORA stellt außerdem klar, dass Finanzunternehmen für die Einhaltung verantwortlich bleiben, wenn sie IKT-Drittdienstleister einsetzen.

Dadurch entsteht eine neue Compliance-Realität. Ein CISO kann nicht bis zum Auditmonat warten, um festzustellen, dass:

• Berechtigungsüberprüfungen für privilegierte Zugriffe zwei Quartale lang versäumt wurden;
• Ausstiegspläne für Lieferanten dokumentiert, aber nie getestet wurden;
• Schweregradkriterien für Vorfälle nicht auf regulatorische Meldeschwellen abgebildet sind;
• Backups konfiguriert sind, aber Wiederherstellungsnachweise fehlen;
• die Geschäftsleitung überfällige Risikobehandlungen nie überprüft hat;
• Cloud-Verträge keine Auditrechte, keine Transparenz zu Unterauftragnehmern oder keine Klauseln zur Meldung von Vorfällen enthalten.

Das alte projektbasierte Modell erzeugt Panikzyklen. Teams hasten vor einem Audit, sammeln Screenshots, aktualisieren Richtliniendaten und hoffen, dass die Nachweise eine schlüssige Geschichte erzählen. NIS2 und DORA sind darauf ausgelegt, diesen Ansatz scheitern zu lassen. Sie konzentrieren sich auf Rechenschaftspflicht, Verhältnismäßigkeit, Resilienz und Betriebsnachweise.

ISO/IEC 27001:2022 stellt das Betriebssystem für dieses Problem bereit. Die Normkapitel verlangen von Organisationen, Kontext, interessierte Parteien, gesetzliche und vertragliche Anforderungen, Geltungsbereich, Führung, Rollen, Risikobeurteilung, Risikobehandlung, Statement of Applicability, operative Planung, Leistungsbewertung, internes Audit, Managementbewertung, Behandlung von Nichtkonformitäten und kontinuierliche Verbesserung zu verstehen und zu steuern. Diese Struktur ist ideal, um NIS2, DORA, GDPR, Customer Assurance und interne Risiken in einem kontinuierlichen Überwachungsmodell zusammenzuführen.

Kontinuierliche Compliance bedeutet nicht mehr Dashboards. Sie bedeutet einen gesteuerten Nachweisrhythmus.

Die Compliance-Maschine auf ISO/IEC 27001:2022 aufbauen

Viele Organisationen missverstehen ISO/IEC 27001:2022 als reines Zertifizierungsrahmenwerk. In der Praxis ist es ein Risikomanagementsystem, das Sicherheitsgovernance wiederholbar, messbar und auditierbar macht.

Das ist wichtig, weil NIS2 und DORA keine isolierten Checklisten sind. Sie verlangen ein Betriebsmodell, das rechtliche Anforderungen aufnehmen, in Kontrollen übersetzen, Verantwortung zuweisen, Leistung überwachen und Verbesserungen anstoßen kann, wenn Lücken festgestellt werden.

Die grundlegenden Kapitel von ISO/IEC 27001:2022 stellen dieses Modell bereit:

Für ein FinTech, einen SaaS-Anbieter, einen Managed-Security-Dienst oder einen IKT-Lieferanten für Finanzunternehmen verhindert diese Struktur doppelte Compliance-Projekte. Ein ISMS kann Verpflichtungen einmal auf Kontrollen abbilden und anschließend Nachweise über NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, ISO/IEC 27001:2022-Zertifizierung und Customer-Assurance-Prüfungen hinweg wiederverwenden.

Mit Kontrollverantwortung beginnen, nicht mit Werkzeugen

Das erste Fehlermuster bei kontinuierlicher Compliance ist die werkzeuggetriebene Implementierung. Ein Unternehmen kauft eine GRC-Plattform, importiert Hunderte Anforderungen, weist alles „Security“ zu und nennt das kontinuierliche Überwachung. Sechs Monate später ist das Dashboard rot, Engineering stellt Schwachstellennachweise infrage, die Rechtsabteilung erklärt Lieferantendokumente für unvollständig, und die Geschäftsleitung kann das Restrisiko nicht klar erkennen.

ISO/IEC 27001:2022 vermeidet dies, indem Verantwortlichkeiten und Befugnisse zugewiesen und kommuniziert werden müssen. NIS2 und DORA verstärken dieselbe Erwartung durch Rechenschaftspflicht des Managements, definierte Rollen und Aufsicht.

Clarysecs Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU legt fest:

Jede Rolle mit Sicherheitsverantwortung muss in einem zentralen Protokoll erfasst und schriftlich bestätigt werden.

Diese Klausel ist wichtiger als die meisten Dashboards. Wenn Backup-Tests, Schwachstellenbehebung, Lieferanten-Due-Diligence, Vorfallklassifizierung und Berechtigungsüberprüfung für privilegierte Zugriffe keine benannten Verantwortlichen haben, gibt es keinen verlässlichen Nachweisrhythmus.

Die Informationssicherheitsleitlinie operationalisiert dies für Unternehmensumgebungen:

Auditnachweise für Audits und Kontrollüberprüfungen sammeln und aufbewahren.

Sie verlangt außerdem von Kontrollverantwortlichen:

Kontrollleistung sowie Lücken oder Probleme an den ISMS-Manager berichten.

In Zenith Controls wird dieses Thema direkt auf ISO/IEC 27002:2022-Maßnahme 5.2 Rollen und Verantwortlichkeiten für Informationssicherheit, 5.35 Unabhängige Überprüfung der Informationssicherheit und 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit abgebildet.

Der Zenith Blueprint bietet in der Phase ISMS Foundation & Leadership, Schritt 4: Rollen und Verantwortlichkeiten im ISMS, einen praktischen Einstiegspunkt. Er empfiehlt formale Ernennung, Aktualisierung von Stellenbeschreibungen, Ausrichtung an KPIs, organisationsweite Kommunikation und Verantwortung auf Abteilungsebene.

Ein typischer Ernennungsnachweis kann lauten:

„Mit sofortiger Wirkung werden Sie zum Informationssicherheitsbeauftragten ernannt, mit der Verantwortung, das ISMS einschließlich Risikomanagement, Kontrollumsetzung und Compliance-Überwachung zu beaufsichtigen und zu koordinieren.“

Diese Ernennung ist keine Bürokratie. Sie ist Auditnachweis für Führung und Rollenzuweisung nach ISO/IEC 27001:2022. Sie unterstützt außerdem Managementaufsicht nach NIS2 und Governance nach DORA. Aufsichtsbehörden, Zertifizierungsauditoren und Bankkunden wollen sehen, dass Verantwortung nicht nur impliziert wird. Sie ist zugewiesen, bestätigt, mit Ressourcen unterlegt und überwacht.

Ein praxistaugliches Register der Kontrollverantwortung sollte folgende Felder enthalten:

Dieses Register wird zur Brücke zwischen Richtlinie und Nachweis.

KPIs und KRIs definieren, die Kontrollwirksamkeit belegen

Sobald Verantwortliche benannt sind, müssen sie wissen, wie „gut“ aussieht. Kontinuierliche Compliance-Überwachung basiert auf aussagekräftigen Indikatoren, nicht auf allgemeinen Absichten.

„Patching verbessern“ ist kein KPI. „Lieferanten regelmäßig überprüfen“ ist kein Nachweis. „Resilienz aufrechterhalten“ ist keine messbare Kontrolle.

Clarysec trennt die beiden Indikatortypen klar:

• KPI, ein Key Performance Indicator, misst, ob der Prozess wie erwartet läuft.
• KRI, ein Key Risk Indicator, signalisiert steigendes Risiko oder eine Schwellenwertverletzung, die eine Eskalation erfordert.

Die unternehmensweite Risikomanagement-Richtlinie legt fest:

KRIs (Key Risk Indicators) und Sicherheitskennzahlen müssen für kritische Risiken definiert und monatlich überwacht werden.

Sie verlangt außerdem eine Eskalationslogik:

Eskalationsauslöser müssen in die Überwachungslogik eingebettet werden, z. B. wenn das Restrisiko um mehr als eine Stufe steigt oder Fristen für Risikobehandlungen verfehlt werden.

Für kleinere Organisationen verfolgt Clarysecs Risikomanagement-Richtlinie – KMU einen verhältnismäßigen Ansatz:

Fortschritte bei der Risikominderung müssen vierteljährlich überprüft werden.

Sie erlaubt auch schlanke Kennzahlen:

Informelle Kennzahlen können nachverfolgt werden, z. B. Anzahl offener Risiken, überfällige Maßnahmen, neue Vorfälle.

Diese Verhältnismäßigkeit ist wesentlich. Eine multinationale Bank und ein FinTech-Lieferant mit 60 Mitarbeitenden benötigen keine identische Telemetrie, aber beide benötigen zugewiesene Verantwortung, wiederholbare Messung, Eskalationsschwellen und Nachweise zu Korrekturmaßnahmen.

Ein praxistaugliches KPI- und KRI-Modell für NIS2 und DORA sieht so aus:

Diese Kennzahlen unterstützen mehr als die ISO/IEC 27001:2022-Zertifizierung. Sie unterstützen auch Maßnahmen zum Management von Cybersicherheitsrisiken nach NIS2, die Bereitschaft zur NIS2-Vorfallmeldung, das IKT-Risikomanagement nach DORA, Drittparteienrisiken nach DORA, Rechenschaftspflicht nach GDPR, Governance-Ergebnisse nach NIST CSF 2.0 und COBIT-orientiertes Leistungsmanagement.

Einen Nachweisrhythmus festlegen, bevor das Audit danach fragt

Viele Organisationen sammeln Nachweise zufällig. Ein Screenshot erscheint in einem Teams-Kanal. Ein Jira-Ticket wird in einer E-Mail verlinkt. Ein Lieferantenfragebogen liegt in der Beschaffung. Ein Backup-Test wird mündlich beschrieben. In der Auditwoche wird der ISMS-Manager zum forensischen Ermittler.

Kontinuierliche Compliance erfordert einen geplanten Rhythmus und saubere Nachweishygiene.

Clarysecs Richtlinie zur Audit- und Compliance-Überwachung – KMU legt fest:

Jedes Audit muss einen definierten Geltungsbereich, Ziele, verantwortliches Personal und erforderliche Nachweise enthalten.

Sie sagt außerdem:

Nachweise müssen mindestens zwei Jahre aufbewahrt werden, oder länger, sofern dies durch Zertifizierungs- oder Kundenvereinbarungen erforderlich ist.

Für Unternehmensorganisationen ergänzt die Richtlinie zur Audit- und Compliance-Überwachung Erwartungen an Automatisierung:

Automatisierte Werkzeuge müssen eingesetzt werden, um Konformität von Konfigurationen, Schwachstellenmanagement, Patch-Status und privilegierten Zugriff zu überwachen.

Automatisierung sollte gezielt eingesetzt werden. Kontrollen mit hohem Risiko und hoher Frequenz sollten nicht von manuellen Screenshots abhängen. Das beste Nachweismodell kombiniert automatisierte Telemetrie, Bestätigungen der Verantwortlichen, Ausnahmenprotokolle, Ticketaufzeichnungen, Testergebnisse und Protokolle der Managementbewertung.

Auch eine Namenskonvention ist wichtig. Nachweise sollten ohne übermäßigen Aufwand auffindbar sein. Zum Beispiel:

• wöchentlicher Schwachstellenbericht: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• monatliche Überprüfung privilegierter Zugriffe: YYYY-MM_IAM-Privileged-Review_Attestation
• vierteljährliche Lieferantenüberprüfung: YYYY-QX_Critical-Supplier-Review
• Vorfallpaket: INC-YYYY-###_Timeline-Classification-RCA-CAPA

An dieser Stelle wird Richtlinie operativ. Nachweisaufbewahrung ist keine Archivierungsaufgabe. Sie ist Teil der Kontrolle.

Ein Nachweiselement auf viele Verpflichtungen abbilden

Kontinuierliche Compliance wird wirksam, wenn ein Nachweiselement mehrere Rahmenwerke erfüllt. Deshalb ist Zenith Controls zentral für Clarysecs Ansatz zur übergreifenden Compliance.

Betrachten wir die Behandlung von Sicherheitsvorfällen. Nach NIS2 erfordern erhebliche Vorfälle eine gestufte Berichterstattung, einschließlich Frühwarnung innerhalb von 24 Stunden ab Kenntnis, Benachrichtigung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats, vorbehaltlich nationaler Umsetzung und der tatsächlichen Vorfallsumstände. DORA verlangt von Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle anhand vorgeschriebener Prozesse und Vorlagen zu verwalten, zu klassifizieren, zu eskalieren und zu melden. GDPR verlangt von Verantwortlichen, Verletzungen des Schutzes personenbezogener Daten zu bewerten und zu steuern, wenn Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten betroffen sind.

Ein einziges Vorfallsnachweispaket kann alle drei unterstützen, wenn es Folgendes enthält:

• Zeitachse des Vorfalls und Zeitpunkt der Kenntnisnahme;
• Begründung der Klassifizierung;
• betroffene Services und Rechtsräume;
• Auswirkungen auf Kunden, Transaktionen oder Benutzer;
• Bewertung der Auswirkungen auf personenbezogene Daten;
• Ursachenanalyse;
• Minderungs- und Wiederherstellungsmaßnahmen;
• Kommunikation und Benachrichtigungen;
• Aufzeichnung der Managementeskalation;
• Eintrag zur Korrekturmaßnahme.

Dieselbe Logik der übergreifenden Compliance gilt für Lieferantenrisiken. NIS2 verlangt Sicherheit der Lieferkette und Aufmerksamkeit für direkte Lieferanten- und Dienstleisterbeziehungen. DORA verlangt eine Strategie für IKT-Drittparteienrisiken, Register, vorvertragliche Due-Diligence, vertragliche Klauseln, Auditrechte, Service Levels, Ausstiegsstrategien und Überwachung von Konzentrationsrisiken. NIST CSF 2.0 behandelt Lieferkettenrisiko als Governance-Disziplin über den Lebenszyklus. ISO/IEC 27001:2022 bindet diese Anforderungen in Geltungsbereich, Anforderungen interessierter Parteien, Risikobehandlung und operative Steuerung extern bereitgestellter Prozesse ein.

Eine praxistaugliche Nachweismatrix hilft Kontrollverantwortlichen zu verstehen, warum Nachweise relevant sind:

Dieser Ansatz verhindert doppelte Compliance-Arbeit. Die Organisation sammelt einen belastbaren Nachweissatz und ordnet ihn anschließend mehreren Verpflichtungen zu.

Das Clarysec-Überwachungsmodell: von der Verpflichtung über den Verantwortlichen zum Nachweis

Ein belastbares Überwachungsmodell folgt einer einfachen Sequenz.

Erstens: Verpflichtung definieren. DORA verlangt beispielsweise, dass IKT-Drittparteienrisiken als Teil des IKT-Risikomanagements gesteuert werden, mit Registern, Due-Diligence, vertraglichen Anforderungen, Auditrechten und Ausstiegsstrategien für kritische oder wichtige Funktionen. NIS2 verlangt Sicherheit der Lieferkette und angemessene Korrekturmaßnahmen.

Zweitens: Verpflichtung in ISO/IEC 27001:2022-ISMS-Anforderungen übersetzen. Dazu gehören Anforderungen interessierter Parteien, Geltungsbereich, Risikobeurteilung, Risikobehandlung, Statement of Applicability, operative Steuerung, Überwachung, internes Audit, Managementbewertung und Verbesserung.

Drittens: operative Kontrollen auswählen. In Zenith Controls umfassen zentrale Governance-Kontrollen für kontinuierliche Compliance die ISO/IEC 27002:2022-Maßnahmen 5.2, 5.35 und 5.36. Unterstützende Kontrollen umfassen häufig 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, 5.23 Informationssicherheit bei Nutzung von Cloud-Services, 5.24 Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, 5.26 Reaktion auf Informationssicherheitsvorfälle, 5.30 IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs, 5.31 rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen, 8.8 Management technischer Schwachstellen, 8.13 Informationssicherung, 8.15 Protokollierung, 8.16 Überwachungsaktivitäten und 8.9 Konfigurationsmanagement.

Viertens: Verantwortlichen und Rhythmus zuweisen. Lieferantenrisiken können Beschaffung, Recht, Sicherheit und den Business-Service-Verantwortlichen betreffen, aber ein verantwortlicher Eigentümer muss das Register pflegen und Ausnahmen berichten.

Fünftens: KPIs, KRIs und Nachweise definieren. Lieferanten-KPIs können den Prozentsatz kritischer IKT-Lieferanten mit abgeschlossener Due-Diligence, den Prozentsatz mit genehmigten Vertragsklauseln, die Anzahl ohne getestete Ausstiegspläne und die Anzahl überfälliger Lieferantenüberprüfungen umfassen. KRIs können ungelöste Feststellungen mit hohem Risiko bei Lieferanten, Konzentrationsrisiken über der Toleranz oder fehlende Auditrechte für einen Service umfassen, der eine kritische oder wichtige Funktion unterstützt.

Sechstens: berichten und eskalieren. Monatliche ISMS-Dashboards dürfen nicht lediglich einen grünen Status zeigen. Sie müssen überfällige Nachweise, Risikobewegungen, verpasste Fristen für Risikobehandlungen und erforderliche Managemententscheidungen ausweisen.

Siebtens: auditieren und verbessern. Nachweislücken werden zu Korrekturmaßnahmen, nicht zu Ausreden.

Dies entspricht der Audit-, Review- & Improvement-Phase des Zenith Blueprint. Schritt 25, Internes Auditprogramm, empfiehlt, relevante ISMS-Prozesse und Kontrollen über den Auditzyklus abzudecken, mit einem jährlichen Audit des vollständigen Geltungsbereichs und kleineren vierteljährlichen Stichproben für Hochrisikobereiche, sofern angemessen. Schritt 28, Managementbewertung, verlangt Eingaben wie Änderungen von Anforderungen, Überwachungs- und Messergebnisse, Auditergebnisse, Vorfälle, Nichtkonformitäten, Verbesserungsmöglichkeiten und Ressourcenbedarf. Schritt 29, Kontinuierliche Verbesserung, nutzt das CAPA-Protokoll, um Problembeschreibung, Ursachenanalyse, Korrekturmaßnahme, verantwortlichen Eigentümer, Zieldatum und Status zu erfassen.

Das ist kontinuierliche Compliance in der Praxis.

Ein praktisches Szenario: kritische Schwachstelle an einer öffentlichen API

Um 02:15 Uhr wird eine SIEM-Warnmeldung ausgelöst. Ein Schwachstellenscan hat eine kritische Schwachstelle zur Remotecodeausführung auf einem öffentlich erreichbaren API-Gateway identifiziert, das einen regulierten Zahlungsdienst unterstützt.

Das kontinuierliche Überwachungsmodell sollte reagieren, ohne auf eine Besprechung zu warten.

Erstens klassifiziert das Asset-Inventar das Gateway als kritisch. Die KPI-Uhr für das Schwachstellenmanagement startet. Der KRI für ungepatchte kritische Schwachstellen steigt. Wenn das Asset internetseitig erreichbar ist und der Exploit aktiv ist, wird die Eskalationsschwelle sofort ausgelöst.

Zweitens wird das Ticket an das diensthabende DevOps-Team weitergeleitet. Der Leiter DevOps erhält als Kontrollverantwortlicher für Schwachstellenmanagement eine automatisierte Benachrichtigung. Der SOC Manager verfolgt, ob Indikatoren für Ausnutzung vorliegen. Der ISMS-Manager überwacht, ob Vorfallkriterien erfüllt sind.

Drittens werden Nachweise als Nebenprodukt des Workflows gesammelt. SIEM-Warnmeldung, Schwachstellenscan, Asset-Klassifizierung, Ticket-Zeitstempel, Response-Chat, Patch-Aufzeichnung, Validierungsscan und Abschlussfreigabe werden dem Nachweispaket beigefügt.

Viertens bewertet das Team, ob es sich nur um eine Schwachstelle, ein Sicherheitsereignis oder einen Vorfall handelt. Wenn Serviceauswirkung, Kompromittierungsindikatoren, Kundenauswirkung oder Exponierung personenbezogener Daten vorliegen, löst der Vorfalls-Workflow Bewertungen zu NIS2, DORA, GDPR und vertraglichen Meldepflichten aus.

Fünftens erhält das Management einen knappen Bericht. Wenn die Schwachstelle innerhalb von vier Stunden behoben wurde, stützen die Nachweise die Kontrollwirksamkeit. Wenn das SLA verfehlt wurde, erfasst das CAPA-Protokoll Ursachenanalyse, Korrekturmaßnahme, Verantwortlichen, Zieldatum und Status.

Dieses einzelne Ereignis erzeugt nutzbare Nachweise für Schwachstellenmanagement, Vorfallsbereitschaft, Überwachung, Zugriff auf kritische Assets, Managementbewertung und kontinuierliche Verbesserung.

Wie Auditoren und Aufsichtsbehörden dasselbe Überwachungsmodell prüfen

Ein ausgereiftes Programm zur kontinuierlichen Compliance muss unterschiedlichen Prüfungsblickwinkeln standhalten. Die Nachweise ändern sich nicht, aber die Fragen schon.

Bei ISO/IEC 27002:2022-Maßnahme 5.35 Unabhängige Überprüfung der Informationssicherheit wird ein ISO/IEC 27001:2022-Auditor den internen Auditplan, Geltungsbereich, Kompetenz, Feststellungen und Korrekturmaßnahmen prüfen. Eine NIS2- oder DORA-Aufsichtsbehörde wird darauf achten, ob das Management die Feststellungen verstanden, Abhilfemaßnahmen finanziert und systemisches Risiko reduziert hat. Ein NIST CSF 2.0-Prüfer kann die Überprüfung der GOVERN-Funktion zuordnen, einschließlich Aufsicht und Anpassung der Leistung.

Derselbe Nachweissatz dient allen, wenn er vollständig, aktuell und mit Verantwortung verknüpft ist.

Häufige Fallstricke, die kontinuierliche Compliance schwächen

Der erste Fallstrick besteht darin, NIS2 und DORA als getrennte Projekte zu behandeln. Das erzeugt doppelte Register, widersprüchliche Kennzahlen und überlastete Kontrollverantwortliche. Nutzen Sie ISO/IEC 27001:2022 als ISMS-Rückgrat und bilden Sie Verpflichtungen über eine einzige Kontrollbibliothek ab.

Der zweite Fallstrick besteht darin, Kontrollen Teams statt Personen zuzuweisen. „IT besitzt Backups“ reicht nicht aus. Ein benannter Verantwortlicher muss bestätigen, Ausnahmen berichten und Risiken eskalieren.

Der dritte Fallstrick besteht darin, Nachweise zu sammeln, ohne Wirksamkeit zu bewerten. Ein Screenshot eines erfolgreichen Backups belegt keine Wiederherstellbarkeit. Ein Wiederherstellungstest tut das. Ein Lieferantenfragebogen belegt keine Drittparteienresilienz. Vertragliche Klauseln, Auditrechte, Bedingungen zur Meldung von Vorfällen, Leistungsberichte und Ausstiegsplanung schaffen stärkere Nachweise.

Der vierte Fallstrick besteht darin, Aktivität statt Risiko zu messen. Schwachstellen zu zählen ist nützlich. Überfällige kritische Schwachstellen auf internetseitig erreichbaren Systemen zu verfolgen ist besser. Lieferanten zu zählen ist nützlich. Kritische Lieferanten ohne Ausstiegspläne zu verfolgen ist besser.

Der fünfte Fallstrick ist schwache Disziplin bei Korrekturmaßnahmen. Der Zenith Blueprint Schritt 29 ist klar: Feststellungen benötigen Problembeschreibung, Ursachenanalyse, Korrekturmaßnahme, verantwortlichen Eigentümer, Zieldatum und Status. Wenn das CAPA-Protokoll nicht überprüft wird, wird kontinuierliche Compliance zur kontinuierlichen Ansammlung bekannter Schwachstellen.

Was das Management jeden Monat sehen sollte

Leitungsorgane nach NIS2 und DORA benötigen keine rohen Scanner-Exporte. Sie benötigen eine entscheidungsfähige Sicht auf Cyber- und IKT-Risiken.

Ein monatliches Dashboard für Leitungsorgan oder Management sollte enthalten:

• wichtigste Cyber- und IKT-Risiken mit Entwicklung des Restrisikos;
• überfällige Risikobehandlungen und verpasste Fristen;
• erhebliche Vorfälle, Kandidaten für schwerwiegende IKT-bezogene Vorfälle und Lessons Learned;
• kritische Ausnahmen bei Lieferantenrisiken;
• Schwachstellen-SLA-Leistung für kritische Assets;
• Status von Backup- und Wiederherstellungstests;
• Ausnahmen bei der Überprüfung privilegierter Zugriffe;
• Abschlussquote für Compliance-Nachweise;
• Audit-Feststellungen und CAPA-Status;
• erforderliche Ressourcenentscheidungen.

Dies unterstützt unmittelbar die Managementbewertung nach ISO/IEC 27001:2022 und die Governance-Erwartungen von NIS2 und DORA. Es steht außerdem im Einklang mit NIST CSF 2.0, in dem Führungskräfte Prioritäten, Rechenschaftspflicht, Ressourcen und Risikobereitschaft festlegen, während Manager diese Prioritäten in Zielprofile und Aktionspläne übersetzen.

Bauen Sie Ihren NIS2- und DORA-Nachweisrhythmus diese Woche auf

Sie müssen nicht alles auf einmal lösen, um zu beginnen. Eine sinnvolle erste Woche kann einfach sein.

Tag 1: Erstellen Sie ein Register der Kontrollverantwortlichen für fünf Bereiche: Governance und Risikomanagement, Vorfallmanagement und Vorfallmeldung, Schwachstellen- und Patch-Management, Lieferanten- und Cloud-Risiken sowie Aufrechterhaltung des Geschäftsbetriebs und Wiederherstellung.

Tag 2: Definieren Sie je Bereich einen KPI und einen KRI. Halten Sie sie spezifisch, messbar und an die Risikobereitschaft gebunden.

Tag 3: Ordnen Sie jedes Nachweiselement seinem Wert für NIS2, DORA, ISO/IEC 27001:2022, GDPR und Customer Assurance zu.

Tag 4: Legen Sie Nachweisrhythmus, Speicherort, Namenskonvention, Aufbewahrungsregel und Prüfer fest.

Tag 5: Führen Sie eine Tabletop-Eskalation durch. Verwenden Sie ein Cloud-Ausfall- oder kritisches Schwachstellenszenario. Bestätigen Sie Klassifizierung, Bewertung regulatorischer Meldepflichten, Kundenkommunikation, Nachweisspeicherung und CAPA-Erstellung.

Wenn Ihre Organisation NIS2 und DORA noch über Tabellen, jährliche Workshops und verstreute Nachweisordner steuert, ist jetzt der Zeitpunkt, auf einen überwachten Betriebsrhythmus umzustellen.

Beginnen Sie mit drei Maßnahmen:

1. Bauen Sie ein Register der Kontrollverantwortlichen für Ihre Bereiche mit dem höchsten Risiko auf.
2. Definieren Sie pro Kontrolle einen KPI, einen KRI, ein Nachweiselement und einen Rhythmus.
3. Führen Sie eine 30-minütige Nachweisüberprüfung durch und öffnen Sie CAPA-Einträge für alles Fehlende.

Clarysec kann Ihnen helfen, den Umstieg zu beschleunigen: mit dem Zenith Blueprint für die Implementierungssequenz, Zenith Controls für die Zuordnung über Compliance-Anforderungen hinweg und der Clarysec-Richtlinienbibliothek, einschließlich der Informationssicherheitsleitlinie, Risikomanagement-Richtlinie, Richtlinie zur Audit- und Compliance-Überwachung, Richtlinie zu Governance-Rollen und Verantwortlichkeiten – KMU, Risikomanagement-Richtlinie – KMU und Richtlinie zur Audit- und Compliance-Überwachung – KMU.

Das Ziel ist nicht mehr Compliance-Papier. Das Ziel ist, die Freitagnachmittagsfrage sicher beantworten zu können:

„Ja, wir wissen, wer die Kontrolle verantwortet, wir kennen den KPI, wir haben die Nachweise, wir kennen die Ausnahmen, und das Management hat das Risiko überprüft.“

Kontaktieren Sie Clarysec, um ein Modell zur kontinuierlichen Compliance-Überwachung aufzubauen, das auditbereit, leitungsorgantauglich und resilient genug für NIS2, DORA und die nächste Regulierung ist.