⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

NIS2-Haftung von Leitungsorganen: Nachweise mit ISO 27001

Igor Petreski
14 min read
Diagramm zur NIS2-Haftung des Leitungsorgans und zu Governance-Nachweisen nach 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:

  1. Die Organisation hat bewertet, ob NIS2 anwendbar ist, und die Grundlage dokumentiert.
  2. Das Leitungsorgan oder die oberste Leitung hat das Rahmenwerk für Cybersicherheitsrisikomanagement genehmigt.
  3. Risikobereitschaft und Toleranzschwellen wurden definiert.
  4. Hohe Cyberrisiken wurden eskaliert und überprüft.
  5. Entscheidungen zur Risikobehandlung wurden genehmigt, einschließlich akzeptierter Restrisiken.
  6. Verfahren zur Vorfallmeldung berücksichtigen, sofern anwendbar, 24-Stunden-, 72-Stunden- und Abschlussberichtspflichten.
  7. Lieferanten- und Cloud-Abhängigkeiten sind erfasst und gesteuert.
  8. Die Managementbewertung umfasst Auditfeststellungen, Sicherheitsvorfalltrends, Kennzahlen und Verbesserungsmaßnahmen.
  9. Führungskräfte haben Schulungen erhalten, die ihrer Rechenschaftspflicht entsprechen.
  10. 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.

NachweisartefaktBeantwortete Frage zur Rechenschaftspflicht des LeitungsorgansISO/IEC 27001:2022-AnkerClarysec-Quelle
NIS2-AnwendbarkeitsbewertungSind wir wesentlich, wichtig, indirekt exponiert oder außerhalb des Geltungsbereichs?Klauseln 4.1 bis 4.4Zenith Blueprint, Schritt 1 und Schritt 2
ISMS-Geltungsbereich und AbhängigkeitsübersichtWelche Services, Standorte, Lieferanten, Schnittstellen und Prozesse werden gesteuert?Klauseln 4.1 bis 4.4Zenith Blueprint, ISMS-Foundation-Phase
Cyber-RisikoregisterWas sind unsere höchsten Cyberrisiken und wer ist dafür verantwortlich?Klauseln 6.1.1 und 6.1.2Risk Management Policy
Risikobehandlungsplan und SoAWelche Kontrollen wurden ausgewählt, warum, und wer hat das Restrisiko genehmigt?Klausel 6.1.3Zenith Blueprint, Schritt 13
Sitzungsprotokolle des Leitungsorgans und EntscheidungsprotokollHat die Leitung Maßnahmen genehmigt, hinterfragt und überwacht?Klauseln 5.1, 5.3, 9.3Governance Roles and Responsibilities Policy
Verfahren zur Vorfalleskalation und -meldungKönnen wir die gestuften NIS2-Meldefristen einhalten?Klauseln 8.1, 9.1, Anhang A-Kontrollen zu VorfällenIncident-Response-Toolkit und Managementbewertung
Lieferantenrisiko-DashboardWerden kritische Lieferanten und Cloud-Abhängigkeiten gesteuert?Klausel 8.1 und Anhang A-LieferantenkontrollenZenith Controls Cross-Mapping
Schulungsnachweis für FührungskräfteHaben Mitglieder des Leitungsorgans geeignete Schulungen absolviert?Klausel 7.2 und SensibilisierungskontrollenInformation Security Awareness and Training Policy
Ergebnisse aus internem Audit und ManagementbewertungWird die Umsetzung unabhängig geprüft und verbessert?Klauseln 9.2, 9.3, 10.1Audit 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.

AnforderungsthemaNIS2DORAGDPRNIST CSF 2.0COBIT 2019Clarysec-Nachweisfokus
Rechenschaftspflicht des ManagementsArticle 20 Genehmigung, Aufsicht, Schulung, HaftungArticles 5 und 6 Verantwortung des Leitungsorgans und Rahmenwerk für das Management von IKT-RisikenArticle 5(2) Rechenschaftspflicht und Article 24 VerantwortungGOVERN, insbesondere GV.RR, GV.RM und GV.OVEDM03 RisikooptimierungSitzungsprotokolle des Leitungsorgans, Rollenmandate, Schulungsnachweise
RisikomanagementmaßnahmenArticle 21 technische, operative und organisatorische MaßnahmenRahmenwerk für das Management von IKT-RisikenArticle 32 Sicherheit der VerarbeitungGOVERN, IDENTIFY, PROTECTAPO13 Managed SecurityRisikoregister, Behandlungsplan, SoA
VorfallmeldungArticle 23 Frühwarnung, Vorfallmeldung, AbschlussberichtArticles 17 bis 20 Meldung schwerwiegender IKT-bezogener VorfälleArticles 33 und 34 Meldung von Verletzungen des Schutzes personenbezogener Daten, sofern anwendbarRESPOND und RECOVERDSS02 Managed Service Requests and IncidentsEskalationsmatrix, Vorfall-Playbooks, Simulationen
Lieferanten-GovernanceArticle 21(2)(d) Sicherheit der LieferketteArticles 28 bis 30 IKT-DrittparteirisikoPflichten von Auftragsverarbeitern und SicherheitspflichtenGV.SC Management von Cybersicherheitsrisiken in der LieferketteAPO10 Managed VendorsLieferantenregister, gebotene Sorgfalt, vertragliche Kontrollen
Wirksamkeit und SicherstellungArticle 21(2)(f) Richtlinien und Verfahren zur WirksamkeitsbewertungArticle 6 Überprüfung des IKT-Risikomanagementrahmens und AuditerwartungenArticle 32(1)(d) regelmäßige Tests und BewertungGV.OV Aufsicht, ID.RA Risikobeurteilung, DE.CM kontinuierliche ÜberwachungMEA01 und MEA03 Überwachung und EinhaltungInternes 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:

  1. Änderungen bei NIS2, DORA, GDPR sowie vertraglichen und kundenseitigen Anforderungen.
  2. Änderungen im Geschäftskontext, bei Services, Akquisitionen, Lieferanten, Cloud-Architektur und regulierten Kundensegmenten.
  3. Status der wichtigsten Informationssicherheitsrisiken und Restrisiko im Verhältnis zur Risikobereitschaft.
  4. Fortschritt des Risikobehandlungsplans und überfällige Maßnahmen.
  5. Sicherheitsvorfalltrends, erhebliche Ereignisse, Beinahe-Vorfälle und Meldebereitschaft.
  6. Lieferanten- und IKT-Abhängigkeitsrisiken, einschließlich Konzentrations- und Exit-Belangen.
  7. Ergebnisse interner Audits, externer Audits, Kundenbewertungen und Penetrationstests.
  8. Abschluss von Security-Awareness-Schulung und Führungskräfteschulung.
  9. Kennzahlen für Zugriffskontrolle, Schwachstellenmanagement, Backups, Protokollierung, Überwachung, sichere Entwicklung und Kontinuitätstests.
  10. 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üferperspektiveWas gefragt wirdErwartete NachweiseHäufiges Versagen
