DORA-Umsetzungs-Roadmap für den CISO: Gap-Analyse, Prioritäten und Nachweisführung

Problem in der Praxis

Mit dem Geltungsbeginn entsteht häufig der Eindruck, die DORA-Umsetzung sei mit dem Stichtag erledigt. Tatsächlich existieren in vielen Häusern Inseln: Ein Register wurde unter Zeitdruck für den ersten Meldetermin zusammengestellt, aber nicht als laufend gepflegter Bestand angelegt. Verträge mit IKT-Dienstleistern wurden inventarisiert, aber nicht systematisch um die geforderten Vertragsbestimmungen nachverhandelt. Beim TLPT herrscht Unklarheit, ob und wann das eigene Haus zu den identifizierten Einheiten gehört. Die Vorfallmeldung ist prozessual beschrieben, aber nicht gegen die konkreten Fristen und Schwellen der technischen Standards geprüft.

Das gemeinsame Muster ist eine Roadmap, die als Projektliste begann und nach dem Stichtag zerfällt. Ohne konsolidierte Gap-Analyse und ohne feste Governance-Taktung bleibt unklar, welche Pflicht erfüllt, welche nur teilweise abgedeckt und welche offen ist. Das Ergebnis ist Compliance-Theater statt nachweisbarer operationaler Resilienz.

CISO-Einordnung

DORA ist eine Verordnung und damit in allen Mitgliedstaaten unmittelbar anwendbar; in Deutschland regeln das Finanzmarktdigitalisierungsgesetz (FinmadiG) mit dem DORA-Durchführungsgesetz vor allem Zuständigkeiten und Durchführung, federführend bei BaFin und Deutscher Bundesbank. Inhaltlich strukturiert sich die Verordnung in fünf Säulen: IKT-Risikomanagement, Behandlung und Meldung IKT-bezogener Vorfälle, Resilienztests einschließlich TLPT, Management des IKT-Drittparteienrisikos und Informationsaustausch.

Die Gap-Analyse ist das Diagnoseinstrument der Roadmap, nicht ihr Ziel. Sie zeigt, wo ein bestehendes ISMS (ISO/IEC 27001, IT-Grundschutz) die DORA-Outcomes bereits trägt und wo echte Deltas bleiben. Typische Deltas sind das Register der Informationen, die Schlüsselvertragsbestimmungen, die standardisierte Klassifizierung und Meldung schwerwiegender Vorfälle, das TLPT für identifizierte Einheiten sowie die ausdrückliche Verantwortung des Leitungsorgans. Die Verordnung sieht durchgängig Proportionalität vor; für bestimmte kleinere Einheiten gilt ein vereinfachter IKT-Risikomanagementrahmen. Die Roadmap muss diese Skalierung abbilden, statt einheitlich maximale Strukturen zu fordern.

Umsetzungsperspektive

Der CISO sollte die Roadmap als wenige, klar getaktete Arbeitsströme führen:

• Gap-Baseline: Die fünf Säulen werden gegen das vorhandene Control-Set abgebildet. Jede Anforderung erhält einen Status (erfüllt, teilweise, offen), einen Owner und einen Nachweisbezug. Ergebnis ist eine gepflegte Lückenliste, nicht eine einmalige Präsentation.
• Register der Informationen: Es wird als lebender Bestand aller vertraglichen Vereinbarungen über IKT-Dienste geführt, an einen Pflegeprozess gebunden und mit dem Vertrags- und Asset-Management verzahnt. Die zuerst abgegebene Fassung ist der Startpunkt der Pflege, nicht ihr Abschluss.
• Vertragsnachverhandlung: Aus dem Register werden die Verträge priorisiert, denen geforderte Bestimmungen fehlen. Maßstab ist die Kritikalität der gestützten Funktion. Die konkreten Pflichtinhalte sind am Verordnungstext und den einschlägigen technischen Standards zu führen.
• TLPT-Scoping: Es wird geklärt, ob das Haus zu den identifizierten Einheiten zählt. Falls ja, wird ein mehrjähriger Testzyklus geplant; die Methodik lehnt sich an TIBER-EU an. Davon zu trennen sind die regelmäßigen Basistests des Testprogramms.
• Vorfallprozess: Klassifizierung, Erst-, Zwischen- und Abschlussmeldung werden gegen die in den technischen Standards festgelegten Fristen und Schwellen geprüft und an den nationalen Melde-Hub angebunden.
• Governance-Anbindung: Status, Lücken und Entscheidungen laufen in einem festen Takt zum Leitungsorgan. Die Nachweisführung entsteht aus diesem Betrieb, nicht als Sammelaktion.

Typische Fehler

