NIS2-Nachweiszuordnung mit ISO 27001:2022 für 2026

Das NIS2-Problem 2026 ist nicht Sensibilisierung, sondern Nachweisbarkeit

Es ist Montagmorgen, 08:35 Uhr. Maria, die neu ernannte CISO eines schnell wachsenden B2B-Cloud- und Managed-Service-Providers, nimmt mit einer umfangreichen NIS2-Lückenanalyse auf ihrem Laptop an der quartalsweisen Risikositzung des Leitungsorgans teil. Die erste Folie wirkt beruhigend. Richtlinien sind vorhanden. Eine Risikobeurteilung liegt vor. Incident Response ist dokumentiert. Lieferanten sind aufgelistet. Schwachstellenscans laufen monatlich.

Dann stellt der Vorsitzende die Frage, die die Sitzung verändert:

„Können wir nachweisen, dass diese Maßnahmen im letzten Quartal wirksam betrieben wurden, und können wir zeigen, welche ISO 27001:2022-Maßnahmen, Verantwortlichkeiten und Aufzeichnungen jede NIS2-Verpflichtung unterstützen?“

Der Raum wird still.

Die Rechtsabteilung weiß, dass das Unternehmen in den Anwendungsbereich der NIS2 fällt, weil es Managed-IKT- und Cloud-Services für EU-Kunden erbringt. Das Compliance-Team weiß, dass Article 21 technische, operative und organisatorische Maßnahmen zum Management von Cybersicherheitsrisiken verlangt. Der Betrieb weiß, dass das Team Systeme patcht, Lieferanten prüft und Protokolle überwacht. Die Nachweise sind jedoch über Ticketsysteme, SIEM-Exporte, Richtlinienordner, Tabellen, Cloud-Konsolen, Lieferantenportale und Sitzungsnotizen verteilt.

Niemand kann kurzfristig eine belastbare Kette von NIS2 Article 21 zu ISO 27001:2022-Geltungsbereich, Risiko, Maßnahme, Richtlinie, Verantwortlichkeit, Verfahren, Betriebsaufzeichnung und Auditfeststellung darstellen.

Das ist die eigentliche Herausforderung für 2026.

Viele Organisationen fragen nicht mehr: „Fallen wir in den NIS2-Geltungsbereich?“ Sie stellen eine schwierigere Frage: „Können wir nachweisen, dass unsere technischen NIS2-Maßnahmen tatsächlich funktionieren?“ Die Antwort darf keine einmalige Mapping-Tabelle sein. Sie muss ein lebendiges Betriebsmodell im Informationssicherheitsmanagementsystem sein, in dem rechtliche Verpflichtungen in Risiken, Richtlinien, Maßnahmen, Verantwortlichkeiten, Nachweise und kontinuierliche Verbesserung übersetzt werden.

Das Modell von Clarysec nutzt ISO/IEC 27001:2022 als Rückgrat des Managementsystems, NIS2 Article 21 als Satz regulatorischer Verpflichtungen, Richtlinienklauseln als operatives Regelwerk, Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren als Umsetzungspfad und Zenith Controls: Der Leitfaden für Cross-Compliance als Cross-Compliance-Zuordnung für ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF und COBIT-orientierte Assurance.

Beginnen Sie mit dem Geltungsbereich, denn NIS2-Nachweise entstehen vor den Maßnahmen

Ein häufiger NIS2-Fehler besteht darin, direkt mit MFA, Protokollierung, Incident Response und Schwachstellenmanagement zu beginnen, bevor der Geltungsbereich in Bezug auf Unternehmen, Services und Rechtsordnungen bestätigt wurde.

NIS2 gilt für erfasste öffentliche und private Einrichtungen in regulierten Sektoren, die Größen- und Tätigkeitskriterien erfüllen; bestimmte Einrichtungstypen sind unabhängig von ihrer Größe erfasst. Relevante digitale und IKT-Kategorien umfassen Cloud-Computing-Service-Provider, Rechenzentrumsdiensteanbieter, Content-Delivery-Network-Anbieter, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsdienste, Managed Service Provider (MSPs), Managed Security Service Provider (MSSPs), Online-Marktplätze, Online-Suchmaschinen und Plattformen sozialer Netzwerke.

