NIS2 und DIN EN ISO 27001: Was das Zertifikat abdeckt – und was für die KSC-Compliance noch fehlt

In vielen Unternehmen beginnt die Diskussion über NIS2 mit der Frage nach einer ISO-27001-Zertifizierung. Das ist nachvollziehbar, aus Sicht der Geschäftsleitung und der Prozessverantwortlichen jedoch der falsche Ausgangspunkt. Zunächst ist zu klären, ob und in welchem Umfang die Organisation betroffen ist, welche Dienste und Ressourcen erfasst sind und wer die Verantwortung dafür trägt. Erst danach lässt sich belastbar bewerten, was das vorhandene Informationssicherheits-Managementsystem tatsächlich abdeckt und welche Lücken gegenüber dem KSC noch bestehen. Genau hier zeigt sich in der Praxis der Unterschied zwischen einem wirksamen Managementsystem und einer kostspieligen Scheinsicherheit.

Der teuerste Fehler: Zertifizierung mit Compliance gleichsetzen

Der größte Fehler zu Projektbeginn ist nicht das Fehlen eines ISO-27001-Zertifikats. Problematisch ist vielmehr die Annahme, eine bestehende Zertifizierung bestätige automatisch die Erfüllung der Pflichten aus NIS2 und den nationalen Vorschriften zur Umsetzung im KSC. Für die Leitungsebene lautet die entscheidende Frage nicht: „Sind wir nach DIN EN ISO 27001 zertifiziert?“, sondern: „Unterliegen wir den Pflichten, in welcher Eigenschaft und bezogen auf welche Dienste, Prozesse und Ressourcen?“ Erst wenn der Status der Organisation, der betroffene Tätigkeitsumfang und die Verantwortung der Geschäftsleitung geklärt sind, kann bewertet werden, inwieweit das bestehende System die Compliance tatsächlich unterstützt oder lediglich den Eindruck geordneter Verhältnisse vermittelt.

Diese Unterscheidung hat unmittelbare Auswirkungen auf Projektumfang und Budget. Ein Zertifikat bestätigt die Konformität eines Managementsystems mit den Anforderungen der Norm innerhalb eines festgelegten Zertifizierungsumfangs. Dieser ist üblicherweise auf dem Zertifikat beschrieben und wird durch die Erklärung zur Anwendbarkeit konkretisiert. Das Zertifikat ersetzt jedoch weder die Analyse gesetzlicher Pflichten noch die Identifikation relevanter Dienste, die Bewertung von Lieferantenabhängigkeiten oder die Festlegung formaler Maßnahmen, die eine regulierte Organisation ergreifen muss. Die Geschäftsleitung sollte daher drei Ebenen klar voneinander trennen, die in der Praxis häufig vermischt werden: Managementsystem, regulatorische Compliance und operative Handlungsfähigkeit unter dem Druck eines Sicherheitsvorfalls.

Am teuersten werden Projekte, wenn diese Reihenfolge umgekehrt wird. Die Organisation richtet zunächst Dokumentation und Kontrollen auf das Zertifizierungsaudit aus und stellt erst später fest, dass kritische Prozesse, Meldepflichten für Sicherheitsvorfälle, Anforderungen an Lieferanten, Leitungsverantwortung oder sektorspezifische Vorgaben außerhalb des betrachteten Umfangs liegen. Dann genügt es nicht, einige Verfahren zu ergänzen. Vielmehr müssen der Systemumfang, Entscheidungsrollen und Reaktionsabläufe neu gestaltet werden.

Aus operativer Sicht sollte deshalb nicht allein das Vorhandensein eines Zertifikats gemessen werden. Entscheidend sind drei Punkte: die Übereinstimmung des Zertifizierungsumfangs mit den kritischen Diensten, das Ergebnis der Selbstbewertung zur Anwendbarkeit des KSC sowie die Anzahl der Lücken zwischen dokumentierten Verfahren und tatsächlicher Handlungsfähigkeit. Der sinnvolle erste Schritt ist daher nicht der Ausbau der Dokumentation, sondern die Klärung, ob die Organisation in den Anwendungsbereich fällt und welche formalen Maßnahmen erforderlich sind. Diese Reihenfolge wird auch im Beitrag NIS2: Selbstbewertung und Eintragung in das KSC-Verzeichnis – was muss ein Produktionsunternehmen tun? aufgegriffen. Denn genau an diesem Punkt entscheidet sich, ob ein Unternehmen sein System auf reale Pflichten ausrichtet oder auf eine bequeme, aber kostspielige Illusion der Bereitschaft.

