NIS2-Registrierungsnachweise mit ISO 27001:2022

Die E-Mail landete in Annas Posteingang mit einem leisen Aufprall, der sich eher wie eine Sirene anfühlte. Als CISO von CloudFlow, einem schnell wachsenden B2B-SaaS-Anbieter mit Kunden in der gesamten EU, war sie an Sicherheitsfragebögen, Beschaffungsaudits und ISO 27001-Überwachungsaudits gewöhnt. Diese Nachricht war anders.

Die Betreffzeile lautete: „Information Request Regarding National Implementation of Directive (EU) 2022/2555 (NIS2).“ Die nationale Cybersicherheitsbehörde forderte CloudFlow auf, seine Einstufung zu bestätigen, Informationen für die Registrierung als Einrichtung vorzubereiten, die in den Geltungsbereich fallenden Dienste zu identifizieren und bereit zu sein, Maßnahmen zum Management von Cybersicherheitsrisiken nachzuweisen.

Anna hatte ein ISO 27001:2022-Zertifikat gerahmt an der Wand. Der Vertrieb nutzte es bei Enterprise-Deals. Das Leitungsorgan hatte die Informationssicherheitsleitlinie genehmigt. Das interne Audit hatte kürzlich zwei Feststellungen geschlossen. Doch die Frage vor ihr war präziser als der bloße Zertifizierungsstatus.

Konnte CloudFlow schnell und belastbar nachweisen, dass sein ISO 27001:2022-ISMS die NIS2-Verpflichtungen abdeckt?

Genau an diesem Punkt treffen viele Organisationen die falsche Entscheidung. Sie behandeln die NIS2-Registrierung als Einrichtung wie eine administrative Meldung, vergleichbar mit der Aktualisierung eines Unternehmensregisters oder Steuerportals. Das ist sie nicht. Die Registrierung ist der Eintritt in die aufsichtsrechtliche Sichtbarkeit. Danach kann die zuständige Behörde Begründungen zum Geltungsbereich, Aufzeichnungen über Genehmigungen des Leitungsorgans, Verfahren zur Vorfallmeldung, Nachweise zu Lieferantenrisiken, Kontaktstellen, Kennzahlen zur Wirksamkeit von Maßnahmen und den Nachweis verlangen, dass die Organisation weiß, welche Dienste kritisch sind.

Für SaaS-, Cloud-, Managed-Service-, Managed-Security-, Rechenzentrums-, digitale Infrastruktur- und bestimmte Finanzsektoranbieter lautet die eigentliche Frage nicht mehr: „Haben wir eine Sicherheitsrichtlinie?“ Sie lautet: „Können wir eine Nachweiskette von der rechtlichen Verpflichtung über ISMS-Geltungsbereich, Risikobehandlung und Betrieb der Maßnahmen bis hin zur Managementaufsicht zeigen?“

Das stärkste Programm zur Vorbereitung auf die NIS2-Durchsetzung ist keine parallele Tabelle. Es ist ein nachvollziehbares Nachweismodell innerhalb von ISO 27001:2022.

NIS2-Registrierung ist im Kern ein Nachweisproblem

NIS2 gilt breit für öffentliche oder private Einrichtungen in den in Anhang I und Anhang II aufgeführten Sektoren, die den maßgeblichen Schwellenwert für mittlere Unternehmen erreichen oder überschreiten. Außerdem erfasst sie bestimmte Einrichtungen unabhängig von ihrer Größe, darunter Anbieter öffentlicher elektronischer Kommunikationsnetze oder -dienste, Vertrauensdiensteanbieter, TLD-Register, DNS-Diensteanbieter, alleinige Anbieter wesentlicher Dienste sowie Einrichtungen, deren Störung die öffentliche Sicherheit, Gesundheit, systemische Risiken oder nationale beziehungsweise regionale Kritikalität beeinträchtigen könnte.

Für Technologieunternehmen sind die digitalen Kategorien besonders wichtig. Anhang I umfasst digitale Infrastruktur, etwa Anbieter von Cloud-Computing-Diensten, Rechenzentrumsdienste, Content-Delivery-Network-Anbieter, Vertrauensdiensteanbieter, DNS-Diensteanbieter sowie Anbieter öffentlicher elektronischer Kommunikationsnetze oder -dienste. Anhang I umfasst außerdem IKT-Servicemanagement für Business-to-Business-Dienste, einschließlich Managed Service Provider (MSPs) und Managed Security Service Provider (MSSPs). Anhang II umfasst digitale Anbieter wie Online-Marktplätze, Online-Suchmaschinen und Plattformen sozialer Netzwerkdienste.