Für Cloud-Anbieter, SaaS-Plattformen, MSPs, MSSPs und Anbieter digitaler Infrastruktur ist diese Abgrenzung nicht theoretisch. Article 3 verpflichtet die Mitgliedstaaten, zwischen wesentlichen und wichtigen Einrichtungen zu unterscheiden. Article 27 verpflichtet ENISA, ein Register für mehrere digitale und IKT-Anbieter zu führen, darunter DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Domainnamen-Registrierungsdiensten, Cloud-Computing-Service-Provider, Rechenzentrumsdiensteanbieter, Content-Delivery-Network-Anbieter, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Online-Suchmaschinen und Plattformen sozialer Netzwerke.

ISO 27001:2022 liefert die passende Struktur. Clauses 4.1 bis 4.4 verlangen, dass die Organisation externe und interne Themen, interessierte Parteien, Anforderungen, Schnittstellen und Abhängigkeiten versteht und anschließend den ISMS-Geltungsbereich festlegt. NIS2 muss hier erfasst werden und darf nicht in einem Rechtsvermerk verbleiben.

Eine praxistaugliche NIS2-Geltungsbereichsaufzeichnung sollte Folgendes enthalten:

• Analyse der Rechtseinheit und EU-Niederlassung
• NIS2-Sektor und Servicekategorie
• Status als wesentliche oder wichtige Einrichtung, sofern durch nationales Recht oder behördliche Einstufung bestätigt
• Relevanz für das ENISA-Register, sofern anwendbar
• Kritische Services, die für Kunden erbracht werden
• Netzwerk- und Informationssysteme, die diese Services unterstützen
• Abhängigkeiten von Cloud-, Rechenzentrums-, Telekommunikations-, Sicherheitsüberwachungs-, Identitäts- und Softwareanbietern
• Bezüge zu DORA, GDPR, Kundenverträgen und branchenspezifischen Verpflichtungen
• Nachweisablagen, Systemverantwortliche und Überprüfungsrhythmus

An dieser Stelle muss auch DORA sauber abgegrenzt werden. NIS2 erkennt an, dass dort, wo ein sektorspezifischer EU-Rechtsakt gleichwertige Verpflichtungen zum Management von Cybersicherheitsrisiken oder zur Meldung von Vorfällen auferlegt, dieses sektorspezifische Regime anstelle der entsprechenden NIS2-Bestimmungen gilt. Für erfasste Finanzunternehmen ist DORA in der Regel das maßgebliche Regime für Cybersicherheit und IKT-Vorfallmeldungen. DORA gilt seit dem 17. Januar 2025 und umfasst IKT-Risikomanagement, Vorfallmeldung, Tests der digitalen operationalen Resilienz, IKT-Drittparteienrisiken und die Aufsicht über kritische IKT-Drittdienstleister.

Eine Fintech-Gruppe kann daher innerhalb einer Konzernstruktur unterschiedliche Compliance-Behandlungen haben. Die Zahlungseinheit kann primär DORA unterliegen. Die MSP-Tochter kann direkt unter NIS2 fallen. Eine gemeinsame Cloud-Plattform kann beide unterstützen. Die reife Antwort sind keine doppelten Kontrollen. Sie ist ein ISMS-Nachweismodell, das mehrere regulatorische Perspektiven bedienen kann.

ISO 27001:2022 als Betriebssystem für die NIS2-Einhaltung

NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, um Risiken für Netzwerk- und Informationssysteme zu steuern und Auswirkungen von Vorfällen auf Leistungsempfänger und andere Services zu verhindern oder zu minimieren.

ISO 27001:2022 eignet sich sehr gut, um diese Anforderung zu operationalisieren, weil sie drei Disziplinen erzwingt.

Erstens: Governance. Clauses 5.1 bis 5.3 verlangen Verpflichtung der obersten Leitung, Ausrichtung an der strategischen Richtung, Bereitstellung von Ressourcen, Kommunikation, Zuweisung von Verantwortlichkeiten und eine dokumentierte Informationssicherheitsleitlinie. Dies entspricht unmittelbar NIS2 Article 20, der verlangt, dass Leitungsorgane Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen erhalten.

Zweitens: Risikobehandlung. Clauses 6.1.1 bis 6.1.3 verlangen einen wiederholbaren Risikobeurteilungsprozess, Risikoverantwortliche, Risikobewertung, Behandlungsoptionen, Maßnahmenselektion, eine Anwendbarkeitserklärung (SoA), einen Risikobehandlungsplan und die Genehmigung des Restrisikos.

