DORA-Testprogramm: Tests ISO 27001 zuordnen

Es ist Februar 2026. Der CISO eines mittelgroßen Zahlungsinstituts hat in zwei Tagen eine Sitzung des Leitungsorgans, in sechs Wochen ein Überwachungsaudit nach ISO/IEC 27001:2022 und eine DORA-Anfrage der Aufsichtsbehörde im Postfach der Compliance-Funktion.

Die Aufsichtsbehörde verlangt keine glänzende Cyberstrategie. Die Anfrage ist operativ und konkret:

• Legen Sie Ihr Testprogramm für digitale operationale Resilienz 2026 vor.
• Zeigen Sie, welche Tests kritische oder wichtige Funktionen abdecken.
• Weisen Sie nach, wie Feststellungen behoben und erneut getestet werden.
• Belegen Sie die Überwachung durch das Leitungsorgan.
• Erläutern Sie, wie IKT-Drittdienstleister einbezogen werden.
• Stellen Sie Aufzeichnungen zu Schwachstellenbewertungen, szenariobasierten Tests, Leistungs- und Kapazitätstests sowie Penetrationstests bereit.

Der CISO öffnet vier Ordner. Schwachstellenscans liegen im Ticketsystem des SOC. Notizen zu Tabletop-Übungen befinden sich auf einem gemeinsamen Laufwerk. Lasttestergebnisse liegen in der Verantwortung des Engineerings. Penetrationstestberichte liegen im zugriffsbeschränkten Repository der Rechtsabteilung. Die Nachverfolgung von Abhilfemaßnahmen ist auf Jira, E-Mail und eine Tabelle verteilt, die für das ISO-Audit des Vorjahres erstellt wurde.

Nichts davon ist unecht. Vieles ist gute Arbeit. Aber es ist noch kein gesteuertes DORA-Testprogramm für digitale operationale Resilienz. Es ist eine Sammlung von Tests.

Dieser Unterschied ist 2026 wesentlich. DORA gilt seit dem 17. Januar 2025 und schafft einen einheitlichen EU-Rahmen für digitale operationale Resilienz über IKT-Risikomanagement, Meldung von Vorfällen, Resilienztests, Austausch von Informationen über Cyberbedrohungen und Schwachstellen, IKT-Drittparteienrisikomanagement, vertragliche Anforderungen und Aufsicht über kritische IKT-Drittdienstleister. DORA erfasst ein breites Spektrum von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, Wertpapierfirmen, Anbieter von Kryptowerte-Dienstleistungen, Versicherungsunternehmen und andere regulierte Unternehmen. DORA fungiert außerdem als sektorspezifischer Rechtsakt der Union für Finanzunternehmen, die andernfalls gleichwertigen Cybersicherheitsverpflichtungen nach NIS2 unterlägen.

Die praktische Frage für Leitungsorgane, CISOs, Compliance-Manager und IKT-Dienstleister lautet nicht mehr, ob getestet wird. Die Frage lautet, ob Tests geplant, risikobasiert, nachweisbar, mit Abhilfemaßnahmen versehen, überprüft und über DORA und ISO/IEC 27001:2022 hinweg wiederverwendbar sind.

Das Betriebsmodell von Clarysec ist genau für dieses Problem ausgelegt. Mit der Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, der ISO-ausgerichteten Richtliniensuite von Clarysec und Zenith Controls: Leitfaden für Cross-Compliance können Organisationen verstreute Resilienzaktivitäten in einen kontrollierten jährlichen Testkatalog überführen, der Aufsichtsbehörden, Auditoren, Kunden und Leitungsorgane überzeugt.

Warum DORA Tests zu einer Governance-Frage macht

DORA ist hinsichtlich der Verantwortung der Führungsebene eindeutig. Artikel 5 weist dem Leitungsorgan die Verantwortung für das IKT-Risikomanagement zu. Artikel 6 verlangt ein solides, umfassendes und gut dokumentiertes IKT-Risikomanagementrahmenwerk, das in das gesamte Risikomanagementsystem der Organisation integriert ist. Artikel 4 ergänzt den Grundsatz der Verhältnismäßigkeit: Anforderungen sind anhand von Größe, Gesamtrisikoprofil sowie Art, Umfang und Komplexität von Dienstleistungen, Tätigkeiten und Geschäftsbetrieb anzuwenden.

Damit werden Tests der digitalen operationalen Resilienz zu mehr als einer technischen Aufgabe. Sie werden zu Nachweisen dafür, dass das Leitungsorgan Risiken versteht, eine Strategie genehmigt hat, aussagekräftige Berichterstattung erhält und Abhilfemaßnahmen vorantreibt.