Das bedeutet: Eine Organisation kann in den NIS2-Geltungsbereich fallen, ohne sich selbst als „kritische Infrastruktur“ zu verstehen. Ein B2B-SaaS-Unternehmen mit Managed-Security-Funktionalität, eine Cloud-Plattform zur Unterstützung regulierter Kunden oder ein fintechnaher Anbieter kann plötzlich eine Registrierungsakte, ein Kontaktmodell für die zuständige Behörde und eine belastbare Argumentation zu den umgesetzten Maßnahmen benötigen.

NIS2 unterscheidet außerdem zwischen wesentlichen und wichtigen Einrichtungen. Wesentliche Einrichtungen unterliegen in der Regel einem proaktiveren Aufsichtsmodell, während wichtige Einrichtungen meist nach Hinweisen auf Nichteinhaltung oder nach Vorfällen beaufsichtigt werden. Die Unterscheidung ist relevant, beseitigt aber nicht den Vorbereitungsbedarf. Beide Kategorien benötigen Governance, Risikomanagement, Vorfallmeldung, Lieferantensicherheit und Nachweise.

Finanzunternehmen müssen zudem DORA berücksichtigen. NIS2 Article 4 erkennt an, dass dort, wo ein sektorspezifischer Rechtsakt der Union mindestens gleichwertige Verpflichtungen zum Management von Cybersicherheitsrisiken und zur Meldung von Vorfällen auferlegt, diese sektorspezifischen Vorschriften für die entsprechenden Bereiche gelten. DORA gilt ab dem 17. Januar 2025 und regelt IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch, Management von IKT-Drittparteienrisiken, vertragliche Kontrollen und die Überwachung kritischer IKT-Drittdienstleister. Für erfasste Finanzunternehmen ist DORA das primäre Cyberresilienz-Rahmenwerk für sich überschneidende Anforderungen; NIS2-Schnittstellen und die Koordination mit nationalen Behörden können dennoch relevant bleiben.

Die Lehre ist einfach: Warten Sie nicht auf das Portalfeld oder die E-Mail der Aufsichtsbehörde, bevor Sie Nachweise aufbauen. Jede Registrierungsantwort impliziert eine spätere Auditfrage.

Mit dem ISMS-Geltungsbereich beginnen, nicht mit dem Portalformular

ISO 27001:2022 ist hilfreich, weil die Norm die Organisation zwingt, Kontext, interessierte Parteien, regulatorische Verpflichtungen, Geltungsbereich, Risiken, Behandlungspläne, Betrieb der Maßnahmen, Überwachung, internes Audit, Managementbewertung und Verbesserung festzulegen.

Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen bestimmt, interessierte Parteien und deren Anforderungen identifiziert, entscheidet, welche Anforderungen durch das ISMS adressiert werden, den ISMS-Geltungsbereich unter Berücksichtigung von Schnittstellen und Abhängigkeiten definiert, diesen Geltungsbereich dokumentiert und die ISMS-Prozesse betreibt.

Für NIS2 sollte dieser Geltungsbereich praktische Fragen beantworten:

• Welche EU-Dienste, juristischen Einheiten, Tochtergesellschaften, Plattformen, Infrastrukturkomponenten und Geschäftsbereiche sind relevant?
• Welche Kategorie aus Anhang I oder Anhang II kann anwendbar sein?
• Ist die Organisation wesentlich, wichtig, von DORA erfasst, außerhalb des Geltungsbereichs oder noch Gegenstand einer nationalen Einstufung?
• Welche Dienste sind für Kunden, öffentliche Sicherheit, Finanzstabilität, Gesundheitswesen, digitale Infrastruktur oder andere regulierte Sektoren kritisch?
• Welche Cloud-Anbieter, MSPs, MSSPs, Rechenzentren, Unterauftragnehmer und sonstigen Lieferanten unterstützen diese Dienste?
• Welche Mitgliedstaaten, zuständigen Behörden, CSIRTs, Datenschutzaufsichtsbehörden und Finanzaufsichtsbehörden können relevant sein?

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint platziert diese Arbeit früh, in Schritt 2, Anforderungen interessierter Parteien und ISMS-Geltungsbereich. Er weist Organisationen an, Aufsichtsbehörden und Behörden zu identifizieren, rechtliche und regulatorische Anforderungen zu prüfen, Verträge und Vereinbarungen zu überprüfen, Stakeholder-Interviews durchzuführen und erwartete Branchenstandards zu berücksichtigen.

Aktionspunkt 4.2: Erstellen Sie eine Liste aller wesentlichen interessierten Parteien und dokumentieren Sie deren Anforderungen in Bezug auf Informationssicherheit. Seien Sie gründlich – denken Sie an alle, die sich beschweren oder Konsequenzen tragen würden, wenn Ihre Sicherheit versagt oder eine bestimmte Maßnahme fehlt. Diese Liste zeigt, was Sie über Ihr ISMS einhalten oder erfüllen müssen, und fließt in Risikobeurteilung und Auswahl der Maßnahmen ein.

