Ein mittelständischer Maschinenbauer liefert vernetzte Anlagen aus. Damit fällt er unter den Cyber Resilience Act, dessen Meldepflichten am 11. September greifen. Als Unternehmen einer wichtigen Branche ist er zugleich NIS2-pflichtig. Für Ausschreibungen soll er nach ISO 27001 zertifiziert sein. Und weil er einen Finanzdienstleister beliefert, reicht dieser DORA-Anforderungen in den Vertrag durch. Vier Regelwerke, vier Fristen, vier Bußgeldregime – und in vielen Unternehmen die Folge: vier getrennte Projekte, jedes mit eigener Dokumentation, eigenem Verantwortlichen und eigenem Audit-Kalender.
Das ist der teure Reflex. Er entsteht, weil die Regelwerke auf den ersten Blick nichts miteinander zu tun haben – der eine Blick auf die Meldefristen genügt, um das Gegenteil zu sehen.
Die Regelwerke regulieren verschiedene Ebenen – nicht verschiedene Welten
Wer den Wust ordnen will, braucht zuerst eine saubere Trennung nach dem, was reguliert wird. NIS2 und DORA regulieren Organisationen: Sie verpflichten Einrichtungen zu Risikomanagement, Governance und Meldepflichten – NIS2 branchenübergreifend, DORA speziell für den Finanzsektor und dessen IT-Dienstleister. Der CRA reguliert Produkte: Er verpflichtet Hersteller, Importeure und Händler von Produkten mit digitalen Elementen zu Security by Design, Schwachstellenmanagement und Meldepflichten. Und ISO/IEC 27001 ist der freiwillige Standard, auf dem die anderen aufsetzen – kein Gesetz, aber der etablierte Nachweisrahmen für ein funktionierendes Informationssicherheits-Managementsystem.
Der entscheidende Punkt: Diese Regelwerke stapeln sich, sie widersprechen sich nicht. Wer NIS2-pflichtig ist und zugleich Produkte herstellt, braucht CRA und NIS2. Wer beides mit einem zertifizierten ISMS unterlegt, führt die Nachweise für alle drei – und für DORA – aus einer Quelle statt aus vier getrennten Silos.
Wo sich die Pflichten tatsächlich überschneiden
Der Mehrwert eines gemeinsamen Fundaments zeigt sich nicht in der Theorie, sondern an den konkreten Berührungspunkten.
Risikomanagement. NIS2 verlangt in § 30 BSIG ein Risikomanagement über zehn Maßnahmenbereiche. DORA fordert einen IKT-Risikomanagementrahmen. Der CRA verlangt eine Risikobewertung über den Produktlebenszyklus. ISO 27001 stellt mit dem risikobasierten Ansatz und Anhang A genau die Methodik bereit, die alle drei einfordern. Wer den Risikomanagementprozess einmal sauber aufsetzt, bedient damit den Kern jeder der vier Anforderungen – die Unterschiede liegen im Geltungsbereich, nicht in der Methode.
Meldepflichten. Hier wird die Überschneidung greifbar. NIS2 kennt die Kette 24 Stunden / 72 Stunden / ein Monat an CSIRT und BSI. Der CRA verlangt ab dem 11. September dieselbe Staffelung – 24 Stunden Frühwarnung, 72 Stunden Meldung, Abschlussbericht – an CSIRT und ENISA. DORA fordert die Meldung schwerwiegender IKT-Vorfälle an die zuständige Finanzaufsicht. Drei Melderegime mit fast identischer Fristenlogik, aber unterschiedlichen Empfängern und Auslösern. Ein einziger, sauber definierter Incident-Prozess mit allen Pflichtfeldern bedient alle drei – getrennte Prozesse dagegen sorgen dafür, dass im Stress des Vorfalls eine Frist untergeht.
Lieferkette. NIS2 verlangt Sicherheit in der Lieferkette, der CRA zieht Hersteller für die Komponenten ihrer Produkte in die Pflicht, DORA reguliert das Drittparteienmanagement, ISO 27001 adressiert Lieferantenbeziehungen in Anhang A.5.19 ff. Vier Formulierungen desselben Gedankens: Wer fremde Bausteine einsetzt, haftet für deren Sicherheit mit. Ein gemeinsames Lieferantenmanagement mit Bewertung, vertraglicher Absicherung und laufender Überwachung erfüllt alle vier.
Governance und Verantwortung. NIS2 macht die Geschäftsleitung mit § 38 BSIG persönlich verantwortlich, inklusive Schulungspflicht. DORA verlangt die Einbindung des Leitungsorgans. ISO 27001 fordert das Bekenntnis der obersten Leitung. Auch hier: dieselbe Grundidee, einmal umzusetzen.
Der integrierte Ansatz spart nicht nur Geld
Die Einsparung an Umsetzungsaufwand durch Vermeidung von Doppelarbeit ist erheblich – doch der eigentliche Gewinn liegt woanders. Vier getrennte Silos erzeugen widersprüchliche Dokumentation, konkurrierende Zuständigkeiten und einen zersplitterten Audit-Kalender. Im Ernstfall – einem meldepflichtigen Vorfall, der zugleich CRA, NIS2 und DORA berührt – entscheidet nicht die Zahl der Projekte, sondern ob es einen einzigen Prozess gibt, der greift. Ein integriertes Managementsystem ist damit nicht nur billiger, sondern belastbarer.
Für den eingangs genannten Maschinenbauer heißt das konkret: nicht vier Projekte, sondern ein ISMS nach ISO 27001 als Fundament, auf das die spezifischen Zusatzanforderungen von CRA, NIS2 und DORA als Ergänzungsmodule aufsetzen. Die Nachweisführung läuft über ein Dokumentenlenkungssystem, ein Risikoregister, ein Schulungsprogramm, einen Incident-Prozess – jeweils mit den regulierungsspezifischen Feldern, aber nicht in vierfacher Ausfertigung.
Was der integrierte Ansatz nicht leistet
Ehrlichkeit gehört dazu: Ein ISMS ist das Fundament, nicht die Komplettlösung. Es liefert nicht automatisch die produktspezifischen CRA-Anforderungen wie die Software Bill of Materials oder das Security-by-Design im Entwicklungsprozess. Es ersetzt nicht die DORA-spezifischen Anforderungen an Testing und Ausfallszenarien. Und die Zuordnung, welche Einrichtung überhaupt unter welches Regime fällt, bleibt eine juristische Einzelfallprüfung. Der integrierte Ansatz reduziert die Redundanz im Fundament – er hebt die spezifischen Pflichten nicht auf. Wer etwas anderes verspricht, verkauft eine Vereinfachung, die im Audit nicht trägt.
Was jetzt zu tun ist
- Betroffenheit je Regelwerk klären: Fällt das Unternehmen unter NIS2, CRA, DORA? In welcher Rolle? Diese Einordnung ist die Grundlage und gehört dokumentiert.
- Vorhandenes ISMS als Ausgangspunkt nehmen: Wer bereits nach ISO 27001 arbeitet, hat das Fundament – die Frage ist, welche Ergänzungsmodule fehlen.
- Überschneidungen bewusst nutzen: Risikomanagement, Incident-Prozess, Lieferantenmanagement und Governance einmal aufsetzen, mehrfach verwenden.
- Melderegime zusammenführen: Einen Incident-Prozess mit allen Pflichtfeldern der drei Regime definieren, statt drei parallele Ketten.
- Spezifische Zusatzpflichten separat abarbeiten: SBOM und Security by Design für den CRA, Testing für DORA – das, was das ISMS nicht abdeckt.
Fazit
Kaum ein Unternehmen wird heute noch von nur einer Cybersicherheits-Regulierung erfasst. Die Versuchung, für jede ein eigenes Projekt aufzusetzen, ist verständlich – und teuer. Die Regelwerke regulieren verschiedene Ebenen, aber sie teilen dasselbe Fundament: ein funktionierendes Managementsystem, das Risiken bewertet, Vorfälle meldet, die Lieferkette absichert und die Leitung in die Pflicht nimmt. Wer dieses Fundament einmal sauber baut, beantwortet vier regulatorische Fragen mit einer Antwort – und steht im Ernstfall auf einem Prozess statt auf vier Projektplänen.
Als akkreditierter Auditor für ISO/IEC 27001, 27701, 22301 und 42001 begleite ich Unternehmen dabei, aus vier Compliance-Silos ein tragfähiges Managementsystem zu machen – von der Betroffenheitsanalyse über die Gap-Betrachtung bis zur prüfungsfesten Nachweisführung. Sprechen Sie mich an.