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

Um 08:17 Uhr an einem Dienstag erhält Maria, CISO eines europäischen Managed Service Providers, die Warnmeldung, die jeder MSP fürchtet. Ein privilegiertes Konto für die Fernadministration hat Impossible-Travel-Warnmeldungen ausgelöst. Zwei Kunden-Tenants zeigen auffällige administrative Aktionen. Das SOC hat bereits eine Bridge für einen kritischen Vorfall eröffnet.

Um 09:00 Uhr schaltet sich der CEO in die Besprechung ein. Die Fragen ändern sich sofort.

Fallen wir in den Geltungsbereich von NIS2? Gilt die Durchführungsverordnung (EU) 2024/2690 der Kommission für uns? Benötigen wir eine Frühwarnung innerhalb von 24 Stunden? Welche Kunden müssen benachrichtigt werden? Können wir nachweisen, dass MFA, Protokollierung, Segmentierung, Schwachstellenmanagement, Lieferantenkontrollen und Vorfalleskalation bereits vor dem Vorfall wirksam betrieben wurden?

Marias Unternehmen ist nach ISO/IEC 27001:2022 zertifiziert. Es erbringt Cloud-Management, Rechenzentrumsservices und Managed-Security-Unterstützung für Kunden, darunter ein Logistikdienstleister und eine Regionalbank. Das Zertifikat ist wichtig, beantwortet die operativen Fragen aber nicht von selbst. Die Rechtsabteilung hat einen Entwurf für den Meldeprozess. Der Compliance-Manager hat eine Tabelle. Der Auditor fordert die Erklärung zur Anwendbarkeit, Tests der Incident Response, Zugriffsprotokolle für privilegierte Zugriffe, Lieferanten-Due-Diligence, Nachweise zur gemeinsamen Verantwortung in der Cloud und Annahmen zur Aufrechterhaltung des Geschäftsbetriebs.

Das ist der Moment, in dem NIS2 aufhört, ein Rechtstext zu sein, und zu einem operativen Control-Problem wird.

Für Anbieter von Cloud-Computing-Services, Managed Service Provider, Managed Security Service Provider und Rechenzentrumsanbieter heben NIS2 und die Durchführungsverordnung 2024/2690 die Anforderungen von allgemeiner Sicherheitsabsicht auf prüfbare Control-Nachweise an. Governance, Risikomanagement, Zugriffskontrolle, Asset-Management, Schwachstellenbehandlung, Incident Response, Lieferantensicherheit, Protokollierung, Überwachung, Verschlüsselung, Aufrechterhaltung des Geschäftsbetriebs und physische Resilienz müssen als zusammenhängendes System betrieben werden.

ISO/IEC 27001:2022 ist das beste Rückgrat für dieses System, jedoch nur, wenn die Organisation NIS2-Anforderungen in den ISMS-Geltungsbereich, das Risikoregister, die Erklärung zur Anwendbarkeit, die Richtlinien und das Nachweismodell überführt. Ein Zertifikat an der Wand reicht nicht aus. Die eigentliche Arbeit besteht darin, einen auditierbaren roten Faden von der Regulierung zum Risiko, vom Risiko zum Control, vom Control zur Richtlinie und von der Richtlinie zu operativen Nachweisen aufzubauen.

Warum NIS2 2024/2690 die Compliance-Diskussion für Cloud und MSP verändert

NIS2 verwendet ein Sektor-plus-Größe-Modell, die Kategorien digitale Infrastruktur und IKT-Servicemanagement sind jedoch bewusst weit gefasst. Nach NIS2 Article 2 und Article 3 in Verbindung mit Annex I und Annex II können viele Organisationen als wesentliche oder wichtige Einrichtungen eingestuft werden, darunter Anbieter von Cloud-Computing-Services, Anbieter von Rechenzentrumsservices, Managed Service Provider, Managed Security Service Provider, DNS-Anbieter, TLD-Registries, Content Delivery Networks und Vertrauensdiensteanbieter. Die Mitgliedstaaten müssen Listen wesentlicher und wichtiger Einrichtungen erstellen und regelmäßig überprüfen; die erste Frist für diese Liste ist der 17. April 2025.

