Thema
NIS2

NIS2 und ISO 27001: Welche Anforderungen ein ISMS bereits abdeckt

Praxisorientierte Einordnung zu NIS2 und ISO 27001: Welche Anforderungen ein ISMS bereits abdeckt: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für NIS2 aufbauen.
NIS2 und ISO 27001: Welche Anforderungen ein ISMS bereits abdeckt – Fachbeitrag von BlackMount

Ein vorhandenes Informationssicherheitsmanagementsystem nach ISO/IEC 27001 ist eine sehr gute Grundlage für NIS2. Es liefert Risikomanagement, dokumentierte Kontrollen, interne Audits, Managementreview und kontinuierliche Verbesserung. Trotzdem beweist ein Zertifikat nicht automatisch, dass sämtliche Pflichten des deutschen BSI-Gesetzes erfüllt sind. Entscheidend sind Scope, konkrete Umsetzung und belastbare Nachweise.

Ein sinnvolles Mapping vermeidet zwei Extreme: den unnötigen Neubau eines parallelen NIS2-Programms und die pauschale Behauptung, ISO 27001 decke bereits alles ab. Es vergleicht jede gesetzliche Anforderung mit tatsächlichem Prozess, Kontrolle, Verantwortlichem und Evidenz. Lücken werden dort ergänzt, wo Betroffenheit, Meldung, Geschäftsleitung oder dienstbezogene Anforderungen über das bestehende ISMS hinausgehen.

ISO 27001 und NIS2 verfolgen verwandte, aber unterschiedliche Ziele

ISO 27001 definiert Anforderungen an ein Managementsystem, das Informationssicherheitsrisiken an den Kontext der Organisation anpasst. Es schützt Vertraulichkeit, Integrität und Verfügbarkeit und kann freiwillig zertifiziert werden. Der gewählte Scope darf einen Teil der Organisation umfassen.

NIS2 ist ein verbindlicher Rechtsrahmen. Das deutsche BSIG legt fest, welche Einrichtungen betroffen sind, welche Risikomanagement- und Meldepflichten gelten und wie Geschäftsleitung sowie Aufsicht eingebunden werden. Der gesetzliche Scope folgt der betroffenen Einrichtung und ihren Diensten, nicht dem frei gewählten Zertifizierungsscope.

Der Zertifizierungsscope ist der erste Prüfpunkt

Ein Zertifikat nennt Organisation, Standorte, Prozesse und gegebenenfalls Ausschlüsse. Wenn nur ein Rechenzentrum oder eine Produktlinie zertifiziert ist, kann eine NIS2-betroffene Tochter oder ein wesentlicher Dienst außerhalb liegen. Dann sind selbst gute ISMS-Prozesse kein vollständiger Nachweis für die Einrichtung.

Eine Scope-Matrix verbindet Rechtseinheit, Einrichtungsart, Dienst, Standort, Systeme und Zertifizierungsabdeckung. Für Lücken wird entschieden, ob der ISMS-Scope erweitert oder eine gleichwertige Governance außerhalb eingerichtet wird. Aussagen gegenüber Geschäftsleitung und Aufsicht nennen diese Grenzen transparent.

Kontextanalyse für gesetzliche Betroffenheit erweitern

ISO 27001 verlangt die Bestimmung von Kontext und interessierten Parteien. Dieser Prozess kann die NIS2-Betroffenheitsprüfung aufnehmen, ersetzt sie aber nicht automatisch. § 28 BSIG erfordert eine konkrete Analyse von Einrichtungsart, Anlage, Größe, Sonderkategorie und möglichen Ausnahmen.

Das Ergebnis wird als eigenes Rechtsdossier geführt und mit dem ISMS-Kontext verlinkt. Änderungen an Gesellschaft, Tätigkeit, Konzernstruktur oder Größe werden zu Reviewtriggern. So bleibt das Managementsystem mit der regulatorischen Einordnung synchron.

Führung und Verantwortung aus dem ISMS nutzen

