Der Termin steht seit drei Wochen im Kalender. Zwei Prüfer, ein Besprechungsraum, Ihr Testkonzept liegt ausgedruckt auf dem Tisch.
Die ersten drei Fragen laufen gut. Welche Systeme haben Sie im vergangenen Jahr geprüft. Mit welchen Verfahren. Wer hat geprüft. Für alle drei haben Sie Unterlagen.
Dann kommt die vierte: Und woran sehen wir, dass die Befunde behoben sind?
Sie öffnen das Ticketsystem. Achtundvierzig Vorgänge, alle auf erledigt. Der Prüfer nickt nicht. Ein geschlossener Vorgang sagt, dass jemand ihn geschlossen hat. Er sagt nichts darüber, ob der Fehler weg ist.
Seit dem 17. Januar 2025 gilt die Verordnung (EU) 2022/2554, kurz DORA. Ihr Kapitel IV regelt das Testen der digitalen operationalen Resilienz auf vier Artikeln. Zwei davon betreffen nahezu jedes Finanzunternehmen, zwei betreffen einen kleinen, von der Aufsicht bestimmten Kreis. Diese Zweiteilung zu kennen, entscheidet darüber, ob Sie das Richtige tun oder das Teure.
Dieser Artikel übersetzt die Artikel 24 bis 27 in die Sprache des Testens: was ins Testkonzept gehört, welche Verfahren die Verordnung namentlich nennt, wo ihre Begriffe vom ISTQB-Glossar abweichen und an welcher Stelle die viel zitierte Testdatenregel tatsächlich steht. Alle Zitate sind am Verordnungstext im Amtsblatt geprüft, nicht aus Beratungsseiten übernommen.
Inhaltsverzeichnis
- Was DORA vom Testen verlangt, und seit wann
- Wen die Testpflicht trifft, und wen die erweiterte Prüfung nicht
- Das Testprogramm aufsetzen: was Artikel 24 vom Testkonzept verlangt
- Die Testverfahren aus Artikel 25 im Testkonzept verorten
- Testdaten in der Nichtproduktionsumgebung: die Regel steht nicht in DORA
- Bedrohungsorientierte Penetrationstests: wann Artikel 26 greift
- Für wen sich dieser Aufwand nicht lohnt
- Vier Irrtümer, die in Projekten Geld kosten
- Einwände, die wir im Gespräch hören
- Die ersten Schritte
- Fazit
- Häufige Fragen zu DORA und Testen
Was DORA vom Testen verlangt, und seit wann
Die DORA-Verordnung, ausgeschrieben Digital Operational Resilience Act, ist die Verordnung (EU) 2022/2554. Sie verpflichtet Finanzunternehmen in der Europäischen Union, ihre Widerstandsfähigkeit gegen Störungen und Angriffe auf die Informations- und Kommunikationstechnik nachweisbar zu organisieren. Kapitel IV der DORA-Verordnung regelt, wie dafür getestet wird.
Veröffentlicht wurde sie am 27. Dezember 2022, in Kraft trat sie am 16. Januar 2023, anwendbar ist sie seit dem 17. Januar 2025. Artikel 64 formuliert das in einem Satz: „Sie gilt ab dem 17. Januar 2025."
Ein Hinweis vorweg, weil die Verwechslung im technischen Umfeld regelmäßig passiert: Gemeint ist die EU-Verordnung, nicht die DORA-Metriken aus dem DevOps-Umfeld, die für DevOps Research and Assessment stehen. Zwei verschiedene Dinge mit demselben Kürzel, ohne inhaltlichen Zusammenhang.
Für das Testen ist Kapitel IV zuständig. Es umfasst vier Artikel:
| Artikel | Regelt | Gilt für |
|---|---|---|
| 24 | Allgemeine Anforderungen an das Testprogramm | alle Finanzunternehmen außer Kleinstunternehmen |
| 25 | Testen von IKT-Tools und Systemen, Aufzählung der Verfahren | dieselben, plus Sonderregeln |
| 26 | Erweiterte Tests auf Basis von TLPT | nur ein von der Aufsicht ermittelter Kreis |
| 27 | Anforderungen an die Tester bei TLPT | Tester, intern wie extern |
Eine zweite Sache muss man wissen, um nicht die Hälfte zu lesen: DORA selbst wurde seit 2022 nie geändert. Es gibt neun Berichtigungen, davon eine deutsche vom 19. Dezember 2024, die ausschließlich Artikel 6 betrifft. Es gibt aber zehn ergänzende Rechtsakte, die technischen Regulierungsstandards, abgekürzt RTS. Die operativen Vorgaben stehen dort, nicht im Verordnungstext. Das wird weiter unten beim Thema Testdaten sehr konkret.
Wen die Testpflicht trifft, und wen die erweiterte Prüfung nicht
Artikel 24 richtet sich an „Finanzunternehmen, die keine Kleinstunternehmen sind". Diese Formulierung wiederholt sich in jedem einzelnen Absatz des Artikels. Wer also kein Kleinstunternehmen ist, hat ein Testprogramm zu betreiben. Das ist die breite Pflicht, und sie trifft Banken, Versicherer, Zahlungsdienstleister, Wertpapierfirmen und viele weitere.
Artikel 26 sieht völlig anders aus. Dort steht:
„Gemäß Absatz 8 Unterabsatz 3 des vorliegenden Artikels ermittelte Finanzunternehmen, bei denen es sich weder um die in Artikel 16 Absatz 1 Unterabsatz 1 genannten Unternehmen noch um Kleinstunternehmen handelt, führen mindestens alle drei Jahre anhand von TLPT erweiterte Tests durch."
Das entscheidende Wort ist ermittelte. Die erweiterte Prüfung ist keine Selbsteinschätzung. Die zuständige Behörde bestimmt den Kreis, in Deutschland ist das die BaFin. Sie entscheidet anhand von drei Kriterien: der Wirkung der Tätigkeiten auf den Finanzsektor, Bedenken hinsichtlich der Finanzstabilität und dem IKT-Risikoprofil samt Reifegrad. Ein Institut wird nicht dadurch prüfungspflichtig, dass es sich für groß hält.
Der praktische Wert dieser Unterscheidung ist hoch. Ein mittelgroßer Zahlungsdienstleister, der in Vorbereitung auf eine vermeintliche TLPT-Pflicht ein Red-Team-Budget einplant, gibt Geld für etwas aus, das ihn nicht betrifft, während das Testprogramm nach Artikel 24 unfertig bleibt.
Das Testprogramm aufsetzen: was Artikel 24 vom Testkonzept verlangt
Artikel 24 besteht aus sechs Absätzen. Vier davon haben unmittelbare Konsequenzen für die Art, wie ein Testkonzept geschrieben und gepflegt wird.
Absatz 1 macht aus dem Testen eine Daueraufgabe. Die drei Verben im Text lauten „erstellen, pflegen und überprüfen". Ein einmal geschriebenes und danach abgelegtes Testkonzept erfüllt das nicht. Verlangt ist ein Programm mit eigenem Lebenszyklus, verankert im Rahmen für das IKT-Risikomanagement. Wer belegen will, dass gepflegt und überprüft wurde, braucht datierte Fassungen und dokumentierte Anlässe für jede Überprüfung.
Absatz 4 regelt die Unabhängigkeit und trifft die Aufbauorganisation. Interne Tester sind ausdrücklich zulässig. Die Bedingung ist keine formale Trennung, sondern zweierlei: ausreichende Ressourcen und Freiheit von Interessenkonflikten „während der Konzeptions- und Durchführungsphase der Prüfung". Der Konfliktfall in der Praxis ist selten der böswillige, sondern der strukturelle: der Entwickler, der seine eigene Änderung abnimmt, oder der Testmanager, dessen Zielvereinbarung am Termin hängt, gegen den er prüft.
Absatz 5 ist der Absatz, an dem die meisten Programme scheitern. Er nennt vier Stationen: Priorisierung, Klassifizierung, Behebung und interne Validierung. Die vierte fehlt fast immer. Ein geschlossenes Ticket ist keine Validierung. Der Text verlangt festgelegte „interne Validierungsmethoden", mit denen belegt wird, dass die Schwäche tatsächlich verschwunden ist. In der Praxis heißt das: ein wiederholbarer Test, der vorher fehlgeschlagen ist und jetzt besteht, mit beiden Läufen im Protokoll.
Absatz 6 setzt Frequenz und Umfang. Mindestens einmal jährlich, und zwar für alle Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen. Damit wird die Kritikalitätsbewertung der Anwendungslandschaft zur eigentlichen Vorarbeit. Ohne ein belastbares Inventar, das sagt, welche Anwendung welche Funktion stützt, lässt sich dieser Absatz weder planen noch nachweisen. Erfahrungsgemäß ist genau dieses Inventar der Punkt, an dem Projekte drei Monate länger brauchen als geplant.
Die Testverfahren aus Artikel 25 im Testkonzept verorten
Artikel 25 Absatz 1 zählt die Verfahren auf, die das Testprogramm umfasst. Der Wortlaut nennt dreizehn: Schwachstellenbewertung und Scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests.
Diese Liste ist der Grund, warum Testmanagement bei DORA am Tisch sitzt und nicht nur die Informationssicherheit. Drei Gruppen lassen sich unterscheiden, wobei diese Einteilung eine Lesehilfe ist und nicht im Text steht:
| Gruppe | Verfahren aus dem Wortlaut | Wer das üblicherweise verantwortet |
|---|---|---|
| Sicherheitsnah | Schwachstellenbewertung und Scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, physische Sicherheit, Penetrationstests | Informationssicherheit |
| Analytisch | Lückenanalysen, Fragebögen und Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar | Architektur, Entwicklung, Revision |
| Testfachlich | szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests | Testmanagement |
Zwei Eigenschaften der Aufzählung werden häufig übersehen. Erstens ist sie offen: der Text sagt „wie etwa". Es ist weder verlangt, alle dreizehn Verfahren einzusetzen, noch verboten, weitere zu ergänzen. Was zählt, ist die Begründung, welches Verfahren für welches System eingesetzt wird, abgeleitet aus dem Risikoprofil.
Zweitens liefert die Verordnung selbst ein Beispiel für den begründeten Verzicht. Bei Quellcodeprüfungen steht ausdrücklich „soweit durchführbar". Für zugekaufte Standardsoftware ohne Quellcodezugang ist die Prüfung nicht durchführbar, und das ist regelkonform, sofern es dokumentiert ist. Dieselbe Logik trägt für andere Verfahren, dann allerdings über den risikobasierten Ansatz und nicht über den Wortlaut.
Wo die Verordnung und das ISTQB-Glossar auseinandergehen
Wer die Verfahren aus Artikel 25 in ein bestehendes Testkonzept überträgt, stößt auf ein Problem, das in keiner Beratungsübersicht steht: Die Verordnung benutzt teilweise andere Begriffe als das ISTQB-Glossar. Wir haben jeden Begriff gegen das deutsche Glossar geprüft.
| Begriff in Artikel 25 | ISTQB-Glossar (deutsch) | Folge für das Testkonzept |
|---|---|---|
| Leistungstests | kein Eintrag. Der Glossarbegriff lautet Performanztest | Zuordnung im Konzept explizit machen, sonst findet die Revision den Nachweis nicht |
| End-to-End-Tests | Ende-zu-Ende-Test, als Synonym geführt | Schreibweise vereinheitlichen, beide Formen im Glossar des Konzepts nennen |
| Kompatibilitätstests | kein Eintrag | eigene Definition im Testkonzept nötig, sonst ist der Umfang unbestimmt |
| szenariobasierte Tests | szenariobasierter Test, deckungsgleich | keine Anpassung nötig |
| Penetrationstests | Penetrationstest, deckungsgleich | keine Anpassung nötig |
Das ist keine Wortklauberei. Wenn im Testkonzept „Performanztest" steht und im Prüfbericht nach „Leistungstest" gesucht wird, entsteht eine Lücke, die es fachlich nicht gibt. Ein kurzer Abschnitt im Testkonzept, der die Begriffe der Verordnung auf die eigenen Begriffe abbildet, löst das dauerhaft.
Testdaten in der Nichtproduktionsumgebung: die Regel steht nicht in DORA
Kaum eine Aussage zu DORA wird so oft wiederholt wie diese: DORA verlange anonymisierte Testdaten. Wir haben den kompletten Verordnungstext daraufhin geprüft, mit zwei voneinander unabhängigen Suchverfahren.
| Begriff | Treffer im DORA-Text |
|---|---|
| Testdaten | 0 |
| Testumgebung | 0 |
| Produktionsdaten | 0 |
| pseudonymisiert | 0 |
| anonymisiert | 4, sämtlich zur Meldung von Vorfällen und zur Veröffentlichung von Sanktionen |
Zur Kontrolle: die Zeichenfolge „test" kommt 133 mal im Dokument vor, der Text war also vollständig geladen. Die Aussage ist am Verordnungstext schlicht nicht belegbar.
Belegbar ist sie an anderer Stelle. Die Regel steht in der Delegierten Verordnung (EU) 2024/1774, dem technischen Regulierungsstandard (RTS) zum IKT-Risikomanagement, dort in Artikel 16 Absatz 5:
„in Nichtproduktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden"
Drei Punkte daran sind für das Testdatenmanagement entscheidend.
Erstens sind die drei Verfahren gleichrangig. Anonymisiert, pseudonymisiert oder randomisiert, ohne Rangfolge. Eine Pflicht zur Vollanonymisierung lässt sich daraus nicht ableiten. Wer strenger vorgeht, tut das aus Gründen der Datenschutz-Grundverordnung, nicht wegen dieses Artikels.
Zweitens ist der Bezugspunkt die Umgebung, nicht der Datensatz. Die Regel greift an der Nichtproduktionsumgebung. Damit ist die Umgebungslandschaft die eigentliche Prüfgröße: welche Umgebungen existieren, welche gelten als Nichtproduktion, wer hat Zugriff. Ein sauber maskierter Datenbestand in einer nicht klassifizierten Umgebung erfüllt die Regel nicht.
Drittens hat die Ausnahme vier Bedingungen, nicht drei. Absatz 6 erlaubt echte Produktionsdaten, aber nur kumulativ bei bestimmtem Testanlass, begrenztem Zeitraum, Genehmigung durch die betreffende Funktion und Meldung des Anlasses an die Funktion für das IKT-Risikomanagement. Die vierte Bedingung wird in Sekundärquellen fast durchgängig weggelassen. Sie ist genau die Stelle, an der aus einer technischen Maßnahme ein nachweispflichtiger Prozess wird. Ohne Meldeweg ist die Ausnahme nicht regelkonform nutzbar, unabhängig davon, wie gut die Genehmigung dokumentiert ist.
Eine Randbemerkung, weil sie oft anders dargestellt wird: synthetische Testdaten kommen im Rechtstext nicht vor. Sie sind zulässig und häufig sinnvoll, aber sie sind nicht das genannte Mittel. Genannt sind abgeleitete Produktionsdaten.
Bedrohungsorientierte Penetrationstests: wann Artikel 26 greift
TLPT steht für Threat-Led Penetration Testing, im deutschen Verordnungstext bedrohungsorientierter Penetrationstest. Wen es betrifft, steht weiter oben. Was es bedeutet, steht in Absatz 2:
„Jeder bedrohungsorientierte Penetrationstest schließt mehrere oder alle kritischen oder wichtigen Funktionen eines Finanzunternehmens ein und wird an Live-Produktionssystemen durchgeführt, die derartige Funktionen unterstützen."
Geprüft wird also in der Produktion, nicht in einer Testumgebung. Das ist die schärfste Einzelaussage von Kapitel IV. Der Umfang wird vom Unternehmen bewertet und anschließend von der zuständigen Behörde validiert. Ausgelagerte Funktionen sind einzubeziehen, und die Verantwortung bleibt beim Finanzunternehmen, auch wenn Dienstleister beteiligt sind.
Zwei weitere Regeln lohnen die Aufmerksamkeit. Wer interne Tester einsetzt, muss nach Absatz 8 „für jeden dritten Test einen externen Tester" beauftragen. Und bedeutende Kreditinstitute dürfen ausschließlich externe Tester heranziehen.
Artikel 27 legt fest, wer als Tester in Frage kommt. Verlangt sind unter anderem der Nachweis von Fachwissen in Bedrohungsanalyse, Penetrationstests und Red-Team-Tests, eine Zertifizierung durch eine Akkreditierungsstelle oder die Einhaltung formaler Verhaltenskodizes, ein unabhängiger Auditbericht über das eigene Risikomanagement und eine Berufshaftpflichtversicherung, die auch Fehlverhalten und Fahrlässigkeit abdeckt.
An dieser Stelle gehört eine offene Aussage hin: TLPT ist nicht unser Feld. Das in Artikel 27 beschriebene Profil ist ein Sicherheitsprofil, kein Quality-Engineering-Profil. Für TLPT brauchen Sie ein spezialisiertes Red-Team-Haus. Unsere Hälfte von Kapitel IV ist das Testprogramm nach Artikel 24, die testfachlichen Verfahren nach Artikel 25 und die Nachweisführung, die beides prüfbar macht.
Für wen sich dieser Aufwand nicht lohnt
Nicht jede Organisation braucht ein Projekt zu diesem Thema. Drei Fälle, in denen wir abraten:
Sie sind Kleinstunternehmen im Sinne der Verordnung. Artikel 24 nimmt Sie ausdrücklich aus. Artikel 25 Absatz 3 verlangt von Ihnen einen risikobasierten Ansatz mit strategischer Planung und erlaubt ausdrücklich, Aufwand gegen Dringlichkeit und Kritikalität abzuwägen. Der Wortlaut spricht sogar von der Fähigkeit, „kalkulierte Risiken einzugehen". Ein umfangreiches Programm wäre hier Verschwendung.
Ihr Anwendungsinventar ist noch nicht belastbar. Solange nicht feststeht, welche Anwendung welche kritische oder wichtige Funktion stützt, ist jede Testplanung Spekulation. Dann ist das Inventar das Projekt, nicht das Testen.
Sie erwarten eine Bescheinigung. Wer ein Dokument sucht, das die Konformität bestätigt, wird enttäuscht. Für TLPT stellen die Behörden eine Bescheinigung aus, für das Testprogramm nach Artikel 24 gibt es nichts Vergleichbares. Was zählt, ist die Nachvollziehbarkeit der eigenen Unterlagen.
Vier Irrtümer, die in Projekten Geld kosten
„DORA verlangt anonymisierte Testdaten"
Nicht im Verordnungstext. Die Regel steht in der Delegierten Verordnung (EU) 2024/1774, Artikel 16 Absatz 5, und sie nennt drei gleichrangige Verfahren. Wer die falsche Fundstelle zitiert, verliert in der Prüfung an Glaubwürdigkeit, obwohl er inhaltlich fast richtig liegt.
„Wir müssen TLPT durchführen"
Nur, wenn die zuständige Behörde Sie dafür ermittelt hat. Artikel 26 Absatz 1 knüpft die Pflicht an diese Ermittlung. Ohne sie gelten die Artikel 24 und 25, und die sind umfangreich genug.
„Einmal jährlich testen reicht"
Artikel 24 Absatz 6 nennt eine Untergrenze für angemessene Tests, keine ausreichende Frequenz. Der risikobasierte Ansatz aus Absatz 3 kann für einzelne Systeme deutlich häufigere Prüfungen verlangen. Wer den Jahresrhythmus als Zielwert liest, unterschreitet die Anforderung bei den kritischsten Systemen.
„Wir sind zu 100 Prozent DORA-konform"
Diesen Satz sollte niemand sagen, weder Institut noch Dienstleister. Testen ist Kapitel IV von mehreren Kapiteln der Verordnung. Konform ist am Ende das Institut als Ganzes, nicht ein Werkzeug und nicht ein einzelner Prozess. Wer Vollständigkeit verspricht, verspricht etwas, das er nicht liefern kann.
Einwände, die wir im Gespräch hören
„Wir testen doch längst. Warum sollte das plötzlich nicht reichen?" Meistens reicht das Testen. Was fehlt, ist der Nachweis, dass es geplant, unabhängig und mit dokumentierter Validierung stattgefunden hat. Der Aufwand liegt selten im Testen selbst, sondern in der Beweisführung darüber.
„Unsere Informationssicherheit hat das Thema übernommen." Für die sicherheitsnahen Verfahren ist das richtig. Leistungstests, End-to-End-Tests und szenariobasierte Tests stehen aber ebenfalls im Artikel 25, und für die ist die Informationssicherheit typischerweise weder besetzt noch zuständig. Diese Verfahren fallen sonst zwischen die Zuständigkeiten.
„Können Sie uns nicht einfach die Konformität bestätigen?" Nein. Wir können prüfbar machen, was Sie tun, und Lücken gegen die Artikel benennen. Die Bewertung der Konformität liegt bei Ihnen und Ihrer Aufsicht.
Die ersten Schritte
Wenn Sie in den nächsten Wochen anfangen wollen, ist diese Reihenfolge sinnvoll:
- Betroffenheit klären. Kleinstunternehmen oder nicht, und liegt eine Ermittlung durch die Aufsicht für TLPT vor. Beides sind Ja-Nein-Fragen mit großer Wirkung auf den Aufwand.
- Inventar der kritischen und wichtigen Funktionen prüfen. Welche Anwendung stützt welche Funktion. Ohne diese Zuordnung ist Artikel 24 Absatz 6 nicht planbar.
- Die dreizehn Verfahren auf Ihr Testkonzept abbilden. Für jedes Verfahren eine von drei Aussagen: wird eingesetzt, wird nicht eingesetzt mit Begründung, ist nicht durchführbar mit Begründung.
- Begriffe angleichen. Einen Abschnitt ergänzen, der die Verordnungsbegriffe auf Ihre Terminologie abbildet.
- Die Validierungsmethode festlegen. Artikel 24 Absatz 5. Wie wird belegt, dass ein Befund tatsächlich behoben ist. Das ist der Punkt mit der größten Lücke und dem geringsten Aufwand zur Schließung.
- Testdatenprozess gegen Artikel 16 des Regulierungsstandards prüfen. Besonders den Meldeweg an die Funktion für das IKT-Risikomanagement.
Fazit
DORA verlangt vom Testen nichts fachlich Neues. Die Verfahren aus Artikel 25 kennt jeder Testmanager. Neu ist der Anspruch, dass das Testen geplant, unabhängig, wiederkehrend und mit belegter Validierung stattfindet, und dass sich das aus Unterlagen nachvollziehen lässt.
Der größte vermeidbare Fehler ist die Verwechslung der beiden Ebenen: die breite Pflicht aus den Artikeln 24 und 25 mit der schmalen Zusatzpflicht aus den Artikeln 26 und 27. Wer beides zusammenwirft, plant entweder zu viel oder das Falsche.
Wenn Sie Ihre Testlandschaft in einem regulierten Umfeld betreiben, ist der zweite Blick in Richtung der weiteren Anforderungen sinnvoll. Für Banken und Versicherer haben wir die Anforderungen aus BAIT, VAIT und MaRisk auf unserer Seite für Finanzdienstleister und Versicherer zusammengefasst. Wer zusätzlich KI-Systeme betreibt, findet die entsprechenden Nachweispflichten in unserem Beitrag zur Qualitätssicherung für KI-Systeme.
Standortbestimmung zum Testprogramm anfragen
In einem Gespräch von 60 Minuten ordnen wir Ihr bestehendes Testkonzept gegen die Artikel 24 und 25 ein und benennen die Lücken, die eine Prüfung zuerst finden würde. Ohne Vorbereitung Ihrerseits und ohne Verpflichtung. Termin anfragen.
Häufige Fragen zu DORA und Testen
Was ist die DORA-Verordnung?
Die DORA-Verordnung ist die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor, ausgeschrieben Digital Operational Resilience Act. Sie verpflichtet Finanzunternehmen in der Europäischen Union, ihre Widerstandsfähigkeit gegen Störungen und Angriffe auf die Informations- und Kommunikationstechnik nachweisbar zu organisieren. Geregelt sind unter anderem IKT-Risikomanagement, die Meldung von Vorfällen, das Testen der Resilienz in Kapitel IV und das Management des Drittparteienrisikos. Zuständige Aufsichtsbehörde in Deutschland ist die BaFin.
Seit wann gilt DORA?
DORA gilt seit dem 17. Januar 2025. Die Verordnung (EU) 2022/2554 wurde am 27. Dezember 2022 veröffentlicht und trat am 16. Januar 2023 in Kraft. Artikel 64 legt den Anwendungsbeginn auf den 17. Januar 2025 fest.
Welche Testarten verlangt DORA?
Artikel 25 nennt dreizehn Verfahren, darunter Schwachstellenbewertung und Scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests. Die Aufzählung ist offen formuliert, es müssen nicht alle Verfahren eingesetzt werden.
Wie oft muss nach DORA getestet werden?
Artikel 24 Absatz 6 verlangt mindestens einmal jährlich angemessene Tests für alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen. Für die erweiterten Tests auf Basis von TLPT gilt nach Artikel 26 ein Turnus von mindestens drei Jahren.
Verlangt DORA anonymisierte Testdaten?
Nicht im Verordnungstext selbst, dort kommen die Begriffe Testdaten und Produktionsdaten nicht vor. Die Regel steht in der Delegierten Verordnung (EU) 2024/1774, Artikel 16 Absatz 5: in Nichtproduktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden. Absatz 6 erlaubt Ausnahmen für bestimmte Testanlässe unter vier Bedingungen.
Wer muss TLPT durchführen?
Nur Finanzunternehmen, die von der zuständigen Behörde dafür ermittelt wurden und die weder Kleinstunternehmen sind noch unter den vereinfachten Rahmen nach Artikel 16 Absatz 1 fallen. In Deutschland ermittelt die BaFin diesen Kreis, und zwar anhand der Wirkung auf den Finanzsektor, der Finanzstabilität und des IKT-Risikoprofils.
Dürfen interne Mitarbeitende die Tests durchführen?
Ja. Artikel 24 Absatz 4 erlaubt interne Tester ausdrücklich, verlangt aber ausreichende Ressourcen und die Freiheit von Interessenkonflikten während Konzeption und Durchführung. Bei TLPT ist der Einsatz interner Tester zusätzlich von der zuständigen Behörde zu genehmigen, und für jeden dritten Test ist ein externer Tester zu beauftragen.
Reicht unser bestehendes Testkonzept für DORA aus?
Das hängt an drei Punkten: ob das Konzept nachweislich gepflegt und überprüft wird, ob die Unabhängigkeit der Tester dokumentiert ist und ob eine festgelegte Methode zur internen Validierung behobener Befunde existiert. Der dritte Punkt fehlt in der Praxis am häufigsten.