Das ist relevant, weil Cloud-, MSP-, MSSP- und Rechenzentrumsanbieter Teil der Risikoketten anderer Organisationen sind. Eine Kompromittierung der Cloud-Control-Plane kann Tausende Kundensysteme betreffen. Ein Rechenzentrumsausfall kann Auswirkungen auf Banken, Gesundheitswesen, Logistik und öffentliche Verwaltung haben. Ein kompromittierter MSP-Zugang kann zu einem Multi-Client-Ransomware-Ereignis werden. Ein Erkennungsfehler eines MSSP kann die Eindämmung bei regulierten Kunden verzögern.

NIS2 Article 20 verlangt, dass Leitungsorgane Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und deren Umsetzung überwachen. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen auf Basis eines All-Gefahren-Ansatzes. Die Grundlage umfasst Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Schwachstellenbehandlung und Offenlegung, Bewertung der Wirksamkeit, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management, MFA oder kontinuierliche Authentifizierung, sichere Kommunikation und Notfallkommunikation.

Article 23 ergänzt eine gestufte Meldung erheblicher Vorfälle, einschließlich einer Frühwarnung innerhalb von 24 Stunden, einer Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichten auf Anfrage und eines Abschlussberichts innerhalb eines Monats nach der Meldung oder, wenn der Vorfall andauert, nach Abschluss der Vorfallsbehandlung.

Die Durchführungsverordnung 2024/2690 konkretisiert diese Erwartungen für relevante digitale Anbieter. In der Praxis werden Behörden, Kunden und Auditoren nicht nur fragen, ob Richtlinien existieren. Sie werden fragen, ob die Controls zugeordnet, verantwortet, getestet und nachgewiesen sind.

ISO/IEC 27001:2022 macht NIS2 zum operativen Kontext des ISMS

Ein häufiger Fehler bei der NIS2-Vorbereitung besteht darin, mit einer großen Checkliste zu beginnen und Aufgaben auf IT, Rechtsabteilung, SOC, Infrastruktur, Lieferantenmanagement und Compliance zu verteilen. Das erzeugt Aktivität, scheitert aber im Audit häufig daran, dass niemand zeigen kann, warum Controls ausgewählt wurden, wie sie mit Risiken zusammenhängen, wer das Restrisiko akzeptiert hat und welche Nachweise die Wirksamkeit belegen.

ISO/IEC 27001:2022 gibt Anbietern die Struktur, um dieses Scheitern zu vermeiden.

Clauses 4.1 bis 4.4 verlangen von der Organisation, interne und externe Themen zu bestimmen, interessierte Parteien und deren Anforderungen zu identifizieren, zu entscheiden, welche Anforderungen über das ISMS adressiert werden, und den ISMS-Geltungsbereich einschließlich Schnittstellen und Abhängigkeiten festzulegen. Für einen Cloud- oder MSP-Anbieter sollte der Geltungsbereich NIS2, die Durchführungsverordnung 2024/2690, kundenseitige Sicherheitsanhänge, DORA-getriebene Kundenanforderungen, Cloud-Regionen, Unterauftragnehmer, Rechenzentrumsabhängigkeiten, Fernadministrationsplattformen, privilegierte Zugriffspfade und Vorfallmeldepflichten ausdrücklich berücksichtigen.

Clauses 5.1 bis 5.3 verlangen Führung, Ausrichtung der Richtlinien, Ressourcen, Kommunikation, zugewiesene Verantwortlichkeiten und Rechenschaftspflicht des Managements. Dies unterstützt NIS2 Article 20 unmittelbar.

Clauses 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Risikoverantwortliche, Analyse von Eintrittswahrscheinlichkeit und Auswirkungen, Control-Auswahl, Abgleich mit Annex A, eine Erklärung zur Anwendbarkeit, einen Risikobehandlungsplan und die formale Akzeptanz des Restrisikos. An dieser Stelle wird NIS2 operativ. Jede regulatorische Anforderung wird zu einem Risikotreiber, einer Compliance-Verpflichtung, einer Control-Anforderung oder einer Nachweisanforderung.

Clarysec beginnt diese Arbeit mit Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, insbesondere in der Phase Risikomanagement.

Ab Step 13, Risk Treatment Planning and Statement of Applicability, weist der Zenith Blueprint Teams an, Nachvollziehbarkeit zwischen Risiken, Controls und regulatorischen Treibern aufzubauen:

„Regelungen querverweisen: Wenn bestimmte Controls speziell umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister oder in den SoA-Notizen vermerken. Beispiel: Control 8.27 (sichere Löschung von Daten) kann für die GDPR-Anforderung zur Entsorgung personenbezogener Daten sehr relevant sein; Sie könnten vermerken: ‚Anwendbar – unterstützt GDPR Art.32 (Sicherheit der Verarbeitung)‘. Dies ist nach ISO nicht erforderlich, hilft aber nachzuweisen, dass Sie diese Rahmenwerke berücksichtigt haben.“

Step 14, Risk Treatment Policies and Regulatory Cross-References, ergänzt die praktische Disziplin der Zuordnung:

„Für jede Regulierung können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen, die die wichtigsten Sicherheitsanforderungen der Regulierung und die entsprechenden Controls/Richtlinien in Ihrem ISMS aufführt. Dies ist in ISO 27001 nicht verpflichtend, aber eine nützliche interne Übung, um sicherzustellen, dass nichts übersehen wurde.“

Das ist der Unterschied zwischen „wir sind ISO-zertifiziert“ und dem Nachweis, dass „unser ISO/IEC 27001:2022-ISMS die NIS2-Durchführungsverordnung 2024/2690 adressiert“.

Einheitliche Control-Zuordnung von NIS2 zu ISO/IEC 27001:2022

Die folgende Zuordnung ist keine Rechtsberatung und kein Ersatz für die Analyse der nationalen Umsetzung. Sie ist eine praktische Control-Architektur für Anbieter, die einen auditierbaren Weg über ISO/IEC 27001:2022 zur NIS2-Vorbereitung benötigen.

Diese Zuordnung wird wirksam, wenn sie in das Risikoregister und die Erklärung zur Anwendbarkeit eingebettet wird. Ein Anbieter kann beispielsweise ein Risikoszenario mit der Bezeichnung „Kompromittierung der Fernadministrationsplattform führt zu unautorisierten Aktionen in Kundenumgebungen“ erstellen. Controls umfassen MFA, Privileged Access Management (PAM), Segmentierung, Protokollierung, Schwachstellenmanagement, Lieferantensicherheit, Vorfallsplanung und Verfahren zur Kundenbenachrichtigung. Die SoA-Notizen können, soweit relevant, auf NIS2 Article 21, Article 23, die Durchführungsverordnung 2024/2690, Kundenverträge und DORA-Anforderungen an die Kunden-Due-Diligence verweisen.

Cloud-Governance: ISO control 5.23 ist ein NIS2-Anker

Für Cloud-Anbieter und MSPs, die Cloud-Services zur Erbringung von Kundenservices nutzen, ist ISO/IEC 27001:2022 Annex A control 5.23, Informationssicherheit für die Nutzung von Cloud-Services, einer der wichtigsten Anker.

Zenith Controls: The Cross-Compliance Guide Zenith Controls fasst Control 5.23 als präventives Control zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit zusammen, verbunden mit Sicherheit in Lieferantenbeziehungen, Governance, Ökosystemrisiko und Schutz. Es umfasst Cloud-Service-Governance, gemeinsame Verantwortung, Anbieterbewertung, Inventare, Datenstandort, Protokollierung, Verschlüsselung, Identitätsrollen, Überwachung, Vertragsklauseln, Lieferantenrisiko, Cloud-Exit und Resilienzplanung.

Der Zenith Blueprint, Phase Controls in Action, Step 23, erläutert den praktischen Grund:

„Die Cloud ist kein Ziel mehr, sie ist der Standard. Control 5.23 erkennt diese Realität an und verlangt, dass Informationssicherheit bei der Auswahl, Nutzung und Verwaltung von Cloud-Services ausdrücklich berücksichtigt wird – nicht nachträglich, sondern von Anfang an als Gestaltungsprinzip.“

Für einen MSP müssen jede Remote-Monitoring-and-Management-Plattform, jedes Kundenportal, Ticketsystem, jede Plattform für Sicherheitstelemetrie, jeder Backup-Service, jedes Cloud-Verzeichnis und jede administrative SaaS-Konsole gesteuert werden. Für einen Rechenzentrumsanbieter kann Cloud-Governance Überwachungsplattformen, Besuchermanagementsysteme, Integrationen der physischen Zugriffskontrolle, Fernverwaltungssysteme und die Infrastruktur des Kundenportals betreffen.

