Es gibt Regulierungstexte, die man einmal liest, abnickt und dann in den Schrank stellt. Und es gibt Gesetze wie den Cyber Resilience Act (CRA): Er verändert, wie Produkte mit digitalen Funktionen in Europa entwickelt, gebaut, ausgeliefert, gepflegt und aus dem Verkehr gezogen werden. Der CRA ist kein weiteres „nice to have“ in Sachen IT-Security, sondern die neue Grundlinie, an der sich künftig jedes „Produkt mit digitalen Elementen“ messen lassen muss – vom smarten Heizkörperthermostat über Routers, Türschlösser, Kameras, Medizingeräte-Software bis hin zu industriellen Steuerungen, Entwicklungswerkzeugen, Passwortmanagern oder Betriebssystemen.

Der CRA ist seit Ende 2024 im EU-Amtsblatt veröffentlicht und in Kraft; die Pflichten greifen gestaffelt: Die Melde- und Vulnerability-Management-Pflichten gelten 21 Monate nach Inkrafttreten, die übrigen Pflichten nach 36 Monaten – also spätestens Ende 2027 muss das Regelwerk in der Breite erfüllt sein. Wer ab dann Produkte in der EU „in Verkehr bringt“ (Hersteller), importiert (Importeure) oder weiterverkauft (Händler), bewegt sich nur noch innerhalb dieses neuen Spielraums. Das gilt auch für Unternehmen außerhalb der EU, die ihre Soft- oder Hardware hier vermarkten: Sie benötigen einen in der EU ansässigen Bevollmächtigten und unterliegen denselben Regeln.

Man hört es inzwischen auf fast jeder Konferenz und liest es in beinahe jeder Vorstandsvorlage: NIS2 und DORA sind gekommen, um zu bleiben. Zwei europäische Regelwerke, zwei unterschiedliche juristische Instrumente, ein gemeinsames Ziel: Europas digitale Widerstandskraft deutlich erhöhen. Auf den ersten Blick wirken beide wie Geschwister – beide verlangen strukturiertes Risikomanagement, Meldeprozesse, technische und organisatorische Schutzmaßnahmen, Verantwortlichkeit des Managements sowie einen klaren Blick auf die Lieferkette. Wer aber tiefer einsteigt, merkt schnell: Es sind keine Zwillinge, sondern eher zwei präzise Werkzeuge mit unterschiedlicher Klinge. NIS2 spannt den großen Bogen über viele Sektoren und Kategorien kritischer und wichtiger Einrichtungen; DORA wählt den chirurgischen Schnitt in das Betriebssystem der Finanzbranche und ihrer ICT-Dienstleister – inklusive Aufsicht über kritische Drittanbieter. Wer beides gleichzeitig erfüllen muss, steht vor der Aufgabe, Überschneidungen klug zu nutzen und Unterschiede bewusst zu adressieren. Genau darum geht es in diesem Beitrag: Was unterscheidet NIS2 und DORA, wo überlappen sie, und wie setzt man sie mit möglichst wenig Reibungsverlusten um?

Warum jetzt? Das gemeinsame „Warum“ hinter NIS2 und DORA

Beide Regelwerke sind Antworten auf eine Realität, die niemand mehr wegdiskutieren kann: Cyberangriffe sind zum Betriebsrisiko Nummer eins geworden, Lieferketten sind verwundbar, kritische Dienste hängen an digitaler Infrastruktur, die teils über Jahre zu wenig priorisiert wurde. Dazu kommt eine europäische Zielsetzung, Abhängigkeiten zu reduzieren und Mindeststandards hochzuziehen, damit ein Ausfall nicht zum Dominoeffekt wird. NIS2 setzt dabei in der Breite an und will, dass jeder kritische oder wichtige Player in Europa ein Mindestniveau erreicht – von Energie bis Gesundheit, von Verkehr bis Digitalinfrastruktur. DORA nimmt die Finanzbranche in den Fokus, weil operationale Resilienz dort unmittelbar systemrelevant ist: Ein stundenlanger Ausfall von Zahlungsverkehr, Börsenhandel oder Marktinfrastruktur ist weit mehr als eine Unannehmlichkeit.

Es beginnt selten spektakulär. Eine völlig normale Nachricht im gewohnten Ton, mit der richtigen Anrede, im exakt passenden Timing. „Nur schnell freigeben“, „kurzer Login für das neue HR-Portal“, „Bestätigung der Reisekosten“ – nichts, was Angst macht. Und doch steckt dahinter inzwischen eine neue Qualität von Angriffen: Phishing, generiert und gesteuert von Künstlicher Intelligenz.

