ISO 27001 vs NIS2: So baust du ein belastbares Mapping

Definition

ISO/IEC 27001 ist ein internationaler Standard für ein ISMS (Information Security Management System) und beschreibt Anforderungen an Management, Prozesse, Risikomanagement und Kontrollen. NIS2 ist eine EU-Richtlinie, die als gesetzliche Pflicht umgesetzt wird und Nachweise zu Sicherheitsmaßnahmen, Meldepflichten (NIS2) und Incident Response verlangt.

ISO 27001 ist kein Gesetz und NIS2 ist keine Zertifizierung; beide adressieren Informationssicherheit, aber mit unterschiedlichem Fokus auf Compliance und Durchsetzung. Ein NIS2 – ISO 27001 Mapping verbindet beides für strukturierte Umsetzung und Dokumentation.

Einleitung

Wenn du iso 27001 vs nis2 vergleichst, willst du am Ende zwei Dinge wissen: Was deckt dein ISMS schon ab, und was fehlt für die gesetzliche NIS2-Compliance? Genau dafür brauchst du Mapping statt Bauchgefühl.

Der praktische Nutzen: Du reduzierst Abstimmungsaufwand, kannst Entscheidungen im Management sauber begründen und bist im Incident schneller handlungsfähig, weil Prozesse, Rollen und Nachweise nicht erst im Ernstfall gesucht werden.

Unterschiede, die für Umsetzung und Nachweise zählen

ISO/IEC 27001 ist stark im „Wie“: Governance, strukturierte Prozesse, Verantwortlichkeiten, Risikoanalyse, Ziele, interne Audits und kontinuierliche Verbesserung. NIS2 ist stark im „Muss“: gesetzliche Anforderungen, Nachweisführung gegenüber Aufsicht, Meldeketten und klare Erwartungen an Incident-Handling.

Wichtig in der Praxis: Ein ISO-Zertifikat kann helfen, wirkt aber nicht automatisch als „Zertifizierung NIS“. NIS2 verlangt, dass Maßnahmen nicht nur geplant, sondern umgesetzt, getestet und dokumentiert nachweisbar sind, inklusive Management-Entscheidungen und Eskalationswegen.

Mapping-Strategie: So ordnest du ISO 27001 auf NIS2

Ein gutes ISO Mapping ist keine Feature-Liste, sondern eine Nachweis-Logik: NIS2-Anforderung → passende ISO/IEC-27001-Klausel und ISO 27001 Annex A (Controls) → vorhandener Nachweis → Lücke → Umsetzungsmaßnahme → Eigentümer im Management.

Damit das im Alltag funktioniert, sollten die Nachweise in wiederverwendbaren Artefakten landen: Mapping-Tabelle, Richtlinie, Prozessbeschreibung, Checkliste, Testprotokoll. Diese Struktur ist auditfähig und beschleunigt Reviews, weil nicht jedes Team neu interpretieren muss, „ob es reicht“.

Minimaler Mapping-Kern (Startpunkt)

• Governance & Management: Rollen, Verantwortlichkeiten, Risikoakzeptanz, Reviews, „Tone from the top“.
• Risikomanagement: Risikoanalyse, Maßnahmenplan, Wirksamkeitskontrolle, Lieferketten- bzw. Supplier-Risikomanagement.
• Incident Response & Meldepflichten: Ablauf, Entscheidungslogik, Dokumentation, Kommunikationswege, Fristen.

Typische Lücken: Wo ISO 27001 alleine nicht reicht

„ISO deckt NIS“ gilt oft nur teilweise. Häufig sind Prozesse beschrieben, aber nicht so operationalisiert, dass sie bei Vorfällen oder Audits belastbar sind. Genau hier entstehen Zeitaufwand, Komplexität und fehlende Messbarkeit.

• Meldepflichten (NIS2): Fristen, Zuständigkeiten, Vorlagen, Kontaktpunkte (z. B. Registrierung beim BSI) sind nicht automatisch Teil des ISMS.
• Incident-Nachweise: Timeline, Entscheidungen, Maßnahmen, Scope, Lessons Learned fehlen oft als standardisierte Dokumentation.
• Betriebsreife: Monitoring/Detektion ist vorhanden, aber ohne klaren Prozess für Triage und Eskalation bleibt es „Alarm-Sammlung“.

Kurzer Umsetzungsplan in 5 Schritten (ohne Overhead)

Der schnellste Weg ist ein strukturierter Plan, der sofort Nachweise erzeugt und nicht erst „nach der Implementierung“ an die Dokumentation denkt.

• Gap-Analyse: NIS2-Anforderungen gegen vorhandenes ISMS spiegeln, inklusive BSIG-Bezug (z. B. § 30 BSIG) und KRITIS-Nähe, falls relevant.
• Mapping-Tabelle bauen: pro Anforderung Control, Owner, Status, Nachweislink, offene Maßnahme.
• Incident Response operationalisieren: Playbooks, Meldeketten, Kommunikationsmatrix, Übungen, Vorlagen.

Danach: BCM (Business Continuity Management) testen, Risiken neu bewerten, und die kontinuierliche Verbesserung mit festen Review-Terminen im Management verankern.

Praxisbeispiel: Warum SIEM-Nachweise im Audit Zeit sparen

Ein Unternehmen hat ISO-Prozesse, aber im Audit wird gefragt, ob Angriffserkennung und Reaktion nachweisbar sind. Mit SIEM- und Incident-Protokollen aus Microsoft Sentinel lassen sich Erkennung, Eskalation und Maßnahmen als zusammenhängende Dokumentation zeigen.

Der Effekt ist messbar im Alltag: weniger manuelle Screenshots, weniger Suchaufwand und schnellere Abstimmung zwischen IT, Informationssicherheit und Management, weil ein gemeinsamer „Incident-Faktenstand“ existiert.

Audit-Readiness: Welche Nachweise du wirklich brauchst

Audit-Readiness heißt: zu jeder relevanten Anforderung gibt es eine Richtlinie, einen Prozess und einen belegbaren Umsetzungsnachweis. Vorlagen und Checklisten sind kein Bürokratie-Extra, sondern reduzieren Kosten durch weniger Ad-hoc-Arbeit im Incident und weniger Reibung in Audits.

Kompakte Nachweis-Sammlung

• NIS2 – ISO 27001 Mapping-Tabelle (Versionierung, Owner, Status).
• Incident-Dokumentation: Report-Vorlage, Timeline, Maßnahmen, Lessons Learned.
• Risikomanagement: Risikoanalyse, Maßnahmen-Backlog, Management-Freigaben.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung wird sinnvoll, wenn Mapping, Governance, Technik und Betrieb zusammenlaufen und intern niemand die End-to-End-Verantwortung halten kann. Typische Auslöser sind unklare Verantwortlichkeiten im Management, fehlende Incident-Prozesse oder ein ISMS, das „auf dem Papier“ funktioniert, aber nicht im Tagesbetrieb.

Auch wenn Monitoring vorhanden ist, aber niemand kontinuierlich triagiert, dokumentiert und verbessert, bleibt Compliance fragil. Spätestens dann lohnt sich ein strukturierter Betrieb, der Nachweise automatisch erzeugt statt sie im Nachhinein zu sammeln.