ISO 27001 als Kontrollrückgrat für NIS2- und DORA-Nachweise

Die Compliance-Kollision am Montagmorgen

Um 08:12 Uhr am Montag erhält Maria, CISO eines europäischen Zahlungsdienstleisters, drei Nachrichten, die auf den ersten Blick nichts miteinander zu tun haben.

Der Leiter der Internen Revision bittet um Nachweise, dass die ISO 27001:2022-Anwendbarkeitserklärung aktuell ist. Das Rechtsteam leitet den Fragebogen eines Bankpartners zur DORA-Aufsicht über IKT-Drittparteienrisiken weiter. Der Betriebsleiter fragt, ob dasselbe Incident-Playbook die NIS2-Meldeerwartungen für eine neu erworbene Geschäftseinheit in der EU unterstützen kann.

Um 09:00 Uhr ist das Whiteboard in Marias Büro mit Abkürzungen gefüllt: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Ihre Organisation verfügt über Kontrollen. Sie hat Zugriffsmanagement, Backups, Lieferantenfragebögen, Verschlüsselung, Incident Response, Richtlinienfreigaben, Managementbewertungen und Schulungsnachweise. Was fehlt, ist ein einheitliches, auditbereites Nachweisrückgrat, das erklärt, warum diese Kontrollen existieren, welche Risiken sie behandeln, welche Vorschriften sie unterstützen, wer verantwortlich ist und wo die Nachweise abgelegt sind.

Dieses Problem tritt in Europa immer häufiger auf. NIS2 verschärft die Anforderungen an Cybersicherheitsrisikomanagement, Governance, Verfahren zum Umgang mit Informationssicherheitsvorfällen und Resilienz der Lieferkette. DORA ergänzt detaillierte Anforderungen an das Management von IKT-Risiken, Resilienztests, Vorfallsmeldung und die Aufsicht über IKT-Drittparteien für Finanzunternehmen. GDPR verlangt weiterhin Rechenschaftspflicht, Sicherheit der Verarbeitung, Governance für Auftragsverarbeiter und die Bewertung von Verletzungen des Schutzes personenbezogener Daten.

Die falsche Reaktion besteht darin, drei parallele Compliance-Programme aufzubauen. Das führt zu doppelten Kontrollen, uneinheitlichen Nachweisen und überlasteten Teams.

Die stärkere Reaktion besteht darin, ISO 27001:2022 als Kontrollrückgrat zu nutzen. Nicht als Zertifikat an der Wand, sondern als Betriebssystem für Risiko, Richtlinien, Lieferanten-Governance, Incident Response, Compliance-Zuordnung und Auditnachweise.

Das praktische Modell von Clarysec ist einfach: Nutzen Sie das ISO 27001:2022-ISMS als Ordnungssystem, die Anwendbarkeitserklärung als Brücke, Richtlinien als verbindliche Betriebsregeln und Zenith Controls: The Cross-Compliance Guide als Kompass für die übergreifende Compliance. Einmal aufbauen, sorgfältig zuordnen, kontinuierlich nachweisen.

Warum ISO 27001:2022 als Compliance-Rückgrat funktioniert

NIS2 und DORA haben unterschiedliche Geltungsbereiche, rechtliche Mechanismen und Aufsichtsmodelle. NIS2 gilt für wesentliche und wichtige Einrichtungen in verschiedenen Sektoren. DORA gilt für Finanzunternehmen und schafft detaillierte Anforderungen an die digitale operationale Resilienz. GDPR konzentriert sich auf die Verarbeitung personenbezogener Daten und Rechenschaftspflicht.

Die operativen Fragen hinter diesen Rahmenwerken überschneiden sich jedoch:

• Wird Cybersicherheit durch von der Leitung genehmigte Richtlinien gesteuert?
• Werden Informationssicherheits- und IKT-Risiken identifiziert, bewertet und behandelt?
• Werden Kontrollen auf Basis von Risiko, Geschäftskontext und rechtlichen Verpflichtungen ausgewählt?
• Werden Lieferanten durch Due Diligence, Verträge, Überwachung und Exit-Kontrollen gesteuert?
• Kann Personal Sicherheitsereignisse frühzeitig erkennen und melden?
• Können Vorfälle triagiert, eskaliert, untersucht und im Hinblick auf regulatorische Meldepflichten bewertet werden?
• Kann die Organisation Nachweise während eines Audits, einer Kundenprüfung oder einer Anfrage der Aufsicht schnell abrufen?

ISO 27001:2022 bietet der Leitung ein Managementsystem, um diese Fragen konsistent zu beantworten. ISO/IEC 27007:2022 behandelt die Anwendbarkeitserklärung als auditierbare Liste ausgewählter Informationssicherheitskontrollen, einschließlich Kontrollen aus ISO 27001:2022 Anhang A, anderen Standards oder organisationsspezifischen Maßnahmen, mit dokumentierter Begründung für Aufnahme oder Ausschluss. ISO/IEC 27006-1:2024 bekräftigt, dass die SoA und die zugehörige ISMS-Dokumentation eine zentrale Nachweisgrundlage bilden, um darzustellen, welche Kontrollen erforderlich sind, wie Verantwortlichkeiten zugewiesen werden und wie Richtlinien umgesetzt und kommuniziert werden.

Damit ist die SoA weit mehr als eine Tabelle. Sie wird zum Kontrollvertrag zwischen Risiko, Compliance, Betrieb, Recht, Beschaffung, Audit und Leitungsorgan.

Clarysecs [P01] Informationssicherheitsleitlinie verankert diese Governance-Anforderung:

Die Organisation muss ein Informationssicherheits-Managementsystem (ISMS) gemäß ISO/IEC 27001:2022, Klauseln 4 bis 10, implementieren und aufrechterhalten.

Aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.1.1.

Das ist wichtig, weil Nachweisanforderungen zu NIS2 und DORA selten in ISO-Sprache formuliert sind. Eine Aufsichtsbehörde, ein Kunde oder ein Ausschuss des Leitungsorgans kann Nachweise zum Cybersicherheitsrisikomanagement, zur IKT-Governance, zur Aufsicht über Drittparteienabhängigkeiten, zur Vorfalleskalation oder zu Tests der operationalen Resilienz verlangen. Das ISO 27001:2022-ISMS gibt diesen Antworten eine Struktur.

Die SoA ist die Brücke, keine Papierübung

In Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Risikomanagement, Schritt 13, beschreibt Clarysec die SoA als den zentralen Mechanismus zur Nachvollziehbarkeit zwischen Risikobehandlung und implementierten Kontrollen:

Die SoA ist tatsächlich ein Brückendokument: Sie verbindet Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlich vorhandenen Kontrollen.

Dieser Satz ist der Kern der übergreifenden Compliance. Eine Kontrolle ohne Nachvollziehbarkeit wird zu einem losen Artefakt. Eine Kontrolle, die mit einem Risiko, einer rechtlichen Verpflichtung, einer Richtlinie, einem Verantwortlichen, einem Nachweisdatensatz und einem Testergebnis verknüpft ist, wird auditbereit.

Schritt 13 empfiehlt außerdem, Kontrollreferenzen zu Risikoszenarien hinzuzufügen, etwa die Verknüpfung eines Szenarios zu einer Verletzung einer Kundendatenbank mit Zugriffskontrolle, Kryptografie, Schwachstellenmanagement, Incident Response und Lieferantenkontrollen. Außerdem wird empfohlen festzuhalten, wann Kontrollen externe Anforderungen wie GDPR, NIS2 oder DORA unterstützen.

Clarysecs [P06] Risikomanagement-Richtlinie macht diese Betriebsregel ausdrücklich:

Kontrollentscheidungen aus dem Risikobehandlungsprozess müssen in der SoA abgebildet werden.

Aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.5.1.

Für kleinere Organisationen nutzt die Risikomanagement-Richtlinie - SME dieselbe Logik:

Sie stellt sicher, dass Risikomanagement ein aktiver Bestandteil von Planung, Projektdurchführung, Lieferantenauswahl und Incident Response ist – in Übereinstimmung mit ISO 27001, ISO 31000 und anwendbaren regulatorischen Anforderungen.

Aus dem Abschnitt “Zweck”, Richtlinienklausel 1.2.

Wenn eine DORA-Risikobehandlung für Drittparteien, eine NIS2-Maßnahme zum Umgang mit Informationssicherheitsvorfällen oder eine GDPR-Sicherheitsanforderung an Auftragsverarbeiter nicht in der SoA oder im zugehörigen Compliance-Register abgebildet ist, leistet die Organisation möglicherweise dennoch die Arbeit. Sie wird jedoch Schwierigkeiten haben, diese Arbeit kohärent nachzuweisen.

Ein praktischer ISO 27001:2022-Crosswalk für NIS2 und DORA

Der folgende Crosswalk ist keine Rechtsberatung. Er ist ein praktisches Nachweismodell für CISOs, Compliance-Verantwortliche, interne Auditoren und Geschäftsverantwortliche, die ISO 27001:2022-Nachweise an NIS2- und DORA-Erwartungen ausrichten müssen.

ENISA hat in Zusammenarbeit mit der Europäischen Kommission und der NIS Cooperation Group beratende Querverweise bereitgestellt, die helfen, EU-Cybersicherheitsanforderungen mit internationalen und nationalen Standards, einschließlich ISO 27001, abzugleichen. Diese Leitlinien sind rechtlich nicht bindend und müssen durch Vorgaben nationaler Behörden, sektorspezifische Regeln und rechtliche Prüfung ergänzt werden. Sie unterstützen jedoch einen belastbaren Zuordnungsansatz.

Der Crosswalk funktioniert, weil er keine doppelten Kontrollen für jede Regulierung schafft. Er nutzt ISO 27001:2022 als Kontrollrückgrat und ergänzt regulatorische Tags, Verantwortlichkeiten und Nachweiserwartungen.

Drei ISO 27001:2022-Kontrollen, die das Rückgrat erschließen

Mehrere Kontrollen sind für NIS2 und DORA relevant, aber drei ISO/IEC 27002:2022-Kontrollen bilden häufig das Rückgrat des Nachweismodells: 5.1, 5.19 und 5.24. Eine vierte Kontrolle, 6.8, entscheidet oft darüber, ob Vorfallmeldungen in der Praxis funktionieren.

In Zenith Controls wird ISO/IEC 27002:2022-Kontrolle 5.1, Policies for information security, als präventive Kontrolle beschrieben, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt; Governance und Richtlinienmanagement gelten dabei als zentrale operative Fähigkeiten. Die Querverknüpfung erläutert, dass GDPR Articles 5(2), 24 und 32 Rechenschaftspflicht, Verantwortlichkeit und Sicherheit der Verarbeitung verlangen. Außerdem wird dieselbe Kontrolle den Erwartungen von NIS2 an Cybersicherheitsrisikomanagement und Governance sowie den DORA-Anforderungen an IKT-Governance und das IKT-Risikomanagementrahmenwerk zugeordnet.

Deshalb ist die Informationssicherheitsleitlinie nicht einfach eine weitere Richtlinie. Ein NIS2-Prüfer kann sie als Governance-Nachweis lesen. Eine DORA-Aufsicht kann sie als Nachweis für das IKT-Risikomanagementrahmenwerk lesen. Ein GDPR-Prüfer kann sie als Nachweis der Rechenschaftspflicht lesen. Ein ISO 27001:2022-Auditor kann sie als Teil der ISMS-Richtlinienstruktur lesen.