Die ISO-Norm verlangt Führung, Politik, Rollen und Ressourcen. Managementreviews und interne Berichte schaffen bereits einen Kanal zur Leitung. Diese Struktur unterstützt § 38 BSIG, wenn die betroffene Geschäftsleitung tatsächlich Umsetzung und Überwachung der §-30-Maßnahmen übernimmt.

Ergänzt werden ausdrückliche Beschlüsse, Leitungsschulungen und ein NIS2-orientiertes Cockpit. Ein Managementreview der Konzernmutter reicht nicht automatisch für jede betroffene Tochter. Die jeweilige Geschäftsleitung benötigt nachvollziehbare Informationen und eigene Entscheidungen über wesentliche Restrisiken.

Risikomanagement grundsätzlich gut abgedeckt

ISO 27001 liefert einen wiederholbaren Prozess für Identifikation, Analyse, Bewertung und Behandlung von Informationssicherheitsrisiken. Risikokriterien, Eigentümer, Behandlungsplan und akzeptiertes Restrisiko sind zentrale Bausteine. Diese Struktur passt gut zur allgefahrenbasierten Risikosteuerung nach NIS2.

Für NIS2 wird die Sicht konsequent auf erbrachte Dienste und gesellschaftliche sowie wirtschaftliche Auswirkungen erweitert. Szenarien verknüpfen Systeme, Lieferanten und Prozesse mit Dienstunterbrechung. Risikobereitschaft und Verhältnismäßigkeit werden durch die Geschäftsleitung dokumentiert.

Statement of Applicability als Ausgangspunkt, nicht als Endnachweis

Die Anwendbarkeitserklärung dokumentiert ausgewählte Kontrollen und Begründungen. Sie ist eine wertvolle Brücke zu den Maßnahmenbereichen des § 30. Ein bloßes Kreuz neben einem Annex-A-Control beweist jedoch weder konkrete Umsetzung noch Wirksamkeit im NIS2-Scope.

Das NIS2-Mapping ergänzt Kontrolle, Systembezug, Eigentümer, Frequenz und Evidenz. Teilabdeckungen werden gekennzeichnet. Beispielsweise kann Lieferantensteuerung grundsätzlich vorhanden sein, ohne Konzentrationsrisiken oder Vorfallfristen kritischer Dienstleister ausreichend zu behandeln.

Richtlinien zur Risikoanalyse und Systemsicherheit

ISMS-Organisationen besitzen häufig Sicherheitsleitlinie, Risikomethode und themenspezifische Vorgaben. Damit ist der erste NIS2-Maßnahmenbereich strukturell gut vorbereitet. Wichtig ist, dass die Richtlinien die betroffene Einrichtung, ihre Dienste und aktuelle Technik tatsächlich erfassen.

Eine Richtlinie wird durch Prozesse und Nachweise wirksam. Stichproben verfolgen Risikoszenarien bis zur Kontrolle, Konfiguration und Entscheidung. Veraltete Vorgaben oder nicht gelebte Verfahren werden als Lücke behandelt, auch wenn sie im Zertifizierungsaudit bisher nicht auffielen.

Vorfallbehandlung mit gesetzlicher Meldung ergänzen

ISO 27001 unterstützt Erkennung, Bewertung, Reaktion, Lernen und Beweissicherung. Viele ISMS besitzen Incident-Kategorien, Rollen und Runbooks. NIS2 ergänzt die gestufte Meldung erheblicher Sicherheitsvorfälle, gesetzliche Fristen, BSI-Portal und mögliche Unterrichtung von Empfängern.

Das Mapping prüft Erheblichkeitsentscheidung, Zeitpunkt der Kenntnis, 24/7-Erreichbarkeit, Portalzugang, Freigabe und Aktualisierung. Eine technische Incident-Priorität ist nicht automatisch die rechtliche Erheblichkeit. Tabletop-Übungen testen beide Perspektiven gemeinsam.

Business Continuity aus der Dienstsicht schärfen

