DORA erklärt: was der Digital Operational Resilience Act von Entwicklern verlangt, die Finanzkunden bedienen

Der ehrliche Ausgangspunkt: ich baue für DORA, ich bin keine Finanzeinrichtung

DORA ist der Digital Operational Resilience Act, die Verordnung (EU) 2022/2554, und sie gilt in der gesamten Europäischen Union seit dem 17. Jänner 2025.¹ Es ist ein Gesetz für den Finanzsektor: Banken, Versicherer, Wertpapierfirmen, Zahlungs und E Geld Institute, Anbieter von Krypto Dienstleistungen und viele mehr.¹ Ich bin nichts davon. Ich baue Software.

Warum geht ein Gesetz für Banken dann einen Entwickler etwas an? Weil DORA nicht bei der Finanzeinrichtung haltmacht. Es erreicht die Unternehmen, die der Finanzeinrichtung ihre Technik liefern, und es erreicht sie über den Vertrag. Eine Finanzeinrichtung muss eine Reihe von Resilienz und Sicherheitspflichten in jeden Vertrag schreiben, den sie mit einem IKT Drittdienstleister schließt. Wenn ich das Kundenportal für ein Zahlungsinstitut baue, bin ich einer dieser Dienstleister.¹ Mich holen die Klauseln in meinem Vertrag herein, nicht die Verordnung, die mich direkt benennt.

Diese Unterscheidung ist der ganze Artikel, und sie ist die ehrliche Linie, an die ich mich halte. Ich bin ein IKT Anbieter für einen Finanzkunden. Ich bin keine regulierte Finanzeinrichtung, ich gebe mich nie als eine aus, und für DORA zu bauen macht mich zu keiner. Meine Aufgabe ist es, so zu bauen und zu kontrahieren, dass ein Finanzkunde DORA erfüllen kann. Dieser Text gehört zu meiner Arbeit an geschäftskritischer Software, die über allem steht, und er ist die vertraglichste Fassung dieser Disziplin, mit der ich zu tun habe.

Die Unternehmen im durchgerechneten Beispiel sind erfunden. Das Gesetz, die Daten und die Artikel sind an die Verordnung und an die Europäischen Aufsichtsbehörden gefußnotet.

Was DORA ist und seit wann es gilt

DORA setzt, in seinen eigenen Worten, "einheitliche Anforderungen an die Sicherheit von Netzwerk und Informationssystemen", die den Geschäftsbetrieb von Finanzeinrichtungen stützen.¹ Davor war der Umgang mit operationaler Resilienz und Technikrisiko quer über die Mitgliedstaaten und quer über verschiedene Teile des Finanzrechts uneinheitlich geregelt. DORA zieht das in einer Verordnung zusammen, in jedem Mitgliedstaat unmittelbar anwendbar, ohne den Umweg über ein nationales Umsetzungsgesetz. Genau deshalb ist es eine Verordnung und keine Richtlinie.

Es ist am zwanzigsten Tag nach der Veröffentlichung im Amtsblatt Ende 2022 in Kraft getreten und gilt seit dem 17. Jänner 2025.¹ Dieser Anwendungstag ist der entscheidende. Seit diesem Tag muss eine betroffene Finanzeinrichtung ihr IKT Risikomanagement, ihre Vorfallsmeldung, ihre Tests und ihre Verträge mit Dienstleistern nach dem Maßstab betreiben, den DORA setzt, und die vertraglichen Pflichten, die sie an Lieferanten weitergeben muss, sind seither scharf geschaltet.

Die Verordnung ruht auf einer Schicht technischer Standards, die von den drei Europäischen Aufsichtsbehörden entworfen werden: der Europäischen Bankenaufsichtsbehörde, der Europäischen Wertpapier und Marktaufsichtsbehörde und der Europäischen Aufsichtsbehörde für das Versicherungswesen und die betriebliche Altersversorgung, zusammen die ESAs genannt.² Diese regulatorischen und technischen Durchführungsstandards liefern das Detail: den genauen Inhalt der Vorfallsmeldungen, die Vorlagen für das Informationsregister, die Methodik der bedrohungsorientierten Tests. Wenn ich die Einzelheiten einer Klausel brauche, lebt die eigentliche Anforderung dort, nicht in der Verordnung allein.

