DORA 2026-Roadmap für IKT-Risiken, IKT-Drittanbieter und TLPT

Bei der DORA 2026-Suchpanik geht es nicht wirklich um Regulierung, sondern um Nachweise

Es ist 08:15 Uhr an einem Montag, und der CISO eines mittelgroßen Zahlungsinstituts hat drei Browser-Tabs geöffnet: „DORA RTS/ITS-Checkliste“, „DORA IKT-Drittparteienregister-Vorlage“ und „TLPT-Anforderungen Finanzunternehmen“.

Der Compliance-Manager hat bereits gefragt, ob die Unterlagen für das Leitungsorgan den neuesten Workflow zur Vorfallklassifizierung enthalten sollten. Die Beschaffung möchte eine neue Cloud-Analytics-Plattform onboarden. Der COO möchte die Zusicherung, dass der Kernbanking-SaaS-Anbieter keine verdeckte Exponierung durch Unterauftragnehmer außerhalb der EU aufweist. Die Interne Revision fragt nach einem Testkalender. Die Rechtsabteilung fragt, ob die GDPR-Fristen zur Meldung von Datenschutzverletzungen mit der DORA-Meldung von Vorfällen abgestimmt wurden.

Niemand stellt eine theoretische Frage. Die Frage lautet: „Können wir das bis Freitag nachweisen?“

Das ist das eigentliche DORA 2026-Problem. Die meisten Finanzunternehmen verstehen die Hauptpflichten: IKT-Risikomanagement, Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, IKT-Drittparteienrisikomanagement und eine stärkere Überwachung kritischer IKT-Dienstleister. Die Schwierigkeit liegt darin, Regulatory Technical Standards, Implementing Technical Standards und Pflichten auf Artikelebene in kontrollierte, wiederholbare und auditierbare Praxis zu überführen.

Der Digital Operational Resilience Act verpflichtet Finanzunternehmen dazu, belastbare Fähigkeiten für das IKT-Risikomanagement, Richtlinien für das Management und die Meldung IKT-bezogener Vorfälle, Tests von IKT-Systemen, Kontrollen und Prozessen sowie eine strukturierte Überwachung von IKT-Drittdienstleistern aufrechtzuerhalten. Außerdem gilt der Grundsatz der Verhältnismäßigkeit. Eine kleinere Wertpapierfirma und eine große Bankengruppe benötigen keine identischen Nachweismodelle, aber beide müssen belegen, dass ihr Ansatz ihrer Größe, ihrem Risikoprofil, ihrer Komplexität und ihren kritischen Funktionen angemessen ist.

DORA-Projekte scheitern in der Regel aus einem von drei Gründen. Erstens behandelt die Organisation DORA als juristische Mapping-Übung statt als Betriebsmodell. Zweitens wird Lieferantenrisiko als Lieferantenliste dokumentiert statt als Abhängigkeit, Ersetzbarkeit und Konzentrationsrisiko. Drittens wird Testing als jährlicher Penetrationstest betrachtet statt als Resilienzprogramm, das Schwachstellenscans, szenariobasierte Tests, Vorfallsübungen und, sofern anwendbar, threat-led penetration testing umfasst, häufig als TLPT gesucht.

Der bessere Ansatz besteht darin, ein einheitliches Nachweissystem aufzubauen, das Richtlinien, Register, Verantwortliche, Risiken, Vorfälle, Lieferanten, Tests, Wiederherstellung und Managementbewertung verbindet. Genau hier helfen Clarysecs Zenith Blueprint, sofort einsetzbare Richtlinien und Zenith Controls Finanzunternehmen dabei, DORA von einer Frist in einen operativen Rhythmus zu überführen.

Beginnen Sie mit dem DORA-Betriebsmodell, nicht mit der RTS/ITS-Tabelle

Viele Teams beginnen mit einer Tabelle, in der DORA-Artikel und RTS/ITS-Anforderungen aufgeführt sind. Das ist nützlich, aber nicht ausreichend. Eine Tabelle kann zeigen, was vorhanden sein muss. Sie weist jedoch keine Verantwortlichen zu, definiert keine Überprüfungsfrequenz, bewahrt keine Nachweise auf und belegt nicht, dass eine Kontrolle tatsächlich wirksam ist.

Im Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren adressiert Clarysec dies in der Risikomanagementphase, Schritt 14, Richtlinien zur Risikobehandlung und regulatorische Querverweise:

„DORA: Für Unternehmen des Finanzsektors verlangt DORA ein Rahmenwerk für das IKT-Risikomanagement, das sehr eng an dem ausgerichtet ist, was wir umgesetzt haben: Risiken identifizieren, Kontrollen und Richtlinien einrichten und diese testen. DORA legt außerdem besonderen Wert auf Incident Response und Berichterstattung sowie auf die Aufsicht über IKT-Drittdienstleister.“

