DORA: was Ihr RSSI Ihnen nicht gesagt hat.

Die meisten Finanzunternehmen haben DORA nicht bei null begonnen. Sie hatten ein ISMS, einen Geschäftsfortführungsplan, eine Auslagerungsrichtlinie und ein Drittparteien-Inventar, das größtenteils aus Beschaffungsverträgen bestand. DORA wirft das nicht weg. Es rahmt es neu, hebt die Messlatte insbesondere bei zwei Säulen an und verschiebt das Gespräch von "Haben Sie eine Kontrolle" zu "Können Sie nachweisen, dass Ihr Dienst weiterläuft, wenn ein IKT-Dienstleister ausfällt." Auf dieser Seite geht es um diese Lücke: wie die fünf Säulen tatsächlich im Betrieb ankommen, was eine Aufsichtsbehörde zuerst öffnet und wo Teams Zeit verlieren.

Die fünf Säulen und wer bei jeder geprüft wird

Die Verordnung beruht auf fünf Säulen. In der Praxis sind sie nicht gleich gewichtet. Säule 1 ist grundlegend, aber jedem vertraut, der ein ISMS betreibt. Die Säulen 3 und 4 sind es, wo sich die aufsichtliche Aufmerksamkeit konzentriert, weil sie Nachweise erzeugen, die schwer zu fälschen und leicht zu prüfen sind. Die folgende Tabelle ist die Fassung, die wir verwenden, um einen Vorstand zu briefen: was jede Säule verlangt und wer im Unternehmen am Ende am stärksten exponiert ist, wenn die Aufsicht Nachweise verlangt.

Was zuerst zu tun ist

Der Fehler besteht darin, mit der Aktualisierung der Richtlinien zu beginnen, weil das die bequeme Arbeit ist. Beginnen Sie stattdessen mit den beiden Artefakten, die eine Aufsicht schriftlich anfordern kann und deren korrekter Aufbau am längsten dauert: das IKT-Drittparteienregister und die Zuordnung kritischer oder wichtiger Funktionen zu den IKT-Vermögenswerten und Dienstleistern, die sie stützen. Alles andere hängt von dieser Zuordnung ab. Sie können den Umfang der Resilienztests nicht festlegen, Sie können die Schwere von Vorfällen nicht klassifizieren und Sie können nicht über Konzentrationsrisiko nachdenken, bevor Sie wissen, welche Funktionen kritisch sind und wovon sie abhängen.

Eine praktikable Abfolge für die ersten 90 Tage:

1. Definieren Sie Ihre kritischen oder wichtigen Funktionen. Das ist eine geschäftliche Entscheidung, keine sicherheitstechnische. Sie bestimmt den Umfang fast jeder anderen Verpflichtung.
2. Ordnen Sie jede kritische Funktion den IKT-Dienstleistungen zu, intern und ausgelagert, auf die sie angewiesen ist. Das ist Ihr Abhängigkeitsgraph.
3. Bauen Sie das Drittparteienregister aus diesem Graphen auf, nicht aus der Beschaffungstabelle. Das Register muss Vereinbarungen beschreiben, die Funktionen stützen, einschließlich der Unterauftragnehmer in der Kette.
4. Schließen Sie die von DORA geforderten vertraglichen Lücken (Prüfungsrechte, Ausstiegsstrategien, Transparenz der Unterauftragsvergabe, Zusammenarbeit bei Vorfällen) zuerst bei den Vereinbarungen, die kritische Funktionen stützen.
5. Erst danach formalisieren Sie den IKT-Risikomanagementrahmen und das Testprogramm, weil beide nun einen definierten Umfang haben, gegen den sie arbeiten können.

Das IKT-Drittparteienregister (Säule 4) in der Praxis