Annex A enthält Kontrollen zur Informationssicherheit bei Störungen und zur IKT-Bereitschaft für Geschäftskontinuität. Vorhandene BIA, Notfallpläne und Wiederherstellungstests sind direkt nutzbar. Sie müssen jedoch die NIS2-auslösenden Dienste und ihre vollständigen Abhängigkeiten abdecken.

Wiederherstellungszeit, Datenverlusttoleranz und Mindestbetrieb werden vom Fachbereich bestätigt. Tests messen reale Ergebnisse statt nur Dokumentenaktualität. Identitäten, Netze, Personal und externe Plattformen werden einbezogen. Abweichungen fließen als Risiko in das Managementreview.

Krisenmanagement über technische Notfälle hinaus

Ein ISMS kann Incident Response gut abdecken, ohne ein vollständiges Unternehmenskrisenmodell zu besitzen. NIS2 verlangt im Rahmen der Kontinuität auch Krisenmanagement. Entscheidungen über Betrieb, Kunden, Behörden, Öffentlichkeit und Ressourcen benötigen ein übergreifendes Führungssystem.

Krisenstab, Eskalationskriterien, sichere Kommunikation, Vertretung und Lagebild werden mit dem technischen Incident-Prozess verbunden. Übungen kombinieren Cyberangriff und Geschäftsauswirkung. Die Geschäftsleitung trainiert ihre Rolle und dokumentiert Verbesserungen.

Lieferkettensicherheit aus dem ISMS vertiefen

ISO 27001 enthält Kontrollen für Lieferantenbeziehungen, Cloudnutzung und die IKT-Lieferkette. Bestehende Due-Diligence-Fragebögen, Verträge und Reviews sind wertvoll. NIS2 verlangt eine risikobasierte Betrachtung der Lieferkette und der Beziehungen zu unmittelbaren Anbietern.

Das Mapping ergänzt Dienstkritikalität, Konzentration, Unterauftragnehmer, Vorfallunterstützung, Wiederherstellung und Exit. Sicherheitszusagen werden technisch verifiziert. Ein Zertifikat des Lieferanten ist ein Evidenzbaustein, ersetzt aber keine Bewertung der konkret bezogenen Leistung.

Sichere Beschaffung und Entwicklung weitgehend anschlussfähig

Annex A adressiert sicheren Entwicklungslebenszyklus, Sicherheitsanforderungen an Anwendungen, Architektur, Coding, Tests, Outsourcing und Change Management. Reife ISMS-Organisationen können diese Kontrollen direkt auf NIS2 abbilden. Entscheidend ist die praktische Verankerung in Einkauf und Engineering.

Anforderungen müssen vor Auswahl und Design feststehen. Änderungen erhalten Test, Freigabe und Rückfallplan. Schwachstellenmeldungen und Wartungsstatus fließen in den Lebenszyklus. Stichproben aus kritischen Diensten prüfen, ob Prozessvorgaben tatsächlich angewendet wurden.

Schwachstellenbehandlung konkretisieren

ISO 27001 fordert Management technischer Schwachstellen. Ein funktionierender Prozess erfasst Assets, Hinweise, Bewertung, Behebung und Ausnahmen. NIS2 verlangt außerdem sichere Handhabung und Offenlegung von Schwachstellen im Maßnahmenkatalog.

Priorität berücksichtigt Ausnutzbarkeit, Exposition, Dienstbezug und Geschäftsauswirkung statt nur CVSS. Ausnahmen besitzen kompensierende Kontrollen und Ablaufdatum. Eigene Produkte benötigen einen Meldekanal sowie abgestimmte Behandlung externer Sicherheitsforscher.

Wirksamkeitsbewertung ist Kern beider Rahmenwerke

ISO 27001 verlangt Überwachung, Messung, Analyse, interne Audits und Managementreview. § 30 BSIG fordert Maßnahmen zur Bewertung der Wirksamkeit. Ein reifes ISMS besitzt damit die richtige Governance. Die Qualität hängt jedoch von den konkreten Tests ab.