Kontrolle 5.19, Information security in supplier relationships, ist der Punkt, an dem Beschaffung, Recht, Sicherheit, Datenschutz und Resilienz zusammenkommen. Zenith Controls ordnet sie GDPR-Pflichten für Auftragsverarbeiter, der Cybersicherheit der NIS2-Lieferkette und dem DORA-Management von IKT-Drittparteienrisiken zu. Für DORA wird dieser Nachweis noch stärker, wenn er durch die Kontrollen 5.20, Addressing information security within supplier agreements, 5.21, Managing information security in the ICT supply chain, und 5.23, Information security for use of cloud services, unterstützt wird.

Kontrolle 5.24, Information security incident management planning and preparation, ist der operative Motor der Vorfallsbereitschaft. Zenith Controls ordnet sie dem NIS2-Umgang mit Vorfällen und der Meldung, der GDPR-Meldung von Verletzungen des Schutzes personenbezogener Daten sowie dem DORA-Management und der Meldung IKT-bezogener Vorfälle zu. Ihr Nachweis besteht nicht nur aus einer Incident-Response-Richtlinie. Er umfasst Meldekanäle, Triage-Kriterien, Eskalationsaufzeichnungen, rechtliche Bewertungen von Meldepflichten, Tabletop-Übungen, Vorfalltickets und Lessons Learned.

Kontrolle 6.8, Information security event reporting, schließt die Lücke zwischen schriftlichem Plan und menschlichem Verhalten. Wenn Personal nicht weiß, wie vermutetes Phishing, Datenabfluss, Lieferantenausfälle oder verdächtige Systemaktivitäten zu melden sind, kann die Organisation kritische Zeit verlieren, bevor rechtliche oder regulatorische Meldebewertungen überhaupt beginnen.

Ein Lieferantenvorfall, eine koordinierte Nachweiskette

Stellen Sie sich vor, ein Cloud-Analytics-Anbieter, den Marias Zahlungsdienstleister nutzt, erkennt nicht autorisierten Zugriff auf ein Support-Portal. Der Anbieter hostet pseudonymisierte Kundennutzungsdaten und unterstützt einen geschäftskritischen Reporting-Workflow. Der Vorfall kann personenbezogene Daten, regulierte IKT-Resilienz und Serviceverfügbarkeit betreffen.

Ein fragmentiertes Compliance-Programm eröffnet drei getrennte Arbeitsstränge: eine GDPR-Bewertung einer Datenschutzverletzung, eine DORA-Prüfung eines IKT-Vorfalls und ein ISO 27001-Lieferantenticket. Jedes Team fordert ähnliche Nachweise in einem anderen Format an. Die Beschaffung sucht den Vertrag. Recht fragt, ob der Anbieter Auftragsverarbeiter ist. Sicherheit fragt, ob der Vorfall Meldeschwellen erreicht. Das Compliance-Team beginnt eine neue Tabelle.

Ein ausgereiftes ISO 27001:2022-Rückgrat eröffnet eine koordinierte Nachweiskette.

Zunächst wird das Ereignis im Rahmen des Incident-Response-Prozesses protokolliert. Die meldende Person nutzt einen definierten Kanal, das Sicherheitsteam triagiert das Ereignis, und Recht bewertet Meldepflichten. Clarysecs [P30] Incident-Response-Richtlinie verlangt, dass Vorfälle mit regulierten Daten durch Recht und DPO bewertet werden:

Wenn ein Vorfall zu einer bestätigten oder wahrscheinlichen Offenlegung personenbezogener Daten oder anderer regulierter Daten führt, müssen Recht und DPO die Anwendbarkeit folgender Anforderungen bewerten:

Aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.4.1.

Für kleinere Organisationen weist die Incident Response Policy-sme - SME denselben praktischen Entscheidungspunkt zu:

Wenn Kundendaten betroffen sind, muss der General Manager rechtliche Benachrichtigungspflichten auf Grundlage der Anwendbarkeit von GDPR, NIS2 oder DORA bewerten.

Aus dem Abschnitt “Risikobehandlung und Ausnahmen”, Richtlinienklausel 7.4.1.

