DORA: Anforderungen an die digitale Betriebsresilienz im Finanzsektor

1. Was ist DORA? Gel­tungs­be­reich und betrof­fe­ne Unter­neh­men #

DORA steht für Digi­tal Ope­ra­tio­nal Resi­li­ence Act. Die Ver­ord­nung schafft einen ein­heit­li­chen Rah­men für das IKT-Risi­ko­ma­nage­ment im euro­päi­schen Finanz­sek­tor und zielt dar­auf ab, dass Finanz­in­sti­tu­te einem brei­ten Spek­trum ope­ra­ti­ver Stö­run­gen stand­hal­ten kön­nen — von Cyber­an­grif­fen über Sys­tem­aus­fäl­le bis hin zu Ver­sa­gen bei Drittdienstleistern.

Wer ist betrof­fen? #

Rund 22.500 Finanz­in­sti­tu­te und IKT-Dienst­leis­ter in der EU fal­len in den Anwen­dungs­be­reich von DORA. Kon­kret betrof­fen sind:

Unter­neh­mens­typ	Bei­spie­le
Kre­dit­in­sti­tu­te	Ban­ken, Spar­kas­sen, Genossenschaftsbanken
Wert­pa­pier­fir­men	Bro­ker, Handelshäuser
Zah­lungs­dienst­leis­ter	Acqui­rer, Issuer, PSPs
E‑Geld-Insti­tu­te	Pre­paid-Kar­ten-Anbie­ter, digi­ta­le Wallets
Ver­si­che­run­gen und Rückversicherungen	Alle Spar­ten
Invest­ment­fonds und Kapitalverwaltungsgesellschaften	OGAW, AIF
Kryp­to­as­set-Dienst­leis­ter	Exch­an­ges, Cus­to­di­ans (unter MiCA)
Daten­be­reit­stel­lungs­diens­te	Han­dels- und Genehmigungssysteme
Kri­ti­sche IKT-Drittdienstleister	Cloud-Anbie­ter, Rechen­zen­tren, Soft­ware­an­bie­ter mit Systemrelevanz

Kleinst­un­ter­neh­men (weni­ger als 10 Mit­ar­bei­ter, weni­ger als 2 Mio. EUR Umsatz) sind von bestimm­ten Anfor­de­run­gen aus­ge­nom­men — der Kern des Regel­werks gilt jedoch für den über­wie­gen­den Teil der Branche.

---

2. Die fünf Säu­len von DORA #

DORA struk­tu­riert sei­ne Anfor­de­run­gen in fünf Berei­che. Jeder Bereich stellt eigen­stän­di­ge ope­ra­ti­ve Pflich­ten auf.

Säu­le 1: IKT-Risi­ko­ma­nage­ment (Art. 5 – 16) #

Finanz­in­sti­tu­te müs­sen einen umfas­sen­den IKT-Risi­ko­rah­men ein­rich­ten, doku­men­tie­ren und regel­mä­ßig tes­ten. Das schließt ein: Risi­ko­iden­ti­fi­ka­ti­on und ‑klas­si­fi­zie­rung, Schutz­maß­nah­men, Erken­nung von Anoma­lien, Reak­ti­ons­ka­pa­zi­tä­ten und Wie­der­her­stel­lungs­ver­fah­ren. Das Lei­tungs­or­gan trägt die Ver­ant­wor­tung — persönlich.

Säu­le 2: IKT-bezo­ge­nes Vor­falls­ma­nage­ment (Art. 17 – 23) #

Wesent­li­che IKT-Vor­fäl­le müs­sen klas­si­fi­ziert, doku­men­tiert und gemel­det wer­den. Die zustän­di­ge Behör­de in Deutsch­land ist die BaFin. Die Fris­ten sind eng: Erst­mel­dung inner­halb von 4 Stun­den nach Klas­si­fi­zie­rung als wesent­li­cher Vor­fall, Abschluss­be­richt inner­halb eines Monats.

Säu­le 3: Tes­ten der digi­ta­len Betriebs­re­si­li­enz (Art. 24 – 27) #

Jähr­li­che Basis­tests sind für alle betrof­fe­nen Unter­neh­men ver­pflich­tend — inklu­si­ve Pene­tra­ti­ons­tests für bedeu­ten­de Insti­tu­te (TLPT: Thre­at-Led Pene­tra­ti­on Test­ing). Tests müs­sen doku­men­tiert, Schwach­stel­len beho­ben und Ergeb­nis­se der Auf­sicht zugäng­lich gemacht werden.

Säu­le 4: IKT-Dritt­par­tei­en­ri­si­ko (Art. 28 – 44) #