Kontrolltests definieren Ziel, Methode, Stichprobe, Ergebnis und Nachverfolgung. Restore, Alarm, Rezertifizierung, Segmentierung und Lieferantennotfall werden praktisch geprüft. Eine grüne Dokumentenprüfung ohne technische Evidenz genügt nicht. Wiederkehrende Fehler lösen Ursachenanalyse aus.

Cyberhygiene und Schulungen zusammenführen

Annex A enthält Awareness und Informationssicherheitsschulung. NIS2 nennt grundlegende Verfahren der Cyberhygiene und Schulungen ausdrücklich. Bestehende Programme können genutzt werden, wenn sie rollen- und risikobezogen sind und ihre Wirkung überprüft wird.

Administratoren, Entwickler, Einkauf und normale Nutzer benötigen unterschiedliche Inhalte. Phishing-Simulationen, Fallübungen und Stichproben ergänzen Teilnahmequoten. Die spezielle regelmäßige Schulung der Geschäftsleitung nach § 38 wird als eigener Nachweis geführt.

Kryptografie aus bestehenden Kontrollen übernehmen

ISO 27001 adressiert Kryptografie und Schlüsselmanagement. Richtlinien, zugelassene Verfahren, Zertifikatsmanagement und Geheimnisschutz können den NIS2-Bereich weitgehend abdecken. Das Mapping prüft Scope, Aktualität und technische Durchsetzung.

Besonders relevant sind alte Protokolle, gemeinsam genutzte Schlüssel und unkontrollierte Zertifikate in Produktions- oder OT-Umgebungen. Übergänge erhalten Risikoentscheidung und Zeitplan. Schlüsselwiederherstellung und Notfallzugang werden getestet, ohne Schutzmechanismen zu unterlaufen.

Personalsicherheit und Zugriffskontrolle verbinden

Annex A enthält Screening, Beschäftigungsbedingungen, Verantwortlichkeiten, Austrittsprozesse, Vertraulichkeit, Remote Work, Identitäts- und Zugriffsmanagement. Damit besteht eine starke Überlappung. NIS2 nennt Personalsicherheit, Zugriffskontrolle und Assetmanagement ausdrücklich.

Die Umsetzung prüft Joiner-Mover-Leaver, privilegierte Konten, Serviceidentitäten und Dienstleisterzugriffe. Rezertifizierungen müssen kritische Dienste abdecken. HR, Fachbereich und IT teilen Verantwortung. Technische Stichproben vergleichen genehmigte Rollen mit tatsächlichen Berechtigungen.

Starke Authentisierung und sichere Kommunikation nachschärfen

ISO-Controls zu Authentisierungsinformationen, Identitätsmanagement, Netzwerk- und Kommunikationssicherheit bieten eine Grundlage. § 30 nennt Multi-Faktor- oder kontinuierliche Authentisierung sowie gesicherte Sprach-, Video- und Textkommunikation, soweit angemessen. Ein allgemeines Passwortkonzept kann daher unzureichend sein.

Privilegierte und externe Zugriffe werden zuerst mit phishingresistenter Mehrfaktorauthentisierung geschützt. Notfallkonten erhalten getrennte Kontrollen. Krisenkommunikation muss auch bei Ausfall der Unternehmensidentität verfügbar sein. Übungen prüfen Zugang und Vertraulichkeit.

Assetmanagement als Voraussetzung für belastbaren Scope

ISO 27001 enthält Inventarisierung, Eigentümerschaft, zulässige Nutzung, Rückgabe und Klassifizierung. Diese Kontrollen bilden die Grundlage für NIS2-Risikomanagement. Unbekannte Assets können weder geschützt noch einer Dienstleistung zugeordnet werden.

Das Inventar verbindet Hardware, Software, Cloudressourcen, Informationen und Lieferanten mit kritischen Diensten. Automatische Funde werden gegen verantwortete Stammdaten geprüft. Veraltete oder nicht unterstützte Assets erscheinen als Risiko. Änderungen aktualisieren Scope und Kontrolltests.