Die praktische Botschaft ist einfach: Bauen Sie „DORA-Compliance“ nicht als Parallelbürokratie auf. Bauen Sie eine risikobasierte IKT-Governance-Schicht auf, die DORA-Anforderungen Richtlinien, Registern, Kontrollverantwortlichen, Testaufzeichnungen, Lieferantennachweisen und Managementbewertungen zuordnet.

Ein praktikables DORA-Betriebsmodell sollte fünf Nachweissäulen umfassen:

Für regulierte Finanzunternehmen überführt diese Struktur die RTS/ITS-Umsetzung in ein auditbereites Nachweissystem. Für Unternehmen mit vereinfachtem IKT-Risikomanagement kann dasselbe Modell auf weniger Dokumente und einfachere Register skaliert werden. Die Kerndisziplinen bleiben identisch: identifizieren, schützen, erkennen, reagieren, wiederherstellen, testen und Lieferanten steuern.

IKT-Risikomanagement: Das Register ist der Kontrollraum

Die DORA-Erwartungen an das IKT-Risikomanagement verlangen von Finanzunternehmen, IKT-Risiken über Systeme, Daten, Prozesse, kritische oder wichtige Funktionen und Abhängigkeiten von Drittparteien hinweg zu identifizieren, zu klassifizieren und zu steuern.

Der häufige Fehler ist nicht das Fehlen eines Risikoregisters. Der Fehler besteht darin, dass das Register von Lieferanten, Assets, Vorfällen und Tests entkoppelt ist. DORA belohnt keine sauber gestaltete Tabelle, wenn diese nicht erklären kann, warum ein Lieferant mit hohem Risiko keinen Exit-Plan hat oder warum eine kritische Plattform für Kundenzahlungen nicht getestet wurde.

Clarysecs SME-Risikomanagement-Richtlinie bietet kleineren Finanzunternehmen eine knappe Nachweisbasis:

„Jeder Risikoeintrag muss Folgendes enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlicher und Behandlungsplan.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.2.

Für größere Finanzunternehmen verlangt Clarysecs Enterprise-Risikomanagement-Richtlinie einen formelleren Prozess:

„Ein formeller Risikomanagementprozess ist gemäß ISO/IEC 27005 und ISO 31000 aufrechtzuerhalten und muss Risikoidentifizierung, -analyse, -bewertung, -behandlung, -überwachung und -kommunikation abdecken.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.

Diese Unterscheidung ist wichtig. DORA ist verhältnismäßig, aber Verhältnismäßigkeit bedeutet nicht informell. Ein kleines Zahlungsinstitut kann ein schlankes Register verwenden, während eine Bankengruppe integrierte GRC-Werkzeuge einsetzen kann. In beiden Fällen wird der Auditor dennoch fragen: Welche IKT-Risiken haben Sie? Wer ist dafür verantwortlich? Wie lautet der Behandlungsplan? Welche Nachweise zeigen Fortschritte? Wie beeinflussen Lieferanten und kritische Funktionen die Bewertung?

Ein belastbares DORA-IKT-Risikoregister sollte diese Felder enthalten:

Eine praktische Übung besteht darin, einen kritischen IKT-Service, etwa eine Cloud-basierte Plattform zur Transaktionsüberwachung, zu nehmen und innerhalb von 20 Minuten einen Risikoeintrag zu erstellen. Beschreiben Sie das Ausfall- oder Kompromittierungsszenario, bewerten Sie Eintrittswahrscheinlichkeit und Auswirkung, weisen Sie einen Verantwortlichen zu, identifizieren Sie zugehörige Lieferanten, definieren Sie einen Behandlungsplan und verknüpfen Sie den Eintrag mit Nachweisen wie Lieferanten-Due-Diligence, SLA, Vorfallklauseln, BIA, DR-Testergebnissen, Monitoring-Dashboards und Berechtigungsüberprüfung.

Dieser einzelne Eintrag wird zum roten Faden, der DORA-IKT-Risikomanagement, Drittparteienüberwachung, Vorfallserkennung, Kontinuität und Testing verbindet. So wird ein Risikoregister zum Kontrollraum und nicht zum Ablageschrank.

RTS/ITS-Bereitschaft: Pflichten Richtlinien zuordnen, nicht Zusagen

Der praktische Suchbegriff „DORA RTS/ITS-Checkliste“ bedeutet meist: „Welche Dokumente werden Aufsichtsbehörden erwarten?“ Finanzunternehmen sollten vermeiden, Compliance durch generische Aussagen zu versprechen. Sie benötigen eine Zuordnung, die jede Pflicht mit einer Richtlinie, einer Kontrolle, einem Verantwortlichen und einem Nachweis verbindet.

Clarysecs SME-Richtlinie zur rechtlichen und regulatorischen Compliance etabliert einen einfachen Governance-Anker:

„Der GM muss ein einfaches, strukturiertes Compliance-Register führen, das Folgendes auflistet:“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.1.

Für DORA 2026 sollte Ihr Compliance-Register Folgendes enthalten:

• DORA-Pflicht oder RTS/ITS-Anforderungsbereich.
• Anwendbarkeit einschließlich Begründung der Verhältnismäßigkeit.
• Verweis auf Richtlinie oder Verfahren.
• Kontrollverantwortlicher.
• Nachweisablage.
• Überprüfungsfrequenz.
• Offene Lücken und Frist für Abhilfemaßnahmen.
• Status der Berichterstattung an Leitungsorgan oder Management.

Dies entspricht dem Ansatz aus Zenith Blueprint Schritt 14: regulatorische Anforderungen ISMS-Kontrollen und Richtlinien zuordnen, damit nichts durch das Raster fällt. Statt zu fragen „Sind wir DORA-konform?“, kann die Leitung fragen: „Welche DORA-Nachweise sind überfällig, welchen kritischen Lieferanten fehlen Exit-Pläne, und welche Testaktivitäten haben noch keine Nachweise für Abhilfemaßnahmen erzeugt?“

IKT-Drittparteienrisiko: Konzentration, Ersetzbarkeit und Unterauftragnehmer

DORA hat die Lieferantendiskussion im Finanzsektor verändert. Es reicht nicht mehr, zu fragen, ob ein Anbieter über eine Sicherheitszertifizierung, Versicherung oder einen Auftragsverarbeitungsvertrag verfügt. Finanzunternehmen müssen bewerten, ob ein Anbieter ein Konzentrationsrisiko erzeugt, ob er realistisch ersetzt werden kann, ob mehrere kritische Services von einem Lieferanten oder verbundenen Lieferanten abhängen und ob Unterbeauftragungen zusätzliche rechtliche oder resilienzbezogene Exponierungen einführen.

Das ist das Thema, das viele CISOs wachhält. Ein Unternehmen kann sich für Transaktionsverarbeitung, Datenanalysen, Kundenportale und interne Zusammenarbeit auf einen großen Cloud Service Provider stützen. Wenn dieser Anbieter einen längeren Ausfall, eine regulatorische Auseinandersetzung oder den Ausfall eines Unterauftragnehmers erleidet, lautet die Frage nicht nur: „Haben wir einen Vertrag?“ Die Frage lautet: „Können wir kritische Services fortführen, mit Kunden kommunizieren und nachweisen, dass wir die Abhängigkeit vor ihrem Ausfall verstanden haben?“

Clarysecs SME-Richtlinie zur Lieferanten- und Drittparteiensicherheit legt die Grundlage:

„Ein Lieferantenregister muss von der administrativen Ansprechperson oder dem Beschaffungskontakt geführt und aktualisiert werden. Es muss Folgendes enthalten:“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.

Für Enterprise-Programme geht Clarysecs Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten tiefer auf DORA-spezifische Abhängigkeiten und Ersetzbarkeit ein:

„Register für Lieferantenabhängigkeiten: Das VMO muss ein aktuelles Register aller kritischen Lieferanten führen, einschließlich Angaben wie bereitgestellte Services/Produkte, ob es sich um eine Single-Source-Beziehung handelt, verfügbare alternative Lieferanten oder Ersetzbarkeit, aktuelle Vertragsbedingungen sowie eine Bewertung der Auswirkungen, falls der Lieferant ausfällt oder kompromittiert wird. Das Register muss Lieferanten mit hoher Abhängigkeit klar kennzeichnen, z. B. solche, für die keine schnelle Alternative besteht.“
Aus dem Abschnitt „Umsetzungsanforderungen“, Richtlinienklausel 6.1.

Das ist der Lieferantennachweis, den DORA-Projekte häufig übersehen. Ein Lieferantenregister sagt, wer der Lieferant ist. Ein Register für Lieferantenabhängigkeiten sagt, was passiert, wenn der Lieferant ausfällt.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, Organisatorische Maßnahmen, stellt einen praktischen Workflow für Lieferantenüberwachung bereit. Er empfiehlt, eine vollständige Lieferantenliste zu erstellen, Lieferanten anhand ihres Zugriffs auf Systeme, Daten oder operative Kontrolle zu klassifizieren, zu überprüfen, dass Sicherheitserwartungen in Verträgen verankert sind, Unterauftragnehmer- und nachgelagerte Risiken zu steuern, Änderungs- und Überwachungsverfahren zu definieren und einen Bewertungsprozess für Cloud-Services einzurichten.

In Zenith Controls: Der Cross-Compliance-Leitfaden wird ISO/IEC 27002:2022 Maßnahme 5.21, Management der Informationssicherheit in der IKT-Lieferkette, als präventive Kontrolle abgebildet, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist der Sicherheit in Lieferantenbeziehungen und dem Cybersicherheitskonzept Identify zugeordnet. Sie verbindet sich mit sicherem Engineering, sicherer Programmierung, Zugriffskontrolle, Sicherheitsprüfung, Beweissicherung, sicherem Entwicklungslebenszyklus und ausgelagerter Entwicklung.