Clarysecs Enterprise-Cloud Usage Policy Cloud Usage Policy macht die Due-Diligence vor Aktivierung verpflichtend:

„Jede Cloud-Nutzung muss vor der Aktivierung einer risikobasierten Due-Diligence unterzogen werden, einschließlich Anbieterbewertung, Validierung der Einhaltung rechtlicher Anforderungen und Überprüfungen der Control-Validierung.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.

Für kleinere Anbieter schafft die Cloud Usage Policy-sme Cloud Usage Policy-sme - SME ein schlankes Genehmigungsmodell:

„Jede Nutzung von Cloud-Services muss vor der Umsetzung oder dem Abonnement durch den General Manager (GM) überprüft und genehmigt werden.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.

Beide Ansätze unterstützen dieselbe NIS2-Erwartung: Das Risiko aus Cloud-Abhängigkeiten muss verstanden sein, bevor der Service Teil der Leistungserbringung wird.

Incident Response: Die 24-Stunden-Uhr läuft, bevor der Bericht verfasst ist

NIS2 Article 23 ist unerbittlich, weil die Meldefrist mit der Kenntnis eines erheblichen Vorfalls beginnt und nicht erst, wenn eine vollständige Ursachenanalyse vorliegt. Die Herausforderung für Anbieter besteht darin, schnell zu bestimmen, ob ein Ereignis erheblich ist, welche Kunden betroffen sind, ob personenbezogene Daten beteiligt sind, ob grenzüberschreitende Serviceauswirkungen bestehen und welche vertraglichen Fristen ausgelöst wurden.

ISO/IEC 27001:2022 Annex A control 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, ist das Planungs-Control. Zenith Controls fasst es als korrektives Control zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit zusammen, verbunden mit Respond- und Recover-Konzepten, Governance, Ereignismanagement und Verteidigung. Es umfasst Rollen, Verantwortlichkeiten, Eskalationswege, Kommunikationsprotokolle, Bereitschaft zu regulatorischen Meldungen, Ausrichtung an Protokollierung und Überwachung, Integration mit Aufrechterhaltung des Geschäftsbetriebs und Disaster Recovery, Lernen nach Vorfällen sowie Zuordnung zu NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 und COBIT 2019.

Clarysecs Incident Response Policy-sme Incident Response Policy-sme - SME macht die erste Entscheidung zu einer zeitgebundenen Anforderung:

„Der General Manager muss unter Einbindung des IT-Dienstleisters alle Vorfälle innerhalb einer Stunde nach Benachrichtigung nach Schweregrad klassifizieren.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.

Diese Klassifizierung innerhalb einer Stunde unterstützt die operative Disziplin, die für die NIS2-Analyse zur 24-Stunden-Frühwarnung, die Bewertung einer GDPR-Datenpanne, die DORA-Kundeneskalation und die Triage vertraglicher Meldepflichten erforderlich ist.

Der Entscheidungsbaum eines Anbieters für Vorfälle sollte vier Fragen beantworten:

1. Liegt eine bestätigte oder vermutete Kompromittierung von Vertraulichkeit, Integrität oder Verfügbarkeit vor?
2. Betrifft das Ereignis die Leistungserbringung, Kundenumgebungen, regulierte Kunden, personenbezogene Daten oder kritische Funktionen?
3. Könnte es zu schwerwiegenden Betriebsstörungen, finanziellen Verlusten oder materiellen oder immateriellen Schäden führen?
4. Welche Meldepflichten gelten: NIS2, GDPR, DORA-Kundenverpflichtungen, vertragliche SLAs oder Erwartungen nationaler Aufsichtsbehörden?

Der Entscheidungsbaum sollte in Tabletop-Übungen getestet werden, bevor ein echter Vorfall eintritt.

Schwachstellenmanagement: Risikoreduzierung vor Eintritt der Auswirkungen nachweisen

NIS2 verlangt Schwachstellenbehandlung und Offenlegung. Für Kunden und Aufsichtsbehörden ist Schwachstellenmanagement einer der am einfachsten messbaren Control-Bereiche, weil er klare Nachweise erzeugt: Scan-Abdeckung, Patch-Fristen, Ausnahmegenehmigungen, Analyse ausgenutzter Schwachstellen und Aufzeichnungen zu Abhilfemaßnahmen.