Das ist der richtige Ausgangspunkt für die NIS2-Registrierung. Erstellen Sie vor der Einreichung eine kurze NIS2-Geltungsbereichsnotiz, die das Geschäftsmodell mit Kategorien aus Anhang I oder Anhang II verbindet, Größen- und Dienstannahmen dokumentiert, die Auslegung des nationalen Rechts festhält, zuständige Behörden identifiziert und angibt, ob DORA, GDPR, Kundenverträge oder Sektorregeln ebenfalls gelten.

Clarysecs SME Legal and Regulatory Compliance Policy Richtlinie zur rechtlichen und regulatorischen Compliance für KMU definiert den Zweck klar:

„Diese Richtlinie definiert den Ansatz der Organisation zur Identifizierung, Erfüllung und zum Nachweis der Einhaltung rechtlicher, regulatorischer und vertraglicher Verpflichtungen.“

Für größere Programme ist Clarysecs Legal and Regulatory Compliance Policy Richtlinie zur rechtlichen und regulatorischen Compliance noch expliziter:

„Alle rechtlichen und regulatorischen Verpflichtungen müssen spezifischen Richtlinien, Maßnahmen und Verantwortlichen innerhalb des Informationssicherheits-Managementsystems (ISMS) zugeordnet werden.“

Dieser Satz ist die Grundlage der Vorbereitung auf Durchsetzungsmaßnahmen. Wenn eine Aufsichtsbehörde fragt, wie NIS2-Verpflichtungen identifiziert wurden, sollte die Antwort nicht lauten: „Die Rechtsabteilung hat uns beraten.“ Die Antwort sollte ein dokumentiertes Register sein, verknüpft mit Geltungsbereich, Risiken, Maßnahmenverantwortlichen, Verfahren, aufbewahrten Nachweisen und Managementbewertung.

Die NIS2-Nachweiskette innerhalb von ISO 27001:2022 aufbauen

NIS2 Article 21 verlangt von wesentlichen und wichtigen Einrichtungen, geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen umzusetzen, um Risiken für Netzwerk- und Informationssysteme zu steuern, die für Betrieb oder Leistungserbringung genutzt werden. Die Maßnahmen müssen Stand der Technik, einschlägige europäische und internationale Normen, soweit anwendbar, Kosten, Risikoexposition, Größe, Wahrscheinlichkeit und Schwere von Vorfällen sowie gesellschaftliche und wirtschaftliche Auswirkungen berücksichtigen.

Article 21(2) nennt Mindestbereiche, darunter Risikoanalyse und Sicherheitsrichtlinien für Informationssysteme, Incident Handling, Aufrechterhaltung des Geschäftsbetriebs, Backups, Disaster Recovery, Krisenmanagement, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Umgang mit Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptografie, Sicherheit im Personalwesen, Zugriffskontrolle, Asset-Management, Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung sowie sichere Kommunikation, soweit angemessen.

ISO 27001:2022 lässt sich dieser Struktur natürlich zuordnen. Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung und Risikobehandlung, einschließlich Risikoakzeptanzkriterien, Risikoverantwortlichen, Analyse von Wahrscheinlichkeit und Auswirkung, Risikobehandlungsplan, Vergleich mit Anhang-A-Maßnahmen und einer Anwendbarkeitserklärung. Klausel 8 verlangt operative Planung und Steuerung, Nachweise, dass Prozesse wie geplant betrieben wurden, Änderungskontrolle, Steuerung extern bereitgestellter Prozesse, wiederkehrende Risikobeurteilungen und dokumentierte Behandlungsergebnisse. Klausel 9.1 verlangt Überwachung, Messung, Analyse und Bewertung. Klausel 9.2 verlangt internes Audit. Klausel 10.2 verlangt Maßnahmen bei Nichtkonformitäten und Korrekturmaßnahmen.

Clarysecs Risk Management Policy Risikomanagement-Richtlinie für KMU macht daraus eine operative Regel:

„Alle identifizierten Risiken müssen im Risikoregister erfasst werden.“

Die Enterprise Risk Management Policy Risikomanagement-Richtlinie verbindet Risikobehandlung mit der Auswahl von Maßnahmen nach ISO 27001:2022:

„Entscheidungen zu Maßnahmen, die aus dem Risikobehandlungsprozess resultieren, sind in der SoA abzubilden.“

Das ist wichtig, weil NIS2-Nachweise nachvollziehbar sein sollten. Wenn eine Behörde fragt, warum eine Maßnahme existiert, verweisen Sie auf Verpflichtung, Risiko, Behandlungsentscheidung, Maßnahmenverantwortlichen, SoA-Eintrag, Verfahren und Nachweis. Wenn die Behörde fragt, warum eine Maßnahme nicht ausgewählt wurde, verweisen Sie auf die SoA-Begründung, die genehmigte Risikoakzeptanz und die Managementbewertung.

