Dein ISO-27001-Zertifikat startet nicht die Uhren von DORA

Eine gängige Methode, um ein DORA-Programm zu starten, ist die Verwendung einer Tabellenkalkulation. Eine Spalte listet die Anforderungen der Verordnung (EU) 2022/2554 auf, eine weitere die ISO/IEC 27001:2022-Anlage-A-Kontrollen, die das Unternehmen bereits in seinem zertifizierten ISMS umgesetzt hat, und eine dritte Spalte erfasst die Überschneidungen. Wenn die Abbildung abgeschlossen ist, fällt die Überschneidung groß aus: IKT-Risikomanagement, Zugriffskontrolle, Lieferantenmanagement, Business Continuity, Incident-Handling. Der Rest wirkt wie eine reine Schreibübung, die auf ein bestehendes Zertifikat Bezug nimmt.

Doch genau diese Denkweise ist die Falle. Sie ist nicht falsch, was die Überschneidungen betrifft – diese sind tatsächlich vorhanden. Sie ist jedoch falsch, was den Rest angeht. Die Teile von DORA, die ein zertifiziertes ISO-27001-Unternehmen nicht bereits erfüllt, sind nicht einfach nur zu dokumentierende Aufgaben. Einige davon sind Verpflichtungen, die zu einer bestimmten Spezifikation und innerhalb einer festgelegten Frist erfüllt werden müssen – und ein Zertifikat ist das falsche Instrument, um dies nachzuweisen.

Ein Zertifikat bestätigt ein abgegrenztes System; eine Verordnung schreibt Verpflichtungen vor

ISO/IEC 27001:2022 zertifiziert, dass ein Informationssicherheits-Managementsystem (ISMS) mit definiertem Geltungsbereich die Anforderungen der Norm erfüllt. Die Zertifizierung ist kein einmaliger Vorgang: Eine Zertifizierungsstelle stellt das Zertifikat nach einem Audit aus, und es wird in der Regel über einen dreijährigen Zyklus mit Überwachungsaudits und Rezertifizierungen aufrechterhalten. Zwei Dinge begleiten das Zertifikat, die hier relevant sind. Zum einen ist das zertifizierte Objekt ein Managementsystem, das durch die Geltungsbereichserklärung begrenzt ist, und zum anderen ist die Zertifizierungsfrage eine der Konformität: Erfüllt das ISMS die Anforderungen?

DORA ist anders aufgebaut. Sie gilt ab dem 17. Januar 2025 direkt für Finanzunternehmen (Verordnung (EU) 2022/2554), und ihre Bestimmungen sind keine Anforderungen an ein Managementsystem, dem man entsprechen muss, sondern Verpflichtungen, die zu erfüllen sind – einige davon mit festgelegten Fristen und Spezifikationen. Ein gültiges ISO-27001-Zertifikat im definierten Geltungsbereich und mit aktuellem Datum zu besitzen, bedeutet nicht, dass man DORA einhält. Denn das Zertifikat beantwortet eine Frage, die DORA gar nicht stellt. Drei der Verpflichtungen von DORA laufen nach festgelegten Fristen oder erfordern Spezifikationen, die ein Zertifikat nie geprüft hat; eine vierte verschiebt die Verantwortung an eine Stelle, die ein Zertifikat nie überprüft.

Das Register

Artikel 28(3) verlangt von Finanzunternehmen, ein Register über vertragliche Vereinbarungen für die Nutzung von IKT-Dienstleistungen durch IKT-Drittanbieter zu führen und diese Informationen mindestens einmal jährlich an die zuständige Behörde zu melden. Das Register ist ein strukturiertes Artefakt, kein frei formuliertes Dokument: Die Durchführungsverordnung (EU) 2024/2956, veröffentlicht im Amtsblatt am 2. Dezember 2024, legt die Standardvorlagen und Datenfelder fest. Nach den Meldeverfahren der Europäischen Aufsichtsbehörden sammeln die zuständigen Behörden diese Register von beaufsichtigten Unternehmen und leiten sie an die ESAs weiter. Die erste solche Sammlung findet 2025 statt.