ISO/IEC 27001:2022 Annex A control 8.8, Management technischer Schwachstellen, wird in Zenith Controls als präventives Control über Vertraulichkeit, Integrität und Verfügbarkeit hinweg zusammengefasst, verbunden mit Identify und Protect, Bedrohungs- und Schwachstellenmanagement, Governance, Ökosystem, Schutz und Verteidigung. Es umfasst Identifizierung von Schwachstellen, Bewertung, Priorisierung, Patching, kompensierende Controls, Integration von Bedrohungsinformationen, Offenlegung von Schwachstellen, Verantwortlichkeiten für Cloud- und Anwendungsschwachstellen, Auditnachweise und Fristen für Abhilfemaßnahmen.

Clarysecs Enterprise-Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy gibt Auditoren ein konkretes Prüfmodell:

„Die Organisation muss alle erkannten Schwachstellen anhand einer standardisierten Methodik (z. B. CVSS v3.x) klassifizieren und Fristen für Abhilfemaßnahmen anwenden, die an der Geschäftskritikalität ausgerichtet sind: 5.2.1 Kritisch (CVSS 9.0-10.0): Sofortige Überprüfung; Frist für das Einspielen von Patches maximal 72 Stunden. 5.2.2 Hoch (7.0-8.9): Reaktion innerhalb von 48 Stunden; Frist für das Einspielen von Patches 7 Kalendertage. 5.2.3 Mittel (4.0-6.9): Reaktion innerhalb von 5 Tagen; Frist für das Einspielen von Patches 30 Kalendertage. 5.2.4 Niedrig (<4.0): Reaktion innerhalb von 10 Tagen; Frist für das Einspielen von Patches 60 Kalendertage.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.

Für einen Cloud-Anbieter muss dies Hypervisor-Komponenten, Container-Images, Orchestrierungsschichten, kundenbezogene Programmierschnittstellen, CI/CD-Pipelines, administrative Konsolen und Drittanbieter-Bibliotheken umfassen. Für einen MSP lautet die zentrale Frage, ob interne Schwachstellen von kundenseitig verwalteten Schwachstellen getrennt sind und ob Verträge die Verantwortlichkeit definieren. Für einen Rechenzentrumsanbieter kann der Geltungsbereich Gebäudeleittechnik, Zugriffskontrollsysteme, Überwachungsplattformen, Remote-Hands-Werkzeuge und Netzwerkinfrastruktur umfassen.

Das Modell der gemeinsamen Verantwortung muss dokumentiert sein. Ein Anbieter ist möglicherweise nicht für jeden Patch verantwortlich, muss das Risiko aber dennoch steuern, den Kunden gegebenenfalls benachrichtigen und nachweisen, dass Verantwortungsgrenzen verstanden sind.

Protokollierung, Überwachung und Segmentierung machen Vorfälle untersuchbar

Wenn ein Vorfall bei einem Anbieter Auswirkungen auf Kunden hat, lauten die ersten Nachweisfragen schlicht: Wer hat sich angemeldet, von wo, mit welcher Berechtigung, bei welchem Tenant, was wurde geändert, welche Protokolle existieren und ob administrative Pfade segmentiert waren.

Clarysecs Enterprise-Logging and Monitoring Policy Logging and Monitoring Policy verlangt von erfassten Systemen, die Protokolle zu erzeugen, die Incident Handler und Auditoren benötigen:

„Alle erfassten Systeme müssen Protokolle erzeugen, die Folgendes erfassen: 6.1.1.1 Nutzerauthentifizierung und Zugriffsversuche 6.1.1.2 Aktivitäten privilegierter Benutzer 6.1.1.3 Konfigurationsänderungen 6.1.1.4 Fehlgeschlagene Zugriffsversuche oder Systemereignisse 6.1.1.5 Erkennungen von Schadsoftware und Sicherheitswarnmeldungen 6.1.1.6 Externe Kommunikation und Auslöser von Firewall-Regeln“

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

Für KMU, die sich auf externe Anbieter stützen, ergänzt die Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME eine vertragliche Anforderung:

„Verträge müssen Anbieter verpflichten, Protokolle für mindestens 12 Monate aufzubewahren und auf Anfrage Zugriff zu gewähren.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.5.1.3.