Drittens: operative Steuerung. Clause 8.1 verlangt, dass die Organisation ISMS-Prozesse plant, umsetzt und steuert, dokumentierte Informationen aufrechterhält, Änderungen kontrolliert und extern bereitgestellte Prozesse, Produkte und Services mit Relevanz für das ISMS steuert.

Dadurch wird NIS2 von einer rechtlichen Checkliste zu einem operativen Kontrollmodell.

Jede Zeile benötigt einen Verantwortlichen, eine Aufzeichnungsquelle und eine Stichprobenmethode. Fehlen diese Angaben, hat die Organisation eine Kontrollabsicht, aber keine wirksame Kontrolle.

Richtlinien machen NIS2 zu operativem Verhalten

Richtlinien werden häufig wie Vorlagen behandelt. Für NIS2 ist das gefährlich. Eine Aufsichtsbehörde oder ein Auditor wird sich von einem Richtlinienordner nicht überzeugen lassen, wenn die Richtlinien keine Verantwortlichkeiten zuweisen, Aufzeichnungen definieren, mit Risiken verknüpft sind und Nachweise erzeugen.

Die Enterprise-Richtlinie zur rechtlichen und regulatorischen Einhaltung legt in Clause 6.2.1 die Grundlage fest:

Alle gesetzlichen und regulatorischen Verpflichtungen müssen innerhalb des Information Security Management System (ISMS) bestimmten Richtlinien, Maßnahmen und Verantwortlichen zugeordnet werden.

Diese Klausel ist die Brücke zwischen NIS2 und ISO 27001:2022. NIS2 Article 21 wird nicht lediglich als externe Anforderung aufgelistet. Er wird in Richtlinienverpflichtungen zerlegt, Maßnahmen zugeordnet, Verantwortlichen zugewiesen und anhand von Nachweisen geprüft.

Für kleinere Organisationen hält die SME-Richtlinie zur rechtlichen und regulatorischen Einhaltung dasselbe Konzept schlank. Clause 5.1.1 verlangt:

Der GM muss ein einfaches, strukturiertes Compliance-Register führen, das Folgendes auflistet:

Der Satz ist bewusst praxisorientiert. SMEs benötigen zu Beginn keine komplexe GRC-Implementierung. Sie benötigen ein Compliance-Register, das Verpflichtung, Anwendbarkeit, Verantwortlichen, Richtlinie, Nachweis und Überprüfungsrhythmus erfasst.

Die Risikobehandlung überführt die Verpflichtung anschließend in Maßnahmen. Die Enterprise-Risikomanagement-Richtlinie, Clause 6.4.2, legt fest:

Der Risikobeauftragte muss sicherstellen, dass Behandlungen realistisch, zeitgebunden und den ISO/IEC 27001 Annex A-Maßnahmen zugeordnet sind.

Für SMEs gibt die Risikomanagement-Richtlinie - SME, Clause 5.1.2, den minimal tragfähigen Risikodatensatz vor:

Jeder Risikoeintrag muss Folgendes enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichen und Behandlungsplan.

Diese Klauseln sind wichtig, weil NIS2 ausdrücklich risikobasiert und verhältnismäßig ist. Article 21 erwartet, dass Maßnahmen den Stand der Technik, relevante Standards, Umsetzungskosten, Risikoexposition, Größe, Eintrittswahrscheinlichkeit und Schwere von Vorfällen einschließlich gesellschaftlicher und wirtschaftlicher Auswirkungen berücksichtigen. Ein Risikoregister ohne Verantwortliche und Behandlungspläne kann Verhältnismäßigkeit nicht nachweisen.

Die Enterprise-Informationssicherheitsleitlinie vervollständigt das Nachweisprinzip in Clause 6.6.1:

Alle umgesetzten Maßnahmen müssen auditierbar sein, durch dokumentierte Verfahren unterstützt werden und durch aufbewahrte Nachweise des Betriebs belegt sein.

Das ist der Unterschied zwischen einem NIS2-Programm und einem NIS2-Nachweisprogramm.

Der Clarysec-Weg vom Mapping zum Betrieb

Der Zenith Blueprint ist wertvoll, weil er die Denkweise von Auditoren abbildet. Sie fragen nicht nur, ob eine Maßnahme existiert. Sie fragen, warum sie ausgewählt wurde, wo sie dokumentiert ist, wie sie funktioniert, wer verantwortlich ist, welche Nachweise ihre Wirksamkeit belegen und wie die Organisation sie verbessert.