Ein zertifiziertes Unternehmen verwaltet seine IKT-Lieferanten bereits über Anlage-A-Kontrollen wie A.5.19 bis A.5.23, die durch die Risikobehandlung ausgewählt und in der Statement of Applicability dokumentiert werden. Doch allein daraus ergibt sich noch kein Register im vorgeschriebenen Schema, das mit den DORA-Datenfeldern gefüllt, mit den tatsächlichen Verträgen abgeglichen und an die Aufsicht im Meldezyklus übermittelt werden kann. Die Verwaltung von Lieferanten und die Erstellung eines spezifischen, strukturierten Artefakts für eine Aufsichtsbehörde sind unterschiedliche Verpflichtungen – und die zweite wird nicht durch die erste nachgewiesen.

Die Vorfallsfrist

Artikel 19 verpflichtet Finanzunternehmen, wesentliche IKT-bezogene Vorfälle an die zuständige Behörde zu melden. Der technische Standard legt dabei die Fristen fest. Die Delegierte Verordnung (EU) 2025/301 vom 23. Oktober 2024 verlangt eine Erstmeldung innerhalb von vier Stunden, nachdem der Vorfall als „wesentlich“ klassifiziert wurde – und spätestens 24 Stunden nach Kenntniserlangung. Anschließend ist innerhalb von 72 Stunden eine Zwischenmeldung und innerhalb eines Monats nach der Zwischenmeldung (oder der letzten aktualisierten Zwischenmeldung) ein Abschlussbericht vorzulegen. Ob ein Vorfall überhaupt „wesentlich“ ist, wird anhand der Klassifizierungskriterien in der Delegierten Verordnung (EU) 2024/1772 entschieden.

Der entscheidende Punkt steht im zweiten Satz: Die vierstündige Frist von DORA beginnt erst mit der Klassifizierung des Vorfalls als „wesentlich“. Das bedeutet, dass eine genaue und zeitnahe Klassifizierung Teil der Verpflichtung ist – und nicht nur eine Voraussetzung dafür. Das unterscheidet sich von den Vorfallsmeldepflichten, die Finanzteams bereits kennen: NIS2 verlangt eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung eines erheblichen Vorfalls (Richtlinie (EU) 2022/2555, Artikel 23), und die DSGVO fordert eine Meldung von Datenschutzverletzungen, die Risiken für die Rechte von Personen bergen, unverzüglich und, soweit möglich, innerhalb von 72 Stunden nach Kenntniserlangung (Verordnung (EU) 2016/679, Artikel 33). Diese Fristen sind nicht austauschbar. Ein zertifiziertes Unternehmen plant, bewertet, reagiert und lernt aus Informationssicherheitsvorfällen gemäß den Anlage-A-Kontrollen A.5.24 bis A.5.27 durch den umgesetzten Prozess – und ein Auditor hat diesen Prozess als konform akzeptiert. Doch die Akzeptanz des Auditors, dass der Prozess konform ist, ist nicht dasselbe, wie wenn dieser Prozess eine korrekt klassifizierte Meldepflicht innerhalb von vier Stunden nach der Klassifizierung erfüllt.

Die Testverpflichtung

Artikel 26 verlangt von Finanzunternehmen, die von ihren zuständigen Behörden aufgrund von Größe, Risikoprofil und systemischer Bedeutung identifiziert werden, mindestens alle drei Jahre bedrohungsgesteuerte Penetrationstests auf Live-Produktionssystemen, die kritische oder wichtige Funktionen unterstützen, durchzuführen. Die drei Jahre sind eine Untergrenze, die die zuständige Behörde anpassen kann. Die detaillierte Methodik und Identifizierungskriterien sind in der Delegierten Verordnung (EU) 2025/1190 festgelegt, die ab dem 8. Juli 2025 gilt. Diese Verpflichtung betrifft nicht jedes Finanzunternehmen, und die Identifizierung obliegt der Aufsicht. Doch für ein betroffenes Unternehmen handelt es sich um eine wiederkehrende, nachweisbare Verpflichtung einer bestimmten Art.