Segmentierung ist ebenso wichtig. Die Network Security Policy-sme Network Security Policy-sme - SME legt fest:

„Interne Netzwerke müssen nach Funktion segmentiert werden (z. B. Finanzen, Gast, IoT, administrative Systeme).“

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

Der Zenith Blueprint, Phase Controls in Action, Step 20, beschreibt das praktische Auditverfahren für Netzwerkarchitektur und Segmentierung. Er weist Teams an, die Netzwerktopologie zu überprüfen und zu dokumentieren, Firewall-Regeln, IPS/IDS- und Fernzugriffskonfigurationen zu verifizieren, zu bestätigen, dass Cloud-Sicherheitsgruppen und VPC- oder Subnetzregeln der vorgesehenen Architektur entsprechen, interne und externe Netzwerkdienste aufzulisten und zu validieren, dass sensitive Systeme nicht aus allgemeinen Benutzer-VLANs oder Gastnetzwerken erreichbar sind.

Für einen MSP dürfen Fernverwaltungswerkzeuge nicht flach im Büronetzwerk liegen. Für einen Rechenzentrumsanbieter sollten Verwaltungsschnittstellen für Strom, Kühlung, Zugriffskontrolle und Kundennetzwerkservices isoliert und überwacht werden. Für einen Cloud-Anbieter sollte der Zugriff auf die Control Plane durch Identität, Netzwerk, Gerätezustand und privilegierte Workflows beschränkt werden.

Lieferantensicherheit: Der Anbieter ist ebenfalls Kunde

Cloud-, MSP-, MSSP- und Rechenzentrumsanbieter sind Lieferanten regulierter Kunden, aber sie sind auch Kunden von Softwareherstellern, Telekommunikationsanbietern, Identitätsanbietern, SaaS-Plattformen, Hardwarelieferanten, Unterauftragnehmern und Infrastrukturbetreibern.

NIS2 macht die Sicherheit der Lieferkette zu einer Kernanforderung. DORA, das ab dem 17. Januar 2025 gilt, macht das Management von IKT-Drittparteienrisiken für Finanzunternehmen zentral. NIS2 Article 4 und Recital 28 erkennen DORA als sektorspezifischen Rechtsakt der Union für Finanzunternehmen an, soweit Anforderungen sich überschneiden. Dies nimmt den Druck von Cloud- und MSP-Anbietern nicht. Es erhöht ihn, weil Finanzkunden vertragliche Anforderungen auf DORA-Niveau, Auditrechte, Resilienztests, Exit-Strategien und Erwartungen an die Vorfallmeldung in Lieferantenverträge aufnehmen.

Clarysecs Enterprise-Third party and supplier security policy Third party and supplier security policy verlangt kontrollierten Zugang Dritter:

„Jeder Zugang Dritter muss protokolliert und überwacht und, soweit praktikabel, über Bastion Hosts, VPNs oder Zero-Trust-Gateways segmentiert werden.“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.2.

Die Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME formuliert das Prinzip der minimalen Berechtigung in klaren Worten:

„Lieferanten dürfen nur Zugriff auf die Mindestsysteme und -daten erhalten, die zur Erfüllung ihrer Funktion erforderlich sind.“

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

Diese Klauseln lassen sich unmittelbar den ISO/IEC 27001:2022 Annex A controls 5.19, 5.20, 5.21 und 5.22 zuordnen. Sie unterstützen außerdem die Governance für Auftragsverarbeiter und Unterauftragsverarbeiter nach GDPR, DORA-Überprüfungen von Drittparteienrisiken und Auditfragebögen von Kunden.

Aufrechterhaltung des Geschäftsbetriebs und Resilienz von Rechenzentren: Annahmen nachweisen

NIS2 Article 21 umfasst Aufrechterhaltung des Geschäftsbetriebs, Backup-Management, Disaster Recovery und Krisenmanagement. DORA Articles 11 bis 14 verlangen für Finanzunternehmen Richtlinien zur Aufrechterhaltung des IKT-Geschäftsbetriebs, Reaktions- und Wiederherstellungspläne, Business Impact Analysis, Backup-Richtlinien, Wiederherstellungsverfahren, Wiederherstellungsziele, Tests, Nachprüfungen nach Vorfällen und Krisenkommunikation.