ISO/IEC 27001:2022 folgt einer ähnlichen Managementsystemlogik. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation Kontext, interessierte Parteien, gesetzliche und vertragliche Verpflichtungen, Geltungsbereich, Schnittstellen und Abhängigkeiten versteht. Die Abschnitte 5.1 bis 5.3 verlangen Führung, Ausrichtung an Richtlinien, Ressourcen, Kommunikation, zugewiesene Verantwortlichkeiten und Berichterstattung an die oberste Leitung. Abschnitt 6.1 verlangt Informationssicherheitsrisikobeurteilung und Risikobehandlung.

Ein DORA-Testprogramm sollte daher Folgendes miteinander verbinden:

• Geschäftsservices und kritische oder wichtige Funktionen
• IKT-Assets, Daten und Abhängigkeiten von Dritten
• Risikobeurteilung, Risikoverantwortliche und Behandlungspläne
• Testarten, Häufigkeit und Auslöser
• Autorisierung, Unabhängigkeit und Einsatzregeln
• Feststellungen, Fristen für Abhilfemaßnahmen und Wiederholungstests
• Nachweisaufbewahrung und Zugriffskontrolle
• Managementberichterstattung und kontinuierliche Verbesserung

Für kleinere oder risikoärmere Finanzunternehmen sieht Artikel 16 ein vereinfachtes IKT-Risikomanagementrahmenwerk vor. Vereinfacht bedeutet jedoch nicht informell. Auch skalierte Programme benötigen weiterhin dokumentiertes IKT-Risikomanagement, Überwachung, resiliente Systeme, Identifizierung von IKT-Risikoquellen und Anomalien, wesentliche IKT-Drittparteienabhängigkeiten, Kontinuitäts- und Wiederherstellungsmaßnahmen, regelmäßige Tests und Lessons Learned.

Anders gesagt: DORA belohnt nicht die Menge der Tests. DORA belohnt gesteuerte, risikobasierte Tests, die Resilienz für die Services belegen, die am wichtigsten sind.

Was gehört in ein DORA-Testprogramm 2026?

Ein ausgereiftes DORA-Testprogramm sollte als jährlicher Testkatalog betrieben werden. Es sollte nicht auf einen jährlichen Penetrationstest oder einen Stapel von Schwachstellenscan-Exporten beschränkt sein. Es sollte Basis- und fortgeschrittene Tests umfassen, geplant entlang von Risiko, Servicekritikalität, regulatorischen Verpflichtungen, Lieferantenabhängigkeiten, wesentlichen Änderungen und früheren Feststellungen.

DORA Artikel 24 legt das Testprogramm für digitale operationale Resilienz fest. Artikel 25 beschreibt eine Reihe von Tests, darunter Schwachstellenbewertungen und -scans, Open-Source-Analysen, Bewertungen der Netzwerksicherheit, Gap-Analysen, physische Sicherheitsüberprüfungen, Fragebögen, Scan-Softwarelösungen, Quellcodeprüfungen, soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, Ende-zu-Ende-Tests und Penetrationstests. Artikel 26 ergänzt bedrohungsorientierte Penetrationstests für Finanzunternehmen, die von den zuständigen Behörden identifiziert werden.

Für die meisten Organisationen wird der praktische Katalog um vier Testfamilien herum aufgebaut.

Clarysecs Richtlinie zu Sicherheitstests und Red-Team-Übungen bietet einen starken Richtlinienanker für diesen Katalog:

“Testarten: Das Sicherheitsprüfungsprogramm 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, tiefgehenden Tests bestimmter Systeme oder Anwendungen durch qualifizierte Tester zur Identifizierung komplexer Schwächen; 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.”

Dieselbe Richtlinie verlangt eine regelmäßige Planung:

“Testzeitplan: Die Organisation muss Sicherheitstests nach einem regelmäßigen Zeitplan durchführen. Wichtige internetseitig erreichbare Systeme und kritische interne Anwendungen müssen mindestens jährlich Penetrationstests durchlaufen. Risikoreiche Änderungen, wie die Bereitstellung eines neuen kritischen Systems oder wesentliche Upgrades, erfordern Ad-hoc-Tests vor und/oder kurz nach der Produktivsetzung.”

Dies ist für DORA kritisch. Ein statischer Jahresplan reicht nicht aus, wenn das Unternehmen ein neues Zahlungsgateway bereitstellt, ein Kernsystem in die Cloud migriert, einen Managed Service Provider wechselt oder einen neuen Ablauf zur Kundenauthentifizierung veröffentlicht. Risikoreiche Änderungen müssen zusätzliche Tests auslösen.

Den jährlichen Testkatalog als Single Source of Truth aufbauen