ISO/IEC 27001:2022-AuditorWie weist die oberste Leitung Führung nach, genehmigt Risikobehandlung und überprüft die ISMS-Leistung?Richtlinienfreigaben, Risikoregister, SoA-Genehmigung, Protokolle der Managementbewertung, Ergebnisse interner AuditsManagementbewertung existiert, enthält aber keine Entscheidungen oder Maßnahmenverfolgung
NIS2-fokussierter PrüferHat das Leitungsorgan Cybersicherheitsmaßnahmen genehmigt und deren Umsetzung überwacht?Sitzungsprotokolle des Leitungsorgans, Eskalationsmatrix, Schulungsnachweise der Geschäftsleitung, Article 21-Baseline-ZuordnungSicherheitsmaßnahmen wurden nur durch den CISO genehmigt, ohne Nachvollziehbarkeit zum Leitungsorgan
NIST CSF 2.0-PrüferSind Governance-Ergebnisse, Risikobereitschaft, Rollen, Ressourcen, Aufsicht und Lieferkettenrisiken in das Enterprise Risk Management integriert?Aktuelle und Zielprofile, Lückenplan, Berichterstattung an die Leitung, KennzahlenNIST wird als Checkliste ohne Governance-Verantwortung genutzt
COBIT 2019- oder ISACA-AuditorBewertet, steuert und überwacht die Governance das Cyberrisikomanagement?Governance-Mandate, Risikobereitschaft, Managementberichte, Assurance-ErgebnisseDas Leitungsorgan erhält technische Kennzahlen, aber keinen Kontext für Risikoentscheidungen
DORA-Kunde oder Prüfer aus dem FinanzsektorWerden IKT-Risiken, Vorfälle, Resilienz und Drittparteienabhängigkeiten gesteuert und dokumentiert?IKT-Abhängigkeitsübersicht, Lieferantenregister, gebotene Sorgfalt, Auditrechte, VorfallslebenszyklusLieferantenrisiko basiert nur auf Fragebögen, ohne Konzentrations- oder Exit-Analyse
GDPR-Auditor oder DatenschutzprüferKann die Organisation Sicherheit und Rechenschaftspflicht für die Verarbeitung personenbezogener Daten nachweisen?Datenflussübersichten, Modell der Rechtsgrundlagen, Prozess zur Bewertung von Datenschutzverletzungen, SicherheitskontrollenDatenschutz- 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:

  1. Nutzen Sie Zenith Blueprint Schritt 3, Schritt 13 und Schritt 28, um Führungsengagement, Genehmigung der Risikobehandlung und Managementbewertung zu strukturieren.
  2. 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.
  3. 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

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

Share this article

Related Articles

NIS2- und DORA-Kontaktregister als ISO 27001-Nachweis

NIS2- und DORA-Kontaktregister als ISO 27001-Nachweis

Ein regulatorisches Kontaktregister ist keine administrative Nebensache mehr. Für NIS2, DORA, GDPR und ISO/IEC 27001:2022 ist es ein operativer Nachweis dafür, dass Ihre Organisation die richtige Behörde, Aufsicht, den richtigen Lieferanten oder die zuständige Führungskraft benachrichtigen kann, bevor die Frist abläuft.

NIS2 2024/2690: ISO 27001-Zuordnung für Cloud-Anbieter

NIS2 2024/2690: ISO 27001-Zuordnung für Cloud-Anbieter

Eine einheitliche Control-Zuordnung der NIS2-Durchführungsverordnung 2024/2690 zu ISO/IEC 27001:2022 für Cloud-, MSP-, MSSP- und Rechenzentrumsanbieter. Enthält Clarysec-Richtlinienklauseln, Auditnachweise, die Ausrichtung an DORA und GDPR sowie einen praktischen Umsetzungsfahrplan.