Wer betroffen ist

DORA zählt die betroffenen Einrichtungen in Artikel 2 auf. Die EIOPA fasst es als rund zwanzig Arten von Finanzeinrichtungen samt ihren IKT Anbietern zusammen.² Die Liste in Artikel 2 Absatz 1 reicht über Kreditinstitute, Zahlungsinstitute, Kontoinformationsdienstleister, E Geld Institute, Wertpapierfirmen, Anbieter von Krypto Dienstleistungen und Emittenten wertreferenzierter Token, Zentralverwahrer, zentrale Gegenparteien, Handelsplätze, Transaktionsregister, Verwalter alternativer Investmentfonds, Verwaltungsgesellschaften, Datenbereitstellungsdienste, Versicherungs und Rückversicherungsunternehmen, Versicherungs und Rückversicherungsvermittler, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Administratoren kritischer Referenzwerte, Schwarmfinanzierungsdienstleister und Verbriefungsregister.¹

Die Punkte (a) bis (t) dieser Liste sind die "Finanzeinrichtungen".¹ Dann kommt Punkt (u): IKT Drittdienstleister.¹ Dieser letzte Eintrag ist die Tür, durch die ein Softwarelieferant überhaupt relevant wird. Er macht einen IKT Anbieter nicht zur Finanzeinrichtung, und er unterwirft einen gewöhnlichen Lieferanten nicht der ganzen Verordnung. Er ist der Haken, an dem DORA ein Aufsichtsregime für die größten, systemisch wichtigsten Techniklieferanten aufhängen kann, zu dem ich weiter unten komme.

DORA baut auch Verhältnismäßigkeit ein. Kleinstunternehmen und bestimmte kleine Einrichtungen fahren ein leichteres, vereinfachtes IKT Risikomanagement statt des vollen, und die Tiefe des Erwarteten skaliert mit Größe, Risiko und Komplexität der Einrichtung.¹ Eine kleine Pensionskasse muss nicht leisten, was eine systemische Bank leistet. Aber Verhältnismäßigkeit betrifft das Wie viel, nicht das Ob: wer drin ist, ist drin.

Die fünf Säulen, in klaren Worten

DORA wird meist mit fünf Säulen beschrieben, obwohl die Verordnung selbst das Wort nicht verwendet. Sie liegen in den Kapiteln II bis VI. Die EIOPA listet sechs Bereiche und zieht die Aufsicht über kritische Anbieter als eigenen Punkt heraus.² Hier sind die fünf, so wie ein Entwickler ihnen begegnet.

IKT Risikomanagement. Die Einrichtung braucht einen dokumentierten Rahmen, um Technikrisiko zu erkennen, abzuwehren, aufzuspüren, darauf zu reagieren und sich davon zu erholen: Steuerung durch das Leitungsorgan, eine aktuelle Landkarte ihrer Systeme und Abhängigkeiten, Schutz und Vorbeugung, Erkennung sowie Geschäftsfortführung mit Sicherung und Wiederanlauf.¹ Das ist das Rückgrat, und das meiste, was folgt, hängt als konkrete Pflicht daran.

IKT Vorfallsmanagement und Meldung. Die Einrichtung muss Technikvorfälle erkennen, steuern und einstufen und die schweren davon ihrer zuständigen Behörde an einer engen Uhr melden. Die Uhr stelle ich unten in einem eigenen Abschnitt dar.¹

Tests der digitalen operationalen Resilienz. Die Einrichtung muss ihre Resilienz regelmäßig testen, von einfachen Schwachstellenbewertungen und Penetrationstests bis hin, bei den größeren Einrichtungen, zu fortgeschrittenen bedrohungsorientierten Penetrationstests.¹ Mehr dazu, wer wie testet, weiter unten.