Der effizienteste Weg, DORA und ISO/IEC 27001:2022 zu erfüllen, ist ein einziger kontrollierter jährlicher Testkatalog. Er kann in einer GRC-Plattform, einem Ticketing-Workflow oder einer kontrollierten Tabelle geführt werden. Das Format ist weniger wichtig als die Nachvollziehbarkeit.

Jeder Test sollte fünf Auditfragen beantworten:

1. Welcher Service, welches Asset, welcher Lieferant, welche Anwendung oder welcher Prozess wurde getestet?
2. Welches Risiko, welche Verpflichtung oder welche Kontrollanforderung hat den Test ausgelöst?
3. Wer hat den Test autorisiert und durchgeführt?
4. Welche Feststellungen wurden identifiziert, akzeptiert, behoben oder zurückgestellt?
5. Welche Nachweise belegen, dass der Test stattgefunden hat und das Ergebnis überprüft wurde?

Ein praxisnaher Katalog im Clarysec-Stil enthält diese Felder.

Clarysecs P33 – Richtlinie zur Audit- und Compliance-Überwachung – SME gibt eine knappe Governance-Regel vor, die zu dieser Struktur passt:

“Jedes Audit muss einen definierten Geltungsbereich, Ziele, verantwortliches Personal und erforderliche Nachweise umfassen.”

Obwohl dies für Audits formuliert ist, sollte dieselbe Regel für Resilienztests gelten. Wenn ein Schwachstellenscan, eine Tabletop-Übung, eine Failover-Simulation oder ein Penetrationstest keinen definierten Geltungsbereich, kein Ziel, keinen Verantwortlichen und keine erforderlichen Nachweise hat, ist er sowohl unter DORA als auch unter ISO-Auditgesichtspunkten schwach.

Dieselbe Richtlinie legt fest:

“Nachweise müssen mindestens zwei Jahre oder länger aufbewahrt werden, wenn dies durch Zertifizierungen oder Kundenvereinbarungen erforderlich ist.”

Für DORA-regulierte Finanzunternehmen und IKT-Dienstleister sollten zwei Jahre als Untergrenze behandelt werden. Vertragliche Verpflichtungen, Erwartungen der Aufsicht, Zertifizierungszyklen und Untersuchungen von Vorfällen können längere Aufbewahrungsfristen erfordern.

DORA-Testarten ISO 27001-Nachweisen zuordnen

Die Stärke eines integrierten Programms liegt darin, dass ein Test mehrere Verpflichtungen erfüllen kann. Entscheidend ist, Nachweise richtig zu kennzeichnen und mit dem ISMS zu verbinden.

Der Zenith Blueprint erläutert dies in der Phase Audit, Überprüfung und Verbesserung, Schritt 24:

“Ihre SoA sollte mit Ihrem Risikoregister und Ihrem Risikobehandlungsplan konsistent sein. Prüfen Sie nochmals, dass jede Kontrolle, die Sie als Risikobehandlung ausgewählt haben, in der SoA als „anwendbar“ markiert ist.”

Für ein DORA-Testprogramm wird der Testkatalog zur Brücke zwischen Risikobehandlung und operativen Nachweisen. Die Anwendbarkeitserklärung sollte nicht aussagen, dass eine Kontrolle anwendbar ist, während die Testnachweise anderswo liegen, nicht zugeordnet und nicht gesteuert.

Diese Tabelle hilft einem CISO, die häufige Frage des CEO zu beantworten: „Reichen unsere ISO-Penetrationstests und Schwachstellenscans für DORA aus?“

Die Antwort lautet: Sie können Teil der DORA-Compliance sein, aber nur, wenn sie risikobasiert sind, mit kritischen oder wichtigen Funktionen verknüpft sind, durch Richtlinien gesteuert werden, über Abhilfemaßnahmen nachverfolgt und an das Management berichtet werden.

Schwachstellenbewertungen: kontinuierliche Nachweise, nicht nur Scan-Ausgaben

Schwachstellenbewertung ist häufig die am einfachsten durchzuführende und zugleich am leichtesten falsch zu handhabende Testaktivität. Viele Organisationen können Scanberichte vorlegen. Weniger können nachweisen, dass die Scans die richtigen Assets abdecken, kritische Services priorisieren, zeitnahe Abhilfemaßnahmen auslösen und Entscheidungen zur Risikobehandlung speisen.

Clarysecs Richtlinie zum Schwachstellen- und Patch-Management – SME beginnt mit dem richtigen Ziel:

“Bekannte Schwachstellen über alle IT-Assets hinweg zeitnah und konsistent identifizieren und bewerten”

Für DORA unterstützt dies die Identifizierung von IKT-Risikoquellen, resiliente und aktualisierte Systeme, Überwachung, Anomalieerkennung und kontinuierliche Verbesserung. Für ISO/IEC 27001:2022 wird dies direkt 8.8 Management technischer Schwachstellen zugeordnet; außerdem stützt es sich auf 5.9 Inventar von Informationen und anderen zugehörigen Assets, 8.16 Überwachungstätigkeiten und 8.32 Änderungsmanagement.