Genau das ist die DORA-Realität der Drittparteienüberwachung. Lieferantenrisiko ist nicht nur Beschaffung. Es berührt Architektur, Entwicklung, Incident Response, Zugriffskontrolle, Geschäftskontinuität und Recht.

Aus Cross-Compliance-Sicht ordnet Zenith Controls die Sicherheit der IKT-Lieferkette GDPR Articles 28 und 32 zu, weil Auftragsverarbeiter und Unterauftragsverarbeiter mit geeigneten technischen und organisatorischen Maßnahmen ausgewählt und überwacht werden müssen. Es unterstützt die NIS2-Erwartungen an die Sicherheit der Lieferkette, einschließlich Article 21 zu Maßnahmen des Cybersicherheitsrisikomanagements und Article 22 zu koordinierten Risikobewertungen der Lieferkette. Es ist eng mit DORA Articles 28, 29 und 30 verknüpft, in denen IKT-Drittparteienrisiko, Konzentrationsrisiko, Weitervergabe und Vertragsbestimmungen zentral sind.

Unterstützende Standards stärken die Nachweisführung. ISO/IEC 27036-3:2021 unterstützt die Sicherheit bei IKT-Beschaffung und Lieferantenauswahl. ISO/IEC 20243:2018 unterstützt die Integrität vertrauenswürdiger Technologieprodukte und die Sicherheit der Lieferkette. ISO/IEC 27001:2022 verbindet dies mit Risikobehandlung und Lieferantenkontrollen aus Annex A.

Vorfallsmeldung: Die Eskalationskette vor dem Vorfall aufbauen

DORA-Vorfallsmeldung bedeutet nicht nur, eine Meldung einzureichen. Es geht um Erkennung, Klassifizierung, Eskalation, Kommunikation und Lernen aus IKT-bezogenen Vorfällen. Finanzunternehmen müssen Prozesse für IKT-Vorfallmanagement und -meldung aufrechterhalten, mit definierten Rollen, Klassifizierungskriterien, Meldewegen und Nachbetrachtung.

Clarysecs SME-Incident-Response-Richtlinie verbindet Reaktionsfristen für Vorfälle mit rechtlichen Anforderungen:

„Reaktionsfristen, einschließlich Datenwiederherstellung und Benachrichtigungspflichten, müssen dokumentiert und an rechtlichen Anforderungen ausgerichtet sein, etwa an der GDPR-Pflicht zur Meldung einer Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.2.

Für Enterprise-Umgebungen ergänzt Clarysecs Incident-Response-Richtlinie die Perspektive der Eskalation bei regulierten Daten:

„Wenn ein Vorfall zu einer bestätigten oder wahrscheinlichen Offenlegung personenbezogener Daten oder anderer regulierter Daten führt, müssen Recht und DPO die Anwendbarkeit folgender Anforderungen bewerten:“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.1.

Das Zitat endet am Auslösepunkt, und genau dort scheitern viele Vorfallsprozesse. Wenn der Auslöser unklar ist, diskutieren Teams über Meldepflichten, während die Uhr bereits läuft.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 16, People Controls II, betont personalgestützte Vorfallsmeldung. Mitarbeiter, Auftragnehmer und Interessenträger müssen wissen, wie sie potenzielle Sicherheitsvorfälle erkennen und über einfache Kanäle wie ein dediziertes Postfach, ein Portal oder eine Hotline melden. Der Blueprint verknüpft dies mit GDPR Article 33, NIS2 Article 23 und DORA Article 17, weil regulatorische Berichterstattung mit interner Sensibilisierung und Eskalation beginnt.

In Zenith Controls wird ISO/IEC 27002:2022 Maßnahme 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, als korrektive Kontrolle abgebildet, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt und an Respond und Recover ausgerichtet ist. Sie ist direkt mit Ereignisbewertung, Lernen aus Vorfällen, Protokollierung und Überwachung, Sicherheit während Störungen, Aufrechterhaltung der Informationssicherheit und Kontakt mit Behörden verknüpft. Der Leitfaden ordnet dies DORA Articles 17 bis 23 für Management, Klassifizierung und Meldung IKT-bezogener Vorfälle sowie freiwillige Cyberbedrohungsbenachrichtigungen, GDPR Articles 33 und 34 für Meldungen von Datenschutzverletzungen und NIS2 Article 23 für Vorfallbenachrichtigungen zu.

Ein DORA-tauglicher Vorfallsprozess sollte Folgendes umfassen:

• Klare Eingangskanäle für Vorfälle.
• Triage von Ereignissen und Klassifizierungskriterien.
• Eskalations-Workflow für schwerwiegende IKT-bezogene Vorfälle.
• Entscheidungspunkte für Recht, DPO und regulatorische Meldungen.
• Auslöser für Vorfallbenachrichtigungen durch Lieferanten.
• Anforderungen an die Beweissicherung.
• Kommunikationsregeln für Geschäftsleitung und Leitungsorgan.
• Nachbetrachtung und Lessons Learned nach Vorfällen.
• Verknüpfung mit Aktualisierungen des Risikoregisters und Abhilfemaßnahmen für Kontrollen.

