NIS2-Haftung von Leitungsorganen: Nachweise mit ISO 27001

Die E-Mail ging an einem Montagmorgen um 08:15 Uhr in Marias Posteingang ein. Als CISO eines schnell wachsenden europäischen Anbieters von Cloud-Diensten war sie dringende Nachrichten gewohnt, doch diese fühlte sich anders an.
Der CFO hatte einen Sicherheitsfragebogen eines Kunden an den CEO, den Gremiensekretär und Maria weitergeleitet. Die Betreffzeile war kurz: „Nachweise zur Rechenschaftspflicht des Leitungsorgans nach NIS2 vor Vertragsverlängerung erforderlich.“
Der Kunde fragte nicht nach einem weiteren Penetrationstestbericht. Er wollte wissen, ob das Leitungsorgan Risikomanagementmaßnahmen im Bereich Cybersicherheit genehmigt hatte, wie deren Umsetzung überwacht wurde, ob Führungskräfte Schulungen zu Cyberrisiken erhalten hatten, wie erhebliche Vorfälle eskaliert wurden und wie Lieferantenrisiken auf Managementebene überprüft werden. Der CEO ergänzte nur einen Satz: „Maria, wie hoch ist unsere Risikoexposition, und wie weisen wir gebotene Sorgfalt nach? Das Leitungsorgan benötigt dies nächste Woche.“
Das ist der Moment, in dem NIS2 für viele SaaS-, Cloud-, MSP-, MSSP-, Rechenzentrums-, Fintech- und Anbieter digitaler Infrastrukturen konkret wird. Die Richtlinie (EU) 2022/2555 behandelt Cybersicherheit nicht als Problem einer technischen Abteilung. Sie macht Cyberrisiko zu einer Frage der Rechenschaftspflicht des Leitungsorgans.
NIS2 Article 20 verlangt von Leitungsorganen wesentlicher und wichtiger Einrichtungen, Risikomanagementmaßnahmen im Bereich Cybersicherheit zu genehmigen, deren Umsetzung zu überwachen und Schulungen zu absolvieren. Außerdem können Mitgliedstaaten eine Haftung für Verstöße vorsehen. Article 21 definiert anschließend die praktische Mindestanforderung: Risikoanalyse, Sicherheitsrichtlinien, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und Authentifizierung.
Für Organisationen, die bereits ISO/IEC 27001:2022 nutzen, ist die Struktur vertraut. Anders sind die Zielgruppe und die Nachweispflicht. Die Frage lautet nicht mehr nur: „Haben wir Sicherheitskontrollen?“ Sie lautet: „Kann das Leitungsorgan nachweisen, dass es diese Kontrollen genehmigt, verstanden, finanziert, überprüft, hinterfragt und verbessert hat?“
Hier wird ISO/IEC 27001:2022 zu einem belastbaren Governance-System. Clarysecs Ansatz besteht darin, ISO/IEC 27001:2022 als Nachweisgerüst zu nutzen, Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint als Umsetzungsroute, Clarysec-Richtlinien als für Leitungsorgane geeignete Artefakte und Zenith Controls: The Cross-Compliance Guide Zenith Controls als rahmenwerkübergreifenden Zuordnungsleitfaden für NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 und Auditerwartungen.
Warum die NIS2-Haftung des Leitungsorgans die Cybersicherheitsdiskussion verändert
NIS2 verlangt von Mitgliedern des Leitungsorgans nicht, Firewall-Ingenieure zu werden. NIS2 verlangt, dass sie steuern und überwachen. Dieser Unterschied ist entscheidend.
Ein CISO kann Schwachstellenberichte, MFA-Abdeckung, Endpoint-Schutz-Dashboards und Bewertungen des Cloud-Risikoprofils zeigen. Das sind nützliche operative Signale, sie belegen jedoch nicht automatisch die Aufsicht durch das Leitungsorgan. Eine Aufsichtsbehörde, ein Unternehmenskunde, ein Zertifizierungsauditor oder ein Prüfer aus dem Finanzsektor wird nach einer Kette von Governance-Nachweisen suchen:
- Die Organisation hat bewertet, ob NIS2 anwendbar ist, und die Grundlage dokumentiert.
- Das Leitungsorgan oder die oberste Leitung hat das Rahmenwerk für Cybersicherheitsrisikomanagement genehmigt.
- Risikobereitschaft und Toleranzschwellen wurden definiert.
- Hohe Cyberrisiken wurden eskaliert und überprüft.
- Entscheidungen zur Risikobehandlung wurden genehmigt, einschließlich akzeptierter Restrisiken.
- Verfahren zur Vorfallmeldung berücksichtigen, sofern anwendbar, 24-Stunden-, 72-Stunden- und Abschlussberichtspflichten.
- Lieferanten- und Cloud-Abhängigkeiten sind erfasst und gesteuert.
- Die Managementbewertung umfasst Auditfeststellungen, Sicherheitsvorfalltrends, Kennzahlen und Verbesserungsmaßnahmen.
- Führungskräfte haben Schulungen erhalten, die ihrer Rechenschaftspflicht entsprechen.
- Entscheidungen, Ausnahmen und Eskalationen sind nachvollziehbar.
An dieser Stelle scheitern viele ältere Sicherheits-Playbooks. Der Kauf eines „NIS2-konformen“ Werkzeugs belegt keine Aufsicht durch das Leitungsorgan. Eine Richtlinie zu unterzeichnen und abzulegen, zeigt keine Umsetzung. Cybersicherheit vollständig an den CISO zu delegieren, erfüllt nicht die Aufsichtspflicht eines Leitungsorgans.
ISO/IEC 27001:2022 löst dieses Problem, weil die Norm Informationssicherheit als strategisches, risikobasiertes Managementsystem definiert, das in Organisationsprozesse integriert ist. Ihre Anforderungen zu Kontext, interessierten Parteien, rechtlichen Verpflichtungen, Geltungsbereich, Führung, Risikobeurteilung, Risikobehandlung, operativer Steuerung, Leistungsbewertung, internem Audit, Managementbewertung und kontinuierlicher Verbesserung schaffen die Struktur, die ein Leitungsorgan für gebotene Sorgfalt benötigt.
Der Zenith Blueprint macht dies in der Phase „ISMS Foundation & Leadership“, Schritt 3, praktisch umsetzbar:
„Klausel 5.1 befasst sich mit Führung und Verpflichtung. ISO 27001 verlangt, dass die oberste Leitung Führung nachweist, indem sie das ISMS unterstützt, Ressourcen bereitstellt, Bewusstsein fördert, sicherstellt, dass Rollen zugewiesen sind, das ISMS in Geschäftsprozesse integriert und kontinuierliche Verbesserung unterstützt.“
Das ist das Betriebsmodell hinter NIS2 Article 20. Das Leitungsorgan muss nicht jedes technische Ticket genehmigen, aber es muss das Governance-Modell genehmigen, wesentliche Risiken verstehen, Ressourcen sicherstellen und die Umsetzung überwachen.
Das NIS2-Nachweispaket für das Leitungsorgan
Ein häufiger Fehler besteht darin, NIS2-Nachweise als Rechtsvermerk plus Richtlinienordner zu behandeln. Das genügt einem ernsthaften Prüfer selten. Rechenschaftspflicht des Leitungsorgans erfordert Nachweise aktiver Governance, nicht bloß passiver Dokumentation.
Ein belastbares NIS2-Nachweispaket für das Leitungsorgan sollte rechtliche Verpflichtungen mit Entscheidungen, Kontrollen und Bewertungszyklen des Leitungsorgans verbinden.
| Nachweisartefakt | Beantwortete Frage zur Rechenschaftspflicht des Leitungsorgans | ISO/IEC 27001:2022-Anker | Clarysec-Quelle |
|---|---|---|---|
| NIS2-Anwendbarkeitsbewertung | Sind wir wesentlich, wichtig, indirekt exponiert oder außerhalb des Geltungsbereichs? | Klauseln 4.1 bis 4.4 | Zenith Blueprint, Schritt 1 und Schritt 2 |
| ISMS-Geltungsbereich und Abhängigkeitsübersicht | Welche Services, Standorte, Lieferanten, Schnittstellen und Prozesse werden gesteuert? | Klauseln 4.1 bis 4.4 | Zenith Blueprint, ISMS-Foundation-Phase |
| Cyber-Risikoregister | Was sind unsere höchsten Cyberrisiken und wer ist dafür verantwortlich? | Klauseln 6.1.1 und 6.1.2 | Risk Management Policy |
| Risikobehandlungsplan und SoA | Welche Kontrollen wurden ausgewählt, warum, und wer hat das Restrisiko genehmigt? | Klausel 6.1.3 | Zenith Blueprint, Schritt 13 |
| Sitzungsprotokolle des Leitungsorgans und Entscheidungsprotokoll | Hat die Leitung Maßnahmen genehmigt, hinterfragt und überwacht? | Klauseln 5.1, 5.3, 9.3 | Governance Roles and Responsibilities Policy |
| Verfahren zur Vorfalleskalation und -meldung | Können wir die gestuften NIS2-Meldefristen einhalten? | Klauseln 8.1, 9.1, Anhang A-Kontrollen zu Vorfällen | Incident-Response-Toolkit und Managementbewertung |
| Lieferantenrisiko-Dashboard | Werden kritische Lieferanten und Cloud-Abhängigkeiten gesteuert? | Klausel 8.1 und Anhang A-Lieferantenkontrollen | Zenith Controls Cross-Mapping |
| Schulungsnachweis für Führungskräfte | Haben Mitglieder des Leitungsorgans geeignete Schulungen absolviert? | Klausel 7.2 und Sensibilisierungskontrollen | Information Security Awareness and Training Policy |
| Ergebnisse aus internem Audit und Managementbewertung | Wird die Umsetzung unabhängig geprüft und verbessert? | Klauseln 9.2, 9.3, 10.1 | Audit and Compliance Monitoring Policy - SME |
Die Stärke dieses Pakets liegt in der Nachvollziehbarkeit. Jedes Artefakt beantwortet eine Governance-Frage und verweist auf einen Mechanismus nach ISO/IEC 27001:2022. Damit erhalten CISO, CEO und Leitungsorgan eine belastbare Darstellung: Cybersicherheit ist keine Sammlung von Werkzeugen, sondern ein gesteuertes System.
Richtlinien in Rechenschaftspflicht auf Ebene des Leitungsorgans überführen
Im Eingangsszenario könnte Marias CEO versucht sein, dem Kunden mit einem ISO-Zertifikat und einigen Richtlinien zu antworten. Das reicht für die Rechenschaftspflicht des Leitungsorgans nach NIS2 nicht aus. Die Organisation benötigt Nachweise dafür, dass Verantwortlichkeiten zugewiesen, Entscheidungen aufgezeichnet und Risiken objektiv eskaliert werden.
Clarysec-Richtlinien sind darauf ausgelegt, diese Nachvollziehbarkeit zu schaffen.
Für kleinere Organisationen legt Information Security Policy - SME Information Security Policy - SME, Klausel 4.1.1, fest, dass die oberste Leitung:
„die Gesamtverantwortung für Informationssicherheit behält.“
Dieser Satz ist wichtig. Er verhindert ein verbreitetes Fehlmuster, bei dem Gründer, CEOs oder Führungsteams informell die gesamte Rechenschaftspflicht für Sicherheit an die IT delegieren, ohne selbst eine wirksame Aufsicht auszuüben.
Für größere Organisationen legt die Risk Management Policy Risk Management Policy, Klausel 4.1.1, fest, dass die Leitung:
„das Risikomanagementrahmenwerk genehmigt und die akzeptable Risikobereitschaft sowie Toleranzschwellen festlegt.“
Das ist ein für Leitungsorgane geeigneter Nachweis für NIS2 Article 20. Eine Erklärung zur Risikobereitschaft, Toleranzschwellen und ein formales Modell für Risikobefugnisse zeigen, wie Genehmigung und Eskalation in der Praxis funktionieren.
Klausel 5.6 derselben Richtlinie ergänzt:
„Die Risikobefugnismatrix muss Schwellenwerte für die Eskalation an die oberste Leitung oder das Leitungsorgan eindeutig festlegen.“
Dies ist eines der wichtigsten Artefakte für NIS2-Governance. Ohne Eskalationsschwellen sieht das Leitungsorgan nur, was jemand zur Eskalation auswählt. Mit Schwellenwerten gelangen hohe Restrisiken, ungelöste kritische Schwachstellen, erhebliche Lieferantenkonzentrationen, wesentliche Vorfälle, Auditfeststellungen und Ausnahmen oberhalb der Toleranz automatisch in die Aufsicht der Geschäftsleitung.
Die Governance Roles and Responsibilities Policy Governance Roles and Responsibilities Policy stärkt die Nachweiskette:
„Governance muss die Integration mit anderen Disziplinen unterstützen, z. B. Risiko, Recht, IT und HR; ISMS-Entscheidungen müssen auf ihre Quelle zurückführbar sein, z. B. Auditaufzeichnungen, Review-Protokolle oder Sitzungsprotokolle.“
Für KMU legt Governance Roles and Responsibilities Policy - SME Governance Roles and Responsibilities Policy - SME fest:
„Alle wesentlichen Sicherheitsentscheidungen, Ausnahmen und Eskalationen müssen aufgezeichnet und nachvollziehbar sein.“
Diese Klauseln wandeln die Aufsicht des Leitungsorgans von einer Besprechung in einen Prüfpfad um.
Die Nachweiskette nach ISO/IEC 27001:2022 für NIS2 Article 20
Ein Leitungsorgan kann NIS2 Article 20 über eine klare Nachweiskette nach ISO/IEC 27001:2022 operationalisieren.
Erstens: Kontext und Geltungsbereich festlegen. ISO/IEC 27001:2022 verlangt, dass die Organisation interne und externe Themen, interessierte Parteien, rechtliche, regulatorische und vertragliche Anforderungen, ISMS-Grenzen, Schnittstellen, Abhängigkeiten und interagierende Prozesse bestimmt. Für einen SaaS- oder Cloud-Anbieter sollte der ISMS-Geltungsbereich EU-Services, Cloud-Umgebungen, Supportprozesse, kritische Lieferanten, regulierte Kundensegmente und die NIS2-Exponierung ausdrücklich benennen.
Zweitens: Führung nachweisen. ISO/IEC 27001:2022 verlangt von der obersten Leitung, Sicherheitsziele an der strategischen Ausrichtung auszurichten, ISMS-Anforderungen in Geschäftsprozesse zu integrieren, Ressourcen bereitzustellen, die Bedeutung zu kommunizieren, Verantwortlichkeiten zuzuweisen und kontinuierliche Verbesserung zu fördern. Für NIS2 wird daraus der Nachweis, dass das Leitungsorgan Risikomanagementmaßnahmen im Bereich Cybersicherheit genehmigt und überwacht hat.
Drittens: wiederholbare Risikobeurteilung und Risikobehandlung durchführen. ISO/IEC 27001:2022 verlangt Risikokriterien, Risikoidentifizierung, Risikoverantwortliche, Analyse von Eintrittswahrscheinlichkeit und Auswirkungen, Behandlungsoptionen, Auswahl von Kontrollen, Abgleich mit Anhang A, eine Erklärung zur Anwendbarkeit, einen Risikobehandlungsplan und die Genehmigung des Restrisikos.
Der Zenith Blueprint, Phase Risikomanagement, Schritt 13, macht den Genehmigungspunkt ausdrücklich:
„Genehmigung durch die Leitung: Entscheidungen zur Risikobehandlung und die SoA sollten von der obersten Leitung überprüft und genehmigt werden. Die Leitung sollte über wesentliche Risiken und vorgeschlagene Behandlungen, zur Akzeptanz vorgeschlagene Risiken und die zur Umsetzung vorgesehenen Kontrollen informiert werden.“
Für NIS2 darf dieses Briefing keine einmalige Übung sein. Das Paket für das Leitungsorgan sollte aktuelle Top-Risiken, Trends, Fortschritt der Risikobehandlung, akzeptierte Restrisiken, überfällige Maßnahmen, Exponierung gegenüber kritischen Lieferanten, Vorfallthemen und wesentliche Wirksamkeitskennzahlen ausweisen.
Viertens: betreiben und Nachweise aufbewahren. ISO/IEC 27001:2022 Klausel 8.1 verlangt operative Planung und Steuerung. Anhang A-Kontrollen unterstützen Lieferantensicherheit, Cloud-Governance, Incident Response, Aufrechterhaltung des Geschäftsbetriebs, Schwachstellenmanagement, Backups, Protokollierung, Überwachung, sichere Entwicklung, Anwendungssicherheit, Architektur, Tests, Outsourcing, Funktionstrennung und Änderungsmanagement.
Fünftens: bewerten und verbessern. Internes Audit, Messung, Managementbewertung, Korrekturmaßnahmen und kontinuierliche Verbesserung machen aus einem Kontrollkatalog ein gesteuertes System.
Die unternehmensweite Information Security Policy Information Security Policy verankert diese Erwartung an die Managementbewertung:
„Tätigkeiten der Managementbewertung gemäß ISO/IEC 27001 Klausel 9.3 müssen mindestens jährlich durchgeführt werden und Folgendes umfassen:“
Der Wert liegt nicht nur darin, dass eine Besprechung stattfindet. Der Wert liegt darin, dass die Bewertung Nachweise erzeugt: Eingaben, Entscheidungen, Maßnahmen, Verantwortliche, Fristen und Nachverfolgung.
Die Audit and Compliance Monitoring Policy - SME Audit and Compliance Monitoring Policy - SME, Klausel 5.4.3, schließt den Regelkreis:
„Auditfeststellungen und Statusaktualisierungen müssen in den ISMS-Managementbewertungsprozess einbezogen werden.“
Das ist der Unterschied zwischen „wir hatten ein Audit“ und „die Leitung hat Auditergebnisse überprüft und Abhilfemaßnahmen veranlasst“.
Cross-Compliance-Zuordnung: NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019
NIS2 kommt selten allein. Ein Cloud-Anbieter kann personenbezogene Daten nach GDPR verarbeiten. Ein Fintech-Kunde kann DORA-getriebene Lieferantenanforderungen auferlegen. Ein US-Unternehmenskunde kann eine Ausrichtung an NIST CSF 2.0 verlangen. Ein Prüfungsausschuss des Leitungsorgans kann COBIT 2019 sprechen.
Die Antwort besteht nicht darin, separate Compliance-Ordner aufzubauen. Die Antwort besteht darin, ISO/IEC 27001:2022 als zentrales Nachweissystem zu nutzen.
Zenith Controls unterstützt Teams bei der Konsolidierung, indem es ISO/IEC 27002:2022 Kontrolle 5.4, Managementverantwortlichkeiten, standard-, regulierungs- und auditmethodenübergreifend zuordnet.
In Zenith Controls klassifiziert der Eintrag zu ISO/IEC 27002:2022 Kontrolle 5.4 „Management responsibilities“ den Kontrolltyp als „präventiv“, verknüpft ihn mit Vertraulichkeit, Integrität und Verfügbarkeit und ordnet ihn einer governanceorientierten operativen Fähigkeit zu.
Das ist relevant, weil NIS2 Article 20 präventive Governance ist. Genehmigung und Aufsicht durch die Leitung verringern die Wahrscheinlichkeit, dass Cyberrisiken unsichtbar, unterfinanziert oder ungesteuert bleiben.
Zenith Controls verknüpft Managementverantwortlichkeiten außerdem mit verwandten ISO/IEC 27002:2022-Kontrollen: 5.1 Richtlinien für Informationssicherheit, 5.2 Rollen und Verantwortlichkeiten für Informationssicherheit, 5.35 unabhängige Überprüfung der Informationssicherheit, 5.36 Einhaltung von Richtlinien, Regeln und Normen für Informationssicherheit sowie 5.8 Sicherheit im Projektmanagement. Rechenschaftspflicht des Leitungsorgans kann nicht isoliert bestehen. Sie benötigt Richtlinien, Rollen, Sicherstellung, Überwachung der Einhaltung und Integration auf Projektebene.
Die breitere Zuordnung ist besonders für die Berichterstattung an die Leitungsebene nützlich.
| Anforderungsthema | NIS2 | DORA | GDPR | NIST CSF 2.0 | COBIT 2019 | Clarysec-Nachweisfokus |
|---|---|---|---|---|---|---|
| Rechenschaftspflicht des Managements | Article 20 Genehmigung, Aufsicht, Schulung, Haftung | Articles 5 und 6 Verantwortung des Leitungsorgans und Rahmenwerk für das Management von IKT-Risiken | Article 5(2) Rechenschaftspflicht und Article 24 Verantwortung | GOVERN, insbesondere GV.RR, GV.RM und GV.OV | EDM03 Risikooptimierung | Sitzungsprotokolle des Leitungsorgans, Rollenmandate, Schulungsnachweise |
| Risikomanagementmaßnahmen | Article 21 technische, operative und organisatorische Maßnahmen | Rahmenwerk für das Management von IKT-Risiken | Article 32 Sicherheit der Verarbeitung | GOVERN, IDENTIFY, PROTECT | APO13 Managed Security | Risikoregister, Behandlungsplan, SoA |
| Vorfallmeldung | Article 23 Frühwarnung, Vorfallmeldung, Abschlussbericht | Articles 17 bis 20 Meldung schwerwiegender IKT-bezogener Vorfälle | Articles 33 und 34 Meldung von Verletzungen des Schutzes personenbezogener Daten, sofern anwendbar | RESPOND und RECOVER | DSS02 Managed Service Requests and Incidents | Eskalationsmatrix, Vorfall-Playbooks, Simulationen |
| Lieferanten-Governance | Article 21(2)(d) Sicherheit der Lieferkette | Articles 28 bis 30 IKT-Drittparteirisiko | Pflichten von Auftragsverarbeitern und Sicherheitspflichten | GV.SC Management von Cybersicherheitsrisiken in der Lieferkette | APO10 Managed Vendors | Lieferantenregister, gebotene Sorgfalt, vertragliche Kontrollen |
| Wirksamkeit und Sicherstellung | Article 21(2)(f) Richtlinien und Verfahren zur Wirksamkeitsbewertung | Article 6 Überprüfung des IKT-Risikomanagementrahmens und Auditerwartungen | Article 32(1)(d) regelmäßige Tests und Bewertung | GV.OV Aufsicht, ID.RA Risikobeurteilung, DE.CM kontinuierliche Überwachung | MEA01 und MEA03 Überwachung und Einhaltung | Internes Audit, Managementbewertung, Korrekturmaßnahmen |
DORA verdient besondere Aufmerksamkeit. NIS2 Article 4 erkennt an, dass sektorspezifische Rechtsakte der EU überlappende NIS2-Bestimmungen verdrängen können, wenn gleichwertige Maßnahmen zum Cybersicherheitsrisikomanagement oder zur Vorfallmeldung gelten. DORA ist das zentrale Beispiel für Finanzunternehmen. DORA gilt ab dem 17. Januar 2025 und schafft ein einheitliches Rahmenwerk für IKT-Risikomanagement, Vorfallmeldung, Resilienztests, Management von Drittparteirisiken und Aufsicht im Finanzsektor.
Ein SaaS- oder Cloud-Anbieter ist möglicherweise nicht unmittelbar wie eine Bank reguliert, DORA kann jedoch über Kundenverträge dennoch relevant werden. Finanzunternehmen müssen IKT-Drittparteirisiken steuern, Register von IKT-Serviceverträgen führen, gebotene Sorgfalt durchführen, Konzentrationsrisiken bewerten, Audit- und Inspektionsrechte aufnehmen, Kündigungsrechte definieren und Exit-Strategien vorhalten. Anbieter, die Finanzkunden bedienen, sollten daher mit Nachweisanfragen rechnen, die den Governance-Fragen des Leitungsorgans nach NIS2 sehr ähnlich sind.
GDPR ergänzt Rechenschaftspflicht für personenbezogene Daten. Article 5(2) verlangt, dass Verantwortliche für die Einhaltung verantwortlich sind und diese nachweisen können. Article 32 verlangt Sicherheit der Verarbeitung, einschließlich regelmäßiger Tests, Beurteilungen und Bewertungen der Wirksamkeit technischer und organisatorischer Maßnahmen. Wenn personenbezogene Daten betroffen sind, müssen Vorfall-Workflows die Bewertung von Verletzungen nach GDPR mit der Eskalation erheblicher Vorfälle nach NIS2 integrieren.
NIST CSF 2.0 ergänzt über die GOVERN-Funktion eine führungsgerechte Sprache. Es betont Organisationskontext, Risikomanagementstrategie, Rollen und Verantwortlichkeiten, Richtlinien, Aufsicht und Management von Risiken in der Lieferkette. COBIT 2019 ergänzt ein Governance-Vokabular, das Prüfungsausschüssen vertraut ist, insbesondere über EDM03 zur Risikooptimierung und MEA-Ziele für Überwachung und Sicherstellung.
Ein 90-Tage-Sprint für NIS2-Nachweise des Leitungsorgans
Ein praxisnaher Nachweissprint kann Organisationen helfen, schnell voranzukommen, ohne eine parallele Bürokratie aufzubauen.
Tage 1 bis 30: Rechenschaftspflicht festlegen
Beginnen Sie mit einem NIS2-Rechenschaftsregister, das Folgendes erfasst:
- Analyse der Einstufung der Einrichtung, einschließlich Begründung für wesentlich, wichtig, indirekte Exponierung oder außerhalb des Geltungsbereichs.
- Services im Geltungsbereich, etwa SaaS, Cloud, Managed Services, Rechenzentrum, DNS, Vertrauensdienste oder kommunikationsbezogene Services.
- EU-Mitgliedstaaten, in denen Services erbracht werden.
- Betroffene Kundensektoren, insbesondere Finanzdienstleistungen, Gesundheitswesen, Transport, Energie, öffentliche Verwaltung und digitale Infrastruktur.
- Anwendbare Verpflichtungen, einschließlich NIS2 Article 20, Article 21 und Article 23.
- Verwandte Verpflichtungen aus DORA, GDPR, Kundenverträgen und Cyberversicherung.
- Verantwortliche Person auf Managementebene und Berichtsfrequenz an das Leitungsorgan.
Verknüpfen Sie dies mit dem Kontext nach ISO/IEC 27001:2022, interessierten Parteien, dem Register der Verpflichtungen und dem ISMS-Geltungsbereich. Aktualisieren Sie anschließend die Risikobefugnismatrix anhand der Anforderung der Risk Management Policy, wonach Eskalationsschwellen für oberste Leitung oder Leitungsorgan definiert sein müssen.
Nützliche Eskalationsauslöser sind Restrisiken oberhalb der Risikobereitschaft, nicht akzeptierte kritische Schwachstellen nach Ablauf des SLA, Lieferantenkonzentrationsrisiken, ungelöste hohe Auditfeststellungen, Vorfälle, die eine NIS2-Meldung auslösen können, Ausnahmen von MFA-, Backup-, Protokollierungs-, Verschlüsselungs- oder Incident-Response-Anforderungen sowie wesentliche Änderungen der Cloud-Architektur.
Tage 31 bis 60: Risikobehandlung genehmigen
Nutzen Sie Zenith Blueprint Schritt 13, um ein Entscheidungspaket für das Leitungsorgan zum Risikobehandlungsplan und zur Erklärung zur Anwendbarkeit vorzubereiten. Das Paket sollte enthalten:
- Die Top 10 Cyberrisiken.
- Vorgeschlagene Behandlungsoption für jedes Risiko.
- Ausgewählte Kontrollgruppen.
- Restrisiko nach Behandlung.
- Risiken, die zur Akzeptanz vorgeschlagen werden.
- Erforderliche Budget- oder Ressourcenentscheidungen.
- Abhängigkeiten von Lieferanten, Recht, HR, Produkt und IT.
- Angeforderte Managemententscheidung.
Das Ergebnis sollte eine unterzeichnete oder protokollierte Genehmigung sein. Ein Foliensatz allein reicht nicht aus.
Ordnen Sie außerdem die Maßnahmen aus NIS2 Article 21 den Klauseln von ISO/IEC 27001:2022 und den Anhang A-Kontrollen zu. Dadurch kann die Organisation zeigen, dass NIS2 über das ISMS behandelt wird und nicht über eine abgekoppelte Checkliste.
Tage 61 bis 90: Vorfallmeldung testen und Nachweise überprüfen
NIS2 Article 23 verlangt eine gestufte Meldung erheblicher Vorfälle: Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden, Zwischenmeldungen, soweit erforderlich oder angefordert, und einen Abschlussbericht spätestens einen Monat nach der Meldung.
Führen Sie eine Tabletop-Übung mit dem Sponsor aus dem Leitungsorgan, CEO, CISO, Recht, Kommunikation, Kundenbetreuung und Betrieb durch. Nutzen Sie ein realistisches Szenario, etwa eine Fehlkonfiguration in der Cloud, die Kundenmetadaten offenlegt, die Serviceverfügbarkeit beeinträchtigt und einen regulierten Kunden betrifft.
Testen Sie, wer entscheidet, ob der Vorfall erheblich sein kann, wer die Rechtsabteilung einbindet, wer zuständige Behörden oder das CSIRT benachrichtigt, soweit erforderlich, wer Kundenkommunikation freigibt, wie Nachweise gesichert werden, wie GDPR-Pflichten bei Datenschutzverletzungen parallel bewertet werden und wie das Leitungsorgan in den ersten 24 Stunden aktualisiert wird.
Führen Sie anschließend eine formale Managementbewertung durch. Der Zenith Blueprint, Phase „Audit, Review & Improvement“, Schritt 28, erklärt warum:
„Managementbewertung ist nicht nur eine Präsentation; sie dient der Entscheidungsfindung.“
Diese Bewertung sollte Auditfeststellungen, Fortschritt der Risikobehandlung, Vorfallsbereitschaft, Lieferantenrisiken, Kennzahlen, Entscheidungen, zugewiesene Maßnahmen und Verantwortliche für die Nachverfolgung umfassen.
Die Managementbewertung, die tatsächlich funktioniert
Viele Managementbewertungen scheitern, weil sie als Statusberichte strukturiert sind. Eine NIS2-fähige Managementbewertung sollte eine Entscheidungssitzung sein.
Die Agenda sollte enthalten:
- Änderungen bei NIS2, DORA, GDPR sowie vertraglichen und kundenseitigen Anforderungen.
- Änderungen im Geschäftskontext, bei Services, Akquisitionen, Lieferanten, Cloud-Architektur und regulierten Kundensegmenten.
- Status der wichtigsten Informationssicherheitsrisiken und Restrisiko im Verhältnis zur Risikobereitschaft.
- Fortschritt des Risikobehandlungsplans und überfällige Maßnahmen.
- Sicherheitsvorfalltrends, erhebliche Ereignisse, Beinahe-Vorfälle und Meldebereitschaft.
- Lieferanten- und IKT-Abhängigkeitsrisiken, einschließlich Konzentrations- und Exit-Belangen.
- Ergebnisse interner Audits, externer Audits, Kundenbewertungen und Penetrationstests.
- Abschluss von Security-Awareness-Schulung und Führungskräfteschulung.
- Kennzahlen für Zugriffskontrolle, Schwachstellenmanagement, Backups, Protokollierung, Überwachung, sichere Entwicklung und Kontinuitätstests.
- Erforderliche Entscheidungen, einschließlich Risikoakzeptanz, Budget, Personal, Richtlinienausnahmen, Lieferantenabhilfe und Kontrollverbesserungen.
Führungskräfteschulung ist besonders wichtig. NIS2 Article 20 verlangt von Mitgliedern des Leitungsorgans, Schulungen zu absolvieren. Die Information Security Awareness and Training Policy Information Security Awareness and Training Policy, Klausel 5.1.2.4, enthält ausdrücklich Schulungsthemen für Führungskräfte:
„Führungskräfte, z. B. Governance, Risikoakzeptanz und rechtliche Verpflichtungen“
Cyber-Schulungen für Führungskräfte sollten sich auf Entscheidungsbefugnisse, Haftung, Eskalation, Risikobereitschaft, Krisen-Governance, Vorfallmeldung und regulatorische Verpflichtungen konzentrieren. Sie dürfen nicht auf Phishing-Sensibilisierung beschränkt bleiben.
Wie Auditoren und Kunden die Aufsicht durch das Leitungsorgan prüfen werden
Unterschiedliche Prüfer verwenden unterschiedliche Sprache, testen aber dieselbe Grundfrage: Wird Cybersicherheit gesteuert?
Zenith Controls ist wertvoll, weil es Zuordnungen zu Auditmethoden enthält. Für Managementverantwortlichkeiten verweist es auf Auditgrundsätze und -durchführung nach ISO/IEC 19011:2018, ISMS-Auditpraktiken nach ISO/IEC 27007:2020, ISO/IEC 27001:2022 Klausel 5.1, COBIT 2019 EDM01 und EDM03, ISACA ITAF Section 1401 sowie NIST SP 800-53A PM-1 und PM-2. Für unabhängige Überprüfung ordnet es ISO/IEC 27001:2022 Klauseln 9.2 und 9.3, Auditplanung und Nachweispraktiken nach ISO/IEC 27007, ISACA ITAF Section 2400 und NIST-Bewertungsmethoden zu. Für die Einhaltung von Richtlinien ordnet es ISO/IEC 27001:2022 Klauseln 9.1, 9.2 und 10.1, Nachweiserhebung nach ISO/IEC 19011, COBIT 2019 MEA01 und NIST-Bewertungen zur kontinuierlichen Überwachung zu.
| Prüferperspektive | Was gefragt wird | Erwartete Nachweise | Häufiges Versagen |
|---|---|---|---|
| ISO/IEC 27001:2022-Auditor | Wie weist die oberste Leitung Führung nach, genehmigt Risikobehandlung und überprüft die ISMS-Leistung? | Richtlinienfreigaben, Risikoregister, SoA-Genehmigung, Protokolle der Managementbewertung, Ergebnisse interner Audits | Managementbewertung existiert, enthält aber keine Entscheidungen oder Maßnahmenverfolgung |
| NIS2-fokussierter Prüfer | Hat das Leitungsorgan Cybersicherheitsmaßnahmen genehmigt und deren Umsetzung überwacht? | Sitzungsprotokolle des Leitungsorgans, Eskalationsmatrix, Schulungsnachweise der Geschäftsleitung, Article 21-Baseline-Zuordnung | Sicherheitsmaßnahmen wurden nur durch den CISO genehmigt, ohne Nachvollziehbarkeit zum Leitungsorgan |
| NIST CSF 2.0-Prüfer | Sind Governance-Ergebnisse, Risikobereitschaft, Rollen, Ressourcen, Aufsicht und Lieferkettenrisiken in das Enterprise Risk Management integriert? | Aktuelle und Zielprofile, Lückenplan, Berichterstattung an die Leitung, Kennzahlen | NIST wird als Checkliste ohne Governance-Verantwortung genutzt |
| COBIT 2019- oder ISACA-Auditor | Bewertet, steuert und überwacht die Governance das Cyberrisikomanagement? | Governance-Mandate, Risikobereitschaft, Managementberichte, Assurance-Ergebnisse | Das Leitungsorgan erhält technische Kennzahlen, aber keinen Kontext für Risikoentscheidungen |
| DORA-Kunde oder Prüfer aus dem Finanzsektor | Werden IKT-Risiken, Vorfälle, Resilienz und Drittparteienabhängigkeiten gesteuert und dokumentiert? | IKT-Abhängigkeitsübersicht, Lieferantenregister, gebotene Sorgfalt, Auditrechte, Vorfallslebenszyklus | Lieferantenrisiko basiert nur auf Fragebögen, ohne Konzentrations- oder Exit-Analyse |
| GDPR-Auditor oder Datenschutzprüfer | Kann die Organisation Sicherheit und Rechenschaftspflicht für die Verarbeitung personenbezogener Daten nachweisen? | Datenflussübersichten, Modell der Rechtsgrundlagen, Prozess zur Bewertung von Datenschutzverletzungen, Sicherheitskontrollen | Datenschutz- und Sicherheitsnachweise sind getrennt und inkonsistent |
Die Lehre ist einfach. Rechenschaftspflicht des Leitungsorgans wird nicht allein durch Anwesenheit belegt. Sie wird durch informierte Entscheidungen, dokumentierte Genehmigungen, risikobasierte Priorisierung, Ressourcenzuweisung und Nachverfolgung belegt.
Häufige Fallstricke, die die Nachweiskette unterbrechen
Organisationen, die mit der Rechenschaftspflicht des Leitungsorgans nach NIS2 kämpfen, fallen meist in vorhersehbare Muster.
Erstens verwechseln sie den technischen Betrieb von Kontrollen mit Governance. MFA-Abdeckung, SIEM-Warnmeldungen, EDR-Bereitstellung und Backup-Erfolgsquoten sind wichtig, aber das Leitungsorgan benötigt Risikokontext, Behandlungsentscheidungen und Sicherstellung, dass Kontrollen wirksam sind.
Zweitens genehmigen sie Richtlinien, aber keine Risikobehandlung. Eine unterschriebene Sicherheitsrichtlinie belegt nicht, dass das Leitungsorgan verhältnismäßige Cybersicherheitsmaßnahmen genehmigt hat. Der Risikobehandlungsplan und die SoA sind stärkere Nachweise, weil sie Risiken, Kontrollen, Restrisiko und Managementgenehmigung verbinden.
Drittens fehlen Eskalationsschwellen. Ohne Risikobefugnismatrix hängt Eskalation von Personen ab. NIS2-Governance benötigt objektive Auslöser.
Viertens trennen sie Incident Response von regulatorischer Berichterstattung. Melde-Workflows für NIS2, DORA und GDPR müssen vor einer Krise integriert sein.
Fünftens ignorieren sie Lieferanten-Governance. NIS2 Article 21 umfasst Sicherheit der Lieferkette und Überlegungen zu Schwachstellen von Lieferanten. DORA-getriebene Kunden können eine tiefere IKT-Drittparteien-Governance erwarten, einschließlich gebotener Sorgfalt, Auditrechten, Konzentrationsrisiko, Kündigungsrechten und Exit-Strategien.
Sechstens schulen sie Führungskräfte nicht. Cyber-Schulung für Führungskräfte ist unter NIS2 kein optionales Feigenblatt. Sie ist Teil der Governance-Nachweiskette.
Wie ein guter Zielzustand aussieht
Nach 90 Tagen sollte ein belastbarer NIS2-Nachweisordner für das Leitungsorgan Folgendes enthalten:
- Anwendbarkeitsbewertung.
- ISMS-Geltungsbereich und Register der Verpflichtungen.
- Erklärung zum Führungsengagement.
- Risikobereitschaft und Toleranzschwellen.
- Risikobefugnismatrix.
- Cyber-Risikoregister.
- Risikobehandlungsplan.
- Erklärung zur Anwendbarkeit.
- Protokolle der Genehmigung durch das Leitungsorgan.
- Schulungsnachweise der Geschäftsleitung.
- Bericht zur Tabletop-Übung für Vorfälle.
- Lieferantenrisiko-Dashboard.
- Bericht des internen Audits.
- Protokoll der Managementbewertung und Aufgabenverfolgungssystem.
Dieser Ordner beantwortet den Kundenfragebogen, den Maria am Montagmorgen erhalten hat. Noch wichtiger: Er hilft dem Leitungsorgan, Cyberrisiken zu steuern, bevor ein Vorfall, ein Audit oder eine Aufsichtsbehörde die Organisation öffentlich prüft.
NIS2-Haftung des Leitungsorgans in auditbereite Governance überführen
NIS2 hat die Cybersicherheitsdiskussion verändert. Leitungsorgane müssen Risikomanagementmaßnahmen im Bereich Cybersicherheit genehmigen, die Umsetzung überwachen und Schulungen absolvieren. Article 21 verlangt ein integriertes Bündel technischer, operativer und organisatorischer Maßnahmen. Article 23 verdichtet die Vorfallmeldung zu einer gestuften Zeitachse, die Vorbereitung vor der Krise erfordert.
ISO/IEC 27001:2022 liefert das Managementsystem. Clarysec liefert die Umsetzungsroute, Richtliniensprache, Cross-Compliance-Zuordnungen und das Modell für Auditnachweise.
Wenn Ihr Leitungsorgan fragt: „Was müssen wir genehmigen, und wie weisen wir Aufsicht nach?“, beginnen Sie mit drei Maßnahmen:
- Nutzen Sie Zenith Blueprint Schritt 3, Schritt 13 und Schritt 28, um Führungsengagement, Genehmigung der Risikobehandlung und Managementbewertung zu strukturieren.
- Nutzen Sie Clarysec-Richtlinien wie Risk Management Policy, Governance Roles and Responsibilities Policy, Information Security Policy und SME-Äquivalente, um Rechenschaftspflicht und Nachvollziehbarkeit zu formalisieren.
- Nutzen Sie Zenith Controls, um die Aufsicht des Leitungsorgans nach NIS2 auf ISO/IEC 27001:2022, ISO/IEC 27002:2022, DORA, GDPR, NIST CSF 2.0, COBIT 2019 und Erwartungen aus Auditmethoden abzubilden.
Clarysec kann Ihnen helfen, das Paket für das Leitungsorgan aufzubauen, die ISMS-Nachweiskette zu aktualisieren, die Managementbewertung vorzubereiten und NIS2-Rechenschaftspflicht in einen wiederholbaren Governance-Prozess für Cyberrisiken zu überführen, den Auditoren, Kunden und Führungskräfte verstehen. Laden Sie die relevanten Clarysec-Toolkits herunter oder fordern Sie eine Bewertung an, um die Haftung des Leitungsorgans in auditbereite Nachweise umzusetzen.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