Die beste Nachweiskette ist auf die bestmögliche Weise unspektakulär. Jede Verpflichtung hat einen Verantwortlichen. Jeder Verantwortliche hat eine Maßnahme. Jede Maßnahme hat Nachweise. Jede Ausnahme hat eine Genehmigung. Jede Audit-Feststellung hat eine Korrekturmaßnahme.

Article 20-Governance in Nachweise des Leitungsorgans überführen

NIS2 Article 20 verlagert Cybersicherheit in den Verantwortungsbereich des Leitungsorgans. Leitungsorgane müssen die für Article 21 angenommenen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und können für Verstöße haftbar gemacht werden. Mitglieder des Leitungsorgans müssen Schulungen absolvieren; Einrichtungen werden angehalten, Mitarbeitenden regelmäßig Cybersicherheitsschulungen bereitzustellen.

Ein Leitungsorgan kann NIS2 nicht einfach an die IT delegieren. Nachweise sollten zeigen, dass das Management die NIS2-Geltungsbereichsanalyse verstanden, den Risikomanagementansatz genehmigt, wesentliche Risiken geprüft, Ressourcen zugewiesen, die Umsetzung nachverfolgt, Vorfälle und Übungen überprüft und Schulungen erhalten hat.

Die ISO 27001:2022-Klauseln 5.1 bis 5.3 unterstützen dieses Governance-Modell, indem sie Engagement der obersten Leitung, Ausrichtung der Informationssicherheitsziele an der Geschäftsstrategie, Integration von ISMS-Anforderungen in Geschäftsprozesse, Ressourcen, Kommunikation, Rechenschaftspflicht und Berichterstattung der ISMS-Leistung an die oberste Leitung verlangen.

Clarysecs Governance Roles and Responsibilities Policy Richtlinie zu Governance-Rollen und Verantwortlichkeiten definiert die Rolle der Sicherheitsverbindung als eine Rolle, die:

„als primäre Schnittstelle zu Auditoren, Aufsichtsbehörden und der obersten Leitung in Fragen der Informationssicherheit fungiert.“

Diese Rolle sollte im NIS2-Registrierungsnachweispaket namentlich benannt werden. Sie sollte nicht implizit bleiben. Behörden, Auditoren und Kunden wollen wissen, wer den regulatorischen Kontakt koordiniert, wer für Vorfallmeldungen verantwortlich ist, wer das Rechtsregister pflegt, wer Behördendaten aktualisiert und wer an das Leitungsorgan berichtet.

Ein praktischer Governance-Nachweissatz umfasst:

• Genehmigung des Rahmenwerks für das Management von Cybersicherheitsrisiken durch das Leitungsorgan.
• Protokolle der Managementbewertung zu NIS2-Geltungsbereich, Risiken, Vorfällen, Lieferanten und Vorbereitungsstand.
• Schulungsaufzeichnungen für Mitglieder des Leitungsorgans und Mitarbeitende.
• Eine RACI-Matrix für NIS2-Verpflichtungen, ISO 27001:2022-Maßnahmen, Vorfallmeldung, Lieferantensicherheit und regulatorische Kommunikation.
• Nachweise, dass NIS2-Verpflichtungen in internes Audit und Compliance-Überwachung einbezogen sind.
• Nachverfolgung von Korrekturmaßnahmen für Lücken, überfällige Risiken, Ausnahmen und fehlgeschlagene Tests.

Articles 32 und 33 machen auch die Nachweisqualität relevant, indem sie Faktoren schwerwiegender Verstöße benennen, etwa wiederholte Verstöße, fehlende Meldung oder Behebung erheblicher Vorfälle, Nichtbehebung von Mängeln nach verbindlichen Anweisungen, Behinderung von Audits oder Überwachung sowie falsche oder grob unzutreffende Informationen. Schwache Nachweise können zu einem Durchsetzungsproblem werden, selbst wenn technische Maßnahmen existieren.

Behördenkontakt- und Vorfallmeldungsnachweise vor 02:00 Uhr vorbereiten

Die schmerzhaftesten Fehler bei der Vorfallmeldung beginnen häufig mit einer einfachen Frage: „Wen benachrichtigen wir?“ Bei Ransomware, DNS-Ausfall, Cloud-Kompromittierung oder Datenexposition verlieren Teams Zeit damit, den richtigen CSIRT, die zuständige Behörde, Datenschutzaufsichtsbehörde, Finanzaufsicht, Strafverfolgungsstelle, Kundenvorlage und interne Genehmigungsstelle zu suchen.

NIS2 Article 23 verlangt die unverzügliche Meldung erheblicher Vorfälle, die die Leistungserbringung beeinträchtigen. Ein erheblicher Vorfall ist ein Vorfall, der schwere Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen könnte oder andere durch erhebliche materielle oder immaterielle Schäden betroffen hat oder betreffen könnte. Die Zeitachse ist gestuft: Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, Vorfallmeldung innerhalb von 72 Stunden, Zwischenaktualisierungen auf Anfrage und ein Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung oder nach Behandlung des Vorfalls bei fortdauernden Vorfällen. Soweit angemessen, müssen auch Leistungsempfänger über erhebliche Vorfälle oder erhebliche Cyberbedrohungen und Schutzmaßnahmen informiert werden.

