STOP.LI Bibliothek · Analysen

Ähnlich ist nicht gleich.

DORA, NIS2 und der Cyber Resilience Act verlangen auf den ersten Blick dasselbe: Vorfälle melden, Lieferanten prüfen, Sicherheit testen, Schwachstellen behandeln. Diese Ähnlichkeit verführt dazu, die drei Regelwerke über ein Mapping gleichzusetzen und die Erfüllung einmal nachzuweisen.

Vier Befunde aus dem amtlichen Wortlaut zeigen, warum das nicht trägt — und warum Reifegrad-Bewertungen deshalb regelmässig zu gut ausfallen.

Kurzbewertung

Befund 01 — Gleiche Zahlen, andere Uhren. Alle drei Regelwerke nennen 24 und 72 Stunden. Die Bezugspunkte sind verschieden. Bei NIS2 und CRA läuft die 72-Stunden-Frist ab Kenntnis, bei DORA ab der Erstmeldung — die selbst bis zu 24 Stunden später erfolgen darf. Wer beide Pflichten trägt, führt zwei Uhren mit verschiedenen Startpunkten.

Befund 02 — Offizielle Zuordnungen haben eine klare Grenze. Für NIS2 existiert eine offizielle Zuordnung zu ISO/IEC 27001 und NIST CSF. Für DORA fehlt eine vergleichbare Quelle. DORA benennt an entscheidenden Stellen konkrete Verfahren, während die Normen Ziele formulieren.

Befund 03 — Reifegrad wird an Dokumenten gemessen, nicht an Wirkung. Die häufigsten Überschätzungen folgen einem Muster: Das verlangte Dokument existiert, der ebenfalls verlangte Nachweis seiner Anwendung fehlt. Der Ausstiegsplan ohne Test ist der Musterfall.

Befund 04 — Der CRA lässt sich organisatorisch nicht abbilden. ISO 27001 beschreibt ein Managementsystem der Organisation. Der CRA verpflichtet zu Eigenschaften jedes einzelnen Produkts im Markt. Zwischen beiden liegt kein Mapping-Problem, sondern ein Ebenenwechsel.

Was daraus folgt. Eine belastbare Reifegradaussage verlangt drei Dinge: getrennte Betrachtung je Regelwerk statt eines Sammelnachweises, Artefakte statt Selbsteinschätzung, und eine ausgewiesene Belastbarkeit für jede behauptete Verbindung zwischen Regelwerk und Norm.

Vertiefung

01 · Gleiche Zahlen, andere Uhren

Die Meldefristen wirken harmonisiert. Sie sind es nicht.

Drei Punkte verdienen Aufmerksamkeit.

Erstens steht die DORA-Frist nicht in DORA. Artikel 19 verweist auf Artikel 20, dieser überträgt die Festlegung an technische Regulierungsstandards. Wer nur die Verordnung liest, findet keine einzige Stundenangabe.

Zweitens kennt DORA einen Auslöser, den die anderen beiden nicht haben: die Einstufung als schwerwiegend. Vier Stunden danach ist die Erstmeldung fällig. Und wenn die Einstufung erst später als 24 Stunden nach Kenntnis erfolgt, verschiebt Artikel 5 Absatz 2 der Delegierten Verordnung die Erstmeldung entsprechend nach hinten. Die DORA-Uhr hängt damit an einem Ereignis, das die Einrichtung selbst herbeiführt.

Das macht den Klassifizierungsschritt von einem internen Vorgang zu einem aufsichtsrelevanten. Wer Kenntniszeitpunkt und Einstufungszeitpunkt nicht getrennt und zeitgestempelt protokolliert, kann die Vier-Stunden-Frist nicht nachweisen — auch dann nicht, wenn er sie eingehalten hat. Das ist ein Nachweisproblem, kein Meldeproblem.

Drittens entfällt die Erleichterung dort, wo sie am ehesten gebraucht würde. Die Delegierte Verordnung erlaubt bei Fristende an Wochenenden und Feiertagen eine Meldung bis 12 Uhr des nächsten Arbeitstags — schliesst diese Erleichterung in Absatz 5 aber ausdrücklich für Kreditinstitute, zentrale Gegenparteien, Betreiber von Handelsplätzen und für Unternehmen aus, die zugleich als wesentliche oder wichtige Einrichtung nach NIS2 eingestuft sind.