Das Register ist keine Lieferantenliste. Es ist ein strukturierter Satz von Informationsregistern, den das Unternehmen pflegt und den die zuständigen Behörden in einer definierten Vorlage einsammeln, um die IKT-Konzentration über den gesamten Finanzsektor hinweg zu erkennen. Das ändert, wie Sie es aufbauen. Ein Feld, das für den internen Gebrauch "nah genug" ist, wird zu einem Datenqualitätsproblem, wenn es auf nationaler und EU-Ebene aggregiert wird. Drei Dinge verursachen den größten Teil des Aufwands.

Erstens ist die Einheit die vertragliche Vereinbarung, nicht der Lieferant. Ein Dienstleister kann hinter mehreren Vereinbarungen stehen, und eine Vereinbarung kann mehrere Funktionen stützen. Sie beschreiben einen Viele-zu-viele-Graphen, und ihn in eine Zeile pro Lieferant zu flachzudrücken, wird die Prüfung nicht überstehen.

Zweitens müssen Sie der Kette folgen. Das Register muss Unterauftragnehmer erfassen, die eine kritische oder wichtige Funktion tatsächlich stützen, was bedeutet, dass Ihre Sicht auf den Dienstleister über Ihre direkte Gegenpartei hinausreichen muss. Wenn Ihr Vertrag Ihnen nicht das Recht gibt zu wissen, wer die vierte Partei ist, dann ist das eine zu schließende vertragliche Lücke, kein leer zu lassendes Feld.

Drittens ist das Funktionskritikalitäts-Kennzeichen bei jeder Vereinbarung das Feld, an dem sich alles andere ausrichtet. Markieren Sie zu viel als kritisch, ertränken Sie Ihre eigenen Tests und vertraglichen Nachbesserungen; markieren Sie zu wenig, untertreiben Sie das Konzentrationsrisiko und führen die Aufsicht in die Irre. Treffen Sie die Kritikalitätsbewertung einmal richtig, auf Funktionsebene, und lassen Sie sie sich fortpflanzen.

Bedrohungsgeleitete Penetrationstests (Säule 3): wie der Raum tatsächlich aussieht

TLPT ist die Säule, die Menschen überrascht, weil sie sich von einem routinemäßigen Penetrationstest unterscheidet. Sie ist intelligence-geleitet, läuft gegen produktive Live-Systeme, ist auf die kritischen oder wichtigen Funktionen zugeschnitten und wird nach der TIBER-EU-Methodik unter Beteiligung der nationalen Behörde durchgeführt. Bedeutende Unternehmen führen sie mindestens in einem Dreijahreszyklus durch. Sie ähnelt eher einer beaufsichtigten Red-Team-Übung als einem Schwachstellenscan, und das entscheidende Ergebnis ist nicht die Liste der Feststellungen; es ist der Nachweis, dass Erkennung und Reaktion funktioniert haben, oder die ehrliche Darlegung, warum nicht.

Drei Realitäten, die Teams unterschätzen:

• Der Umfang wird von kritischen Funktionen bestimmt, nicht davon, was bequem zu testen ist. Wenn eine Funktion einen ausgelagerten Dienstleister umfasst, muss dieser Dienstleister möglicherweise in den Anwendungsbereich aufgenommen werden, was bedeutet, dass die Mitwirkung des Dienstleisters im Voraus vertraglich gesichert werden muss.
• Das Blue Team wird in der Regel nicht informiert. Der Wert liegt darin, echte Erkennung und Reaktion zu testen, sodass ein TLPT, vor dem die Verteidiger gewarnt wurden, den größten Teil seines Sinns verloren hat. Das hat organisatorische Folgen, die Sie einplanen, nicht mitten in der Übung entdecken.
• Tester und Threat-Intelligence-Anbieter müssen Anforderungen an Kompetenz und Unabhängigkeit erfüllen, und die Behörde überprüft den Prozess. Sie können nicht einfach den jährlichen Pentest des Vorjahres als TLPT umetikettieren.