Was DIN EN ISO 27001 tatsächlich abdeckt

Der größte praktische Nutzen von DIN EN ISO 27001 liegt nicht im Besitz des Zertifikats, sondern darin, Informationssicherheit als steuerbaren Managementbereich zu strukturieren. Ein wirksam implementiertes System unterstützt insbesondere dort, wo eine Organisation prozessorientiert handeln muss: bei Risikobeurteilung und Risikobehandlung, bei Richtlinien und Steuerungsmechanismen, bei der Zuweisung von Rollen und Verantwortlichkeiten, bei der Identifikation von Informationswerten, beim Umgang mit Sicherheitsvorfällen, bei der betrieblichen Kontinuität sowie bei Überwachung und fortlaufender Verbesserung. Wenn diese Elemente im Tagesgeschäft funktionieren und nicht nur für das Audit gepflegt werden, verfügt das Unternehmen über eine belastbare Grundlage, um Informationssicherheit als gesteuertes System und nicht als Sammlung einzelner Schutzmaßnahmen nachzuweisen.

Die Geschäftsleitung sollte dennoch nicht nur auf das Zertifikat schauen, sondern auf dessen Nutzen für regulatorisch relevante Dienste, Prozesse und Abhängigkeiten. Dasselbe Zertifikat kann für ein ausgereiftes System stehen, das kritische Prozesse, regelmäßige Bewertungen, Korrekturmaßnahmen und eine wirksame Steuerung durch Prozessverantwortliche umfasst. Es kann aber auch lediglich einen eng begrenzten Teil der Organisation abdecken. Vor einer Selbstbewertung gegenüber NIS2 und KSC sollten deshalb nicht nur die Erklärung zur Anwendbarkeit, sondern auch die in der Risikobeurteilung erfassten Prozesse, Ergebnisse interner Audits und Managementbewertungen geprüft werden. Ebenso wichtig ist die Frage, ob Risikoentscheidungen tatsächlich in Budgets, Verträge, die Servicearchitektur und Reaktionsabläufe einfließen.

Besonders deutlich wird dies bei Unternehmen in komplexen Lieferketten. DIN EN ISO 27001 strukturiert typischerweise vertragliche Anforderungen, die Klassifizierung von Informationen, Zugriffsregeln, Verantwortlichkeiten der Lieferanten und die Dokumentation von Abweichungen. Das ist eine tragfähige Grundlage, insbesondere wenn Kunden einen nachweisbaren Umgang mit Geschäftspartnern verlangen. Die Zertifizierung erfüllt jedoch nicht automatisch sämtliche Branchenanforderungen oder sektorspezifischen Kriterien. Ein vergleichbares Abgrenzungsthema behandelt der Beitrag DIN EN ISO 27001 oder TISAX – was ist zu wählen, wenn ein Kunde Informationssicherheit in der Lieferkette fordert? In der Praxis schafft das Zertifikat geordnete Beziehungen und Verantwortlichkeiten. Es ersetzt jedoch nicht die Prüfung, welche Pflichten zusätzlich in Verträgen, Eskalationsverfahren und die Überwachung externer Dienste aufgenommen werden müssen.

Die Schlussfolgerung ist eindeutig: Eine Zertifizierung kann den Weg zu einer strukturierten Informationssicherheit erheblich verkürzen. Sie ist jedoch kein eigenständiger Nachweis für die Erfüllung aller Pflichten aus dem KSC. Ein Zertifizierungsaudit bewertet die Konformität des Managementsystems mit den Anforderungen der Norm innerhalb des festgelegten Umfangs. Das ist nicht deckungsgleich mit der Prüfung gesetzlicher Pflichten oder der operativen Einsatzbereitschaft. Die Organisation sollte daher parallel prüfen, ob der Systemumfang alle relevanten Prozesse erfasst, ob die Risikobeurteilung die tatsächlichen Dienste und Abhängigkeiten berücksichtigt und ob Verfahren für Sicherheitsvorfälle, Kontinuität und Lieferantensteuerung praktisch funktionieren.