Management des IKT Drittparteienrisikos. Die Einrichtung muss das Risiko aus dem Rückgriff auf externe Techniklieferanten steuern: eine Strategie, ein Register jedes Vertrags, Sorgfaltsprüfung vor der Unterschrift und ein fester Satz an Klauseln im Vertrag.¹ Das ist die Säule, die mich erreicht.

Informationsaustausch. Einrichtungen dürfen freiwillig Erkenntnisse über Cyber Bedrohungen in vertrauenswürdigen Gemeinschaften teilen, um einander beim Erkennen und Abwehren von Angriffen zu helfen.¹ Diese Säule erlaubt, sie verpflichtet nicht.

Die Säulen sind keine getrennten Projekte. Ein einziger Vorfall berührt das Risikomanagement (haben die Kontrollen gehalten), die Meldung (die Uhr läuft), die Tests (hat ein Test das übersehen) und das Drittparteienrisiko (war ein Lieferant beteiligt). DORAs Punkt ist, dass Resilienz eine Disziplin ist, aus mehreren Blickwinkeln gesehen.

Die Vorfallsuhr: vier Stunden, 72 Stunden, ein Monat

Die Vorfallsmeldung ist der Punkt, an dem DORA, wie NIS2, eine Stoppuhr laufen lässt, und das Detail steckt in den technischen Standards. Nach der Verordnung muss eine Finanzeinrichtung, die einen schweren IKT bezogenen Vorfall erleidet, eine Erstmeldung abgeben, dann einen Zwischenbericht und dann einen Abschlussbericht, sobald die Ursachenanalyse fertig ist.¹ Die Fristen kommen aus den regulatorischen technischen Standards, der Delegierten Verordnung (EU) 2025/301.³

Die Erstmeldung ist binnen vier Stunden fällig, nachdem die Einrichtung den Vorfall als schwer eingestuft hat, und jedenfalls spätestens 24 Stunden, nachdem sie davon Kenntnis erlangt hat.³ Der Zwischenbericht ist binnen 72 Stunden nach der Erstmeldung fällig, auch wenn sich die Lage nicht geändert hat, mit Aktualisierungen, sobald sie sich ändert.³ Der Abschlussbericht ist spätestens einen Monat nach dem Zwischenbericht fällig, oder nach dem letzten aktualisierten Zwischenbericht, wenn es mehrere gibt.³ Für Wochenenden und Feiertage gibt es ein kleines Zugeständnis: eine Frist kann auf den Mittag des nächsten Arbeitstags rutschen.³

Diese ersten vier Stunden sind der Teil, der ändert, wie ich baue. Du kannst keinen Vorfall einstufen, den du nicht siehst, und du kannst binnen vier Stunden nicht melden, was deine Protokolle nicht erfasst haben. Die Meldeuhr ist also eigentlich eine Anforderung an Überwachung, Protokollierung und einen schriftlichen Ablauf, lange bevor sie eine Anforderung an irgendjemandes Postfach ist. Trifft ein Vorfall die Interessen der Kundinnen und Kunden, muss die Einrichtung auch die Betroffenen ohne unangemessene Verzögerung informieren.¹

Wie DORA einen Entwickler wie mich erreicht: über den Vertrag

Jetzt der Teil, der auf meinem Tisch landet. Eine Finanzeinrichtung bleibt für ihre Pflichten voll verantwortlich, auch wenn sie die Arbeit auslagert, sie kann sie also nicht an einen Lieferanten wegunterschreiben.¹ Damit diese Verantwortung echt bleibt, lässt DORA die Einrichtung ihr IKT Drittparteienrisiko selbst steuern, und das Werkzeug dafür ist der Vertrag.