Ver­trä­ge mit IKT-Dritt­dienst­leis­tern müs­sen spe­zi­fi­sche DORA-kon­for­me Klau­seln ent­hal­ten: Ver­füg­bar­keits­ga­ran­tien, Aus­stiegs­rech­te, Audit­rech­te, Sub­un­ter­neh­mer­re­ge­lun­gen. Kri­ti­sche IKT-Dritt­dienst­leis­ter wer­den von den euro­päi­schen Auf­sichts­be­hör­den (ESAs) direkt überwacht.

Säu­le 5: Infor­ma­ti­ons­aus­tausch (Art. 45 – 46) #

Finanz­in­sti­tu­te dür­fen — und sol­len — Infor­ma­tio­nen über Cyber­be­dro­hun­gen und Schwach­stel­len unter­ein­an­der tei­len. Frei­wil­li­ge Teil­nah­me an Infor­ma­ti­ons­aus­tausch­ver­ein­ba­run­gen ist aus­drück­lich vor­ge­se­hen und regu­la­to­risch geschützt.

---

3. DORA und Daten­si­che­rung: Was Art. 9 und Art. 12 kon­kret ver­lan­gen #

Back­up und Wie­der­her­stel­lung sind kein Rand­the­ma in DORA — sie sind expli­zit regu­liert. Wer hier lücken­haft auf­ge­stellt ist, hat ein nach­weis­ba­res Compliance-Problem.

Art. 9: Schutz und Prä­ven­ti­on #

Art. 9 ver­langt, dass Finanz­in­sti­tu­te ihre IKT-Sys­te­me vor Daten­ver­lust, unbe­fug­tem Zugriff und Mani­pu­la­ti­on schüt­zen. Das schließt Seg­men­tie­rung, Zugriffs­kon­trol­len und — wo tech­nisch sinn­voll — die phy­si­sche oder logi­sche Iso­la­ti­on schutz­kri­ti­scher Daten­ko­pien ein.

Art. 12: Back­up-Richt­li­ni­en und Wie­der­her­stel­lungs­ver­fah­ren #

Art. 12 ist die zen­tra­le Back­up-Norm unter DORA. Die Anfor­de­run­gen im Überblick:

Anfor­de­rung	Inhalt
Doku­men­tier­te Backup-Richtlinie	Schrift­lich fest­ge­legt, regel­mä­ßig überprüft
RTO/R­PO-Zie­le	Müs­sen defi­niert, doku­men­tiert und getes­tet sein
Täg­li­che Back­ups kri­ti­scher Daten	Min­dest­stan­dard für kri­ti­sche Sys­te­me und Daten
Off­line-Kopien	Wo mög­lich, sind Kopien außer­halb des Pri­mär­netz­werks zu halten
Test­pflicht	Wie­der­her­stel­lungs­ver­fah­ren müs­sen regel­mä­ßig getes­tet werden
Iso­la­ti­on der Backup-Umgebung	Back­up-Sys­te­me müs­sen gegen Angrif­fe auf das Pro­duk­tiv­netz geschützt sein

Beson­ders rele­vant: DORA schreibt nicht nur vor, dass Back­ups exis­tie­ren, son­dern dass sie auch funk­tio­nie­ren. Der Nach­weis der Wie­der­her­stell­bar­keit ist dokumentationspflichtig.

Off­line-Kopien als Schutz­an­for­de­rung #

Die For­mu­lie­rung in Art. 12 ist ein­deu­tig: Wo mög­lich, sind Siche­rungs­ko­pien außer­halb des pri­mä­ren Netz­werks zu hal­ten. Für Finanz­in­sti­tu­te, die Ran­som­wa­re-Sze­na­ri­en in ihren Risi­ko­ana­ly­sen füh­ren, ist das kei­ne theo­re­ti­sche Emp­feh­lung — es ist eine Min­des­ter­war­tung der Aufsicht.

---

Wie set­zen Sie DORA-kon­for­me Daten­si­che­rung in der Pra­xis um? FAST LTA bie­tet Hard­ware-basier­ten Air Gap und unver­aen­der­li­che Spei­cher­ar­chi­tek­tu­ren fuer den Finanz­sek­tor. Spre­chen Sie mit unse­ren Exper­ten. Bera­tung anfra­gen | Silent Brick System

---

4. DORA im Ver­hält­nis zu BAIT, MaRisk und NIS2 #

Eine häu­fi­ge Fra­ge in der Pra­xis: Was gilt noch, was wird abgelöst?

DORA und BAIT #

Die Bank­auf­sicht­li­chen Anfor­de­run­gen an die IT (BAIT) der BaFin sind natio­na­les Auf­sichts­recht. DORA ersetzt BAIT nicht — bei­de gel­ten par­al­lel. Die BaFin hat signa­li­siert, dass BAIT-Anfor­de­run­gen künf­tig stär­ker auf DORA aus­ge­rich­tet wer­den. In der Pra­xis gilt: Wer DORA-kon­form ist, erfüllt in wei­ten Tei­len auch BAIT. Lücken kön­nen jedoch blei­ben, da BAIT in ein­zel­nen Berei­chen spe­zi­fi­scher ist.