Wo das Zertifikat nicht ausreicht

Die erste Lücke betrifft die regulatorische Compliance selbst. Ein Informationssicherheits-Managementsystem strukturiert Regeln, Rollen und Überwachung. Es beantwortet jedoch nicht automatisch, ob die Organisation im Kontext des KSC korrekt eingestuft wurde, wer für formale Meldungen verantwortlich ist, wer die Beziehung zur zuständigen Behörde pflegt und wie Entscheidungen an die Leitungsebene eskaliert werden. Dabei handelt es sich nicht um das Fehlen eines einzelnen Dokuments, sondern um einen Konstruktionsfehler im Verantwortungsmodell. Werden diese Elemente nicht im tatsächlichen Betriebsmodell verankert, schafft die Zertifizierung zwar interne Ordnung, aber noch keine regulatorische Steuerungsfähigkeit.

Die zweite Lücke betrifft den Umfang. Bei vielen Organisationen ist die Zertifizierung auf einen ausgewählten Standort, eine Gesellschaft, einen bestimmten Funktionsbereich oder einen Teil der unterstützenden Dienste begrenzt. Eine Bereitschaftsbewertung nach KSC muss dagegen von der realen Landkarte der Dienste, kritischen Prozesse, Ressourcen und Abhängigkeiten ausgehen – nicht von den Grenzen des Zertifizierungsaudits. Wird ein wesentlicher oder wichtiger Dienst durch mehrere Gesellschaften einer Gruppe erbracht und sind daran ein externes Rechenzentrum, ein gemeinsames Betriebsteam oder ein verteilter Incident-Response-Prozess beteiligt, kann ein formal korrektes Zertifikat nur einen Ausschnitt des Gesamtmodells erfassen. Die Managemententscheidung beschränkt sich dann nicht auf die Frage, ob der Zertifizierungsumfang erweitert werden sollte. Zu klären ist vielmehr, ob ein integriertes Compliance-Projekt oder zwei abgestimmte Arbeitsstränge für Zertifizierung und regulatorische Anforderungen erforderlich sind.

Die dritte Lücke betrifft die Nachweisführung und wird häufig erst bei einem Vorfall, einer Übung oder einer Kontrolle sichtbar. Die Organisation verfügt zwar über Verfahren für Sicherheitsvorfälle, betriebliche Kontinuität und Lieferantensteuerung, kann deren operative Wirksamkeit jedoch nicht belegen. Es fehlen ein Incident-Register, nachvollziehbare Leitungsentscheidungen, Ergebnisse von Übungen, Nachbewertungen nach Ereignissen, Leistungskennzahlen oder dokumentierte Korrekturmaßnahmen. In diesem Zustand ist das System beschrieben, aber nicht nachgewiesen. Gerade hier entstehen die teuersten Nacharbeiten, weil nicht nur Verfahrensdokumente, sondern auch das Reporting an die Geschäftsleitung, der Rhythmus der Bewertungen und die Verantwortung der Prozessverantwortlichen geändert werden müssen. Derselbe Mechanismus ist auch in anderen Managementsystemen erkennbar, etwa im Beitrag IATF 16949 – welche Anforderungen im Qualitätsalltag wirklich Probleme verursachen und wie sie ohne Scheinkonformität gesteuert werden.

Die vierte Lücke liegt in der Lieferkette und bei externen Abhängigkeiten. Die Norm unterstützt dabei, Anforderungen an Lieferanten zu strukturieren. Die KSC-Compliance kann jedoch eine weitergehende Abbildung verlangen: Welche externen Leistungen stützen einen kritischen Dienst? Wo bestehen Single Points of Failure? Welche Störungsszenarien sind relevant? Wie austauschbar sind Lieferanten, Personal oder Standorte? In der Praxis sollte deshalb nicht nur gemessen werden, ob Verträge und Lieferantenbewertungen vorhanden sind. Aussagekräftiger sind die Übereinstimmung des Zertifizierungsumfangs mit der tatsächlichen Landkarte kritischer Dienste, die Vollständigkeit der Incident- und Übungsnachweise sowie die Aktualität der Bewertungen von Lieferanten und Abhängigkeiten. Erst diese Gesamtsicht zeigt, ob die Organisation über ein wirksames System oder nur über dessen formales Abbild verfügt.