Zweitens wird die Lieferantenbeziehung überprüft. Wurde der Anbieter als kritisch eingestuft? Enthielt der Vertrag Pflichten zur Meldung von Verstößen, Auditrechte, Datenschutzverantwortlichkeiten, Erwartungen an Servicekontinuität und Exit-Regelungen? Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit legt diese Erwartung fest:

Standardisierte Sicherheitsanforderungen müssen in alle Lieferantenverträge aufgenommen werden, einschließlich Pflichten zur Meldung von Verstößen, Auditrechten und Datenschutzverantwortlichkeiten.

Aus dem Abschnitt “Ziele”, Richtlinienklausel 3.2.

Für KMU macht die Third-Party and Supplier Security Policy-sme - SME den Zweck der übergreifenden Compliance ausdrücklich:

Unterstützung der Einhaltung von ISO/IEC 27001:2022, GDPR, NIS2 und DORA-Verpflichtungen im Zusammenhang mit Lieferanten-Governance.

Aus dem Abschnitt “Ziele”, Richtlinienklausel 3.6.

Drittens werden Risikoregister, Behandlungsplan und SoA aktualisiert, wenn der Vorfall eine Lücke offenlegt. Vielleicht fehlt im Lieferantenvertrag eine konkrete regulatorische Meldefrist. Vielleicht ist die Überwachungsfrequenz für einen kritischen IKT-Anbieter zu niedrig. Vielleicht unterscheidet der Incident Response Plan nicht klar zwischen Kriterien für Verletzungen des Schutzes personenbezogener Daten und Kriterien für IKT-Serviceunterbrechungen.

Der Punkt ist nicht, ein neues Compliance-Universum zu schaffen. Der Punkt ist, eine integrierte Nachweiskette zu aktualisieren, damit dieselben Aufzeichnungen mehrere Auditfragen beantworten können.

Die SoA in eine NIS2- und DORA-Nachweiskarte überführen

Eine Standard-SoA beantwortet ISO-Fragen oft gut: welche Kontrollen anwendbar sind, warum sie ausgewählt wurden und ob sie implementiert sind. Um daraus eine praktische NIS2- und DORA-Nachweiskarte zu machen, sollte sie um regulatorische und operative Nachweisfelder angereichert werden.

Öffnen Sie die SoA_Builder.xlsx aus dem Audit Ready Toolkit, auf das in Zenith Blueprint, Phase Audit, Review & Improvement, Schritt 24, verwiesen wird. Schritt 24 erläutert, dass Auditoren häufig eine Kontrolle aus der SoA stichprobenartig auswählen und fragen, warum sie implementiert wurde. Die Begründungsspalte und das verknüpfte Risiko oder die verknüpfte Anforderung sollten diese Frage beantworten.

Fügen Sie diese Spalten hinzu:

Wenden Sie dies nun auf den Kernkontrollsatz an.

Führen Sie anschließend eine Stichproben-Nachverfolgung durch. Wählen Sie einen Lieferantenvorfall aus dem letzten Jahr und verfolgen Sie ihn vom Vorfallticket zum Lieferantenvertrag, von der Lieferantenklassifizierung zum Risikoregister, von der Risikobehandlung zur SoA und von der SoA zur Managementbewertung.

Wenn die Kette bricht, ist das kein Scheitern. Es ist eine präzise Korrekturmaßnahme, bevor ein Auditor, Kunde, Regulator oder Ausschuss des Leitungsorgans die Lücke findet.

Zentralisierte Nachweise sind der übersehene Beschleuniger

Viele Organisationen haben angemessene Kontrollen, aber eine schwache Nachweisabrufbarkeit. Nachweise sind über E-Mail, Ticketsysteme, SharePoint-Ordner, Vertrags-Repositories, HR-Plattformen, GRC-Werkzeuge und Lieferantenportale verteilt. Während der Auditsaison verbringt das Compliance-Team Wochen damit, Screenshots zusammenzutragen.

Das ist keine Auditbereitschaft. Das ist Audit-Wiederherstellung.

Clarysecs [P33S] Audit and Compliance Monitoring Policy-sme - SME legt fest:

Alle Nachweise müssen in einem zentralen Auditordner gespeichert werden.

Aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.2.1.

Ein zentraler Auditordner bedeutet keine unkontrollierte Ablagefläche. Er bedeutet ein strukturiertes Repository, das am ISMS, an der SoA, am Risikoregister, am Auditplan und am Compliance-Register ausgerichtet ist.

Clarysecs Richtlinie zur rechtlichen und regulatorischen Einhaltung - SME adressiert das Zuordnungsproblem direkt:

Wenn eine Vorschrift mehrere Bereiche betrifft (z. B. gilt GDPR für Aufbewahrung, Sicherheit und Datenschutz), muss dies im Einhaltungsregister und in den Schulungsmaterialien eindeutig zugeordnet werden.

Aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.2.2.

Genau so wird ISO 27001:2022 zum Kontrollrückgrat für NIS2 und DORA. Sie verlassen sich nicht auf implizites Wissen. Sie ordnen Vorschriften Prozessen, Richtlinien, Kontrollen, Nachweisen und Schulungen zu.

Vorfallsmeldung beginnt bei Menschen, nicht bei Portalen

Eine häufige Auditschwäche zeigt sich, wenn der Incident Response Plan stark aussieht, Mitarbeitende aber nicht wissen, wann oder wie sie melden sollen. Das ist für NIS2, DORA und GDPR gefährlich, weil regulatorische Bewertungsfristen von Erkennung, Eskalation und Klassifizierung abhängen.

In Zenith Blueprint, Phase Controls in Action, Schritt 16, betont Clarysec die personalgetriebene Vorfallsmeldung nach ISO/IEC 27002:2022-Kontrolle 6.8. Die Leitlinie stellt fest, dass Incident Response bei Menschen beginnt. Organisationen sollten einen klaren, einfachen und zugänglichen Meldekanal schaffen, etwa eine überwachte E-Mail-Adresse, ein internes Portal, eine Hotline oder eine Ticketkategorie. Außerdem empfiehlt sie Sensibilisierungsschulung, eine meldungsfreundliche Kultur ohne Schuldzuweisung, Vertraulichkeit, niedrigschwellige Meldung und regelmäßige Simulationen.

Die Auswirkung auf die übergreifende Compliance ist direkt. Zenith Blueprint verknüpft diese Meldefähigkeit des Personals mit GDPR Article 33, NIS2 Article 23 und DORA Article 17. Wenn Mitarbeitende zögern, verdächtige Aktivitäten zu melden, kann die Organisation kritische Zeit verlieren, bevor Rechts-, Sicherheits- oder Regulierungsteams Meldepflichten bewerten können.

Ein praktischer Kontrolltest ist einfach:

1. Fragen Sie fünf Mitarbeitende, wie sie eine verdächtige Phishing-E-Mail melden.
2. Prüfen Sie, ob der Meldekanal überwacht wird.
3. Bestätigen Sie, ob das Ticketsystem eine Kategorie für Sicherheitsvorfälle hat.
4. Überprüfen Sie die letzte Simulation oder Tabletop-Übung.
5. Verifizieren Sie, dass Lessons Learned in der Managementbewertung behandelt wurden.

Wenn eine Antwort unklar ist, aktualisieren Sie das Merkblatt zur Vorfallmeldung, das Schulungsmaterial, den Meldekanal und die SoA-Nachweisreferenz.

Wie unterschiedliche Auditoren dasselbe Rückgrat prüfen

Nachweise zur übergreifenden Compliance müssen unterschiedlichen Auditperspektiven standhalten. Dieselbe Kontrolle kann je nach Prüfmandat unterschiedlich getestet werden.