Wenn Ihr Unternehmen unter der Bedeutsamkeitsschwelle liegt, führen Sie kein TLPT durch, schulden aber dennoch ein risikobasiertes Testprogramm: Schwachstellenbewertungen, szenariobasierte Tests und Resilienztests des Wiederherstellungspfads. Der Kurs Lead Operational Resilience Manager ist genau um diese der Aufsicht zugewandte Test- und Nachweisebene herum aufgebaut, und der Kurs DORA Lead Manager behandelt, wie das gesamte Programm durchgängig gesteuert wird.

DORA als lex specialis gegenüber NIS 2 für Banken

Banken und die meisten anderen Finanzunternehmen fallen in den Anwendungsbereich sowohl von NIS 2 als auch von DORA. Die beiden überschneiden sich stark bei IKT-Risiko, Vorfallmeldung und Lieferkettensicherheit, was die naheliegende Befürchtung weckt, alles doppelt zu tun. DORA löst dies: Bei den IKT-Angelegenheiten, die es regelt, ist DORA lex specialis. Die spezielle Regel verdrängt die allgemeine. Wo DORA die Pflicht zum IKT-Risikomanagement und zur Vorfallmeldung festlegt, folgt ein Finanzunternehmen DORA, und die zuständigen Behörden sollten für dasselbe IKT-Thema nicht zusätzlich die entsprechende NIS-2-Anforderung anwenden.

Was dies nicht bedeutet: Es schaltet NIS 2 für ein Finanzunternehmen nicht vollständig ab, und es ändert nicht, wer für IKT-fremde Angelegenheiten Ihre zuständige Behörde ist. Die praktische Entscheidung für eine Bank besteht darin, jede Verpflichtung ihrem maßgeblichen Instrument zuzuordnen: IKT-operationale Resilienz, Vorfallmeldung und IKT-Drittparteienrisiko laufen unter DORA; alles außerhalb von DORA ist Umfang, den Sie gesondert bewerten. Dokumentieren Sie diese Zuordnung. Sie ist die Antwort auf die Frage "Zählen Sie doppelt oder zählen Sie zu wenig", die Prüfer und Auditoren gleichermaßen stellen.

Häufige Fehler und wo die Kompetenz aufzubauen ist

Die wiederkehrenden Fehler sind nicht exotisch. Das Register wird pro Lieferant statt pro Vereinbarung aufgebaut und bricht in dem Moment, in dem die Unterauftragsvergabe relevant wird. Die Kritikalität kritischer Funktionen wird von der IT statt vom Geschäft bewertet, sodass der Umfang von allem Nachgelagerten falsch ist. Schwellenwerte für die Klassifizierung von Vorfällen werden geschrieben, aber nie gegen einen echten Vorfall getestet, sodass das erste schwerwiegende Ereignis zur ersten Probe für den Meldezeitplan wird. Und die Geschäftsfortführung wird als gesondertes ISO-22301-Projekt behandelt statt als der Wiederherstellungsmuskel, den die DORA-Tests trainieren sollen.

Dieser letzte Punkt ist wichtig: DORA ersetzt kein Business-Continuity-Managementsystem, es setzt eines voraus. Die Wiederherstellungsziele und der getestete Wiederherstellungspfad, die Ihnen ein BCMS gibt, sind das, was die Resilienztests validieren. Bauen Sie das BCMS mit dem Kurs ISO 22301 Lead Implementer richtig auf, und es wird zum Substrat, auf dem die Pflichten zur operationalen Resilienz stehen, statt zu einem parallelen Ordner, den niemand öffnet.

Wenn Sie von der Verordnung selbst ausgehen, vermittelt der Kurs DORA Foundation dem gesamten Team eine gemeinsame, präzise Lesart der fünf Säulen und des Anwendungsbereichs, bevor jemand das Register oder das Testprogramm anfasst. Von dort aus ist der Kurs DORA Lead Manager die Implementierungs- und Governance-Ebene für die Personen, die den Rahmen verantworten werden, und der Kurs Lead Operational Resilience Manager ist für die Funktion, die vor die Aufsicht treten und zeigen muss, dass Resilienz real ist, nicht nur dokumentiert.