Compliance-Projekte müssen bei den Diensten beginnen – nicht bei den Dokumenten

Ein typischer Fehler zu Projektbeginn besteht darin, zunächst Richtlinien, Verfahren und ISO-27001-Aufzeichnungen zu prüfen, statt zu klären, welche Dienste tatsächlich aufrechterhalten werden müssen und welche regulatorischen Pflichten damit verbunden sind. Die richtige Reihenfolge ist umgekehrt: Zuerst werden die aus Sicht der Kontinuität und der Verantwortung nach KSC kritischen Dienste, Prozesse, Ressourcen und Abhängigkeiten identifiziert. Anschließend werden ihnen Systemanforderungen und erforderliche Nachweise zugeordnet. Nur so lässt sich zwischen notwendiger und entbehrlicher Dokumentation unterscheiden.

Für die Geschäftsleitung bedeutet dies, eine Übersicht kritischer Dienste, der Abhängigkeiten von Lieferanten und Systemen sowie der vorhandenen Verfahren zu erstellen, die ohne Doppelstrukturen weitergenutzt werden können. Erst auf dieser Grundlage wird sichtbar, ob das bestehende Managementsystem die für die Aufrechterhaltung der Dienste und die Compliance relevanten Bereiche abdeckt oder lediglich jene Elemente, die historisch in den Zertifizierungsumfang aufgenommen wurden.

Im zweiten Schritt ist das Verantwortungsmodell festzulegen. Wenn Informationssicherheit zwischen IT, Qualitätsmanagement, Compliance, Instandhaltung und Einkauf verteilt ist, ohne dass Rollen eindeutig abgegrenzt sind, entwickelt sich das Projekt schnell zu einer Sammlung lokaler Einzelinitiativen. Deshalb muss feststehen, wer Risiken verantwortet, wer Sicherheitsvorfälle bearbeitet, wer Lieferantenbeziehungen überwacht, wer Managemententscheidungen trifft und wer die Compliance-Nachweise pflegt. In der Praxis bewähren sich eine klare Rollen- und Verantwortungsmatrix sowie ein gemeinsamer Rhythmus für Managementbewertungen anstelle mehrerer paralleler Berichtswege. In diesem Schritt ist außerdem zu entscheiden, ob ein gemeinsamer Lenkungskreis für Compliance und Informationssicherheit eingerichtet und die operative Technologie in dasselbe Risikomodell einbezogen werden soll.

Für Produktionsunternehmen und Organisationen mit mehreren Standorten ist diese Logik besonders relevant. Ein Sicherheitsvorfall beschränkt sich dort nicht auf den Verlust der Vertraulichkeit von Daten. Er kann zum Stillstand einer Fertigungslinie, zu Störungen der Produktionsplanung, zum Verlust der Chargenrückverfolgbarkeit oder zur Unterbrechung eines Dienstes führen. Informationssicherheit muss deshalb mit betrieblicher Kontinuität, Instandhaltung und OT-Umgebungen verbunden werden. Erfasst das Managementsystem nur die Büro-IT und lässt Steuerungssysteme, Fernwartung, Integratorenabhängigkeiten oder betriebliche Notfallverfahren unberücksichtigt, bleibt das Risikobild trotz formal geordneter Strukturen operativ unvollständig. Dieselbe Projektdisziplin gilt in anderen Bereichen mit hohen Überwachungsanforderungen, auch wenn Referenzwerke wie ASME, NQA-1 und ISO 19443 – drei Abkürzungen, die ein Lieferant der Nuklearindustrie kennen muss relevant werden.