Unterstützende Standards schaffen Struktur. ISO/IEC 27035-1:2023 bietet Grundsätze für Planung und Vorbereitung im Vorfallmanagement. ISO/IEC 27035-2:2023 beschreibt Schritte für den Umgang mit Informationssicherheitsvorfällen. ISO/IEC 22320:2018 unterstützt Führung, Steuerung und strukturierte Krisenkommunikation. Das ist relevant, wenn ein IKT-Ausfall zu einer kundenwirksamen Krise wird und das Unternehmen zeigen muss, dass Entscheidungen rechtzeitig, koordiniert und evidenzbasiert getroffen wurden.

Tests der digitalen operationalen Resilienz und TLPT: Der Test darf nicht zum Vorfall werden

Testing ist eines der meistgesuchten DORA 2026-Themen, weil es zugleich technisch und governanceintensiv ist. Finanzunternehmen müssen IKT-Systeme, Kontrollen und Prozesse testen. Für benannte Unternehmen wird fortgeschrittenes Testing wie TLPT zu einer zentralen Anforderung nach DORA Article 26.

Die Auditfrage lautet nicht nur: „Wurde getestet?“ Sie lautet: „War der Test risikobasiert, autorisiert, sicher, wo erforderlich unabhängig, mit Abhilfemaßnahmen versehen und mit Resilienzzielen verknüpft?“

Clarysecs Enterprise-Richtlinie zu Sicherheitstests und Red-Team-Übungen definiert das Mindest-Testprogramm klar:

„Arten von Tests: Das Sicherheitsprüfprogramm muss mindestens Folgendes umfassen: (a) Schwachstellenscans, bestehend aus automatisierten wöchentlichen oder monatlichen Scans von Netzwerken und Anwendungen zur Identifizierung bekannter Schwachstellen; (b) Penetrationstests, bestehend aus manuellen, vertieften Tests bestimmter Systeme oder Anwendungen durch qualifizierte Tester zur Identifizierung komplexer Schwachstellen; und (c) Red-Team-Übungen, bestehend aus szenariobasierten Simulationen realer Angriffe, einschließlich Social Engineering und anderer Taktiken, um die Erkennungs- und Reaktionsfähigkeiten der Organisation insgesamt zu testen.“
Aus dem Abschnitt „Umsetzungsanforderungen“, Richtlinienklausel 6.1.

Das ist die Brücke zwischen Routinetests und TLPT-Reife. Schwachstellenscans finden bekannte Schwachstellen. Penetrationstests validieren Ausnutzbarkeit. Red-Team-Übungen testen Erkennung und Reaktion als System. TLPT sollte, sofern anwendbar, in einem gesteuerten Testprogramm mit Scope-Kontrolle, Sicherheitsregeln, Management von Produktionsrisiken, Nachweiserfassung und Nachverfolgung von Abhilfemaßnahmen verankert sein.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 21, behandelt den Schutz von Informationssystemen während Audits und Tests. Er warnt, dass Audits, Penetrationstests, forensische Prüfungen und operative Bewertungen Risiken einführen können, weil sie erhöhte Berechtigungen, intrusive Werkzeuge oder vorübergehende Änderungen des Systemverhaltens umfassen können. Der Blueprint ordnet dieses Thema GDPR Article 32, den DORA-Erwartungen an Tests der digitalen operationalen Resilienz, NIS2-Belangen der Geschäftskontinuität und COBIT 2019-Praktiken für die sichere Durchführung von Audits und Bewertungen zu.

In Zenith Controls wird ISO/IEC 27002:2022 Maßnahme 5.35, unabhängige Überprüfung der Informationssicherheit, als präventiv und korrektiv abgebildet und unterstützt Vertraulichkeit, Integrität und Verfügbarkeit. Sie ist mit Einhaltung von Richtlinien, Managementverantwortlichkeiten, Lernen aus Vorfällen, Schutz von Aufzeichnungen, Informationslöschung sowie Protokollierung und Überwachung verknüpft. Für DORA liegen die relevanten Testpflichten vor allem in Articles 24 bis 27, einschließlich Article 26 für TLPT. Dies unterstützt außerdem GDPR Article 32(1)(d), der regelmäßige Tests und Bewertungen technischer und organisatorischer Maßnahmen verlangt, sowie NIS2 Article 21, der Maßnahmen des Cybersicherheitsrisikomanagements verlangt.

Ein DORA-TLPT-Bereitschaftspaket sollte Folgendes enthalten:

Die zentrale DORA-Lektion lautet: Testnachweise dürfen nicht beim Bericht enden. Auditoren werden fragen, ob Feststellungen risikobewertet, zugewiesen, behoben und erneut getestet wurden. Sie können außerdem prüfen, ob Tests kritische oder wichtige Funktionen abgedeckt haben und nicht nur internetseitig erreichbare Assets.