Praxis-Hinweis. Ein Kreditinstitut, das zugleich wesentliche Einrichtung ist, führt bei einem einzigen Vorfall zwei Meldeketten mit unterschiedlichen Startpunkten, unterschiedlichen Empfängern und ohne Wochenendregel. Diese Konstellation gehört in die Prozessdokumentation, nicht in die Improvisation am Ereignistag.

02 · Wo Mapping trägt und wo es endet

Für NIS2 gibt es eine offizielle Zuordnung: ENISA hat zur Durchführungsverordnung (EU) 2024/2690 eine Mapping-Tabelle veröffentlicht, die jede Anforderung auf ISO/IEC 27001:2022 und NIST CSF 2.0 bezieht. Diese Quelle ist brauchbar — mit drei Einschränkungen, die sie selbst benennt.

Sie ist nach eigenem Disclaimer nicht rechtsverbindlich und rein beratend. Sie beruht laut Fussnote der zugehörigen Guidance auf Angaben der Mitgliedstaaten-Vertreter im NIS-Kooperationsgruppen-Arbeitsstrang, ist also abgestimmte Praxis und keine normative Ableitung. Und sie gilt nur für die Sektoren der Durchführungsverordnung, die NIS2 in Artikel 21 Absatz 5 abschliessend nennt: DNS-Dienste, TLD-Namenregister, Cloud-Computing, Rechenzentren, Content Delivery, verwaltete Dienste und Sicherheitsdienste, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste. Energie, Gesundheit, Verkehr und Produktion fallen nicht darunter. Für sie gilt Artikel 21 inhaltlich gleich — die Tabelle deckt sie nicht ab.

Eine Beobachtung am Rande, die zur Vorsicht mahnt. Der Anhang der Durchführungsverordnung enthält 53 Anforderungspunkte. Die ENISA-Mapping-Tabelle in der Fassung 1.2 listet 49. Vier Punkte — 3.3, 7.2, 7.3 und 9.3 — erscheinen dort nicht als eigene Zeilen. Wer die Tabelle als Anforderungskatalog verwendet statt als Zuordnungshilfe, arbeitet mit einer unvollständigen Liste.

Für DORA fehlt eine vergleichbare Quelle. Die Verordnung konkretisiert die Verfahren deutlich stärker.

Der Unterschied lässt sich an einem Beispiel zeigen. ISO/IEC 27001:2022 verlangt in A.8.8, Informationen über technische Schwachstellen zeitnah zu erlangen, die eigene Exposition zu bewerten und geeignete Massnahmen zu ergreifen. Ein sinnvoll formuliertes Ziel. DORA Artikel 25 Absatz 1 zählt demgegenüber die zu verwendenden Verfahren auf: Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen, Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests.

Dreizehn benannte Verfahren gegen eine Zielformulierung. Wer A.8.8 erfüllt, hat damit weder eine Quellcodeprüfung noch szenariobasierte Tests noch End-to-End-Tests nachgewiesen.

Dazu kommen Vorgaben, für die es in beiden Normen keine Entsprechung gibt: Artikel 24 Absatz 6 verlangt mindestens jährliche Tests für alle Systeme, die kritische oder wichtige Funktionen unterstützen. Artikel 26 verlangt bedrohungsgeleitete Penetrationstests mindestens alle drei Jahre — und Absatz 2 schreibt vor, dass sie an Live-Produktionssystemen durchzuführen sind. Der Ausweg auf eine Testumgebung ist damit versperrt.

Unsere Position. Ein Control-Mapping auf ISO 27001 oder NIST CSF macht Zusammenhänge sichtbar. Es genügt nicht als Nachweis einer DORA-konformen Umsetzung. Der verbindliche Text verlangt konkrete Verfahren, Frequenzen und Einsatzumgebungen. Ein zertifiziertes ISMS bildet dafür eine tragfähige Grundlage; der Erfüllungsnachweis braucht zusätzlich die geforderten Nachweise.

Wir empfehlen deshalb, jede behauptete Verbindung mit einer ausgewiesenen Belastbarkeit zu versehen:

03 · Reifegrad wird an Dokumenten gemessen, nicht an Wirkung

Selbstbeurteilungen fallen zu gut aus, und zwar nach einem erkennbaren Muster. Der verbindliche Text verlangt zwei Dinge: ein Artefakt und den Nachweis seiner Anwendung. Erfasst wird regelmässig nur das Artefakt.