Erst auf dieser Grundlage sollte das bestehende ISO-27001-System als Basisschicht genutzt und eine separate KSC-Gap-Analyse durchgeführt werden. Eine solche Analyse stellt das Zertifikat nicht infrage. Sie prüft vielmehr, wo eine tatsächliche Abdeckung besteht und wo zusätzliche Verfahren, Register, Eskalationswege oder Wirksamkeitsnachweise erforderlich sind. Dieser Ansatz reduziert unnötige Dokumentation und unterstützt konsistente Steuerungsmechanismen besser als voneinander getrennte, konkurrierende Implementierungsprojekte.

So lässt sich der Ist-Zustand vor Audit oder Kontrolle prüfen

Vor einem Audit, einer Selbstbewertung oder einer Kontrolle sollte nicht gefragt werden, ob die Organisation „DIN EN ISO 27001 hat“. Entscheidend ist, ob sie ihre tatsächliche Handlungsfähigkeit und die Nachvollziehbarkeit von Entscheidungen belegen kann. Diese Bereitschaft sollte auf vier Ebenen bewertet werden: Zuerst werden Anwendungsbereich und Pflichtenstatus geklärt, anschließend die Ausgestaltung des Managementsystems, danach die Wirksamkeit der Prozesse und schließlich die Vollständigkeit der Nachweise. Nur diese Reihenfolge trennt dokumentierte Ordnung von operativer Leistungsfähigkeit.

Die nützlichsten Fragen lauten daher nicht: „Gibt es ein Verfahren?“, sondern: „Ist bekannt, wann es ausgelöst wird, wer entscheidet, welche Eskalationsschwellen gelten, wie die Umsetzung nachgewiesen wird und ob das Szenario geübt wurde?“ Hängt die Bearbeitung eines Sicherheitsvorfalls vom Wissen einer einzelnen Person ab, enthalten Lieferantenbeziehungen keine definierten Sicherheitskriterien oder erhält die Geschäftsleitung nur allgemeine Berichte ohne Entscheidungen und Fristen, kann das System zwar formal seiner eigenen Beschreibung entsprechen, ist aber noch nicht belastbar auf eine Krisensituation vorbereitet.

Die Bereitschaftsbewertung sollte deshalb insbesondere die Schnittstellen zwischen Geschäftsleitung, operativen Bereichen, IT, Instandhaltung und Lieferanten einbeziehen. Genau dort treten häufig Lücken auf, die in den Verfahrensdokumenten nicht sichtbar werden. In der Praxis bewährt sich eine Gap-Analyse in Form eines operativen Audits. Dabei werden nicht nur Dokumentinhalte beurteilt, sondern auch Entscheidungsabläufe, Eskalationswege, Incident-Aufzeichnungen, Ergebnisse von Tests und Übungen sowie das Register von Nichtkonformitäten, Feststellungen und Korrekturmaßnahmen.

Ein einfacher Stresstest liefert häufig klare Ergebnisse: Bei einem Sicherheitsvorfall eines Schlüssellieferanten oder einer Störung in der Produktionsumgebung muss nachvollziehbar sein, wer das Ereignis klassifiziert, wer die Kommunikation auslöst, wer die Auswirkungen auf den Dienst bewertet und welche Nachweise aus diesen Entscheidungen entstehen. Sind die Antworten über mehrere Bereiche verteilt und verweist die Organisation auf eine gelebte Praxis, die sich anhand von Aufzeichnungen nicht rekonstruieren lässt, ist die Bereitschaft nur scheinbar vorhanden – selbst wenn das Managementsystem formal korrekt aufrechterhalten wird.

Bestehen bereits interne Audits nach DIN EN ISO 27001, sollten sie als Träger dieser Prüfung genutzt werden. Die Auditkriterien müssen jedoch um die regulatorischen Pflichten und die aus KSC-Sicht erwarteten Nachweise ergänzt werden. Die Auditmethodik ist hierfür sehr wertvoll, ebenso die Kompetenz von Personen, die sich auf eine Tätigkeit als Lead Auditor oder interner Auditor vorbereiten. Als ergänzende Orientierung kann der Beitrag ISO-27001-Lead-Auditor: umfassender Leitfaden zu Zertifizierung und Normanforderungen dienen. Die Reihenfolge bleibt jedoch entscheidend: Auditkompetenz hilft bei der Bewertung des Systems, ersetzt aber nicht die Analyse der rechtlichen und organisatorischen Pflichten, die auf das jeweilige Unternehmen tatsächlich anwendbar sind.