Zenith Blueprint, Phase „Controls in Action“, Schritt 22, behandelt Behördenkontakte als Vorbereitung, nicht als Panikreaktion:

Das Prinzip ist einfach: Wenn Ihre Organisation Ziel eines Cyberangriffs wäre, in eine Datenpanne verwickelt wäre oder Gegenstand einer Untersuchung wäre, wer würde die Behörden kontaktieren? Woher wüsste diese Person, was zu sagen ist? Unter welchen Bedingungen würde ein solcher Kontakt eingeleitet? Diese Fragen müssen im Voraus beantwortet werden, nicht nachträglich.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022-Maßnahme 5.5, Kontakt mit Behörden. Er klassifiziert die Maßnahme als präventiv und korrektiv, verknüpft mit Vertraulichkeit, Integrität und Verfügbarkeit sowie mit den Konzepten Identify, Protect, Respond und Recover. Außerdem verbindet er Maßnahme 5.5 mit ISO/IEC 27002:2022-Maßnahmen 5.24 Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, 6.8 Meldung von Informationssicherheitsereignissen, 5.7 Bedrohungsinformationen, 5.6 Kontakt mit besonderen Interessengruppen und 5.26 Reaktion auf Informationssicherheitsvorfälle.

Aus Cross-Compliance-Sicht ordnet Zenith Controls den Kontakt mit Behörden NIS2 Article 23, GDPR-Meldungen bei Datenschutzverletzungen, DORA-Vorfallmeldungen, NIST SP 800-53 IR-6 Incident Reporting und COBIT 2019-Praktiken zur externen Eskalation zu. Ein einziges Behördenkontaktregister kann mehrere Verpflichtungen erfüllen, wenn es richtig konzipiert ist.

Clarysecs Incident Response Policy Incident-Response-Richtlinie für KMU macht die rechtliche Triage explizit:

„Wenn Kundendaten betroffen sind, muss der General Manager die rechtlichen Meldepflichten auf Grundlage der Anwendbarkeit von GDPR, NIS2 oder DORA bewerten.“

Ein belastbares Nachweispaket für Behördenkontakte sollte Folgendes enthalten:

• Kontaktdaten der zuständigen Behörde und des CSIRT je Mitgliedstaat und Dienst.
• Kontakte der Datenschutzaufsichtsbehörden für GDPR-Meldungen von Verletzungen des Schutzes personenbezogener Daten.
• Kontakte der Finanzaufsicht, falls DORA anwendbar ist.
• Kontaktwege zu Strafverfolgungs- und Cybercrime-Stellen.
• Autorisierte interne Kommunikatoren und Stellvertretungen.
• Schwellenwerte für Vorfälle nach NIS2, GDPR, DORA, Kundenverträgen und Cyberversicherung.
• Vorlagen für 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Zwischenaktualisierung und Ein-Monats-Abschlussbericht.
• Aufzeichnungen zu Tabletop-Übungen, mit denen externe Meldungen getestet wurden.
• Aufzeichnungen über frühere Meldungen, Entscheidungen gegen eine Meldung und rechtliche Begründungen.

NIS2 Article 21 ISO 27001-Maßnahmen und Richtliniennachweisen zuordnen

Ein Zertifikat allein beantwortet die Frage einer Aufsichtsbehörde nicht. Eine Zuordnung der Maßnahmen tut es. Die folgende Tabelle bietet Sicherheits- und Compliance-Teams eine praktische Brücke zwischen Bereichen aus NIS2 Article 21, ISO/IEC 27002:2022-Maßnahmen, Clarysec-Richtlinienankern und Nachweisen.

Clarysecs Zenith Controls behandelt außerdem ISO/IEC 27002:2022-Maßnahme 5.31, rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen, als präventive Maßnahme mit Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Er verbindet 5.31 mit Datenschutz und Schutz von PII, Aufbewahrung von Aufzeichnungen, unabhängiger Überprüfung und Einhaltung interner Richtlinien. Außerdem ordnet er 5.31 der GDPR-Rechenschaftspflicht, NIS2-Einhaltung in der Lieferkette, DORA-IKT-Risikomanagement, NIST CSF-Governance, NIST SP 800-53-Programmkontrollen und COBIT 2019-Aufsicht über externe Einhaltung zu.

„Maßnahme 5.31 stellt sicher, dass alle relevanten rechtlichen, regulatorischen, gesetzlichen und vertraglichen Anforderungen im Zusammenhang mit Informationssicherheit identifiziert, dokumentiert und kontinuierlich gemanagt werden.“