1. Die Roadmap endet mit dem Geltungsbeginn, statt in einen Regelbetrieb überzugehen.
2. Das Register wird als einmaliger Meldedatensatz behandelt und nicht als gepflegter Bestand mit Pflegeprozess.
3. Verträge werden inventarisiert, aber die Nachverhandlung der geforderten Bestimmungen wird nicht priorisiert.
4. Beim TLPT wird die Frage der Identifizierung übersprungen; Basistests und TLPT werden vermischt.
5. Konkrete Meldefristen und Klassifizierungsschwellen werden aus zweiter Hand übernommen, statt am einschlägigen technischen Standard verifiziert zu werden.
6. Das Leitungsorgan wird informiert, aber nicht in einem nachweisbaren Takt in Entscheidungen eingebunden.
7. Die Proportionalität wird ignoriert; kleinere Einheiten bauen unnötig schwere Strukturen.

Risiken und Trade-offs

Eine reine Statuszuordnung kann ein vorhandenes ISMS überschätzen: Wer Controls nur formal als erfüllt markiert, ohne ihre Wirksamkeit gegen die DORA-Outcomes zu prüfen, erzeugt eine Scheinabdeckung. Umgekehrt bindet ein vollständiger Neuaufbau Ressourcen, die für die echten Deltas fehlen.

Bei der Priorisierung steht Tempo gegen Tiefe. Vertragsnachverhandlungen sind langwierig und von der Verhandlungsmacht gegenüber großen Anbietern abhängig; eine Konzentration auf wenige kritische Dienstleister kann sinnvoller sein als ein flächiger Ansatz. Beim TLPT ist die Bindung externer Spezialisten und produktionsnaher Tests mit Eigenrisiken verbunden, die gegen den Erkenntnisgewinn abzuwägen sind. Schließlich ist der Umgang mit den als noch zu prüfen geltenden Detailwerten ein Risiko: Wer Meldefristen oder einzelne Termine fest annimmt, ohne sie am verbindlichen Rechtsakt zu verankern, riskiert Fehlsteuerung.

Entscheidungspunkte

• Welcher ISMS-Rahmen dient als Gap-Baseline, und wer verantwortet die laufende Pflege der Lückenliste?
• Fällt das Haus unter den vereinfachten Rahmen, und wie skaliert die Roadmap entsprechend?
• Nach welchem Kriterium werden Verträge für die Nachverhandlung priorisiert, und wer führt sie?
• Zählt das Haus zu den für TLPT identifizierten Einheiten, und wie wird der Testzyklus geplant?
• In welchem Takt und mit welchen Inhalten wird das Leitungsorgan eingebunden und die Entscheidung dokumentiert?
• Welche Nachweise entstehen automatisch im Prozess, und welche müssen bewusst erzeugt werden?

Praktische Empfehlungen

1. Führen Sie die Gap-Analyse als gepflegte Lückenliste mit Status, Owner und Nachweisbezug, nicht als einmalige Bestandsaufnahme.
2. Behandeln Sie das Register der Informationen als lebenden Bestand und verzahnen Sie es mit Vertrags- und Asset-Management.
3. Priorisieren Sie die Vertragsnachverhandlung nach Kritikalität der gestützten Funktion und führen Sie die Pflichtinhalte am Verordnungstext und den technischen Standards.
4. Klären Sie die TLPT-Identifizierung früh und trennen Sie TLPT sauber von den regelmäßigen Basistests.
5. Verifizieren Sie Meldefristen und Klassifizierungsschwellen am einschlägigen technischen Standard und binden Sie den Prozess an den nationalen Melde-Hub.
6. Verankern Sie die Verantwortung des Leitungsorgans in einem festen Berichts- und Entscheidungstakt und machen Sie Nachweise zum Nebenprodukt des Betriebs.
7. Skalieren Sie die Roadmap nach Größe, Risikoprofil und Komplexität entlang der Proportionalität der Verordnung.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554: unmittelbar geltendes EU-Recht; verbindliche Details über EUR-Lex und die technischen Standards (RTS/ITS) der ESAs.
• Technische Standards (RTS/ITS) des Joint Committee aus EBA, EIOPA und ESMA: maßgeblich für Vorfallklassifizierung und -meldung, Register der Informationen, TLPT und Vertragsbestimmungen.
• Nationale Durchführung in Deutschland: Finanzmarktdigitalisierungsgesetz (FinmadiG) mit DORA-Durchführungsgesetz; Zuständigkeit bei BaFin und Deutscher Bundesbank.
• ISO/IEC 27001 sowie IT-Grundschutz als ISMS-Umsetzungsrahmen: nutzbar zur Abbildung, kein Ersatz für DORA-Pflichten.
• NIST Cybersecurity Framework als Outcome- und Control-Bezugsrahmen (Mapping möglich, nicht normativ).