Registrierung ist keine typische ISO-Anforderung

Die Registrierung nach § 33 BSIG ist eine gesetzliche Pflicht und wird von ISO 27001 nicht automatisch abgedeckt. Das ISMS kann Dokumentenlenkung und Compliance-Kalender liefern, benötigt aber einen spezifischen Prozess für BSI-Portal, Stammdaten, Kontaktstelle und Änderungen.

Mindestens zwei berechtigte Personen, ein überwachtes Funktionspostfach und regelmäßige Tests sichern Handlungsfähigkeit. Die Bestätigung wird als Evidenz geführt. Neue Gesellschaften oder Tätigkeiten lösen eine Betroffenheits- und Registrierungsprüfung aus.

Leitungsschulung ist eine eigenständige Lücke

ISO 27001 verlangt Kompetenz und Awareness, schreibt aber nicht identisch die regelmäßige Schulung der NIS2-Geschäftsleitung nach § 38 vor. Ein allgemeines Managementbriefing zum ISMS reicht nicht automatisch. Inhalte müssen Risikoerkennung, Risikomanagementpraktiken und Auswirkungen auf Dienste vermitteln.

Curriculum, Teilnehmer, Lernziele, Trainer und praktische Übung werden dokumentiert. Verhinderte oder neue Mitglieder erhalten Nachholtermine. Die Schulung wird mit Managementreview und Krisenübung verbunden, bleibt aber als eigener Pflichtnachweis erkennbar.

Unterrichtung und behördliche Meldung ergänzen

Ein ISMS kann externe Kommunikation und Vorfallmanagement regeln, enthält aber keine automatische Erfüllung der konkreten §§ 32 und 35 BSIG. Meldefristen, Erheblichkeitskriterien, Empfängerkreise und Portalverfahren werden in einem Rechts-Runbook abgebildet.

Datenschutzmeldungen, Kundenpflichten und NIS2-Meldungen werden koordiniert, ohne sie gleichzusetzen. Ein gemeinsames Faktenblatt verhindert Widersprüche. Zeitstempel und Freigaben bleiben nachvollziehbar. Tabletop-Tests messen die tatsächliche Fristfähigkeit.

KRITIS-Nachweise außerhalb der normalen Zertifizierung

§ 39 BSIG verlangt für Betreiber kritischer Anlagen einen besonderen Nachweis durch Sicherheitsaudits, Prüfungen oder Zertifizierungen in Bezug auf die kritischen Anlagen. Eine ISO-27001-Zertifizierung kann hierfür relevant sein, wenn Scope und Verfahren passen, ist aber nicht automatisch ausreichend.

Der Betreiber stimmt Prüfplanung, Einreichung und Mängelbehandlung auf gesetzliche Vorgaben ab. Das Auditprogramm trennt Zertifizierungsaudit, interne Prüfung und gesetzlichen Nachweis. Evidenz wird wiederverwendet, während spezifische Formate und Fristen erhalten bleiben.

Durchführungsverordnung 2024/2690 für bestimmte Anbieter

Für DNS-, TLD-, Cloud-, Rechenzentrums-, CDN-, Managed-Service-, Managed-Security-, Online-Marktplatz-, Suchmaschinen- und soziale Plattformanbieter sowie Vertrauensdiensteanbieter konkretisiert die EU-Durchführungsverordnung technische und methodische Anforderungen. Diese Anforderungen gehen deutlich tiefer als ein allgemeines Annex-A-Mapping.

Die Verordnung basiert ausdrücklich auch auf ISO 27001 und ISO 27002, enthält aber detaillierte Vorgaben zu Policies, Risiko, Incident, Continuity, Supply Chain, Tests, Personal, Zugriff, Asset und weiteren Bereichen. Betroffene Organisationen erstellen ein separates Detailmapping. ENISA liefert hierfür nicht bindende technische Hinweise und Evidenzbeispiele.

Ein Mapping mit acht belastbaren Spalten