Für Cloud- und Rechenzentrumsanbieter ist Kontinuität kein Ordner. Sie besteht aus Architektur, Kapazität, Verträgen, Abhängigkeiten, Wiederherstellungsnachweisen und getesteten Annahmen.

Clarysecs Enterprise-Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy verlangt eine jährliche BIA und eine Überprüfung nach wesentlichen Änderungen:

„Eine Business Impact Analysis (BIA) ist mindestens jährlich für alle kritischen Geschäftsbereiche durchzuführen und bei wesentlichen Änderungen an Systemen, Prozessen oder Abhängigkeiten zu überprüfen. Die BIA-Ergebnisse müssen Folgendes definieren: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Wiederherstellungszeitziele (RTOs) 5.2.3. Wiederherstellungspunktziele (RPOs) 5.2.4. Kritische Abhängigkeiten (Systeme, Lieferanten, Personal)“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.

In einem Rechenzentrumsszenario sollte die BIA Stromzuführungen, USV, Generatoren, Brennstoffverträge, Kühlung, Brandunterdrückung, Netzbetreiber, physische Zutrittssysteme, Remote Hands, Überwachung, Ersatzhardware und Kundenkommunikationskanäle abdecken. In einem Cloud-Szenario sollte sie Regionen, Verfügbarkeitszonen, Replikation, Unveränderbarkeit von Backups, Identitätsabhängigkeiten, DNS, Zertifizierungsstellen, API-Gateways und Supportsysteme abdecken. In einem MSP-Szenario sollte sie Fernverwaltungswerkzeuge, Tresore für privilegierte Zugriffe, EDR-Konsolen, Ticketsysteme, Dokumentationsrepositories und Notfallkommunikation abdecken.

ISO 22301 kann die Disziplin des Business-Continuity-Managements stärken, während ISO/IEC 27005:2022 Risikokriterien, Behandlungsplanung, Überwachung, Nachweise und kontinuierliche Verbesserung unterstützt. Dies ist nützlich, weil NIS2-Vorbereitung verlangt, dass die Organisation rechtliche, vertragliche, operative, lieferantenbezogene, technologische, finanzielle, prozessuale und menschliche Faktoren in einem Risikoprozess konsolidiert.

Praktische Risikospur für einen MSP-Fernzugriffsverstoß

Ein praktischer Workshop kann mit einem Szenario beginnen:

„Die Kompromittierung eines privilegierten Fernzugriffs führt zu unautorisiertem Zugriff auf Kundensysteme, Serviceunterbrechung, möglicher Exposition personenbezogener Daten und regulatorischen Meldepflichten.“

Erstellen Sie eine Zeile im Risikoregister und vervollständigen Sie die Spur.

Aktualisieren Sie anschließend die Erklärung zur Anwendbarkeit. Erläutern Sie für jedes relevante Annex A control, warum es anwendbar ist und welches NIS2-Thema es unterstützt. Sammeln Sie schließlich vor einem Audit Nachweise: Berichte zur Durchsetzung von MFA, Listen privilegierter Konten, Einstellungen zur Protokollaufbewahrung, RMM-Patch-Status, SIEM-Warnmeldungen, Aufzeichnungen zur Vorfallklassifizierung, Genehmigungen für Lieferantenzugriffe und Tabletop-Ergebnisse.

Wie unterschiedliche Auditoren dasselbe Control-Umfeld prüfen

Ein integriertes ISMS muss unterschiedliche Assurance-Perspektiven erfüllen, ohne für jedes Rahmenwerk separate Nachweispakete zu erzeugen.

Hier hilft Zenith Controls als Cross-Compliance-Leitfaden. Für Controls wie 5.23, 5.24 und 8.8 verknüpft es die Control-Erwartungen aus ISO/IEC 27001:2022 mit Themen aus NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF und ISO 22301. Ziel ist nicht, getrennte Compliance-Programme zu schaffen. Ziel ist eine einzige Nachweisarchitektur, die nach Control, Risiko, regulatorischem Treiber und Verantwortlichem gekennzeichnet ist.

Das Clarysec-Umsetzungsmuster

Für Cloud-, MSP-, MSSP- und Rechenzentrumsanbieter sollte die Arbeit in fünf Ebenen erfolgen.