Erstens muss die Einrichtung ein Informationsregister führen: eine gepflegte, aktuelle Aufstellung jedes Vertrags über IKT Dienstleistungen, auf Ebene der Einrichtung und auf Konzernebene, mindestens einmal im Jahr an die zuständige Behörde gemeldet und auf Anfrage übergeben.¹ Wenn ich einen Teil der Dienstleistung einer Finanzeinrichtung baue und betreibe, ist mein Vertrag eine Zeile in diesem Register. Die Einrichtung muss ihrer Behörde zudem rechtzeitig von geplanten Verträgen berichten, die eine kritische oder wichtige Funktion stützen würden.¹

Zweitens muss die Einrichtung vor der Unterschrift ihre Sorgfaltsprüfung machen: prüfen, ob die Dienstleistung eine kritische oder wichtige Funktion stützt, die Risiken samt Konzentrationsrisiko bewerten (zu viel hängt an einem Lieferanten), meine Eignung prüfen und ansehen, ob und wie ich untervergebe.¹ Das ist dieselbe Lieferantenprüfung, über die ich beim GDPR Lieferantenrisiko geschrieben habe, eine Stufe höher gedreht und verpflichtend gemacht.

Drittens muss der Vertrag selbst einen festen Satz an Bedingungen tragen. DORA teilt sie in jene, die jeder IKT Vertrag braucht (Artikel 30 Absatz 2), und die zusätzlichen für Verträge, die eine kritische oder wichtige Funktion stützen (Artikel 30 Absatz 3).¹ Jeder Vertrag braucht unter anderem eine klare, vollständige Beschreibung der Leistungen, die Orte, an denen die Leistung erbracht und Daten verarbeitet werden, samt Vorankündigung, bevor diese sich ändern, Regeln zu Verfügbarkeit, Echtheit, Integrität und Vertraulichkeit der Daten, das Recht der Einrichtung, ihre Daten in zugänglicher Form zurückzubekommen, falls ich untergehe oder der Vertrag endet, Beschreibungen der Dienstgüte, meine Mithilfe bei Vorfällen ohne Zusatzkosten oder zu einem vorab vereinbarten Preis, die Zusammenarbeit mit den Behörden der Einrichtung und Kündigungsrechte mit vernünftiger Frist.¹

Wo meine Arbeit eine kritische oder wichtige Funktion stützt, muss der Vertrag weiter gehen. Er setzt volle, messbare Dienstgüten. Er verpflichtet mich, Entwicklungen zu melden, die meine Lieferfähigkeit beeinträchtigen könnten, meine eigenen Notfallpläne zu testen und meine Sicherheit auf dem regulatorischen Niveau der Einrichtung zu halten. Er verlangt, dass ich am bedrohungsorientierten Penetrationstest der Einrichtung teilnehme. Er gewährt der Einrichtung, ihren Beauftragten und der zuständigen Behörde uneingeschränkte Rechte auf Zugang, Einsicht und Prüfung, auch vor Ort. Und er setzt eine dokumentierte Ausstiegsstrategie, mit einer Übergangsfrist, in der ich die Dienstleistung weiterlaufen lasse, während die Einrichtung zu einem anderen Lieferanten wechselt oder sie ins Haus holt.¹

Lies diese Liste als Entwickler, und sie ist nicht exotisch. Es sind Prüfprotokolle, dokumentierter Wiederanlauf, Mithilfe bei Vorfällen, Datenportabilität, Zugang für Prüfer und ein sauberer Ausstieg. Es ist, mit anderen Worten, die ingenieurmäßige Disziplin eines ernsthaften Baus, in einen Vertrag geschrieben und durchsetzbar gemacht.

Kritische IKT Drittdienstleister und das Aufsichtsregime

Es gibt einen Weg, auf dem ein IKT Anbieter von DORA direkt erreicht wird statt nur über den Vertrag, und es lohnt sich, dabei genau zu sein, weil er oft falsch gelesen wird. Die ESAs können einen Anbieter als kritischen IKT Drittdienstleister einstufen, kurz CTPP, und ihn unter ein direktes Aufsichtsregime stellen.¹