Die begleitende Grafik „Phishing mittels KI“ oben zeigt den Ablauf in fünf klaren Schritten: Links der Angreifer, der seine Texte und Täuschungen mithilfe von KI erstellt; in der Mitte die Phishing-E-Mail; rechts der Benutzer, der zieltreu adressiert wird; unten die täuschend echte Phishing-Website, die Zugangsdaten einsammelt; und der entscheidende Rückpfeil, über den die erbeuteten Informationen in Echtzeit zum Angreifer fließen. Dieser Datenstrom ist der Moment, in dem aus einer hübschen Nachricht ein Sicherheitsvorfall wird.

Vorstände lieben klare Ampeln. Grün heißt: weiter so. Rot heißt: sofort handeln. Gelb bedeutet: beobachten, vielleicht ein Projekt starten. Eine Business Impact Analyse (BIA) liefert solche Ampelfarben scheinbar auf Knopfdruck. Sie verrät, welche Prozesse kritisch sind, welche Ausfälle schmerzen, welche RTOs und RPOs gelten sollen. Das Dokument ist sauber, die Prioritäten sind sichtbar, man nickt, unterschreibt – und geht zum Tagesgeschäft über. Wochen später kommt die Frage nach dem Budget für neue Kontrollen, redundant ausgelegte Systeme, Pen-Tests oder Backup-Modernisierung. Und plötzlich wirkt die BIA erstaunlich leise. Sie beantwortet nämlich nicht die Fragen, die jetzt wirklich zählen: Wie groß ist das Risiko? Wie wahrscheinlich ist welches Szenario? Welcher Euro investiert reduziert welchen Verlust um wie viel? Was bleibt als Rest­risiko – und ist das mit unserer Risikobereitschaft vereinbar?

Genau an dieser Stelle fehlt in vielen Organisationen der nächste, entscheidende Schritt: die Risk Impact Analysis – kurz RIA. Unter RIA verstehen wir hier die systematische Übersetzung der BIA-Erkenntnisse in quantifizierte Risiken, konkrete Steuerungsoptionen und belastbare Investitionsentscheidungen. BIA beschreibt, was passiert, wenn etwas ausfällt. RIA zeigt, wie oft das realistischerweise passieren kann, wie teuer das im Erwartungswert und in Extremszenarien wird, welche Maßnahmen welchen Risikoeffekt haben und welches Rest­risiko bewusst zu akzeptieren ist. Wer diesen Schritt auslässt, produziert schöne Folien – aber keine Steuerung.

Es gibt Frameworks, die man aus Pflichtgefühl pflegt – und es gibt solche, die den Alltag wirklich verändern. Die CIS Controls gehören zur zweiten Kategorie. Sie sind längst kein Poster mehr an der Bürowand, keine Prüfliste, die man kurz vor einem Audit abhakt, und auch kein exotischer „Nice-to-have“-Standard. Sie sind eine Betriebsanleitung für gelebte Sicherheit: priorisiert, messbar, anschlussfähig an bestehende Governance – und robust genug, um in hybriden Realitäten aus Cloud, SaaS, Remote Work und komplexen Lieferketten zu tragen. Spätestens mit der jüngsten Evolutionsstufe haben die Controls die Grenze zwischen „Security-Projekt“ und „Security-Betrieb“ endgültig verwischt. Wer sie ernst nimmt, arbeitet anders: transparenter, wiederholbarer, nachweisbarer – und vor allem wirksamer.

Vom Poster zur Betriebsanleitung

Die ursprüngliche Stärke der Controls war immer ihre Frechheit der Priorisierung: Statt alles für gleich wichtig zu erklären, benennen sie wenige Hebel, die die meisten Angriffe früh stoppen oder schnell sichtbar machen. Dieses Grundprinzip ist erhalten geblieben – aber die Controls sind erwachsen geworden. Die aktuelle Fassung versteht unter „Asset“ nicht mehr nur die Maschine unterm Schreibtisch, sondern den ganzen Zoo moderner Unternehmens-IT: Cloud-Workloads, containerisierte Dienste, SaaS-Komponenten, mobile Endgeräte, Identitäten und Konfigurationen als eigene Schutzgüter. Dass die offizielle Controls-Liste heute konsequent von 18 Themenfeldern spricht, ist kein Modedetail, sondern die logische Folge dieser Realität. Damit spiegeln die Controls eine Gegenwart, in der Angriffsflächen nicht mehr am Rechenzentrumszaun enden.