Praxisorientierte Einordnung zu Digital Operational Resilience Testing: Testprogramm risikobasiert aufbauen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für DORA aufbauen.
Digital Operational Resilience Testing unter DORA ist mehr als ein jährlicher Penetrationstest. Das Finanzunternehmen benötigt ein dauerhaftes, risikobasiertes Programm, das technische Kontrollen, Geschäftsfortführung, Wiederherstellung und kritische oder wichtige Funktionen über den gesamten IKT-Lebenszyklus prüft. Threat-Led Penetration Testing bildet nur die fortgeschrittene Stufe für von der Aufsicht identifizierte Unternehmen.
Artikel 24 bis 27 DORA definieren den Rahmen. Die Delegierte Verordnung (EU) 2025/1190 konkretisiert TLPT seit Juni 2025 und orientiert sich an TIBER-EU. Ein wirksames Programm verbindet Asset- und Funktionskritikalität, Bedrohungslage, Veränderungen, Vorfälle und Drittparteienabhängigkeiten mit klaren Testzielen, unabhängiger Durchführung und konsequenter Mängelbehebung.
Das Ziel: Resilienz statt Schwachstellenmenge
Tests sollen Vorbereitung auf IKT-Vorfälle bewerten, Schwächen und Lücken erkennen und Korrekturen auslösen. Die entscheidende Frage lautet nicht, wie viele Findings erzeugt wurden, sondern ob kritische Finanzfunktionen bei Störung sicher fortgeführt, wiederhergestellt und überwacht werden können.
Eine reine Scannerquote kann ein gutes Sicherheitsniveau vortäuschen. Sie prüft weder Krisenentscheidungen noch Datenwiederherstellung, Anbieterkommunikation oder fachliche Integrität. Das Programm kombiniert deshalb technische, prozessuale und szenariobasierte Methoden.
Wer ein umfassendes Testprogramm benötigt
Finanzunternehmen außerhalb der Mikro-Unternehmensausnahme müssen ein solides und umfassendes Testprogramm aufbauen, pflegen und überprüfen. Proportionalität berücksichtigt Größe, Risikoprofil sowie Art, Umfang und Komplexität. Für Unternehmen im vereinfachten Rahmen gelten angepasste, aber weiterhin wirksame Testanforderungen.
Die Betroffenheitsentscheidung und der angewandte Rahmen werden dokumentiert. Proportionalität darf nicht als pauschale Reduktion verstanden werden. Eine kleine Einrichtung mit hochkritischer digitaler Leistung kann intensive Tests benötigen.
Kritische oder wichtige Funktionen als Ausgangspunkt
Alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, müssen mindestens jährlich angemessen getestet werden. Daher benötigt das Testprogramm eine konsistente Verbindung zwischen Funktion, Prozess, Asset, Dienstleister und Testobjekt.
Die Funktionslandkarte wird mit BIA, Informationsregister und Architektur abgeglichen. Fehlt ein Anbieter oder System in der Testplanung, muss begründet sein, warum sein Ausfall die Funktion nicht beeinträchtigt. So werden blinde Flecken sichtbar.
Ein risikobasiertes Testuniversum erstellen
Das Testuniversum enthält Anwendungen, Infrastruktur, Netzwerke, Daten, Schnittstellen, physische Komponenten, Prozesse und Drittanbieterdienste. Für jedes Objekt werden Kritikalität, Bedrohungen, Änderungen, Vorfälle, bekannte Schwächen, letzte Tests und Abhängigkeiten erfasst.
Aus diesen Faktoren entsteht eine mehrjährige Planung. Hohe Kritikalität, große Veränderung oder wiederholte Findings erhöhen Tiefe und Frequenz. Ein stabiler, niedrigkritischer Dienst kann mit leichteren Methoden angemessen abgedeckt werden.
Methodenportfolio statt Einheitsprüfung
Artikel 25 nennt unter anderem Schwachstellenanalysen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Gap-Analysen, physische Sicherheitsprüfungen, Fragebögen, Quellcodeprüfungen, Szenario-, Kompatibilitäts-, Leistungs-, Ende-zu-Ende- und Penetrationstests.
Methoden werden nach Testziel kombiniert. Ein Onlinebanking-Release benötigt beispielsweise Code- und Konfigurationstests, Schnittstellen- und Leistungstest, Sicherheitsprüfung sowie Wiederanlaufszenario. Ein Fragebogen allein wäre nicht geeignet.
Testziele messbar formulieren
„System ist sicher“ ist kein prüfbares Ziel. Besser sind konkrete Aussagen: Unberechtigte Rollen können keine Zahlungen freigeben; Wiederherstellung erreicht RTO und RPO; ein kompromittiertes Administratorkonto wird innerhalb definierter Zeit erkannt; ein Cloudausfall löst den freigegebenen Ersatzprozess aus.
Jedes Ziel besitzt Erfolgsmaß, Scope, Voraussetzungen und Abbruchkriterien. Ergebnisse werden auf die unterstützte Funktion bezogen. Technischer Erfolg ohne fachliche Verarbeitung gilt nicht als vollständiger Nachweis.
Unabhängigkeit und Interessenkonflikte
DORA verlangt unabhängige interne oder externe Tester. Bei interner Durchführung sind ausreichende Ressourcen und die Vermeidung von Interessenkonflikten sicherzustellen. Wer eine Kontrolle entwickelt und betreibt, sollte ihre Wirksamkeit nicht allein abschließend bewerten.
Das Testmandat dokumentiert organisatorische Trennung, Berichtslinie und Eskalation. Fachliche Eigentümer unterstützen, können Findings aber nicht ohne nachvollziehbare Begründung entfernen. Kritische Ergebnisse gelangen an Risikofunktion und Leitungsorgan.
Testdaten und Produktionsnähe sicher gestalten
Realistische Tests benötigen repräsentative Daten, Last und Abhängigkeiten. Personenbezogene oder vertrauliche Produktivdaten werden nur verwendet, wenn dies rechtlich und technisch beherrscht ist. Synthetische Daten müssen relevante Sonderfälle und Volumen abbilden.
Produktionsnahe Tests erhalten Freigabe, Überwachung, Wartungsfenster und Abbruchplan. Backups und Wiederherstellung sind vorbereitet. Die Sicherheitsmaßnahmen des Tests dürfen keine größere Betriebsgefahr erzeugen als die zu prüfende Schwäche.
Schwachstellen- und Konfigurationstests
Automatisierte Scans liefern Breite, aber nicht automatisch korrekte Risikobewertung. Assetabdeckung, Authentisierung, Aktualität der Prüfsignaturen und Ausnahmen werden gemessen. Ergebnisse werden mit Exponierung und Funktionskritikalität priorisiert.
Konfigurationstests vergleichen Baselines für Betriebssystem, Cloud, Netzwerk, Identitäten und Sicherheitstools. Stichproben prüfen die reale Einstellung. Wiederholte Abweichungen weisen auf schwaches Konfigurationsmanagement hin und verlangen Ursachenbehebung.
Sichere Entwicklung und Codeprüfung
Wo praktikabel, umfasst das Programm Quellcodeanalyse, Abhängigkeitsprüfung, Secret Detection und manuelle Review kritischer Logik. Sicherheitsanforderungen werden vor Entwicklung festgelegt, nicht erst nach Fertigstellung getestet.
Release-Gates berücksichtigen Schweregrad, Ausnutzbarkeit und Geschäftswirkung. Ausnahmeprozesse sind befristet. Nach wesentlichen Änderungen werden betroffene Tests wiederholt, selbst wenn der jährliche Zyklus noch nicht fällig ist.
Ende-zu-Ende-Tests kritischer Funktionen
Ein Ende-zu-Ende-Test folgt einer realen Finanzleistung durch Frontend, Schnittstellen, Kernsystem, Daten, Kontrollschritte und externe Partner. Er prüft nicht nur Verfügbarkeit, sondern Authentizität, Integrität, Vertraulichkeit und korrekte Verarbeitung.
Beispielsweise wird eine Zahlung vom Auftrag bis zur Verbuchung einschließlich Betrugsprüfung, Clearing, Kundeninformation und Rückfallweg getestet. Beobachtungen decken Übergabefehler auf, die Komponententests nicht erkennen.
Leistungs- und Kapazitätstests
Resilienz erfordert, Lastspitzen und reduzierte Kapazität zu beherrschen. Tests modellieren hohe Transaktionsvolumen, verzögerte Drittanbieterantworten, Teilausfall und Wiederanlauf. Kapazitätsgrenzen werden gegen Geschäftsprognose und Notfallszenarien bewertet.
Ein System kann im Normalbetrieb schnell sein und beim Failover unzureichende Leistung besitzen. Deshalb wird auch die sekundäre Umgebung über einen ausreichenden Zeitraum unter Last getestet. Engpässe erhalten konkrete Skalierungs- oder Priorisierungsmaßnahmen.
Business-Continuity- und Recovery-Tests
Der technische Standard verlangt schwere, aber plausible Szenarien und die Einbeziehung von Drittanbieterdiensten, wenn relevant. Umschaltung, Backups, redundante Einrichtungen und Rückkehr zur Primärumgebung werden praktisch bewertet.
Testpläne beruhen auf BIA und IKT-Risikoanalyse. Sie prüfen Aktivierung, Rollen, Kommunikation, manuelle Verfahren, Datenkonsistenz und Wiederaufnahme kritischer Funktionen. Festgestellte Mängel werden dem Leitungsorgan berichtet.
Tabletop-Übungen richtig einsetzen
Tabletops eignen sich für Managemententscheidung, Vorfallklassifizierung, BaFin-Meldung, Kundenkommunikation und Dienstleisterkoordination. Ein dynamisches Szenario liefert Informationen schrittweise und erzeugt Zielkonflikte. Teilnehmer müssen entscheiden, statt vorbereitete Folien vorzutragen.
Messpunkte sind Zeit bis Eskalation, Qualität der Lage, Vollständigkeit der Meldedaten und Umsetzbarkeit von Entscheidungen. Maßnahmen werden Eigentümern zugewiesen und später nachgetestet.
Drittanbieter in das Programm einbeziehen
IKT-Drittdienstleister unterstützen viele kritische Funktionen. Verträge müssen Tests, Informationen, Audit und Zusammenarbeit ermöglichen. Testkalender werden abgestimmt, ohne allein auf Standardberichte des Anbieters zu vertrauen.
Für gemeinsame Cloud- oder Plattformdienste können Servicefailover, Wiederherstellung, Identitätsausfall und Incident-Kommunikation geprüft werden. Das Finanzunternehmen behält Verantwortung für seine Funktion, auch wenn technische Maßnahmen ausgelagert sind.
Findings priorisieren und beheben
Artikel 24 verlangt Verfahren zur Priorisierung, Klassifizierung und Behebung aller Testfeststellungen sowie interne Validierung der vollständigen Schließung. Risikobewertung berücksichtigt Funktion, Ausnutzbarkeit, Reichweite, Daten und vorhandene Kompensation.
Ein Ticketstatus „geschlossen“ genügt nicht. Ein unabhängiger Retest belegt die Korrektur. Ursachenanalyse verhindert, dass dasselbe Muster in anderen Systemen fortbesteht. Akzeptierte Risiken sind befristet, genehmigt und überwacht.
Testabdeckung und Wirksamkeit berichten
Kennzahlen unterscheiden geplante und ausgeführte Tests, Funktionsabdeckung, kritische Findings, Zeit bis Behebung, Wiederholungsfehler und erreichte Recovery-Ziele. Eine hohe Zahl von Tests ist ohne Aussage zur Kritikalität wenig wert.
Das Leitungsorgan erhält Trends, Blocker und Entscheidungen. Berichte zeigen, welche kritischen Funktionen noch keinen wirksamen Ende-zu-Ende- oder Recovery-Test besitzen. Budget wird auf reale Resilienzlücken gelenkt.
Wann TLPT erforderlich wird
TLPT betrifft nicht automatisch jedes Finanzunternehmen. Die zuständige TLPT-Behörde identifiziert Unternehmen anhand DORA und der Delegierten Verordnung (EU) 2025/1190. Die Verordnung nennt Kategorien und Kriterien, berücksichtigt aber auch Wirkung, Finanzstabilität und IKT-Risikoprofil.
Betroffene Unternehmen führen mindestens alle drei Jahre einen bedrohungsgeleiteten Test durch. Eine Behörde kann je nach Risikoprofil Frequenz und Anforderungen beeinflussen. Der Status wird aktiv mit der zuständigen Stelle geklärt.
Was TLPT von einem normalen Penetrationstest unterscheidet
TLPT simuliert Taktiken, Techniken und Verfahren realer Bedrohungsakteure gegen produktionsnahe kritische Funktionen. Ein Threat-Intelligence-Team entwickelt relevante Szenarien, ein Red Team führt sie kontrolliert aus und ein kleines Control Team schützt Geheimhaltung und Betrieb.
Ziel ist die Prüfung von Prävention, Erkennung und Reaktion über Menschen, Prozesse und Technik. Der Test ist mehrphasig, aufsichtsbegleitet und endet mit Ergebnisabgleich, Sanierungsplan, Abschluss und gegebenenfalls Anerkennung durch andere Behörden.
TLPT-Governance vorbereiten
Die Delegierte Verordnung 2025/1190 konkretisiert Auswahl von Threat-Intelligence- und Red-Team-Anbietern, Kontrollteam, Scope, Methodik, Risiko, Ergebnis und Sanierung. Tester müssen die Anforderungen aus Artikel 27 DORA erfüllen; die Behörde kann ungeeignete Anbieter ablehnen.
Das Finanzunternehmen definiert vorab Beschaffung, Vertraulichkeit, Haftung, sichere Kommunikation, Krisenabbruch und Beweisschutz. Interne Tester sind nur unter zusätzlichen Unabhängigkeits- und Eignungsbedingungen möglich.
Scope kritischer Funktionen bei TLPT
Der TLPT-Scope umfasst mehrere oder alle kritischen oder wichtigen Funktionen und die ihnen zugrunde liegenden Live-Produktionssysteme. Wesentliche IKT-Drittdienstleister können einbezogen werden. Ausschlüsse benötigen eine belastbare Begründung und Abstimmung.
Eine technische Systemliste reicht nicht. Geschäftsprozesse, Benutzer, Standorte, Identitäten und Anbieterbeziehungen werden berücksichtigt. White-Team-Informationen bleiben auf den notwendigen Personenkreis begrenzt, damit Reaktion realistisch bleibt.
Von TLPT-Findings zur nachhaltigen Verbesserung
Nach dem Test werden Beobachtungen von Angriffs- und Verteidigungsteam abgeglichen. Findings erhalten Ursache, Wirkung, Verantwortlichen und Sanierungsfrist. Maßnahmen behandeln nicht nur den konkreten Exploit, sondern schwache Prozesse und Erkennungsketten.
Die Behörde erhält die vorgesehenen Ergebnis- und Abschlussinformationen. Lessons Learned fließen in allgemeines Testprogramm, Risikoanalyse, Architektur und Drittparteiensteuerung ein. TLPT ist kein prestigeträchtiges Einzelprojekt, sondern ein Lernzyklus.
Ein jährlicher Planungszyklus
- Testuniversum, Funktionen, Assets, Anbieter und Vorjahresfindings aktualisieren.
- Risiko und regulatorische Mindestfrequenzen in eine priorisierte Testmatrix überführen.
- Methoden, Unabhängigkeit, Ressourcen, Daten und Schutzmaßnahmen festlegen.
- Tests durchführen, Findings validieren und Funktionswirkung bewerten.
- Behebung nachverfolgen und durch Retests bestätigen.
- Abdeckung, Wirkung und neue Risiken an Leitungsorgan und Risikofunktion berichten.
Typische Schwächen in DORA-Testprogrammen
Häufig werden alle Systeme gleich behandelt, obwohl Kritikalität und Bedrohung stark variieren. Andere Programme zählen Schwachstellenscans als jährlichen Test jeder kritischen Anwendung, ohne Geschäfts- oder Recovery-Szenario. Drittanbieter bleiben außerhalb des Testuniversums.
Weiter problematisch sind Findings ohne Retest, Tests nur in unrealistischen Laborumgebungen und TLPT-Vorbereitung erst nach Behördenaufforderung. Ein reifes Programm verbindet tägliche Kontrollprüfung, jährliche Funktionsabdeckung und fortgeschrittene Tests.
Fazit: Testen muss die Finanzfunktion beweisen
DORA verlangt ein Testprogramm, das reale Widerstandsfähigkeit sichtbar macht. Methoden werden nach Funktion und Risiko gewählt, unabhängig ausgeführt und mit verbindlicher Behebung verbunden. TLPT ergänzt diese Basis für besonders relevante Unternehmen um eine realistische, bedrohungsgeleitete Prüfung.
BlackMount entwickelt und prüft DORA-Testprogramme einschließlich Funktionsmapping, Recovery-Tests, Drittanbieterbeteiligung und TLPT-Readiness. Ziel ist eine nachvollziehbare Aussage zur operationalen Resilienz statt einer Ansammlung technischer Reports.