Der Ausstiegsplan ohne Test. DORA Artikel 28 Absatz 8 verlangt für kritische oder wichtige Funktionen Ausstiegsstrategien, deren Pläne „umfassend, dokumentiert und … ausreichend getestet“ sein müssen. Der Plan liegt vor. Der Test fehlt. Die Anforderung ist damit nicht erfüllt — und das lässt sich weder wegdiskutieren noch nachträglich behaupten, weil der Nachweis ein Testprotokoll mit Datum wäre.

Das Register ohne Ausstiegsstrategie. Artikel 28 Absatz 3 verlangt ein Informationsregister über alle Verträge zu IKT-Dienstleistungen, auf Einzel-, teilkonsolidierter und konsolidierter Ebene, mit mindestens jährlicher Meldung an die zuständige Behörde. Häufig existiert eine Vertragsliste aus der Beschaffung. Sie erfüllt weder die Konsolidierungsebenen noch die Verknüpfung mit kritischen Funktionen.

TLPT im Dreijahresrhythmus. Der Nachweis setzt einen durchgeführten Test voraus. Artikel 26 Absatz 2 verlangt die Durchführung an Live-Produktionssystemen.

Die Unabhängigkeit, die nur organisatorisch besteht. Artikel 24 Absatz 4 verlangt Unabhängigkeit der Tester und schliesst Interessenkonflikte in der Konzeptions- und der Durchführungsphase aus. Ein Prüfer, der die getestete Architektur mitentworfen hat, ist in der Konzeptionsphase befangen, auch wenn er in einer anderen Abteilung sitzt.

Das Budget, das genehmigt, aber nicht überprüft wird. DORA Artikel 5 Absatz 2 Buchstabe g verlangt vom Leitungsorgan, angemessene Budgetmittel zuzuweisen und diese regelmässig zu überprüfen. Ein Organ, das Sicherheitsanforderungen genehmigt und die Mittel dafür nicht nachweisbar bereitstellt und nachhält, erfüllt Buchstabe g nicht — unabhängig davon, wie vollständig die Richtlinien sind. Der Nachweis ist das Protokoll, nicht die Richtlinie.

Praxis-Hinweis. Eine Reifegradstufe wird erst erreicht, wenn das zugehörige Artefakt benannt und auffindbar ist. Massgeblich sind Dokument, Protokoll und Zeitstempel. Diese Nachweise führen zu einer belastbaren Bewertung.

04 · Der CRA lässt sich organisatorisch nicht abbilden

Beim Cyber Resilience Act liegt die Herausforderung auf einer anderen Ebene: Er verlangt Eigenschaften jedes einzelnen Produkts.

ISO/IEC 27001 beschreibt ein Managementsystem einer Organisation. Der CRA verpflichtet zu Eigenschaften jedes einzelnen Produkts mit digitalen Elementen, das auf dem Unionsmarkt bereitgestellt wird. Anhang I Teil I Nummer 2 zählt dreizehn solcher Eigenschaften auf — von der sicheren Standardkonfiguration über Datenminimierung und Minimierung der Angriffsflächen bis zur Möglichkeit, alle Daten und Einstellungen sicher zu löschen. Diese Anforderungen richten sich an das Produkt, nicht an den Betrieb.

Drei Besonderheiten fallen auf.

Der CRA kennt eine Veröffentlichungspflicht. Anhang I Teil II Nummer 4 verlangt, nach Bereitstellung einer Sicherheitsaktualisierung Informationen über die behobene Schwachstelle zu teilen und zu veröffentlichen — mit Beschreibung, Schweregrad und verständlichen Hinweisen zur Behebung. Ein interner Patchprozess ohne Advisory-Prozess erfüllt das nicht. Der zulässige Aufschub ist eng gefasst und endet, sobald Nutzer den Patch anwenden konnten.

Artikel 14 behandelt zwei Meldeketten. Die aktiv ausgenutzte Schwachstelle in den Absätzen 1 und 2 und der schwerwiegende Sicherheitsvorfall in den Absätzen 3 und 4 sind eigenständige Tatbestände. Für beide gelten eine 24- und eine 72-Stunden-Kette.

Der Abschluss unterscheidet sich: 14 Tage nach Verfügbarkeit der Korrekturmassnahme bei der Schwachstelle, ein Monat nach Meldung beim Vorfall. Der Prozess muss beide Tatbestände abdecken.