Die Einstufung läuft über den Gemeinsamen Ausschuss der ESAs und stützt sich auf die Kriterien in Artikel 31: die systemische Wirkung, falls der Anbieter ausfällt, wie viele Finanzeinrichtungen von ihm abhängen und wie wichtig sie sind, wie stark Einrichtungen für kritische Funktionen auf ihn setzen und wie austauschbar er ist.¹ Jeder eingestufte Anbieter bekommt eine führende Aufsichtsbehörde, eine der drei ESAs, ausgewählt danach, welche Behörde die Finanzeinrichtungen beaufsichtigt, die zusammen den größten Anteil an Vermögenswerten unter den Kunden des Anbieters halten.¹

Die führende Aufsichtsbehörde kann Auskünfte verlangen, Untersuchungen und Prüfungen durchführen, Berichte über Abhilfemaßnahmen anfordern und Empfehlungen aussprechen.¹ Erfüllt ein kritischer Anbieter nicht, kann die führende Aufsichtsbehörde ein Zwangsgeld von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes des Anbieters im vorangegangenen Geschäftsjahr verhängen, täglich bis zur Erfüllung, für bis zu sechs Monate.¹

Hier die ehrliche Lesart. Dieses Regime zielt auf die Handvoll wirklich systemischer Lieferanten: die großen Cloud Plattformen und die größte gemeinsame Infrastruktur, auf die sich der ganze Sektor stützt. Ein einzelner Entwickler oder ein kleines Studio, das das Portal einer Firma baut, wird nicht als CTPP eingestuft. Für fast jeden Softwarelieferanten kommt DORA also weiterhin nur über den Vertrag, nicht über eine Einstufung. Etwas anderes zu behaupten, nämlich dass für eine Bank zu bauen mich zu einer beaufsichtigten Einrichtung macht, wäre falsch, und ich behaupte es nicht.

Wer wie testet: Resilienztests und bedrohungsorientierte Penetrationstests

DORAs Testsäule hat zwei Stufen. Jede betroffene Einrichtung jenseits der kleinsten fährt ein Programm einfacher Tests: Schwachstellenbewertungen, Scans, Penetrationstests, Quellcodeprüfung und Ähnliches, an den Systemen hinter ihren wichtigen Funktionen.¹ Das sind die gewöhnlichen Sicherheitstests, die ein sorgfältiges Team ohnehin macht, zur stehenden Pflicht gemacht.

Die zweite Stufe sind fortgeschrittene Tests auf Basis bedrohungsorientierter Penetrationstests, kurz TLPT. Einrichtungen, die die zuständige Behörde nach ihrer Wirkung auf den Sektor, nach Erwägungen zur Finanzstabilität und nach ihrem IKT Risikoprofil benennt, müssen mindestens alle drei Jahre TLPT durchführen, wobei die Behörde die Häufigkeit anpassen kann.¹ TLPT ist ein kontrollierter, geheimdienstlich geführter Angriff auf die Produktivsysteme der Einrichtung, der die Taktiken, Techniken und Vorgehensweisen echter Angreifer nachstellen soll und Stärken und Schwächen finden, nicht ein Bestehen oder Durchfallen erzeugen.⁴

DORA verlangt, dass TLPT dem TIBER EU Rahmen folgt, dem europäischen Rahmen für bedrohungsgeleitetes ethisches Red Teaming, den die EZB und die nationalen Zentralbanken entwickelt und 2024 an DORAs Standards angepasst haben.⁴ Die Tester müssen die Anforderungen aus Artikel 27 erfüllen, Einrichtungen müssen mindestens bei jedem dritten Test externe Tester einsetzen (und bedeutende Banken nur externe), und wo meine Systeme hinter einer betroffenen Funktion liegen, kann mein Vertrag mich zur Teilnahme verpflichten.¹ Das ist der praktische Rückbezug auf mich: ich beauftrage den TLPT nicht, das tut die Finanzeinrichtung, aber ich kann in ihrem Umfang liegen und muss mitwirken.