Geschäftskontinuität und Disaster Recovery: Resilienz muss operativ sein

DORA ist eine Verordnung zur digitalen operationalen Resilienz. Wiederherstellung ist ebenso wichtig wie Prävention. Ein dokumentiertes IKT-Rahmenwerk für Risikomanagement hilft nicht, wenn ein Ausfall der Zahlungsplattform zeigt, dass Wiederherstellungszeitziele nie getestet wurden, Kontaktketten von Lieferanten veraltet sind und das Krisenteam sich nicht einigen kann, wer mit Kunden kommuniziert.

Clarysecs SME-Richtlinie zur Geschäftskontinuität und Disaster Recovery setzt eine klare Basislinie:

„Die Organisation muss sowohl ihre BCP- als auch ihre DR-Fähigkeiten mindestens jährlich testen. Tests müssen Folgendes umfassen:“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.1.

Die Enterprise-Richtlinie zur Geschäftskontinuität und Disaster Recovery beginnt mit den geschäftlichen Auswirkungen:

„Für alle kritischen Geschäftsbereiche ist mindestens jährlich eine Business Impact Analysis (BIA) durchzuführen und bei wesentlichen Änderungen an Systemen, Prozessen oder Abhängigkeiten zu überprüfen. BIA-Ergebnisse müssen Folgendes definieren:“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.

Für DORA sollte die BIA mit IKT-Assets, Lieferanten, Incident Response und Testing verbunden sein. Wenn die BIA „Kundenzahlungen“ als kritische Funktion identifiziert, sollte das Register für Lieferantenabhängigkeiten die Prozessoren, Cloud-Services und Netzwerkanbieter identifizieren, die diese Funktion unterstützen. Das Risikoregister sollte Ausfallszenarien enthalten. Der Testplan sollte Resilienzvalidierung umfassen. Der Incident Response Plan sollte Eskalation und Kommunikation enthalten. Der DR-Test sollte Nachweise erzeugen, nicht nur ein Sitzungsprotokoll.

Diese Nachvollziehbarkeit macht aus DORA-Compliance ein System für operationale Resilienz.

Cross-Compliance: ein Nachweissatz, viele Auditfragen

Finanzunternehmen stehen selten nur DORA gegenüber. Häufig bestehen auch GDPR-Pflichten, NIS2-Exponierung, vertragliche Sicherheitsverpflichtungen, Ziele aus ISO/IEC 27001:2022, Anforderungen der Internen Revision, Kundendue-Diligence, SOC-Erwartungen und Risikoberichterstattung an das Leitungsorgan. Die Antwort besteht nicht darin, getrennte Nachweissilos zu schaffen. Die Antwort ist ein Cross-Compliance-Nachweismodell.

Zenith Controls ist Clarysecs Cross-Compliance-Kompass. Es erfindet keine neuen Pflichten. Es ordnet offizielle Standards und Rahmenwerke zu, damit Organisationen verstehen können, wie ein Kontrollbereich mehrere Compliance-Ergebnisse unterstützt.

Das ist relevant für Budget und Governance. Ein CISO kann dem Leitungsorgan erklären, dass eine verbesserte Vorfallklassifizierung DORA-Berichterstattung, GDPR-Meldungen von Datenschutzverletzungen, NIS2-Umgang mit Vorfällen und interne Resilienz unterstützt. Eine Beschaffungsleitung kann die Kartierung von Lieferantenabhängigkeiten begründen, weil sie DORA-Konzentrationsrisiko, GDPR-Due-Diligence für Auftragsverarbeiter und NIS2-Lieferkettensicherheit unterstützt. Ein Verantwortlicher für Testing kann zeigen, dass Red-Team-Übungen und unabhängige Überprüfungen DORA-Testing, GDPR-Kontrollbewertung und breitere Assurance unterstützen.

Audit-Perspektive: Wie Assessoren Ihre DORA-Nachweise prüfen werden

DORA-Bereitschaft wird real, wenn jemand Nachweise anfordert. Unterschiedliche Auditoren und Assessoren werden dasselbe Thema aus unterschiedlichen Blickwinkeln betrachten.

Ein an ISO/IEC 27001:2022 orientierter Auditor beginnt mit der ISMS-Logik: Geltungsbereich, Risikobeurteilung, Risikobehandlung, Anwendbarkeit von Annex A-Kontrollen, Internes Audit, Managementbewertung und Nachweise, dass Kontrollen umgesetzt sind. Bei IKT-Lieferkettensicherheit wird er Richtlinien, Lieferantenklassifizierung, Vertragsklauseln, Due Diligence und laufende Überwachung betrachten. Beim Vorfallmanagement wird er Plan, Rollen, Eskalationswege, Werkzeuge und Aufzeichnungen prüfen. Beim Testing erwartet er geplante Intervalle, wo angemessen Unabhängigkeit, Abhilfemaßnahmen und Input für die Managementbewertung.