Erstens: Geltungsbereich bestätigen. Bestimmen Sie, ob die Organisation und ihre Services unter NIS2 fallen, welche mitgliedstaatlichen Vorschriften gelten, ob die Durchführungsverordnung 2024/2690 für die Anbieterkategorie gilt und ob Kunden DORA-, GDPR-, NIST- oder branchenspezifische Verpflichtungen auferlegen.

Zweitens: ISMS-Kontext aufbauen. Identifizieren Sie nach ISO/IEC 27001:2022 clauses 4 und 5 interessierte Parteien, rechtliche Verpflichtungen, Kundenverpflichtungen, Lieferantenabhängigkeiten, Servicegrenzen und Managementverantwortlichkeiten.

Drittens: Risikobeurteilung und -behandlung nach den Grundsätzen von ISO/IEC 27005:2022 durchführen. Konsolidieren Sie NIS2, DORA, GDPR, Verträge, interne Richtlinien und Servicerisiken in einem Basisregister der Anforderungen. Definieren Sie Risikokriterien, Verantwortliche, Eintrittswahrscheinlichkeit, Auswirkungen, Behandlungsoptionen, Control-Entscheidungen und Genehmigungen zur Restrisikoakzeptanz.

Viertens: Controls in die Erklärung zur Anwendbarkeit einordnen. Nutzen Sie Zenith Blueprint Steps 13 und 14, um Risiken auf Annex A controls und regulatorische Erwartungen zurückzuverfolgen. Nutzen Sie Zenith Controls, um zu verstehen, wie Controls wie 5.23, 5.24, 8.8, 5.20 und 5.30 über Rahmenwerke und Auditperspektiven hinweg zugeordnet werden.

Fünftens: Nachweise operationalisieren. Richtlinien allein reichen nicht aus. Die Richtlinienbibliothek von Clarysec stellt durchsetzbare Anforderungen an Cloud-Genehmigung, Lieferantenzugriff, Protokollierung, Schwachstellenbehebung, Netzwerksegmentierung, Vorfallklassifizierung und Kontinuitätsplanung bereit. Das Nachweispaket belegt, dass diese Anforderungen wirksam umgesetzt sind.

Nächster Schritt: NIS2-Druck in auditfähige Resilienz übersetzen

Die NIS2-Durchführungsverordnung 2024/2690 verlangt kein Chaos. Sie verlangt Nachvollziehbarkeit, Verantwortlichkeit und Nachweise.

Wenn Sie Cloud-Service-Anbieter, MSP, MSSP oder Rechenzentrumsbetreiber sind, beginnen Sie mit Ihren Services, Kunden, Abhängigkeiten, Vorfallszenarien und Nachweispflichten. Führen Sie anschließend eine strukturierte Zuordnung von NIS2 zu ISO/IEC 27001:2022 durch:

1. Bestätigen Sie, ob Ihre Einrichtung und Services im Geltungsbereich liegen.
2. Ordnen Sie NIS2- und Durchführungsverordnungsthemen Ihrem ISMS-Geltungsbereich zu.
3. Aktualisieren Sie das Risikoregister und die Erklärung zur Anwendbarkeit.
4. Wenden Sie Clarysec-Richtlinien für Cloud-Nutzung, Lieferantensicherheit, Protokollierung, Schwachstellenmanagement, Incident Response, Netzwerksicherheit und Kontinuität an.
5. Nutzen Sie Zenith Blueprint Zenith Blueprint Steps 13, 14, 20 und 23, um Nachvollziehbarkeit und operative Nachweise zu schaffen.
6. Nutzen Sie Zenith Controls Zenith Controls, um ISO/IEC 27001:2022 controls gegen Erwartungen aus NIS2, DORA, GDPR, NIST und COBIT 2019 querzuzuordnen.
7. Testen Sie die Nachweise in einer Auditsimulation, bevor ein Kunde, eine Aufsichtsbehörde oder ein Zertifizierungsauditor sie anfordert.

Clarysec kann Ihnen helfen, über Checklisten-Compliance hinauszugehen und ein integriertes ISMS aufzubauen, das dem Druck aus NIS2, DORA, GDPR und Kundenaudits standhält. Laden Sie die relevanten Clarysec-Toolkits herunter, buchen Sie einen Zuordnungsworkshop oder fordern Sie eine Bewertung der Auditbereitschaft an, um regulatorische Komplexität in belastbare Sicherheitsgovernance und operative Resilienz zu überführen.