DORA und MaRisk #

Die Min­dest­an­for­de­run­gen an das Risi­ko­ma­nage­ment (MaRisk) betref­fen den ope­ra­ti­ven Risi­ko­rah­men von Ban­ken. DORA fokus­siert spe­zi­fisch auf IKT-Risi­ken. Bei­de Regel­wer­ke koexis­tie­ren. MaRisk-pflich­ti­ge Insti­tu­te müs­sen bei­de Anfor­de­rungs­rah­men sepa­rat erfül­len und dokumentieren.

DORA und NIS2 #

Merk­mal	DORA	NIS2
Rechts­form	Ver­ord­nung (EU) — direkt anwendbar	Richt­li­nie — natio­na­le Umset­zung erforderlich
Gel­tungs­be­reich	Finanz­sek­tor spezifisch	Sek­tor­über­grei­fend (16 Sektoren)
Gel­tung in DE seit	17. Janu­ar 2025	6. Dezem­ber 2025 (NIS2UmsuCG)
Ver­hält­nis	Lex spe­cia­lis für Finanzsektor	All­ge­mei­ne Cybersicherheitspflichten
Über­schnei­dung	Mel­de­pflich­ten, Risikomanagement	Erheb­li­che Überschneidung

DORA gilt als lex spe­cia­lis: Für Finanz­in­sti­tu­te, die sowohl unter DORA als auch unter NIS2 fal­len, hat DORA in sei­nem Rege­lungs­be­reich Vor­rang. Die spe­zi­fi­sche­ren DORA-Pflich­ten für IKT-Risi­ko­ma­nage­ment und Vor­falls­mel­dung ver­drän­gen die all­ge­mei­nen NIS2-Vor­ga­ben — sofern ein gleich­wer­ti­ges oder höhe­res Schutz­ni­veau erreicht wird.

Wei­ter­füh­rend: NIS2 ein­fach erklärt: Anfor­de­run­gen, Buß­gel­der, Fristen

---

5. Buß­gel­der und Haf­tung: Was Art. 50 bedeu­tet #

DORA hat Zäh­ne. Die Sank­ti­ons­re­geln sind schär­fer als in vie­len ande­ren Compliance-Regelwerken.

Buß­gel­der für kri­ti­sche IKT-Dritt­dienst­leis­ter #

Art. 50 ermög­licht es den euro­päi­schen Auf­sichts­be­hör­den (EBA, EIOPA, ESMA), gegen kri­ti­sche IKT-Dritt­dienst­leis­ter Buß­gel­der von bis zu 1 % des durch­schnitt­li­chen welt­wei­ten Tages­um­sat­zes des vor­an­ge­gan­ge­nen Geschäfts­jah­res zu ver­hän­gen — und das täg­lich, bis der Ver­stoß been­det ist. Bei gro­ßen Cloud-Pro­vi­dern oder Rechen­zen­trums­dienst­leis­tern sum­miert sich das schnell zu erheb­li­chen Beträgen.

Sank­tio­nen gegen Finanz­in­sti­tu­te #

Für regu­lier­te Finanz­in­sti­tu­te sind die Sank­tio­nen in ers­ter Linie Auf­ga­be der natio­na­len Auf­sichts­be­hör­den. In Deutsch­land ist das die BaFin. Die mög­li­chen Maß­nah­men rei­chen von Ver­war­nun­gen über Anord­nun­gen zur Behe­bung von Män­geln bis hin zu Betriebs­un­ter­sa­gun­gen in Teilbereichen.

Per­sön­li­che Haf­tung des Lei­tungs­or­gans #

Ein Punkt, der in der Pra­xis erheb­li­che Auf­merk­sam­keit ver­dient: DORA adres­siert das Lei­tungs­or­gan direkt. Vor­stand und Geschäfts­füh­rung tra­gen nach Art. 5 die Ver­ant­wor­tung für den IKT-Risi­ko­rah­men und müs­sen aus­rei­chend in IKT-Risi­ko­ma­nage­ment geschult sein. Bei nach­ge­wie­se­nen Ver­stö­ßen kann die Auf­sicht indi­vi­du­el­le Maß­nah­men gegen ver­ant­wort­li­che Per­so­nen ergrei­fen. Die Zei­ten, in denen IKT-Com­pli­ance aus­schließ­lich Auf­ga­be der IT-Abtei­lung war, sind regu­la­to­risch vorbei.

---

6. Fünf kon­kre­te Umset­zungs­schrit­te #

Wer DORA noch nicht voll­stän­dig adres­siert hat, soll­te die fol­gen­den Schrit­te priorisieren:

Schritt 1: Gap-Ana­ly­se gegen die fünf DORA-Säu­len #