Eine belastbare Aufzeichnung zur Schwachstellenbewertung sollte enthalten:

• Snapshot des Asset-Inventars, das für die Festlegung des Geltungsbereichs verwendet wurde
• Scandatum, Werkzeug und authentifizierte oder nicht authentifizierte Methode
• Ausschlüsse und geschäftliche Begründung
• Feststellungen nach Schweregrad, Ausnutzbarkeit und Geschäftsservice
• Zuordnung zu kritischen oder wichtigen Funktionen und Datentypen
• Ticketreferenzen und Risikoverantwortlicher
• Abhilfe-SLA und Fälligkeitstermin
• Ergebnis des Wiederholungstests
• Ausnahmen mit Genehmigung des Restrisikos

Zenith Controls positioniert 8.8 Management technischer Schwachstellen als zentralen Nachweisbereich für Identifizierung, Bewertung, Priorisierung und Nachverfolgung von Abhilfemaßnahmen. Außerdem zeigt es, warum Auditoren angrenzende Prozesse prüfen werden. Ist das Asset-Inventar unvollständig, ist die Schwachstellenabdeckung unvollständig. Wird das Änderungsmanagement umgangen, kann die Patch-Bereitstellung neue operationale Risiken erzeugen. Ist die Überwachung schwach, werden Ausnutzungsversuche möglicherweise nicht erkannt.

Szenariotests: Entscheidungsfähigkeit vor dem echten Vorfall nachweisen

Szenariotests machen operationale Resilienz für Führungskräfte sichtbar. Eine Ransomware-Tabletop-Übung, die Simulation eines Ausfalls einer Cloud-Region, eine Übung zur Kompromittierung von privilegiertem Zugriff oder ein Ausfallszenario eines kritischen IKT-Anbieters zeigt Schwächen auf, die ein Scan nicht erkennen kann.

DORA Artikel 17 bis 20 verlangen einen formalen Lebenszyklus für IKT-bezogene Vorfälle: erkennen, steuern, melden, aufzeichnen, überwachen, bearbeiten, nachverfolgen, Ursachenanalyse dokumentieren, Abhilfe schaffen, Schweregrad klassifizieren, Rollen zuweisen, wesentliche Vorfälle eskalieren und über die vorgeschriebenen Stufen berichten. Wenn finanzielle Interessen von Kunden betroffen sind, müssen Kunden ohne unangemessene Verzögerung informiert werden.

NIS2 enthält für Unternehmen in ihrem Geltungsbereich eine ähnliche Dringlichkeit, einschließlich Frühwarnung, Meldung, Zwischenberichterstattung und Abschlussberichterstattung. Für erfasste Finanzunternehmen ist DORA der sektorspezifische Rechtsakt für gleichwertige Pflichten zum Cybersicherheitsrisikomanagement und zur Berichterstattung. IKT-Dienstleister, SaaS-Plattformen, MSPs und MSSPs müssen dennoch prüfen, ob sie direkt in den NIS2-Geltungsbereich fallen oder vertraglich in DORA-Zusicherungen durch regulierte Kunden einbezogen werden.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, gibt das praktische Nachweismodell vor:

“Wählen Sie ein aktuelles Ereignis aus oder führen Sie eine Tabletop-Übung durch, um Ihren Plan zu validieren. Erfassen und protokollieren Sie alle Entscheidungen, Rollen und Kommunikationen (5.26), und aktualisieren Sie den Plan anhand der Lessons Learned (5.27).”

Ein DORA-Szenariotest sollte auditierbare Aufzeichnungen erzeugen, nicht nur Besprechungsnotizen:

• Szenariokurzbeschreibung und Ziele
• Teilnehmende und Rollen, einschließlich Recht, Kommunikation, IT, SOC, Geschäftsinhaber und Lieferantenkontakte
• Zeitachse von Einspielungen und Entscheidungen
• Klassifizierungsentscheidung und Analyse der Meldeschwellen
• Entwürfe interner und externer Kommunikation
• Maßnahmen zur Beweissicherung
• Lessons Learned
• Maßnahmenverantwortliche und Fälligkeitstermine
• Aktualisierte Verfahren für Vorfälle, Kontinuität oder Kommunikation

Clarysecs Richtlinie zu Business Continuity und Disaster Recovery – SME bekräftigt die Erwartung jährlicher Tests:

“Die Organisation muss sowohl ihre BCP- als auch ihre DR-Fähigkeiten mindestens jährlich testen. Tests müssen Folgendes umfassen:”