In der Phase Risikomanagement fordert Step 13 Teams auf, Nachvollziehbarkeit zwischen Risiken, Maßnahmen und Klauseln herzustellen:

✓ Maßnahmen Risiken zuordnen: Im Behandlungsplan Ihres Risikoregisters haben Sie für jedes Risiko bestimmte Maßnahmen aufgeführt. Sie können jedem Risiko eine Spalte „Annex A-Maßnahmenreferenz“ hinzufügen und dort die Maßnahmennummern aufführen.

Für NIS2 bedeutet dies, dass Risikoregister und Anwendbarkeitserklärung zeigen sollten, warum Maßnahmen wie 8.8 Management technischer Schwachstellen, 5.19 Informationssicherheit in Lieferantenbeziehungen und 5.24 Planung und Vorbereitung des Vorfallmanagements anwendbar sind.

Step 14 des Zenith Blueprint macht die regulatorische Zuordnung ausdrücklich:

Für jede Regulierung können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen, etwa als Anhang zu einem Bericht, die die wichtigsten Sicherheitsanforderungen der Regulierung und die entsprechenden Maßnahmen/Richtlinien in Ihrem ISMS aufführt.

Dies verhindert Fragmentierung. Sicherheit personenbezogener Daten nach GDPR, NIS2-Vorfallmeldung, DORA-Tests der IKT-Resilienz und Sicherheitszusagen gegenüber Kunden können alle auf denselben Nachweisen beruhen: Berechtigungsüberprüfungen, Schwachstellenbehebung, Protokollierungsaufzeichnungen, Backup-Tests, Lieferantenprüfungen und Vorfallsberichte.

Step 19 führt vom Design in den Betrieb:

Verknüpfen Sie jedes dieser Dokumente mit der passenden Maßnahme in Ihrer SoA oder Ihrem ISMS-Handbuch. Diese dienen als Nachweis der Umsetzung und als interne Referenz.

Der Dokumentationssatz aus Step 19 umfasst Endpoint-Sicherheit, Zugriffsmanagement, Authentifizierung, sichere Baseline-Konfigurationen, Protokollierung und Überwachung, Patch-Management, Schwachstellenmanagement, Kapazitätsplanung und Berichterstattung zum IT-Betrieb. Genau diese operativen Dokumente werden benötigt, um technische NIS2-Maßnahmen auditierbar zu machen.

Step 26 erläutert, wie Auditnachweise erhoben werden sollten:

Während Sie Nachweise sammeln, zeichnen Sie Ihre Feststellungen auf. Vermerken Sie, wo Sachverhalte der Anforderung entsprechen (positive Feststellungen) und wo nicht (potenzielle Nichtkonformitäten oder Beobachtungen).

Für NIS2 bedeutet dies, Nachweise stichprobenartig zu prüfen, bevor eine Aufsichtsbehörde, ein Kundenprüfer oder ein Zertifizierungsauditor danach fragt.

Die Cross-Compliance-Rolle von Zenith Controls

Zenith Controls ist kein separates Kontrollrahmenwerk. Es ist der Cross-Compliance-Leitfaden von Clarysec zur Zuordnung von ISO/IEC 27001:2022- und ISO/IEC 27002:2022-Maßnahmen zu verwandten Maßnahmen, Auditerwartungen und externen Rahmenwerken. Er hilft Teams zu verstehen, wie eine ISO 27001:2022-Maßnahme NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT-orientierte Assurance unterstützen kann.

Drei ISO 27001:2022-Maßnahmen sind für die NIS2-Nachweiszuordnung besonders wichtig.

Maßnahme 5.1 Richtlinien für Informationssicherheit ist der Einstiegspunkt, weil NIS2 Article 21 Risikoanalyse und Sicherheitsrichtlinien für Informationssysteme umfasst. Wenn eine technische NIS2-Maßnahme nicht in Richtlinien abgebildet ist, ist sie schwer zu steuern und kaum konsistent zu auditieren.

Maßnahme 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit ist der Realitätscheck. Sie verbindet Richtlinienanforderungen mit der tatsächlichen Konformität mit internen Regeln, Standards und externen Verpflichtungen. Aus NIS2-Sicht stellt die Organisation hier die Frage, ob sie tatsächlich tut, was ihre Zuordnung zu Article 21 vorgibt.