DORA und NIS2: ein Sektor herausgeschnitten

Wer meinen Text zur NIS2 Richtlinie gelesen hat, dem wird DORA wie ein naher Verwandter vorkommen, und die beiden lassen sich verwechseln. Der saubere Weg, sie auseinanderzuhalten, ist dieser: NIS2 ist die breite Grundlinie für Cybersicherheit über viele Sektoren, und DORA ist das Spezialregime für die Finanzbranche, das sie dort verdrängt.

DORA sagt das selbst. Für Finanzeinrichtungen, die zugleich als wesentliche oder wichtige Einrichtungen unter NIS2 gelten, ist DORA "als sektorspezifischer Rechtsakt der Union" im Sinne von NIS2 zu betrachten.¹ Im Klartext: wo DORA und NIS2 beide auf eine Finanzeinrichtung zugreifen würden, gehen DORAs Regeln als das speziellere Gesetz vor. Eine Bank fährt nicht zwei parallele Vorfallsregime. Sie fährt DORAs.

Für einen Entwickler liegt der Unterschied darin, wen du bedienst. Ist mein Kunde eine SaaS Plattform, ein Managed Service Provider oder ein Online Marktplatz, steht NIS2 im Hintergrund, und die Sicherheitsforderungen erreichen mich über die Lieferkettenpflichten dieses Kunden. Ist mein Kunde eine Bank, ein Versicherer oder ein Zahlungsinstitut, steht DORA im Hintergrund, und die Forderungen erreichen mich über die DORA Vertragsklauseln von oben. Die Technik, die ich mache, ist weitgehend dieselbe. Das Papier, die Meldeuhren und die Prüfrechte unterscheiden sich.

Durchgerechnetes Beispiel: ein Linzer Fintech beauftragt mich

Nimm einen erfundenen Kunden: Donau Pay, ein E Geld Institut mit Sitz in Linz, tätig unter donaupay.example. Es gibt E Geld aus und betreibt eine Zahlungs App, es ist also eine von DORA erfasste Finanzeinrichtung.¹ Es beauftragt mich, sein Kundenportal und den Dienst neu zu bauen, der Saldodaten zwischen App und Hauptbuch bewegt. Dieser Dienst liegt hinter einer Funktion, die Donau Pay als kritisch behandelt, denn fällt er aus, sehen Kundinnen und Kunden ihr Geld nicht und können es nicht bewegen.

Ich falle nicht unter DORA. Donau Pay schon. Aber weil meine Arbeit eine kritische Funktion stützt, muss Donau Pay den vollen Satz an Klauseln in meinen Vertrag schreiben, und das landet dann tatsächlich.

Mein Vertrag kommt ins Informationsregister von Donau Pay, und Donau Pay berichtet seiner zuständigen Behörde rechtzeitig von dem Vertrag.¹ Vor der Unterschrift prüft Donau Pay mich sorgfältig: es bewertet das Konzentrationsrisiko, Portal und Hauptbuchabgleich bei einem Lieferanten zu bündeln, prüft, wie ich das Hosting untervergeben würde, und verlangt Belege dafür, wie ich baue und teste.¹