Der Testkatalog sollte diese Verpflichtung in konkrete Übungen übersetzen, etwa Krisenmanagement-Tabletop, Backup-Wiederherstellungstest, Cloud-Failover-Test, Test der Kontaktkette und Simulation einer Lieferantenstörung.

Leistungs-, Kapazitäts- und Wiederherstellungstests: die vernachlässigten Resilienznachweise

Leistungstests werden häufig als Engineering-Thema behandelt. Unter DORA werden sie zu Resilienznachweisen.

Eine Handelsplattform, ein Zahlungsdienst, ein Schadenbearbeitungssystem, eine Identitätsplattform oder ein Kundenportal benötigt keinen Cyberangriff, um Kunden zu beeinträchtigen. Kapazitätserschöpfung, Sättigung von Warteschlangen, Datenbankengpässe, falsch konfiguriertes Autoscaling oder fehlerhaftes Failover können dieselbe operationale Störung verursachen wie ein Sicherheitsvorfall.

ISO/IEC 27001:2022 Annex A 8.6 Kapazitätsmanagement ist der primäre Anker. Die Nachweise können Lasttests, Stresstests, Tests zum kontrollierten Serviceabbau, Validierung von Infrastrukturschwellen, Backup-Wiederherstellungstests und Failover-Simulationen umfassen.

Eine gute Aufzeichnung zu Leistungs- und Kapazitätstests sollte erfassen:

• Baseline-Annahmen zu Normallast und Spitzenlast
• Getestete kritische Transaktionspfade
• Getestete Infrastruktur- und Cloud-Grenzen
• Monitoring-Dashboards und Alarmschwellen
• Ausfallmodi, etwa Sättigung von Warteschlangen oder Datenbankengpässe
• Relevanz von RTO und RPO, wenn Failover oder Wiederherstellung getestet wird
• Geschäftliche Auswirkungen bei Überschreitung von Schwellenwerten
• Abhilfemaßnahmen, Skalierungsentscheidungen oder Architekturänderungen
• Managementakzeptanz des verbleibenden Kapazitätsrisikos

Der Zenith Blueprint, Schritt 23, verbindet Wiederherstellungserwartungen mit Nachweisen:

“Überprüfen Sie, dass Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) für kritische Systeme mit den Erwartungen an die Aufrechterhaltung des Geschäftsbetriebs übereinstimmen (5.30). Führen Sie mindestens einen technischen Wiederherstellungstest oder eine Failover-Simulation durch und dokumentieren Sie die Ergebnisse.”

Das ist der Unterschied zwischen der Aussage „wir haben Backups“ und dem Nachweis, dass ein kritischer Service innerhalb der vereinbarten Toleranz wiederhergestellt wurde, mit dokumentierten Ergebnissen und Sichtbarkeit für das Management.

Penetrationstests und Red Teaming: starke Nachweise brauchen starke Steuerung

Penetrationstests sind sehr wertvolle Nachweise, bergen aber auch operationale Risiken. Unzureichend gesteuerte Tests können Produktivsysteme beeinträchtigen, sensitive Daten offenlegen, unkontrollierte Alarme auslösen, rechtliche Probleme verursachen oder Kunden stören.

Die Richtlinie zu Anwendungssicherheitsanforderungen – SME setzt ein klares Freigabekriterium:

“Vor der Bereitstellung müssen alle Anwendungen Sicherheitstests durchlaufen, um die oben aufgeführten Baseline-Merkmale zu verifizieren.”

Für kritische Anwendungen sollte dies in den DORA-Katalog einfließen: als Sicherheitsprüfung vor Produktion, Validierung nach Produktivsetzung bei risikoreichen Änderungen und regelmäßige Penetrationstests auf Grundlage von Exponierung und Kritikalität.

Die Richtlinie zu Sicherheitstests und Red-Team-Übungen stärkt die Abhilfekette:

“Behebung von Feststellungen: Alle identifizierten Schwachstellen oder Schwächen müssen in einem Feststellungsbericht mit Schweregradbewertung dokumentiert werden. Nach Eingang des Berichts sind Systemverantwortliche dafür verantwortlich, einen Abhilfeplan mit Fälligkeitsterminen zu erstellen; kritische Feststellungen sind beispielsweise innerhalb von 30 Tagen und Feststellungen mit hohem Schweregrad innerhalb von 60 Tagen gemäß der Schwachstellen- und Patch-Management-Richtlinie der Organisation zu beheben. Der STC muss den Fortschritt der Abhilfemaßnahmen nachverfolgen. Wiederholungstests müssen durchgeführt werden, um zu bestätigen, dass kritische Probleme behoben oder angemessen gemindert wurden.”

Dieselbe Richtlinie definiert Berichtserwartungen:

“Berichterstattung: Am Ende jedes Tests ist ein formaler Bericht zu erstellen. Bei Penetrationstests muss der Bericht eine Management-Zusammenfassung, die Methodik und detaillierte Feststellungen mit unterstützenden Nachweisen und Empfehlungen enthalten.”

Der Zenith Blueprint, Schritt 21, hebt außerdem den Schutz während Audit und Tests hervor:

“Kein Test und kein Audit darf ohne dokumentierte Genehmigung durch Systemverantwortliche oder relevante Interessenträger durchgeführt werden.”

Einsatzregeln, Testfenster, Notfallkontakte, temporärer Zugriff, Datenverarbeitung, Protokollierung, Rollback-Verfahren und rechtliche Genehmigungen sind keine Bürokratie. Sie sind Schutzmaßnahmen für die Resilienz.

IKT-Drittdienstleister einbeziehen, bevor der Test scheitert

DORA macht IKT-Drittparteienrisiken zu einem zentralen Resilienzthema. Artikel 28 verpflichtet Finanzunternehmen, IKT-Drittparteienrisiken innerhalb des IKT-Risikomanagementrahmenwerks zu steuern, bei der Nutzung von IKT-Diensten verantwortlich zu bleiben, ein Informationsregister zu führen, bestimmte Vereinbarungen zu melden, Vorvertragsprüfungen durchzuführen und Anbieter zu nutzen, die geeignete Informationssicherheitsstandards erfüllen. Artikel 29 und 30 behandeln Konzentrationsrisiken, Unterauftragsvergabe, Datenwiederherstellung, vertragliche Schutzmechanismen, Service Levels, Unterstützung bei Vorfällen, Auditrechte, Notfalltests von Anbietern, Beteiligung an Tests, soweit relevant, und Exit-Regelungen.

ISO/IEC 27001:2022 Annex A stellt unterstützende Lieferantenkontrollen bereit, darunter 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten sowie 5.23 Informationssicherheit für die Nutzung von Cloud-Services.

Ein DORA-Testkatalog sollte ausweisen, welche Tests eine Lieferantenbeteiligung oder Lieferantennachweise erfordern. Beispiele:

• Failover-Annahmen des Cloud-Anbieters
• Eskalation durch ein Managed SOC und Beweissicherung
• Vorfallkommunikation einer Kernbankplattform
• Ausfallszenario eines Zahlungsabwicklers
• Wiederherstellungstest eines Identitätsanbieters
• Penetrationstest-Bescheinigungen eines SaaS-Anbieters
• Auswirkungsbewertung der Kette kritischer Unterauftragnehmer

Ein Programm, das kritische IKT-Anbieter ausschließt, besteht den Realitätscheck nicht. Der kundenbezogene Service mag Ihnen gehören, die Resilienzabhängigkeit kann jedoch in einer Cloud-Region, einem ausgelagerten SOC, einem Identitätsanbieter, einem Softwareanbieter, einem Zahlungsabwickler oder einem Rechenzentrum liegen.

Cross-Compliance-Zuordnung: ein Nachweisbestand, viele Verpflichtungen

Ein gut konzipiertes DORA-Testprogramm reduziert Auditmüdigkeit. Dieselben Nachweise können DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 und COBIT 2019-Governance-Überprüfungen unterstützen, wenn sie korrekt gekennzeichnet, aufbewahrt und berichtet werden.

GDPR sollte nicht vergessen werden. Wenn Resilienztests personenbezogene Daten, Protokolle, Kundendatensätze, Identitätsdaten, HR-Aufzeichnungen, biometrische Daten oder besondere Kategorien personenbezogener Daten einbeziehen, muss die Organisation die GDPR-Grundsätze beachten, darunter Rechtmäßigkeit, Fairness, Transparenz, Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Testdatenkopien, exportierte Protokolle und Nachweise aus Penetrationstests können zu regulierten Datenbeständen werden. Das Testprogramm sollte festlegen, wer darauf zugreifen darf, wie lange sie aufbewahrt und wie sie sicher entsorgt werden.

Wie Auditoren dasselbe Programm prüfen werden

Eine DORA-Aufsicht, ein ISO-Auditor, ein NIST-basierter Assessor, ein COBIT-Reviewer und ein Kundenauditor können dieselben Nachweise aus unterschiedlichen Perspektiven prüfen.

Zenith Controls ist hier als Cross-Compliance-Kompass nützlich. Für DORA-Tests hebt Clarysec 5.35 Unabhängige Überprüfung der Informationssicherheit, 8.8 Management technischer Schwachstellen und 8.6 Kapazitätsmanagement als besonders wichtige Anker in ISO/IEC 27001:2022 Annex A hervor. Sie helfen Kontrollverantwortlichen, Tests mit unabhängiger Assurance, Schwachstellenbehandlung und operativer Kapazität zu verbinden.