ISO/IEC 27001 verlangt von einem Unternehmen, die Leistung seines ISMS zu überwachen, zu messen und zu bewerten (Klausel 9.1), interne Audits durchzuführen (Klausel 9.2) und Anlage-A-Kontrolle A.8.29 deckt Sicherheitstests in Entwicklung und Abnahme ab. Doch allein daraus ergibt sich nicht der Nachweis für ein intelligenzgestütztes Red-Team-Exercise gegen Produktionssysteme, das in der von DORA vorgegebenen Häufigkeit und nach der Aufsichtsmethodik durchgeführt wird. Ein Unternehmen kann voll zertifiziert sein und trotzdem nie einen solchen Test absolviert haben.

Die Verantwortung, die ein Zertifikat nicht abdeckt

Artikel 5(2) legt der Geschäftsleitung die Verpflichtung auf, den IKT-Risikomanagementrahmen zu definieren, zu genehmigen, zu überwachen und dafür verantwortlich zu sein, und Buchstabe (a) macht sie für das „tragende Risikomanagement des IKT-Risikos“ des Finanzunternehmens verantwortlich. Artikel 5(4) fügt eine persönliche Verpflichtung hinzu: Mitglieder der Geschäftsleitung müssen ihr Wissen und ihre Fähigkeiten so aktuell halten, dass sie IKT-Risiken verstehen und bewerten können. Dies ist die einzige der vier Verpflichtungen, die keine Frist hat. Es handelt sich um eine dauerhafte Governance-Verpflichtung.

ISO/IEC 27001, Klausel 5.1, verlangt bereits die Führung und Verpflichtung der obersten Leitung – daher ist dies der Bereich mit der größten Überschneidung. Die Lücke ist jedoch enger und spezifischer als die Aussage „ISO ignoriert den Vorstand“. DORA legt die endgültige Verantwortung auf die „Geschäftsleitung“ – einen rechtlich definierten Begriff – und schreibt ihren Mitgliedern eine persönliche Kompetenzpflicht vor. Die „oberste Leitung“ nach ISO und die „Geschäftsleitung“ nach DORA sind nicht zwangsläufig dieselben Personen, und ein Zertifikat belegt die Führungsverpflichtung für das ISMS, nicht die Einhaltung von Artikel 5(2)(a) oder 5(4). Ein Zertifikat kann erworben werden, ohne dass jemals die spezifische Verantwortung geprüft wurde, die DORA benennt.

Warum die Abbildung alle vier Punkte verdeckt

Die Tabellenkalkulation scheitert auf eine konsistente Weise: Sie vergleicht Text mit Text, und das zusätzliche Gewicht von DORA liegt nicht nur im Text. Eine Kontrolle lautet: „Die Organisation muss Informationssicherheitsvorfälle managen“ – und genau das steht auch in der ISO-Nachweisdokumentation des Unternehmens, sodass die Zellen übereinstimmen. Doch was die Zelle nicht zeigt, ist, dass DORA einen Referenzpunkt mit einer vierstündigen Frist, ein vorgeschriebenes Registerschema, eine mindestens alle drei Jahre durchzuführende Testverpflichtung und eine rechtlich benannte verantwortliche Stelle an Aktivitäten knüpft, die ISO als Fähigkeiten beschreibt. Zwei Anforderungen können fast identische Formulierungen verwenden und trotzdem durch unterschiedliche Handlungen erfüllt werden – weil die eine fragt, ob ein konformes System innerhalb eines Geltungsbereichs existiert, und die andere, ob eine bestimmte Verpflichtung innerhalb einer Frist erfüllt wurde.