Der Vertrag selbst setzt messbare Dienstgüten für den Hauptbuchabgleich, kein vages "nach bestem Bemühen". Er benennt die Regionen, in denen der Dienst läuft und Daten gespeichert werden, und verlangt eine Vorankündigung, bevor ich sie verlege. Er gibt Donau Pay das Recht, seine Daten in zugänglicher Form zurückzubekommen, falls ich den Betrieb einstelle. Er verpflichtet mich, bei jedem Vorfall zu einem vereinbarten Preis mitzuhelfen und Donau Pay alles zu melden, was meine Lieferfähigkeit beeinträchtigen könnte. Er gewährt Donau Pay, seinen Prüfern und der zuständigen Behörde uneingeschränkte Rechte, das von mir Betriebene zu prüfen, auch vor Ort. Er verlangt, dass ich meine Sicherheit auf Donau Pays regulatorischem Niveau halte und meinen eigenen Wiederanlauf teste. Er verlangt, dass ich am bedrohungsorientierten Penetrationstest von Donau Pay teilnehme, falls meine Systeme im Umfang liegen. Und er setzt eine Ausstiegsstrategie: eine bestimmte Übergangsfrist, in der ich das Portal weiterlaufen lasse, während Donau Pay es woandershin verlegt oder ins Haus holt.¹

Nichts davon verlangt, dass ich eine Bank bin. Es verlangt, dass ich etwas baue, hinter dem ich unter Prüfung stehen kann, dass ich es mit einem Wiederanlaufplan betreibe, den ich tatsächlich getestet habe, und dass ich es sauber übergebe, falls Donau Pay je wechseln will. Könnte ich diese Klauseln nicht erfüllen, sollte ich den Auftrag nicht annehmen. Weil ich ohnehin so baue, ist der Vertrag eine Formsache statt eines Hürdenlaufs.

Wie das in einem Rails Bau aussieht

Übersetz die DORA Klauseln in Technik, und sie werden zu einer vertrauten Liste, derselben Strenge, die ich in jeden geschäftskritischen Bau bringe.

Prüfprotokolle zuerst. Jede Änderung an Saldodaten, jede Admin Handlung, jeder Zugriff auf Kundendaten wird mit wer, was und wann protokolliert, in einem nur anfügbaren Protokoll, das die Anfrage überdauert. Dieses Protokoll ist das, was die Vier Stunden Uhr erreichbar macht und was ein Prüfer sehen will. Ich habe gesondert über das Nachweisen von Compliance mit Release Registern und Tests pro Release geschrieben, und genau nach dieser Aufzeichnung greift ein DORA Prüfrecht.

Wiederanlauf mit echten Zahlen. Geschäftsfortführung unter DORA ist keine Sicherung, von der du hoffst, dass sie funktioniert. Es ist ein Wiederanlauf, den du gestoppt hast. Ich setze eine Wiederanlaufzeit (wie lange, bis der Dienst wieder da ist, RTO) und ein Datenverlustziel (wie viel Daten du verlieren könntest, RPO), dann beweise ich sie auf Staging, indem ich aus der Sicherung wiederherstelle und die Minuten und die Datenlücke aufschreibe. Eine Zahl, die du gemessen hast, schlägt ein Versprechen, das du nicht gemessen hast.

Geringste Rechte und Änderungssteuerung. Mehrfaktor Authentifizierung am Admin Panel, an der Auslieferungskette und an der Produktivkonsole. Rollen so eng geschnitten, dass das Support Team nicht an das Hauptbuch kommt. Änderungen an der Produktion, die durch ein Review gehen und eine Spur hinterlassen. Auf Ruby on Rails ist das gewöhnliche, sorgfältige Technik: verschlüsselte Daten im Ruhezustand, TLS überall, Ratenbegrenzung an der Anmeldung und laufend gepatchte Abhängigkeiten.

Vorfallsreaktion, aufgeschrieben. Ein Ablauf, der sagt, wer einen Vorfall einstuft, wer den Kunden informiert und welche Schritte in den vier und den 72 Stunden anstehen, so geprobt, dass niemand ihn zum ersten Mal in einem echten Vorfall befolgt.

Wie ich dafür baue und kontrahiere

Hier zählt der Ehrlichkeitsschutz am meisten, also sage ich klar, was ich bin und was nicht.