Eine Audit-Perspektive nach ISO/IEC 19011:2018 konzentriert sich auf die Auditdurchführung. In Zenith Controls weist die Auditmethodik für IKT-Lieferkettensicherheit darauf hin, dass Auditoren Beschaffungsrichtlinien, RFP-Vorlagen und Lieferantenmanagementprozesse prüfen, um zu verifizieren, dass IKT-spezifische Sicherheitsanforderungen von der Beschaffung bis zur Außerbetriebnahme verankert sind. Beim Vorfallmanagement prüfen Auditoren den Incident Response Plan auf Vollständigkeit und Ausrichtung an Best Practices. Bei der unabhängigen Überprüfung suchen Auditoren Nachweise, dass unabhängige Audits oder Überprüfungen durchgeführt wurden.

Eine Perspektive nach ISO/IEC 27007:2020 ist stärker ISMS-auditspezifisch. Zenith Controls weist darauf hin, dass Auditoren Beschaffungsverantwortliche, IT-Sicherheitsmitarbeitende und Lieferantenmanager interviewen können, um Verständnis und Durchführung der IKT-Lieferkettenkontrollen zu bewerten. Für die Vorfallvorbereitung bestätigen sie, dass ein Incident Response Team besteht und einsatzfähig ist. Bei der unabhängigen Überprüfung verifizieren sie, dass das interne Auditprogramm den vollständigen ISMS-Geltungsbereich abdeckt und angemessen ausgestattet ist.

Ein von NIST SP 800-115 informierter Testing-Assessor konzentriert sich auf Methodik für Schwachstellenbewertung und Penetrationstests. Er kann prüfen, ob Testumfang, Einsatzregeln, Feststellungen, Schweregradbewertung, Abhilfemaßnahmen und Retests dokumentiert sind. Für DORA TLPT bedeutet das: Der Assessor wird sich nicht mit einem Red-Team-Foliensatz zufriedengeben. Er will Nachweise für Governance, Sicherheit, technische Tiefe und Abschluss sehen.

Ein Auditor nach COBIT 2019 oder im ISACA-Stil wird fragen, ob Governance-Ziele erfüllt werden: Wer besitzt den Prozess, wie wird Leistung gemessen, wie werden Ausnahmen genehmigt und wie erhält das Management Assurance?

Die praktische DORA 2026-Bereitschaftscheckliste

Nutzen Sie diese Checkliste als Arbeitsbasis, um DORA-Suchanfragen in Maßnahmen zu überführen.

Governance und RTS/ITS-Zuordnung

• Ein DORA-Compliance-Register mit Pflichtbereich, Anwendbarkeit, Verantwortlichem, Nachweis, Überprüfungsfrequenz und Lückenstatus führen.
• DORA-Anforderungen Richtlinien, Registern, Kontrollen und Managementberichterstattung zuordnen.
• Begründung der Verhältnismäßigkeit für vereinfachtes oder skaliertes IKT-Risikomanagement definieren, sofern anwendbar.
• Rechenschaftspflicht der Geschäftsleitung für IKT-Risiko, Vorfallmeldung, Drittparteienüberwachung und Testing zuweisen.
• DORA-Status in Managementbewertung und Risikoberichterstattung an das Leitungsorgan aufnehmen.

IKT-Risikomanagement

• Ein IKT-Risikoregister mit Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichem und Behandlungsplan führen.
• Risiken mit kritischen oder wichtigen Funktionen verknüpfen.
• Risiken mit IKT-Assets, Lieferanten und Prozessen verknüpfen.
• Risiken nach schwerwiegenden Vorfällen, Lieferantenänderungen, Technologieänderungen oder Testfeststellungen überprüfen.
• Behandlungsmaßnahmen bis zum Abschluss oder bis zur formalen Risikoakzeptanz nachverfolgen.

Überwachung von IKT-Drittparteien

• Ein Lieferantenregister und ein Register für Lieferantenabhängigkeiten führen.
• Lieferanten identifizieren, die kritische oder wichtige Funktionen unterstützen.
• Single-Source-Lieferanten und Ersetzbarkeit bewerten.
• Unterauftragnehmer und Weitervergabe prüfen.
• Sicherheits-, Zugriffs-, Vorfallmelde-, Audit- und Exit-Klauseln in Verträge aufnehmen.
• Kritische Lieferanten mindestens jährlich oder nach wesentlichen Änderungen überwachen.
• Exit- und Notfallpläne für Anbieter mit hoher Abhängigkeit aufrechterhalten.

Vorfallmanagement und Berichterstattung

• Incident-Response-Verfahren mit klaren Rollen und Eskalationswegen aufrechterhalten.
• Kriterien für die Klassifizierung von IKT-Vorfällen definieren.
• DORA-Meldeauslöser mit GDPR, NIS2 und vertraglichen Benachrichtigungspflichten abstimmen.
• Mitarbeiter und Auftragnehmer zu Meldekanälen für Vorfälle schulen.
• Vorfallsprotokolle, Entscheidungsaufzeichnungen und Nachweise aufbewahren.
• Nachprüfungen nach Vorfällen durchführen und Risiken sowie Kontrollen aktualisieren.