Der Unterstützungszeitraum ist keine IT-Entscheidung. Artikel 13 Absatz 8 verlangt mindestens fünf Jahre, Absatz 19 die klare Angabe des Enddatums bereits zum Zeitpunkt des Kaufs, Absatz 9 die Verfügbarkeit ausgelieferter Sicherheitsaktualisierungen für mindestens zehn Jahre. Das bindet Produktmanagement, Vertrieb und Kalkulation.

Hinzu kommt eine zeitliche Unsicherheit: Zum Redaktionsstand waren die harmonisierten Normen zum CRA noch nicht im Amtsblatt veröffentlicht. Jede Zuordnung zu einer Norm ist deshalb vorläufig.

Was das für die Selbstbeurteilung bedeutet

Aus den vier Befunden ergeben sich drei Konsequenzen für jede Reifegradbewertung, die belastbar sein soll.

01 — Je Regelwerk getrennt bewerten. Ein Sammelnachweis über alle drei Regelwerke verdeckt genau die Stellen, an denen sie auseinanderlaufen. Die Anwendbarkeit ist zuerst zu klären; Mehrfachbetroffenheit ist der Regelfall.

02 — Artefakte abfragen, nicht Einschätzungen. Jede Stufe braucht ein benanntes, auffindbares Nachweisstück. Was nicht belegbar ist, ist nicht erreicht.

03 — Nicht verrechnen. Eine Lücke bei einer Frist- oder Nachweispflicht ist etwas anderes als eine Qualitätsschwäche. Ein gemittelter Gesamtwert verwischt den Unterschied, auf den es ankommt. Sinnvoll ist eine Rangfolge, keine Prozentzahl.

Nach diesen Grundsätzen ist die begleitende Arbeitsvorlage aufgebaut: 149 Anforderungen aus DORA, NIS2 einschliesslich der Durchführungsverordnung (EU) 2024/2690 und dem CRA, jede mit amtlicher Fundstelle, verlangtem Nachweis je Stufe und getrennter Ausweisung von Pflicht- und Reifethemen.

Arbeitsvorlage herunterladen

Excel-Arbeitsmappe (.xlsx, rund 67 KB) mit sieben Blättern: Anleitung, Anwendbarkeitsfilter, Reifegradmodell, Selbstbeurteilung mit 149 Anforderungen, Auswertung, Cross-Mapping zu ISO/IEC 27001 und NIST CSF 2.0 sowie Quellenverzeichnis. Die Auswertung rechnet sich beim Ausfüllen selbst; es werden keine Daten übertragen.

Die Vorlage ist kostenlos und darf frei verwendet und weitergegeben werden. Sie ersetzt keine rechtliche Prüfung; massgeblich bleibt der amtliche Wortlaut in der für Sie geltenden Umsetzung.

Quellen und Grenzen

Massgeblich sind die amtlichen Fassungen. Alle Fundstellen wurden im Volltext auf EUR-Lex geprüft.

• Verordnung (EU) 2022/2554 (DORA), CELEX 32022R2554
• Delegierte Verordnung (EU) 2025/301 — Inhalt und Fristen der Vorfallmeldung, CELEX 32025R0301
• Delegierte Verordnung (EU) 2024/1774 — technische Regulierungsstandards zum IKT-Risikomanagement, CELEX 32024R1774
• Richtlinie (EU) 2022/2555 (NIS2), CELEX 32022L2555
• Durchführungsverordnung (EU) 2024/2690, CELEX 32024R2690
• Verordnung (EU) 2024/2847 (Cyber Resilience Act), CELEX 32024R2847
• ENISA, Technical Implementation Guidance, Version 1.0, Juni 2025
• ENISA, Technical Implementation Guidance Mapping Table, Version 1.2, August 2025, CC BY 4.0
• ISO/IEC 27001:2022 · NIST Cybersecurity Framework 2.0

Diese Analyse ist eine Bewertung, keine Rechtsberatung, keine Zertifizierungsaussage und keine vollständige Umsetzungsanleitung. Nationale Umsetzungsvorschriften können über den EU-Text hinausgehen. Eine Selbstbeurteilung ist kein Kontrolltest; sie ersetzt weder eine interne Revision noch eine aufsichtliche Prüfung.

Stand: August 2026