Maßnahme 8.8 Management technischer Schwachstellen ist eines der anspruchsvollsten Testfelder für 2026. Schwachstellenmanagement ist unmittelbar relevant für sichere Beschaffung, Entwicklung, Wartung, Schwachstellenbehandlung und Offenlegung. Es unterstützt außerdem DORA-Tests und Abhilfemaßnahmen, die Rechenschaftspflicht für Sicherheit nach GDPR, Ergebnisse in den NIST CSF-Funktionen Identify und Protect sowie ISO 27001-Auditstichproben.

Unterstützende Standards können das Design schärfen, ohne zusätzliche Zertifizierungen zu verlangen. ISO/IEC 27002:2022 bietet Umsetzungshinweise für Annex A-Maßnahmen. ISO/IEC 27005 unterstützt Informationssicherheitsrisikomanagement. ISO/IEC 27017 unterstützt Cloud-Sicherheit. ISO/IEC 27018 unterstützt den Schutz personenbezogener Daten in Public-Cloud-Processor-Szenarien. ISO 22301 unterstützt Business Continuity. ISO/IEC 27035 unterstützt Vorfallmanagement. ISO/IEC 27036 unterstützt Sicherheit in Lieferantenbeziehungen.

Das Ziel sind nicht mehr Standards um ihrer selbst willen. Das Ziel ist ein besseres Nachweisdesign.

Praxisbeispiel: Aufbau eines NIS2-Nachweispakets für Schwachstellen

Betrachten wir Marias SaaS-Plattform. Sie bedient EU-Fertigungskunden und ist von Cloud-Services, Open-Source-Komponenten, CI/CD-Pipelines und Managed Monitoring abhängig. Ihr Lückenbericht sagt „Schwachstellenmanagement umgesetzt“, doch die Nachweise sind über Scanner, Jira, GitHub, Cloud-Konfigurationswerkzeuge und Änderungstickets verteilt.

Ein NIS2-fähiges Nachweispaket lässt sich in einem fokussierten Sprint aufbauen.

Schritt 1: Risikoszenario definieren

Risiko: Eine ausnutzbare Schwachstelle in einer internetseitig erreichbaren Anwendung, einer Abhängigkeit oder einer Cloud-Komponente verursacht eine Serviceunterbrechung, nicht autorisierten Zugriff oder eine Offenlegung von Kundendaten.

Das Risikoregister sollte Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichen und Behandlungsplan enthalten. Der Behandlungsplan sollte auf ISO 27001:2022-Maßnahme 8.8 Management technischer Schwachstellen verweisen, ergänzt um verwandte Maßnahmen für Asset-Inventar, sichere Entwicklung, Protokollierung, Zugriffskontrolle, Lieferantenmanagement und Incident Response.

Schritt 2: Risiko NIS2 Article 21 zuordnen

Das Risiko unterstützt Anforderungen aus Article 21 zu sicherer Beschaffung, Entwicklung und Wartung, Schwachstellenbehandlung und Offenlegung, Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Sicherheit der Lieferkette und Bewertung der Kontrollwirksamkeit.

Schritt 3: Betriebsregeln in Richtlinien verankern

Nutzen Sie ein Verfahren zum Schwachstellenmanagement, einen Standard für sichere Entwicklung, Anforderungen an das Patch-Management, eine Richtlinie zu Sicherheitstests und Regeln für Auditnachweise.

Die Enterprise-Richtlinie zu Sicherheitstests und Red-Team-Übungen, Clause 6.1, legt fest:

Arten von Tests: Das Sicherheitsprüfungsprogramm muss mindestens Folgendes umfassen: (a) Schwachstellenscans, bestehend aus automatisierten wöchentlichen oder monatlichen Scans von Netzwerken und Anwendungen zur Identifizierung bekannter Schwachstellen; (b) Penetrationstests, bestehend aus manuellen, vertieften Tests bestimmter Systeme oder Anwendungen durch qualifizierte Tester zur Identifizierung komplexer Schwächen; und (c) Red-Team-Übungen, bestehend aus szenariobasierten Simulationen realer Angriffe, einschließlich Social Engineering und anderer Taktiken, um die Erkennungs- und Reaktionsfähigkeiten der Organisation als Ganzes zu testen.

Diese Klausel schafft eine belastbare Testbasislinie. Sie steht außerdem im Einklang mit DORAs Erwartung an wiederkehrende, risikobasierte Tests der digitalen operationalen Resilienz für erfasste Finanzunternehmen.