Hier schafft Zenith Controls Mehrwert über eine einfache Zuordnungstabelle hinaus. Es hilft, ISO/IEC 27002:2022-Kontrollen in auditrelevante Perspektiven zu übersetzen, einschließlich Kontrollattributen, regulatorischen Beziehungen und Nachweiserwartungen. Bei Kontrolle 5.1 unterstützen die Attribute Governance, Richtlinienmanagement, Rechenschaftspflicht und Sicherheitsziele. Bei Kontrolle 5.24 unterstützen die Attribute Reaktions- und Wiederherstellungskonzepte, Vorfallsbereitschaft und Korrekturmaßnahmen. Bei Kontrolle 5.19 verbinden die Attribute der Lieferantenbeziehung Governance, Ökosystemrisiko, Schutz und Drittparteienaufsicht.

Was das Leitungsorgan sehen sollte

Das Leitungsorgan benötigt nicht jede SoA-Zeile. Es benötigt die Geschichte, die die SoA erzählt.

Ein aussagekräftiges Board-Paket zur Ausrichtung von ISO 27001:2022, NIS2 und DORA sollte Folgendes enthalten:

• ISMS-Geltungsbereich und abgedeckte Geschäftsservices.
• Wichtigste Informationssicherheits- und IKT-Risiken.
• Zusammenfassung anwendbarer Kontrollen nach Domäne.
• Zuordnungsstatus für NIS2, DORA und GDPR.
• Kritische Lieferanten und Konzentrationsrisiken.
• Kennzahlen zur Vorfallsmeldung und Ergebnisse von Tabletop-Übungen.
• Offene Korrekturmaßnahmen und überfällige Risikobehandlungen.
• Erforderliche Entscheidungen zu Risikoakzeptanz, Budget, Verantwortlichkeit und Ressourcen.

Dadurch wird Compliance zu Governance-Nachweis. Es entspricht auch dem Zweck von Kontrolle 5.1 in Zenith Controls, wonach Richtlinien zur Informationssicherheit die Ausrichtung auf oberster Leitungsebene, Rechenschaftspflicht und Sicherheitsziele unterstützen.

Häufige Fehler, die vermieden werden sollten

Der erste Fehler besteht in der Annahme, dass eine ISO 27001:2022-Zertifizierung automatisch die Einhaltung von NIS2 oder DORA nachweist. Das tut sie nicht. ISO 27001:2022 bietet ein starkes Managementsystem und Kontrollrückgrat, aber Sie benötigen weiterhin regulatorische Abgrenzung des Geltungsbereichs, rechtliche Analyse, sektorspezifische Auslegung, Melde-Workflows und Kenntnis der Erwartungen nationaler Behörden.

Der zweite Fehler besteht darin, die SoA als statisch zu behandeln. Die SoA muss sich weiterentwickeln, wenn neue Lieferanten, Systeme, Vorfälle, Vorschriften, Services oder Risiken entstehen. Zenith Blueprint, Schritt 24, empfiehlt, die SoA gegen das Risikoregister und den Behandlungsplan gegenzuprüfen und sicherzustellen, dass jede ausgewählte Kontrolle eine Begründung auf Basis eines zugeordneten Risikos, einer rechtlichen Anforderung oder eines geschäftlichen Bedarfs hat.

Der dritte Fehler ist eine zu grobe Zuordnung. Eine Folie mit der Aussage „ISO 27001 maps to DORA“ ist kein Auditnachweis. Ein konkreter SoA-Eintrag, der die Sicherheit in Lieferantenbeziehungen mit einem kritischen IKT-Lieferantenrisiko, einer Vertragsklausel, einer Lieferantenprüfungsaufzeichnung und einer DORA-Erwartung an Drittparteienaufsicht verbindet, ist deutlich stärker.

Der vierte Fehler besteht darin, Nachweise nicht zu zentralisieren. Wenn der Compliance-Manager vor jedem Audit zwei Wochen damit verbringt, Screenshots zu sammeln, hat die Organisation ein Abrufproblem.

Der fünfte Fehler ist die Vernachlässigung menschenbezogener Kontrollen. Vorfallsmeldung, Lieferanten-Onboarding, Berechtigungsüberprüfung, Richtlinienbestätigung und Eskalation hängen alle von menschlichem Verhalten ab. Ein ausgefeilter Prozess, dem niemand folgt, bricht unter Auditstichproben zusammen.