Genau das will eine nationale Behörde nach der Registrierung sehen: nicht nur, dass NIS2 aufgeführt ist, sondern dass die Organisation über einen lebenden Mechanismus verfügt, um Verpflichtungen zu identifizieren, zuzuordnen, umzusetzen, zu überwachen und zu aktualisieren.

NIS2 nicht von DORA, GDPR, Lieferanten und Cloud trennen

NIS2-Nachweise existieren selten isoliert.

NIS2 Article 21(2)(d) verlangt Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zu Lieferanten und Dienstleistern. Article 21(3) verlangt, dass Entscheidungen zu Lieferantenrisiken Schwachstellen, die allgemeine Produktqualität, Cybersicherheitspraktiken, sichere Entwicklungsverfahren und relevante koordinierte EU-Risikobewertungen zur Lieferkette berücksichtigen.

ISO 27001:2022 Anhang A bietet die operative Brücke über A.5.19 bis A.5.23. Für SaaS- und Cloud-Organisationen bestimmen diese Maßnahmen häufig, ob Registrierungsnachweise oberflächlich oder belastbar sind.

DORA schärft das Lieferantenbild für Finanzunternehmen. Articles 28 bis 30 verlangen Management von IKT-Drittparteienrisiken, ein Register der IKT-Serviceverträge, die Unterscheidung von Diensten zur Unterstützung kritischer oder wichtiger Funktionen, Risikobewertung vor Vertragsschluss, Due Diligence, vertragliche Sicherheitsanforderungen, Audit- und Inspektionsrechte, Kündigungsrechte, getestete Exit-Strategien, Bewertung von Unterauftragsvergabe, Transparenz zum Datenstandort, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden und Übergangsregelungen. Wenn ein SaaS-Anbieter DORA-regulierte Kunden bedient, können seine Verträge und sein Assurance-Paket geprüft werden, auch wenn er selbst nicht das Finanzunternehmen ist.

Clarysecs Third-party and supplier security policy - SME Richtlinie zur Sicherheit von Drittparteien und Lieferanten für KMU sollte daher in das NIS2-Nachweispaket eingebunden werden. Die Lieferantenvorbereitung sollte Folgendes umfassen:

• Lieferanteninventar und Kritikalitätsklassifizierung.
• Lieferanten-Due-Diligence und Risikobeurteilungen.
• Vertragsklauseln zu Sicherheit, Vorfallunterstützung, Auditrechten, Datenstandort, Unterauftragsvergabe und Exit.
• Matrizen zur geteilten Cloud-Verantwortung.
• Überwachungsaufzeichnungen für kritische Anbieter.
• Exit- und Wiederherstellungstests für kritische Dienste.
• Verfahren zur Lieferantenvorfallmeldung und Eskalation.

GDPR muss ebenfalls integriert werden. Ein erheblicher NIS2-Vorfall kann zugleich eine Verletzung des Schutzes personenbezogener Daten sein, wenn Kunden-, Mitarbeiter- oder Benutzerdaten kompromittiert werden. GDPR verlangt von Verantwortlichen, Rechenschaftspflicht nachzuweisen und, sofern Meldeschwellen erreicht sind, die Aufsichtsbehörde innerhalb von 72 Stunden nach Kenntniserlangung von einer Verletzung des Schutzes personenbezogener Daten zu benachrichtigen. Ihr Incident-Response-Workflow muss NIS2-, GDPR-, DORA-, vertragliche und kundenbezogene Verpflichtungen parallel bewerten.

Ein einwöchiges NIS2-Nachweispaket zusammenstellen

Ein SaaS-Anbieter, MSP, MSSP, Cloud-Anbieter oder Unternehmen der digitalen Infrastruktur kann in einer fokussierten Woche erhebliche Fortschritte erzielen.

Tag 1, Einrichtung und Dienste klassifizieren. Nutzen Sie die ISMS-Geltungsbereichserklärung und das Register interessierter Parteien. Ergänzen Sie eine NIS2-Geltungsbereichsnotiz, die Kategorien aus Anhang I oder Anhang II, EU-Dienste, Mitgliedstaaten, Kunden, Abhängigkeiten, Größenannahmen und die Frage identifiziert, ob DORA oder Sektorregeln gelten. Erfassen Sie Einstufungsunsicherheit als Risiko, wenn die rechtliche Auslegung noch nicht final ist.

Tag 2, Register der rechtlichen und regulatorischen Verpflichtungen aktualisieren. Ergänzen Sie NIS2 Articles 20, 21 und 23, Registrierungsanforderungen nach nationalem Recht, GDPR-Pflichten bei Datenschutzverletzungen, DORA-Verpflichtungen, soweit relevant, und wesentliche vertragliche Meldepflichten. Ordnen Sie jede Verpflichtung einer Richtlinie, einem Verantwortlichen, einer Maßnahme, einer Nachweisquelle und einer Überprüfungsfrequenz zu.