Schritt 4: Nachweismetadaten definieren

Die Richtlinie zur Audit- und Compliance-Überwachung - SME, Clause 6.2.3, legt fest:

Metadaten, z. B. wer sie erhoben hat, wann und aus welchem System, müssen dokumentiert werden.

Für Schwachstellennachweise sollte das Paket Folgendes erfassen:

• Name und Konfiguration des Scanners
• Scan-Datum und -Uhrzeit
• Asset-Geltungsbereich und Ausschlüsse
• Kritische und hohe Feststellungen
• Ticketnummer und Verantwortlicher
• Patch- oder Minderungsentscheidung
• Risikoakzeptanzentscheidung, sofern anwendbar
• Datum der Behebung
• Validierungsscan
• Link zur Änderungsaufzeichnung
• Ausnahmeverantwortlicher und Ablaufdatum

Schritt 5: Protokollierungsnachweise hinzufügen

Die Richtlinie zur Protokollierung und Überwachung - SME, Clause 5.4.4, umfasst Systemprotokolle wie:

Systemprotokolle: Konfigurationsänderungen, administrative Aktionen, Softwareinstallationen, Patching-Aktivitäten

Ein Patch-Ticket allein belegt möglicherweise nicht, dass die Änderung stattgefunden hat. Konfigurationsprotokolle, administrative Aktionen und Softwareinstallationsaufzeichnungen stärken die Nachweiskette.

Schritt 6: Stichprobenaudit durchführen

Wählen Sie fünf kritische oder hohe Schwachstellen aus dem vorherigen Quartal aus. Prüfen Sie für jedes Element, ob das Asset im Inventar war, der Scanner die Feststellung erkannt hat, innerhalb des SLA ein Ticket eröffnet wurde, ein Verantwortlicher zugewiesen war, die Behebung Schweregrad und Ausnutzbarkeit entsprach, Protokolle die Änderung zeigen, die Validierung den Abschluss bestätigt und jede Ausnahme mit Ablaufdatum durch den Risikoverantwortlichen genehmigt wurde.

Dieser Sprint erzeugt ein NIS2-fähiges Nachweispaket für Schwachstellen und eine interne Auditstichprobe nach ISO 27001:2022.

Lieferantensicherheit ist Ökosystem-Governance

NIS2 Article 21 verlangt Sicherheit der Lieferkette, einschließlich Sicherheitsaspekten in Beziehungen zu unmittelbaren Lieferanten und Dienstleistern. Zudem wird erwartet, dass Organisationen Lieferantenschwachstellen, Produktqualität, Cybersicherheitspraktiken von Lieferanten und sichere Entwicklungspraktiken berücksichtigen.

Genau hier war die erste Version von Marias Lückenbericht am schwächsten. Sie listete Lieferanten auf, wies jedoch weder Due Diligence noch vertragliche Sicherheitsklauseln, Überwachung oder Exit-Bereitschaft nach.

Die Richtlinie zur Lieferanten- und Drittparteiensicherheit liefert den Richtlinienanker. Die Umsetzung kann zusätzlich durch die Richtlinie für sichere Softwareentwicklung, die Richtlinie zur Sensibilisierung und Schulung für Informationssicherheit, die Richtlinie zum Schwachstellen- und Patch-Management, die Richtlinie zu kryptografischen Kontrollen, die Richtlinie zur Zugriffskontrolle und die Richtlinie für Remote-Arbeit unterstützt werden.

Ein einziges Lieferantennachweisregister kann NIS2, DORA und ISO 27001:2022 unterstützen.

Diese Tabelle verhindert doppelte Fragebögen, doppelte Register und widersprüchliche Kontrollverantwortlichkeiten.

Ein Incident-Workflow für NIS2, DORA und GDPR

NIS2 Article 23 verlangt, dass erhebliche Vorfälle unverzüglich gemeldet werden. Er etabliert eine gestufte Frist: Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, Vorfallmeldung innerhalb von 72 Stunden mit erster Schweregrad- oder Auswirkungsbewertung und verfügbaren Indikatoren einer Kompromittierung, Zwischenmeldungen auf Anforderung und ein Abschlussbericht spätestens einen Monat nach der Vorfallmeldung.