Clarysecs Betriebsmodell für übergreifende Compliance

Die Methode von Clarysec verbindet die Compliance-Geschichte von der Strategie bis zum Nachweis:

• In Zenith Blueprint, Phase Risikomanagement, Schritt 13, ordnen Sie Kontrollen Risiken zu und bauen die SoA als Brückendokument auf.
• In Zenith Blueprint, Phase Risikomanagement, Schritt 14, verknüpfen Sie GDPR-, NIS2- und DORA-Anforderungen mit Richtlinien und Kontrollen.
• In Zenith Blueprint, Phase Controls in Action, Schritt 16, operationalisieren Sie personalgetriebene Vorfallsmeldung, damit Eskalation früh beginnt.
• In Zenith Blueprint, Phase Audit, Review & Improvement, Schritt 24, finalisieren und testen Sie die SoA, gleichen sie mit dem Risikobehandlungsplan ab und bereiten sie als eines der ersten Dokumente vor, die ein Auditor anfordern wird.

Diese Methode wird durch Clarysec-Richtlinien unterstützt, die Grundsätze in Betriebsregeln überführen: Informationssicherheits-Governance, Risikobehandlung, Lieferantensicherheit, Incident Response, rechtliche und regulatorische Zuordnung sowie Nachweisspeicherung.

Das Ergebnis ist nicht nur ISO 27001:2022-Bereitschaft. Es ist ein wiederverwendbares Nachweissystem für die Einhaltung von NIS2, DORA, GDPR, Kundenvertrauen, Interne Revision und Aufsicht durch das Leitungsorgan.

Nächste Schritte: einmal aufbauen, vielfach nachweisen

Wenn Ihre Organisation NIS2, DORA, GDPR, Kundenaudits oder Druck zur ISO 27001:2022-Zertifizierung bewältigen muss, beginnen Sie mit dem Rückgrat.

1. Überprüfen Sie Ihre SoA und ergänzen Sie Spalten zu regulatorischen Treibern für NIS2, DORA und GDPR.
2. Gleichen Sie die SoA mit Ihrem Risikoregister und Risikobehandlungsplan ab.
3. Ordnen Sie kritische Lieferanten den Lieferantensicherheitskontrollen, Vertragsklauseln und Überwachungsnachweisen zu.
4. Testen Sie Ihren Workflow zur Vorfallsmeldung mit einer Tabletop-Übung.
5. Zentralisieren Sie Auditnachweise nach Kontrolle, Regulierung, Verantwortlichem und Teststatus.
6. Nutzen Sie Zenith Controls, um ISO/IEC 27002:2022-Kontrollen in Nachweise für die übergreifende Compliance zu übersetzen.
7. Nutzen Sie Zenith Blueprint, um von der Risikobehandlung zur auditbereiten SoA-Validierung zu gelangen.
8. Setzen Sie den Richtliniensatz von Clarysec ein, einschließlich der Informationssicherheitsleitlinie, Risikomanagement-Richtlinie, Richtlinie zur Lieferanten- und Drittparteiensicherheit und Incident-Response-Richtlinie, um die Umsetzung zu beschleunigen.

Der schnellste Weg sind nicht weitere voneinander getrennte Checklisten. Es ist ein integriertes ISMS, eine nachvollziehbare SoA, ein zentralisiertes Nachweismodell und ein einheitlicher Betriebsrhythmus für die übergreifende Compliance.

Clarysec kann Ihnen helfen, ISO 27001:2022 von einem Zertifizierungsprojekt in ein praktisches Kontrollrückgrat für NIS2 und DORA zu verwandeln. Laden Sie Zenith Blueprint herunter, erkunden Sie Zenith Controls, oder buchen Sie ein Clarysec-Assessment, um ein auditbereites Nachweismodell aufzubauen, bevor die nächste Aufsichtsbehörde, der nächste Kunde oder der nächste Ausschuss des Leitungsorgans Nachweise verlangt.