Testing, Red-Teaming und TLPT

• Einen risikobasierten Testkalender führen.
• Schwachstellenscans und Penetrationstests in definierten Intervallen durchführen.
• Szenariobasierte Red-Team-Übungen nutzen, um Erkennung und Reaktion zu testen.
• Für TLPT-Bereitschaft Geltungsbereich, Einsatzregeln, Sicherheitskontrollen und Lieferantenkoordination definieren.
• Produktivsysteme während Tests schützen.
• Feststellungen, Abhilfemaßnahmen, Retests und Lessons Learned nachverfolgen.
• Testergebnisse an das Management berichten.

Kontinuität und Wiederherstellung

• Jährliche BIA für kritische Geschäftsbereiche durchführen und nach wesentlichen Änderungen aktualisieren.
• Wiederherstellungsziele für kritische Funktionen und unterstützende IKT-Services definieren.
• BCP- und DR-Fähigkeiten mindestens jährlich testen.
• Szenarien zu Lieferantenausfällen und Cybervorfällen einbeziehen.
• Testnachweise, Lücken, Abhilfemaßnahmen und Retest-Ergebnisse aufbewahren.
• Kontinuitätspläne mit Incident Response und Krisenkommunikation abstimmen.

Wie Clarysec Finanzunternehmen vom Suchergebnis zu auditbereiten Nachweisen führt

DORA 2026-Bereitschaft wird nicht erreicht, indem eine Checkliste heruntergeladen und darauf gehofft wird, dass die Organisation Lücken später schließen kann. Sie erfordert ein strukturiertes Betriebsmodell, das Risiken, Lieferanten, Vorfälle, Testing, Kontinuität und Auditnachweise verbindet.

Clarysecs Ansatz kombiniert drei Ebenen.

Erstens stellt der Zenith Blueprint die Umsetzungsroadmap bereit. Schritt 14 hilft Organisationen, regulatorische Anforderungen mit Risikobehandlung und Richtlinien querzuverweisen. Schritt 16 stärkt personalgestützte Vorfallsmeldung. Schritt 21 stellt sicher, dass Audits und Tests Produktivsysteme nicht gefährden. Schritt 23 überführt Lieferantenüberwachung in einen praktischen Workflow, der Klassifizierung, Verträge, Unterauftragnehmer, Überwachung und Cloud-Bewertung abdeckt.

Zweitens bieten Clarysec-Richtlinien sofort operationalisierbare Governance. Die Risikomanagement-Richtlinie, Richtlinie zur rechtlichen und regulatorischen Compliance, Richtlinie zur Lieferanten- und Drittparteiensicherheit, Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten, Incident-Response-Richtlinie, Richtlinie zu Sicherheitstests und Red-Team-Übungen sowie Richtlinie zur Geschäftskontinuität und Disaster Recovery geben Teams konkrete Klauseln, Verantwortungsmodelle und Nachweiserwartungen an die Hand.

Drittens stellt Zenith Controls die Cross-Compliance-Zuordnung bereit. Es zeigt, wie IKT-Lieferkettensicherheit, Planung des Vorfallmanagements und unabhängige Überprüfung mit DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 und NIST-Testpraktiken verbunden sind.

Das Ergebnis ist ein DORA-Compliance-Programm, das im Audit belastbar ist und während eines echten Vorfalls, Lieferantenausfalls oder Resilienztests nützlich bleibt.

Nächster Schritt: Bauen Sie Ihr DORA-Nachweispaket vor der nächsten Audit-Anfrage auf

Wenn Ihr Team noch nach „DORA RTS/ITS-Checkliste“, „DORA IKT-Risikomanagement-Vorlage“, „DORA Drittparteienüberwachung“ oder „DORA TLPT-Anforderungen“ sucht, besteht der nächste Schritt darin, diese Suchanfragen in kontrollierte Nachweise zu überführen.

Beginnen Sie diese Woche mit vier Maßnahmen:

1. Erstellen oder aktualisieren Sie Ihr DORA-Compliance-Register nach dem Clarysec-Richtlinienmodell.
2. Wählen Sie eine kritische Funktion aus und verfolgen Sie sie durch Risikoregister, Register für Lieferantenabhängigkeiten, Vorfalls-Workflow, BIA und Testplan.
3. Prüfen Sie Ihre fünf wichtigsten IKT-Lieferanten auf Ersetzbarkeit, Unterauftragnehmer, Vorfallklauseln und Exit-Optionen.
4. Erstellen Sie ein Testnachweispaket mit Geltungsbereich, Autorisierung, Ergebnissen, Abhilfemaßnahmen und Retests.

Clarysec kann Sie bei der Umsetzung mit dem Zenith Blueprint, Richtlinienvorlagen und Zenith Controls unterstützen, damit Ihr DORA 2026-Programm praktikabel, verhältnismäßig und auditbereit ist.