Die Matrix enthält Rechtsquelle und Anforderung, NIS2-Dienst, vorhandenen ISMS-Prozess, konkrete Kontrolle, Eigentümer, Frequenz, Evidenz und Lücke. Ergänzend werden Anwendbarkeit, Risiko und Maßnahme gepflegt. Verweise auf ISO-Klauseln allein sind zu abstrakt.

Eine Stichprobe verfolgt jede grüne Zuordnung bis zur tatsächlichen Evidenz. Teilabdeckung bleibt gelb, bis fehlende Aspekte umgesetzt und getestet sind. Die Matrix wird bei Gesetzes-, Scope- oder Kontrolländerung aktualisiert und bildet die Grundlage für Managementbericht und Prüfung.

Beispiel: zertifizierter Hersteller mit engem Scope

Ein Hersteller ist als wichtige Einrichtung betroffen. Sein ISO-Zertifikat umfasst jedoch nur Entwicklung und zentrale IT am Hauptstandort, nicht Produktion und mehrere Tochtergesellschaften. Das NIS2-Scope-Mapping zeigt, dass Produktionsnetze, lokale Identitäten und Wartungsdienstleister außerhalb liegen.

Das Unternehmen erweitert Inventar, Risikoanalyse und Kontrolltests auf die betroffenen Dienste. Zentrale ISMS-Prozesse bleiben bestehen. Lokale Verantwortliche und Evidenz werden integriert. Registrierung, Leitungsschulung und Meldeprozess kommen als neue gesetzliche Arbeitspakete hinzu.

Beispiel: Cloudanbieter mit ISO-Zertifikat

Ein Cloudanbieter besitzt ISO 27001 und fällt unter die EU-Durchführungsverordnung 2024/2690. Er nutzt sein ISMS für Governance, Risiko, Audit und Verbesserung. Anschließend mappt er jede Detailanforderung der Verordnung und die ENISA-Evidenzbeispiele auf Plattform, Prozesse und Nachweise.

Zusätzliche Lücken zeigen sich etwa bei spezifischen Kriterien, Dokumentation der Nichtanwendbarkeit, Testtiefe und erheblicher Vorfallbewertung. Das Zertifikat reduziert Aufwand, ersetzt aber keine vollständige rechtliche Analyse. Änderungen werden im ISMS kontrolliert nachgeführt.

Typische Mapping-Fehler vermeiden

Der häufigste Fehler ist die Gleichsetzung ähnlich klingender Überschriften. „Incident Management vorhanden“ beweist keine fristgerechte NIS2-Meldung. „Lieferantenkontrolle vorhanden“ beweist keine dienstbezogene Konzentrations- oder Exit-Bewertung. „Managementreview vorhanden“ belegt nicht automatisch die Pflicht der richtigen Geschäftsleitung.

Das andere Extrem ist ein separates NIS2-Managementsystem mit doppelten Risiken, Audits und Maßnahmen. Ein gutes Mapping nutzt vorhandene Prozesse, ergänzt gesetzliche Spezifika und markiert Scope-Grenzen. Jede Abdeckung muss an Evidenz und Wirksamkeit gebunden sein.

Fazit: Das ISMS ist Fundament, nicht Freistellung

ISO 27001 deckt große Teile der NIS2-Risikomanagementmaßnahmen strukturell ab. Besonders stark sind Governance, Risiko, Kontrollen, Audit und Verbesserung. Typische Lücken liegen bei Betroffenheit, gesetzlichem Scope, Registrierung, gestufter Meldung, Leitungsschulung, Unterrichtung und KRITIS-spezifischen Nachweisen.

BlackMount unterstützt beim NIS2-zu-ISO-27001-Mapping, bei Scope- und Evidenzprüfung, Lückenanalyse und Integration in das bestehende ISMS. Ziel ist eine belastbare Umsetzung ohne Doppelstrukturen, aber auch ohne pauschale Compliance-Aussagen auf Basis eines Zertifikats.

Verwendete Primärquellen