Tag 3, Risikobeurteilung und -behandlung aktualisieren. Berücksichtigen Sie rechtliche, regulatorische, operative, lieferantenbezogene, finanzielle, reputationsbezogene und gesellschaftliche Auswirkungen in den Risikokriterien. Ergänzen Sie Risiken wie Nichtregistrierung, falsche Einstufung der Einrichtung, versäumte 24-Stunden-Frühwarnung, nicht verfügbare Behördenkontakte, Lieferantenausfall mit Auswirkungen auf kritische Dienste, unzureichende Aufsicht durch das Leitungsorgan und fehlende Fähigkeit, Wirksamkeit von Maßnahmen nachzuweisen.

Tag 4, SoA aktualisieren. Bestätigen Sie NIS2-relevante Maßnahmen, darunter A.5.5 Kontakt mit Behörden, A.5.19 bis A.5.23 Lieferanten- und Cloud-Maßnahmen, A.5.24 bis A.5.28 Vorfallmaßnahmen, A.5.29 Sicherheit bei Störungen, A.5.30 IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs, A.5.31 rechtliche Anforderungen, A.5.34 Datenschutz, A.8.8 Schwachstellenmanagement, A.8.13 Backups, A.8.15 Protokollierung, A.8.16 Überwachungstätigkeiten, A.8.24 Kryptografie und sichere Entwicklungsmaßnahmen A.8.25 bis A.8.32.

Tag 5, Vorfallmeldung testen. Führen Sie eine Tabletop-Übung durch: Eine fehlerhafte Cloud-Konfiguration legt Kundendaten offen und stört den Dienst in zwei Mitgliedstaaten. Starten Sie die Uhr. Kann das Team das Ereignis klassifizieren, GDPR-, NIS2-, DORA-, vertragliche und kundenspezifische Schwellenwerte bewerten, eine 24-Stunden-Frühwarnung vorbereiten, eine 72-Stunden-Meldung entwerfen, Beweismittel sichern und eine Ursachenanalyse zuweisen?

Tag 6, Nachweise sammeln. Erstellen Sie einen für die Aufsicht belastbaren Ordner mit Geltungsbereichsnotiz, Rechtsregister, Risikoregister, SoA, Behördenkontaktliste, Incident-Playbook, Lieferantenregister, Sitzungsprotokollen des Leitungsorgans, Schulungsaufzeichnungen, Protokollen, Überwachungsberichten, Backup-Tests, Schwachstellenberichten, Geltungsbereich des internen Audits und Korrekturmaßnahmenprotokoll.

Tag 7, Managementbewertung. Präsentieren Sie das Vorbereitungspaket der Führungsebene. Dokumentieren Sie Genehmigungen, Restrisiken, offene Maßnahmen, Fristen, Ressourcen und Rechenschaftspflichten der Verantwortlichen. Wenn die Registrierung fällig ist, fügen Sie den Nachweisindex dem Entscheidungsdatensatz zur Registrierung bei.

Clarysecs Audit and Compliance Monitoring Policy for SMEs Richtlinie zur Audit- und Compliance-Überwachung für KMU nimmt diesen Bedarf vorweg:

„Nachweise müssen an NIS2-Verpflichtungen ausgerichtet sein, wenn die Organisation als wichtige Einrichtung benannt ist oder anderweitig in den Geltungsbereich des nationalen Rechts fällt.“

Die Enterprise Audit and Compliance Monitoring Policy Richtlinie zur Audit- und Compliance-Überwachung formuliert das Ziel:

„Belastbare Nachweise und einen Prüfpfad zur Unterstützung regulatorischer Anfragen, Gerichtsverfahren oder Kundenanforderungen zur Vertrauensbildung erzeugen.“

Das ist das Ziel: belastbare Nachweise, bevor die Anfrage eintrifft.

Auf unterschiedliche Auditperspektiven vorbereiten

Ein Zertifizierungsauditor, eine nationale Behörde, ein Kundenauditor, ein Datenschutzauditor und ein Supplier-Assurance-Team werden nicht identische Fragen stellen. Ein starkes NIS2-Nachweispaket funktioniert für alle.

Für ISO/IEC 27002:2022-Maßnahme 5.5 erwarten Auditoren in der Regel dokumentierte Behördenkontakte, zugewiesene Verantwortlichkeiten, Pflege der Kontaktdaten, Incident-Response-Playbooks und szenariobasierte Klarheit. Eine einfache Auditfrage kann den Reifegrad offenlegen: „Wer kontaktiert bei Ransomware die Strafverfolgungsbehörden oder den nationalen CSIRT?“ Wenn die Antwort davon abhängt, dass sich jemand an einen Namen erinnert, ist die Maßnahme nicht bereit.

Clarysecs Logging and Monitoring Policy Richtlinie zur Protokollierung und Überwachung für KMU verstärkt die Nachweiserwartung:

„Protokolle müssen externen Auditoren oder Aufsichtsbehörden auf Anfrage verfügbar und verständlich sein.“