Ich bin Entwickler und Growth Engineer. Ich baue SaaS auf Ruby on Rails und Shops auf Solidus, und ich baue sie von Anfang an sicher und wiederherstellbar: Prüfprotokolle, getesteter Wiederanlauf, geringste Rechte, dokumentierte Vorfallsabläufe und ein unabhängiger Penetrationstest, bevor irgendetwas ins Netz geht. Das ist die Technik, die DORAs Vertragsklauseln beschreiben, und ich kann sie zeigen statt behaupten.

Ich bin keine Finanzeinrichtung, keine Bank, kein reguliertes Institut, und für DORA zu bauen macht mich zu keinem. Ich bin kein Prüfer, und ich stelle niemandem ein Zertifikat aus. Wenn ein Finanzkunde DORA erfüllen muss, besteht meine Rolle darin, so zu bauen und zu kontrahieren, dass er es kann: die Klauseln aus Artikel 30 zu erfüllen, die Belege bereitzuhalten, nach denen ein Prüfrecht greift, bei einem bedrohungsorientierten Test mitzuwirken und unter einem Ausstiegsplan sauber zu übergeben. Die zuständige Behörde des Kunden und seine eigenen Prüfer besorgen das Regulieren. Für DORA und seine nahen Verwandten wie SOC 2, das ich in SOC 2 Type II erklärt behandle, ruht der Maßstab auf der Disziplin, nach der ich baue, nie auf einem Stempel, den ich zu halten behaupte.

Diese Ehrlichkeit ist das Verkaufsargument. Genug Lieferanten erzählen einer Bank, was sie hören will, und entdecken die Prüfrechte und die Ausstiegsklausel erst, wenn der Vertrag vor ihnen liegt. Ich sage dir lieber vorweg, dass diese Klauseln echt sind, dass ihre Erfüllung den Bau teurer macht und dass es sich lohnt, weil es das ist, was die Behörde eines Finanzkunden, und seine Kundschaft, dem von mir gebauten Dienst weiter vertrauen lässt.

Was jetzt zu tun ist

Wenn du eine Finanzeinrichtung bist oder eine belieferst, arbeite diese Punkte der Reihe nach ab.

Verorte dich. Bist du eine Finanzeinrichtung aus Artikel 2 oder ein Lieferant, der über den Vertrag erreicht wird? Belieferst du eine, wirst du fast sicher über den Vertrag erreicht, nicht über eine CTPP Einstufung.
Bist du eine Einrichtung, bring deine IKT Anbieter in ein Informationsregister und mach vor der Unterschrift deine Sorgfaltsprüfung, mit bewertetem Konzentrationsrisiko und bewerteter Untervergabe.
Bring die Vertragsklauseln in Ordnung, trenne die Grundbedingungen von den zusätzlichen für kritische oder wichtige Funktionen, und vergiss die Ausstiegsstrategie nicht.
Bau die Überwachung und Protokollierung, die eine Einstufung und Meldung in vier Stunden möglich machen, denn die Uhr ist eine Anforderung an deine Systeme, bevor sie eine an dein Personal ist.
Setz und teste eine Wiederanlaufzeit und ein Datenverlustziel. Miss sie auf Staging, nimm sie nicht an.
Bist du Lieferant, bau nach den Klauseln, ob ein Kunde sie verlangt oder nicht, damit der Vertrag eine Formsache ist. Behandle Prüfrechte, Mithilfe bei Vorfällen und einen sauberen Ausstieg als normal.
Halt die Linie klar. Für einen regulierten Kunden zu bauen macht dich nicht reguliert. Sag, was du bist, und gib nicht vor, was du nicht bist.

DORA ist streng, und das aus gutem Grund: wenn die Technik hinter Zahlungen und Versicherungen versagt, verlieren Menschen den Zugang zu ihrem eigenen Geld. Die Lieferanten, die es als Grund nehmen, ordentlich zu bauen, statt als zu überstehende Klauseln, enden mit Systemen, die schneller wiederanlaufen, mit Prüfungen, die leise verlaufen, und mit Finanzkunden, die ihnen mehr anvertrauen.