Bewer­ten Sie Ihren aktu­el­len IKT-Risi­ko­rah­men sys­te­ma­tisch gegen Art. 5 – 16. Doku­men­ta­ti­ons­lü­cken und feh­len­de Tests sind die häu­figs­ten Schwach­stel­len. Nut­zen Sie dafür ein struk­tu­rier­tes Map­ping — idea­ler­wei­se mit exter­ner Beglei­tung durch einen Wirt­schafts­prü­fer oder Com­pli­ance-Bera­ter, der DORA-Erfah­rung mitbringt.

Schritt 2: RTO und RPO schrift­lich defi­nie­ren und tes­ten #

Art. 12 ver­langt doku­men­tier­te Wie­der­her­stel­lungs­zie­le. Defi­nie­ren Sie für jedes kri­ti­sche Sys­tem kon­kre­te RTO- und RPO-Wer­te, und tes­ten Sie die Wie­der­her­stell­bar­keit regel­mä­ßig. Ein Back­up, das nie getes­tet wur­de, gilt regu­la­to­risch nicht als ver­läss­li­ches Back­up. Wei­ter­füh­rend: RTO und RPO defi­nie­ren: So set­zen Sie rea­lis­ti­sche Wiederherstellungsziele

Schritt 3: Back­up-Iso­la­ti­on sicher­stel­len #

Prü­fen Sie, ob Ihre Back­up-Sys­te­me tat­säch­lich vom Pro­duk­tiv­netz iso­liert sind — nicht nur logisch, son­dern phy­sisch oder durch gal­va­ni­sche Tren­nung. Sys­te­me, die über das­sel­be Netz­werk erreich­bar sind wie die Pri­mär­sys­te­me, sind im Ran­som­wa­re-Sze­na­rio kein ver­läss­li­cher Schutz. Die DORA-For­mu­lie­rung zu Off­line-Kopien (“whe­re tech­ni­cal­ly fea­si­ble”) lässt wenig Inter­pre­ta­ti­ons­spiel­raum, wenn ein Insti­tut kri­ti­sche Daten verarbeitet.

Schritt 4: IKT-Dritt­an­bie­ter­ver­trä­ge prü­fen und anpas­sen #

Gehen Sie alle Ver­trä­ge mit wesent­li­chen IKT-Dienst­leis­tern durch. DORA schreibt spe­zi­fi­sche Ver­trags­klau­seln vor: Audit­rech­te, Ver­füg­bar­keits­ga­ran­tien, Aus­stiegs­re­ge­lun­gen, Sub­un­ter­neh­mer­ma­nage­ment. Ver­trä­ge, die vor 2025 abge­schlos­sen wur­den, ent­spre­chen in aller Regel nicht den DORA-Anforderungen.

Schritt 5: Mel­de­pro­zes­se eta­blie­ren und üben #

4 Stun­den von der Klas­si­fi­zie­rung bis zur Erst­mel­dung an die BaFin — das ist wenig Zeit, wenn kein erprob­ter Pro­zess exis­tiert. Defi­nie­ren Sie jetzt: Wer klas­si­fi­ziert? Wer mel­det? Wel­che Infor­ma­tio­nen wer­den benö­tigt? Tes­ten Sie den Pro­zess mit einer Table­top-Übung, bevor ein rea­ler Vor­fall den Ernst­fall erzwingt. Vor­la­ge: Inci­dent-Respon­se-Plan für IT-Sicherheitsvorfälle

---

Fazit: DORA ist kein Pro­jekt, son­dern ein Betriebs­zu­stand #

DORA ist seit Janu­ar 2025 gel­ten­des Recht. Es gibt kei­ne Über­gangs­frist mehr. Finanz­in­sti­tu­te, die jetzt noch in der Gap-Ana­ly­se ste­cken, sind bereits im Ver­zug. Beson­ders die Back­up- und Wie­der­her­stel­lungs­an­for­de­run­gen aus Art. 12 — Off­line-Kopien, getes­te­te RTO/R­PO-Zie­le, iso­lier­te Back­up-Umge­bun­gen — sind tech­nisch anspruchs­voll und las­sen sich nicht mit rei­nen Soft­ware­kon­fi­gu­ra­tio­nen lösen.

Phy­sisch iso­lier­te Spei­cher­ar­chi­tek­tu­ren, wie sie Silent Brick und Silent Cubes bie­ten, adres­sie­ren genau die­se Anfor­de­run­gen: Hard­ware-basier­ter Air Gap, unver­aen­der­li­che Daten­hal­tung und nach­weis­ba­re Wie­der­her­stell­bar­keit — alles On-Pre­mi­ses und unter voll­stän­di­ger Kon­trol­le des Insti­tuts, ohne Abhän­gig­keit von Cloud-Anbie­tern oder exter­nen Drittdiensten.

---