Clarysecs Information Security Policy Informationssicherheitsleitlinie setzt den breiteren Unternehmensstandard:

„Alle implementierten Maßnahmen müssen auditierbar sein, durch dokumentierte Verfahren unterstützt werden und aufbewahrte Nachweise über den Betrieb enthalten.“

Das ist der Audit-Test in einem Satz. Wenn eine Maßnahme nicht nachgewiesen werden kann, wird sie wenig Gewicht haben, wenn eine zuständige Behörde Nachweise verlangt.

Abschließende Checkliste für NIS2-Registrierungsnachweise

Nutzen Sie diese Checkliste vor der Registrierung oder vor der Beantwortung einer Anfrage einer nationalen Behörde.

• Dokumentieren Sie die NIS2-Geltungsbereichsanalyse, einschließlich Begründung nach Anhang I oder Anhang II, Dienstbeschreibungen, Größenannahmen, Präsenz in Mitgliedstaaten und Einstufung der Einrichtung.
• Identifizieren Sie, ob DORA direkt gilt oder indirekt über Finanzsektorkunden und IKT-Serviceverträge relevant ist.
• Aktualisieren Sie den ISMS-Geltungsbereich, um relevante Dienste, Abhängigkeiten, ausgelagerte Prozesse und regulatorische Schnittstellen einzubeziehen.
• Ergänzen Sie NIS2, GDPR, DORA, Sektorregeln und vertragliche Anforderungen im Register der rechtlichen und regulatorischen Verpflichtungen.
• Ordnen Sie jede Verpflichtung Richtlinien, Maßnahmen, Verantwortlichen, Nachweisen, Überprüfungsfrequenz und Managementberichterstattung zu.
• Bestätigen Sie Genehmigung und Aufsicht des Leitungsorgans über Maßnahmen zum Management von Cybersicherheitsrisiken.
• Pflegen Sie Schulungsaufzeichnungen zur Cybersicherheit für Management und Mitarbeitende.
• Aktualisieren Sie Risikokriterien um regulatorische Auswirkungen, Dienstunterbrechung, Kundenschäden, grenzüberschreitende Auswirkungen und Lieferantenabhängigkeit.
• Erfassen Sie NIS2-bezogene Risiken im Risikoregister und verknüpfen Sie sie mit Behandlungsplänen.
• Aktualisieren Sie die SoA mit NIS2-relevanten Anhang-A-Maßnahmen und Umsetzungsstatus.
• Pflegen Sie Behördenkontaktlisten und Meldeverfahren für CSIRTs, zuständige Behörden, Datenschutzaufsichtsbehörden, Finanzaufsichtsbehörden und Strafverfolgungsbehörden.
• Testen Sie den Workflow für 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Zwischenaktualisierung und Ein-Monats-Abschlussbericht.
• Pflegen Sie Lieferanten- und Cloud-Nachweise, einschließlich Due Diligence, Verträgen, Auditrechten, Überwachung, Unterauftragsvergabe und Exit-Plänen.
• Weisen Sie die Wirksamkeit von Maßnahmen durch Protokolle, Kennzahlen, Audits, Dashboards, Testergebnisse und Korrekturmaßnahmen nach.
• Bereiten Sie einen Nachweisindex vor, damit jede Anfrage von Aufsichtsbehörden, Kunden oder Auditoren schnell beantwortet werden kann.

Der nächste Schritt mit Clarysec

Die NIS2-Registrierung als Einrichtung ist nicht die Ziellinie. Sie ist der Punkt, an dem Ihre Organisation für die nationale Cybersicherheitsaufsicht sichtbar wird. Die richtige Frage lautet nicht: „Können wir uns registrieren?“ Die richtige Frage lautet: „Wenn die Behörde nach der Registrierung Nachweise verlangt, können wir innerhalb von Stunden, nicht Wochen, eine kohärente ISO 27001:2022-Argumentation liefern?“

Clarysec unterstützt Organisationen beim Aufbau dieser Argumentation durch den Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls und praxisnahe ISO 27001:2022-Richtliniensets, die rechtliche Verpflichtungen, Risikobehandlung, Vorfallmeldung, Lieferantensicherheit, Protokollierung, Überwachung, Auditnachweise und Rechenschaftspflicht des Managements verbinden.

Führen Sie eine NIS2-Nachweislückenprüfung gegen Ihr aktuelles ISMS durch. Beginnen Sie mit Geltungsbereichsnotiz, Rechtsregister, Risikoregister, SoA, Behördenkontaktliste, Workflow zur Vorfallmeldung, Lieferantenregister und Auditnachweisordner. Wenn diese Artefakte unvollständig oder nicht verbunden sind, kann Clarysec Ihnen helfen, sie in ein belastbares Nachweispaket für die Aufsicht zu überführen, bevor Ihre nationale Behörde danach fragt.