Clarysecs Informationssicherheitsleitlinie unterstützt ebenfalls den Prüfpfad:

“Kontrollverantwortliche müssen Testergebnisse, Protokolle und Überprüfungsaufzeichnungen aufbewahren, um regelmäßige Audits zu unterstützen.”

Dieser Satz sollte zu einer operativen Regel werden. Jeder Testverantwortliche sollte wissen, was aufzubewahren ist, wo es aufzubewahren ist, wie es zu schützen ist und wie es mit Risiko- und Kontrollnachweisen verknüpft ist.

Ein DORA-zu-ISO-Nachweispaket in einer Woche erstellen

Ein Finanzunternehmen oder IKT-Dienstleister kann in fünf Arbeitstagen erhebliche Fortschritte erzielen.

Tag 1: Geltungsbereich und Kritikalität definieren

Nutzen Sie die Denkweise der ISO/IEC 27001:2022 Abschnitte 4.1 bis 4.4. Identifizieren Sie interessierte Parteien, regulatorische Verpflichtungen, vertragliche Verpflichtungen, Schnittstellen und Abhängigkeiten. Listen Sie Geschäftsservices, kritische oder wichtige Funktionen, wesentliche Assets, Datentypen und IKT-Anbieter auf.

Ergebnis: DORA-Test-Geltungsbereichsregister.

Tag 2: Den jährlichen Testkatalog erstellen

Nutzen Sie die vier Testfamilien: Schwachstellen, Szenario, Leistung und Penetration. Definieren Sie für jeden Service, welche Tests gelten, welche Häufigkeit, welcher Verantwortliche, welches Unabhängigkeitsniveau und welcher Auslöser relevant sind. Nehmen Sie Auslöser für risikoreiche Änderungen auf.

Ergebnis: Testkatalog 2026 für digitale operationale Resilienz.

Tag 3: Kontrollen und Verpflichtungen zuordnen

Ordnen Sie jeden Test ISO/IEC 27001:2022 Annex A, dem Risikoregister, der SoA, DORA-Artikeln, Lieferantenverpflichtungen und relevanten Zenith Controls-Einträgen zu. Monatliche externe Schwachstellenscans werden beispielsweise 8.8 Management technischer Schwachstellen, Risikobehandlung, Überwachung, DORA-IKT-Risikomanagement und NIST CSF-Schwachstellenergebnissen zugeordnet.

Ergebnis: Kontrollzuordnungsmatrix.

Tag 4: Nachweisordner standardisieren

Erstellen Sie eine kontrollierte Nachweisstruktur:

• 01 Plan und Autorisierung
• 02 Geltungsbereich und Einsatzregeln
• 03 Rohdaten
• 04 Abschlussbericht
• 05 Feststellungsregister
• 06 Abhilfetickets
• 07 Nachweise zu Wiederholungstests
• 08 Managementberichterstattung
• 09 Lessons Learned und Richtlinienaktualisierungen

Ergebnis: Nachweisspeicher mit Aufbewahrungsregeln.

Tag 5: Feststellungen und Berichterstattung überprüfen

Konsolidieren Sie offene Feststellungen nach Schweregrad, Service, Risikoverantwortlichem und Fälligkeitstermin. Identifizieren Sie überfällige Abhilfemaßnahmen, akzeptierte Risiken und Lücken bei Wiederholungstests. Erstellen Sie ein Dashboard für das Leitungsorgan, das Testabdeckung, wesentliche Feststellungen, überfällige Maßnahmen, Drittparteienprobleme und Restrisiken zeigt.

Ergebnis: DORA- und ISO-Testdashboard für das Leitungsorgan.

Häufige Fallstricke in DORA-Testprogrammen

Das häufigste Versagen ist nicht fehlendes Testen. Es ist fehlende Governance.

Achten Sie auf diese Themen:

• Penetrationstests werden jährlich durchgeführt, Feststellungen aber nicht bis zum Abschluss nachverfolgt
• Schwachstellenscans laufen häufig, kritische Assets fehlen jedoch im Geltungsbereich
• Tabletop-Übungen finden statt, aber ohne Entscheidungsprotokoll oder Maßnahmenplan aus Lessons Learned
• Backup-Wiederherstellungstests werden abgeschlossen, aber nicht RTO und RPO zugeordnet
• Lasttests werden vom Engineering durchgeführt, aber nicht an Risiko oder Compliance berichtet
• IKT-Anbieter werden aus Szenario- und Wiederherstellungstests ausgeschlossen
• Nachweise werden in persönlichen Ordnern, Chatverläufen oder unverwalteten Laufwerken gespeichert
• Berichte an das Leitungsorgan konzentrieren sich auf Aktivitätszahlen statt auf ungelöste Resilienzrisiken
• Die SoA sagt, dass eine Kontrolle anwendbar ist, aber es existieren keine Testnachweise
• Tests erzeugen Produktionsrisiken, weil Autorisierung und Grenzen unklar sind