DORA hat für Finanzunternehmen einen ähnlichen Lebenszyklus: Erkennung, Klassifizierung, Protokollierung, Schweregradbewertung, Eskalation, Kundenkommunikation, Behördenmeldung, Ursachenanalyse und Abhilfemaßnahmen. GDPR ergänzt die Analyse personenbezogener Datenschutzverletzungen, einschließlich Verantwortlichen- und Auftragsverarbeiterrollen, Auswirkungen auf betroffene Personen und der 72-Stunden-Meldefrist, sofern anwendbar.

Das richtige Design sind nicht drei Vorfallsprozesse. Es ist ein Incident-Workflow mit regulatorischen Entscheidungszweigen.

Die Incident-Response-Richtlinie - SME, Clause 5.4.1, legt fest:

Alle Untersuchungen von Vorfällen, Feststellungen und Korrekturmaßnahmen müssen in einem vom General Manager geführten Vorfallsregister aufgezeichnet werden.

Ein starkes Vorfallsregister sollte Folgendes enthalten:

Die GDPR-Verknüpfung sollte nicht unterschätzt werden. NIS2-zuständige Behörden können GDPR-Aufsichtsbehörden informieren, wenn Mängel beim Management von Cybersicherheitsrisiken oder bei Meldungen eine personenbezogene Datenschutzverletzung nach sich ziehen können. Das ISMS sollte Datenschutzbewertung daher als Teil der Sicherheitsvorfall-Triage vorsehen, nicht als nachträglichen Schritt.

Wie Auditoren und Aufsichtsbehörden Ihre NIS2-Nachweise prüfen werden

Eine für 2026 bereite Organisation sollte erwarten, dass dieselbe Maßnahme aus unterschiedlichen Perspektiven geprüft wird.

Ein ISO 27001:2022-Auditor beginnt beim ISMS. Er wird fragen, ob NIS2-Verpflichtungen als Anforderungen interessierter Parteien identifiziert sind, ob der ISMS-Geltungsbereich relevante Services und Abhängigkeiten abdeckt, ob Risiken bewertet und behandelt werden, ob die Anwendbarkeitserklärung die anwendbaren Maßnahmen begründet und ob Aufzeichnungen den Betrieb belegen.

Eine für NIS2 zuständige Behörde konzentriert sich auf rechtliche Ergebnisse. Sie kann fragen, ob alle Maßnahmen aus Article 21 adressiert sind, ob die Kontrollen geeignet und verhältnismäßig sind, ob das Management die Maßnahmen genehmigt und überwacht und ob die Vorfallmeldung die erforderlichen Fristen einhalten kann.

Eine DORA-Aufsichtsbehörde wird bei erfassten Finanzunternehmen IKT-Risikomanagement, Vorfallklassifizierung, Resilienztests, Drittparteienrisiken, vertragliche Vereinbarungen, Konzentrationsrisiko und Exit-Strategien prüfen.

Ein GDPR-Prüfer wird prüfen, ob technische und organisatorische Maßnahmen personenbezogene Daten schützen, ob die Bewertung von Datenschutzverletzungen in den Umgang mit Informationssicherheitsvorfällen eingebettet ist, ob Rollen von Verantwortlichem und Auftragsverarbeiter klar sind und ob Aufzeichnungen zur Rechenschaftspflicht existieren.

Ein Prüfer nach NIST CSF 2.0 oder COBIT 2019-Logik wird sich auf Governance, Risikoverantwortung, Leistungskennzahlen, aktuelle und angestrebte Ergebnisse, Prozessfähigkeit und Ausrichtung an der unternehmensweiten Risikobereitschaft konzentrieren.

Die Enterprise-Richtlinie zur Audit- und Compliance-Überwachung, Clause 3.4, beschreibt den Zweck der Nachweise:

Erzeugung belastbarer Nachweise und eines Prüfpfads zur Unterstützung regulatorischer Anfragen, Gerichtsverfahren oder Kundenanforderungen zur Vertrauensbildung.

Das ist der operative Standard, auf den NIS2-Teams hinarbeiten sollten.

Rechenschaftspflicht des Managements: Das Leitungsorgan kann NIS2 nicht wegdelegieren

NIS2 Article 20 verlangt von Leitungsorganen wesentlicher und wichtiger Einrichtungen, dass sie Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen erhalten. Mitglieder von Leitungsorganen können nach nationalen Haftungsregeln für Verstöße haftbar gemacht werden.