Dies ist der Einwand, der ernst genommen werden sollte – und der viele Programme auf der Dokumentationsschiene hält. Das Argument lautet: Anlage A deckt bereits das Incident-Management, das Lieferantenmanagement und die Tests ab, daher ist DORA dieselbe Substanz mit einer Compliance-Verpackung. Doch die Antwort lautet: Eine Spezifikation und eine Frist sind keine Verpackung um eine Kontrolle. Ein Referenzpunkt, ein Übermittlungsformat, eine anpassbare Testhäufigkeit und eine benannte rechtliche Verantwortung sind neue Verpflichtungen, die das bloße Vorhandensein einer Kontrolle nicht erfüllt – und genau diese werden durch eine Kontrolle-zu-Kontrolle-Abbildung unsichtbar gemacht.

Die Regel, die es zu beachten gilt

Wenn du ein Zertifikat auf eine Verordnung abbildest, dann bilde die operativen Verpflichtungen ab – nicht den Kontrolltext. Ein Zertifikat bestätigt, dass ein Managementsystem eine Norm innerhalb eines Geltungsbereichs über einen Auditzyklus hinweg erfüllt. Eine Verordnung sagt, was dieses System tun muss, nach welcher Spezifikation und bis wann. Wenn beide dasselbe beschreiben, prüfe, ob die Verordnung einen Referenzpunkt mit Frist, ein Format, eine Häufigkeit oder eine benannte Verantwortung hinzugefügt hat – denn genau diese Punkte macht eine Kontrolle-zu-Kontrolle-Abbildung unsichtbar und genau diese werden von einer Aufsichtsbehörde wahrscheinlich geprüft.

Dieses Prinzip lässt sich über DORA hinaus verallgemeinern, auch wenn sich die Details je nach Regelwerk unterscheiden. NIS2 verlangt von den Mitgliedstaaten, sowohl Governance-Verpflichtungen für die Geschäftsleitung (Richtlinie (EU) 2022/2555, Artikel 20) als auch eine 24-Stunden-Frühwarnpflicht (Artikel 23) für Aktivitäten einzuführen, die bereits durch bestehende Kontrollen abgedeckt sind. Der Cyber Resilience Act knüpft zeitlich festgelegte Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle an Hersteller von Produkten mit digitalen Elementen – diese Meldepflichten gelten ab dem 11. September 2026 (Verordnung (EU) 2024/2847, Artikel 14). Die Verantwortungsmodelle sind nicht identisch, aber die Leseweise ist dieselbe: Finde das Verb, finde die Frist oder Spezifikation, und behandle jede Verpflichtung mit einer Deadline oder einem definierten Adressaten als operative Verpflichtung – nicht als zu erstellendes Dokument.

Wenn deine unmittelbare Aufgabe darin besteht, die echten Überschneidungen zwischen ISO 27001 und DORA von den zeitlich festgelegten und spezifizierten Verpflichtungen zu trennen, die ein Zertifikat nicht nachweist, dann ist diese Kreuzreferenzierung mit den tatsächlichen Artikeln und technischen Standards genau die Art von Arbeit, für die ISMS Copilot entwickelt wurde. Eine große Überschneidung in der Abbildung ist real. Sie ist jedoch wiederverwendbares Nachweismaterial, das dennoch einer DORA-spezifischen Validierung bedarf – nicht eine Compliance, die du unverändert übernehmen kannst. Und genau das sollte nicht der Teil sein, der deinen Plan prägt.

Dies ist eine Analyse aus der Praxis zur Compliance und keine Rechtsberatung. Prüfe den Geltungsbereich und die Verpflichtungen deines Unternehmens anhand der Verordnung und ihrer technischen Standards – und wo es darauf ankommt, gemeinsam mit deiner zuständigen Behörde oder deinem Rechtsbeistand.