Jede Lücke ist lösbar. Die Abhilfe besteht nicht in mehr zufälligen Tests. Die Abhilfe besteht in einem kontrollierten Programm, das Risiko, Testaktivität, Abhilfemaßnahmen, Nachweise und Managementaufsicht verbindet.

Was das Leitungsorgan tatsächlich sehen sollte

DORA macht IKT-Resilienz zur Verantwortung des Leitungsorgans. Ein nützlicher Bericht an das Leitungsorgan sollte nicht jede technische Feststellung enthalten. Er sollte beantworten, ob die Organisation im Verhältnis zu ihrer Risikobereitschaft und Störungstoleranz ausreichend resilient ist.

Ein aussagekräftiger quartalsweiser oder halbjährlicher Bericht umfasst:

• Testabdeckung gegenüber kritischen oder wichtigen Funktionen
• Abgeschlossene gegenüber geplanten Tests
• Kritische und hohe Feststellungen je Service
• Überfällige Abhilfemaßnahmen je Verantwortlichem
• Erfolgsquote von Wiederholungstests
• Lieferantenbezogene Feststellungen und Konzentrationsrisiken
• Erkenntnisse aus Szenariotests mit Auswirkungen auf Krisen- oder Vorfallpläne
• Kapazitätsrisiken gegenüber Geschäftswachstum und Spitzenzeiten
• Restrisiken, die Managementakzeptanz erfordern
• Einschränkungen bei Budget, Ressourcen oder Werkzeugen

Dieser Bericht wird zur Eingabe für die ISO-Managementbewertung, zum DORA-Governance-Nachweis und zu einem praktischen Entscheidungsinstrument.

Von verstreuten Tests zu strategischer Resilienz

Das ursprüngliche Problem des CISO war nicht, dass Tests fehlten. Die Organisation hatte Scans, Tabletops, Lastberichte und Penetrationstest-PDFs. Das Problem war, dass diese Aktivitäten noch keine kohärente Nachweisgeschichte erzählten.

Ein einheitliches DORA- und ISO/IEC 27001:2022-Testprogramm ändert das. Die Risikobeurteilung steuert den Katalog. Der Katalog steuert autorisierte Tests. Tests erzeugen Feststellungen. Feststellungen treiben Abhilfemaßnahmen und Wiederholungstests. Ergebnisse fließen in die Managementberichterstattung ein. Lessons Learned aktualisieren Richtlinien, Verfahren, Verträge und Kontrollen.

So wird aus einer Compliance-Last eine strategische Fähigkeit.

Clarysec hilft Organisationen, parallele Compliance-Programme zu vermeiden. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 und COBIT 2019 benötigen keine getrennten Nachweiswelten. Sie benötigen ein einzelnes, gesteuertes Betriebsmodell, das aus unterschiedlichen Auditperspektiven dargestellt werden kann.

Unser Ansatz kombiniert:

• Den Zenith Blueprint für phasenweise ISO-Implementierung und Auditbereitschaft
• Zenith Controls für Cross-Compliance-Zuordnung über Kontrollen, Rahmenwerke und Auditerwartungen hinweg
• Richtlinien für Unternehmen und KMU zu Sicherheitsprüfungen, Auditüberwachung, Schwachstellenmanagement, Anwendungssicherheit, Kontinuität und Informationssicherheit
• Praxisnahe Register, Nachweisstrukturen und Vorlagen für die Managementberichterstattung

Wenn Ihre DORA-Testnachweise 2026 über Scan-Werkzeuge, Engineering-Ordner, Tabletop-Notizen und Penetrationstest-PDFs verstreut sind, ist jetzt der richtige Zeitpunkt, sie zu konsolidieren.

Beginnen Sie mit einem jährlichen Testkatalog, der der Risikobehandlung nach ISO/IEC 27001:2022, Ihrer SoA, kritischen oder wichtigen Funktionen, IKT-Dritten und der Managementberichterstattung zugeordnet ist. Nutzen Sie anschließend Clarysecs Zenith Blueprint, Zenith Controls und das Richtlinien-Toolkit, um diesen Katalog in belastbare Auditnachweise zu überführen.

Clarysec kann Sie dabei unterstützen, das Programm zu konzipieren, die Kontrollen zuzuordnen, das Nachweispaket zu strukturieren und den Resilienzbericht für das Leitungsorgan vorzubereiten, bevor die nächste Anfrage der Aufsichtsbehörde eingeht.