Managemententscheidung: Das Zertifikat als Grundlage, nicht als Alibi

Der sinnvollste Ansatz besteht darin, DIN EN ISO 27001 als Grundlage einer strukturierten Steuerung zu nutzen – nicht als eigenständigen Nachweis für die Erfüllung sämtlicher Pflichten aus NIS2 und KSC. Die Zertifizierung schafft einen Rahmen für Verantwortlichkeiten, Risikobeurteilung, Incident-Management, Audits und fortlaufende Verbesserung. Sie entbindet die Organisation jedoch nicht davon, festzustellen, welche Pflichten in welchem Umfang gelten und welche Nachweise erforderlich sind, um die Wirksamkeit der Umsetzung zu belegen.

Die größte Gefahr für die Geschäftsleitung ist nicht eine Lücke in der Dokumentation, sondern Scheinsicherheit: die Annahme, ein zertifiziertes System bedeute automatisch, dass die Organisation auch auf die Anforderungen des nationalen Rechtsrahmens vorbereitet ist. Die Entscheidung sollte sich daher nicht allein darauf beschränken, ob die Zertifizierung aufrechterhalten oder erweitert wird. Zunächst sind drei Managementfragen zu klären:

• Status der Organisation und Umfang der anwendbaren Pflichten bestätigen,
• eine Gap-Analyse zwischen dem bestehenden System und den KSC-Anforderungen durchführen,
• ein Steuerungsmodell für Maßnahmenumsetzung und Wirksamkeitsnachweise festlegen.

Erst auf dieser Grundlage lässt sich sinnvoll entscheiden, ob der Zertifizierungsumfang erweitert werden sollte oder ob das bestehende ISO-27001-System unverändert als Basis genutzt und um fehlende organisatorische, rechtliche und operative Mechanismen ergänzt werden kann. Drei einfache Steuerungsinstrumente sind dabei besonders hilfreich: ein Abgleich des aktuellen Zertifizierungsumfangs mit der Landkarte kritischer Prozesse, eine Lückenliste mit Bewertung der Auswirkungen auf Risiko und Compliance sowie ein Maßnahmenplan mit Verantwortlichen, Fristen und Abschlusskriterien.

Wenn eine Organisation ihren weiteren Weg erst festlegt, gibt es keine universell richtige Reihenfolge. Bei hohem Kundendruck oder Ausschreibungsanforderungen kann der Aufbau eines zertifizierungsfähigen Systems ein begründeter erster Schritt sein – vorausgesetzt, die Analyse regulatorischer Pflichten wird parallel durchgeführt und nicht aufgeschoben. In Unternehmen mit hohem Betriebsrisiko oder einem stark verteilten Verantwortungsmodell kann es dagegen sinnvoller sein, zunächst regulatorische Lücken zu schließen und erst danach den Zertifizierungsumfang zu ordnen. Es geht nicht um die Reihenfolge von Formalitäten, sondern um die Reihenfolge der Risikoreduktion. Auch das Thema ISO-Zertifikat: Nutzen und Implementierungsprozess sollte daher nicht losgelöst vom Betriebsmodell des Unternehmens betrachtet werden, sondern als Teil einer umfassenderen Entscheidung über die Steuerung von Compliance.

Die besten Ergebnisse entstehen in einem integrierten Programm, in dem Informationssicherheit, betriebliche Kontinuität, Lieferantensteuerung und regulatorische Pflichten als Bestandteile des operativen Modells behandelt werden – nicht als getrennte Initiativen verschiedener Abteilungen. Unter polnischen Rahmenbedingungen ist es häufig gerade die Verteilung der Verantwortung, die die operative und nachweisbezogene Bereitschaft schwächt. Die zentrale Schlussfolgerung lautet daher: Ein ISO-27001-Zertifikat ist hilfreich und kann den Weg zu einem strukturierten System deutlich verkürzen. Die Compliance mit NIS2 und KSC muss jedoch zusätzlich konzipiert, umgesetzt und unter den konkreten Rahmenbedingungen der Organisation belastbar nachgewiesen werden.