Dies stimmt mit den Führungsanforderungen aus ISO 27001:2022 überein. Die oberste Leitung muss sicherstellen, dass Informationssicherheitsleitlinie und -ziele an der strategischen Ausrichtung ausgerichtet sind, ISMS-Anforderungen in Geschäftsprozesse integriert werden, Ressourcen bereitgestellt werden, die Bedeutung kommuniziert wird, Verantwortlichkeiten zugewiesen werden und kontinuierliche Verbesserung gefördert wird.

Ein Leitungsorgan benötigt keine rohen Scanner-Exporte oder vollständigen SIEM-Protokolle. Es benötigt entscheidungsreife Assurance.

Ein quartalsweises NIS2-Nachweispaket für das Leitungsorgan sollte enthalten:

1. Änderungen des Geltungsbereichs und des regulatorischen Status
2. Wichtigste NIS2-Risiken und Status der Risikobehandlung
3. Dashboard zur Kontrollwirksamkeit für Article 21
4. Erhebliche Vorfälle, Beinahe-Vorfälle und Meldeentscheidungen
5. Risikoausnahmen bei Lieferanten und Cloud-Services
6. Interne Auditfeststellungen, Korrekturmaßnahmen und überfällige Nachweise

Dieses Paket gibt dem Management die Informationen, die es benötigt, um Maßnahmen zu genehmigen, Ausnahmen zu hinterfragen und Restrisiken zu akzeptieren.

Das Clarysec-Betriebsmodell für 2026

Die Operationalisierung technischer NIS2-Maßnahmen mit ISO 27001:2022 erfordert ein einfaches, aber diszipliniertes Modell:

• NIS2-, DORA-, GDPR- und vertragliche Verpflichtungen im ISMS erfassen
• Verpflichtungen Risiken, Richtlinien, Maßnahmen, Verantwortlichen und Nachweisen zuordnen
• Die Anwendbarkeitserklärung als maßgebliche Quelle für Maßnahmen nutzen
• Nachweispakete für risikoreiche Bereiche von Article 21 aufbauen
• Vorfallmeldungen in einen einheitlichen regulatorischen Workflow integrieren
• Lieferantensicherheit als Lebenszyklus behandeln, nicht als Fragebogen
• Interne Audits mit echten Stichproben durchführen
• Kontrollwirksamkeit an Leitungsorgane berichten
• Auf Basis von Vorfällen, Auditfeststellungen, Tests und regulatorischen Änderungen verbessern

Für Maria war die entscheidende Erkenntnis, dass sie kein separates NIS2-Projekt benötigte. Sie brauchte eine stärkere ISMS-Nachweisengine.

Die Richtlinien von Clarysec, Zenith Blueprint und Zenith Controls sind dafür konzipiert, zusammenzuarbeiten. Richtlinien definieren erwartetes Verhalten und Aufzeichnungen. Der Zenith Blueprint liefert die 30-Schritte-Route für Umsetzung und Audit. Zenith Controls stellt die Cross-Compliance-Zuordnung bereit, damit NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF und COBIT-orientierte Assurance als ein kohärentes Programm gesteuert werden können.

Nächster Schritt: Erstellen Sie Ihre Nachweiszuordnung von NIS2 zu ISO 27001:2022

Wenn Ihre NIS2-Arbeit noch in einer Lückentabelle lebt, ist 2026 das Jahr, sie zu operationalisieren.

Beginnen Sie mit einer risikoreichen technischen Maßnahme, etwa Schwachstellenmanagement, Umgang mit Informationssicherheitsvorfällen oder Lieferantensicherheit. Ordnen Sie sie ISO 27001:2022-Risiken, Richtlinien, Annex A-Maßnahmen, Verantwortlichen, Verfahren und Nachweisen zu. Ziehen Sie anschließend Stichproben aus den Aufzeichnungen des letzten Quartals und stellen Sie die unbequeme Frage: Würde dies eine Aufsichtsbehörde, einen Kundenprüfer und einen ISO 27001:2022-Auditor zufriedenstellen?

Clarysec kann Ihnen helfen, diese Antwort mithilfe der Richtlinienbibliothek, Zenith Blueprint und Zenith Controls aufzubauen.

Das Ziel ist nicht mehr Dokumentation. Das Ziel sind belastbare, wiederholbare Nachweise dafür, dass Ihre technischen NIS2-Maßnahmen tatsächlich funktionieren.