1. Was DORA zu ICT-Dritt­an­bie­tern kon­kret for­dert (Art. 28 bis 44) #

unter­schei­det sich von frü­he­ren Anfor­de­run­gen wie BAIT oder MaRisk dadurch, dass es ICT-Dritt­an­bie­ter direkt regu­liert, nicht nur die Finanz­in­sti­tu­te, die sie nut­zen. Der regu­la­to­ri­sche Druck wirkt in bei­de Richtungen.

Der Rege­lungs­rah­men im Über­blick #

  • Art. 28 Abs. 3: Infor­ma­ti­ons­re­gis­ter über alle ver­trag­li­chen Ver­ein­ba­run­gen mit ICT-Drittanbietern
  • Art. 28 Abs. 4 und 5: Risi­ko­be­wer­tung vor Ver­trags­ab­schluss, ins­be­son­de­re bei Diens­ten für kri­ti­sche oder wich­ti­ge Funktionen
  • Art. 28 Abs. 8: Exit-Stra­te­gien für ICT-Diens­te, die kri­ti­sche oder wich­ti­ge Funk­tio­nen unterstützen
  • Art. 30: Min­dest­an­for­de­run­gen an Vertragsklauseln
  • Art. 31: Ein­stu­fung kri­ti­scher ICT-Dritt­dienst­leis­ter durch die euro­päi­schen Auf­sichts­be­hör­den (ESAs)
  • Art. 32 bis 44: Über­wa­chungs­rah­men für kri­ti­sche ICT-Dritt­dienst­leis­ter unter direk­ter ESA-Auf­sicht (EBA, EIOPA, ESMA)

Für die ope­ra­ti­ve Umset­zung in IT-Abtei­lun­gen und Com­pli­ance-Teams sind vor allem Art. 28 und 30 rele­vant. Die ESA-Direkt­auf­sicht betrifft die Anbie­ter selbst (zum Bei­spiel gro­ße Cloud-Pro­vi­der). Finanz­in­sti­tu­te müs­sen aber wis­sen und doku­men­tie­ren, ob ihre Anbie­ter als kri­ti­sche ICT-Dritt­dienst­leis­ter ein­ge­stuft sind.

2. Kri­ti­sche oder wich­ti­ge Funk­tio­nen: Die Unter­schei­dung, die alles ver­än­dert #

knüpft die strengs­ten Pflich­ten nicht an den Anbie­ter als sol­chen, son­dern an die Fra­ge, ob ein ICT-Dienst eine kri­ti­sche oder wich­ti­ge Funk­ti­on des Finanz­un­ter­neh­mens unter­stützt. Die­se Ein­stu­fung bestimmt den Auf­wand für Ver­trags­ge­stal­tung, Moni­to­ring und Exit-Planung.

Kri­ti­sche ICT-Dritt­dienst­leis­ter (Ein­stu­fung durch die ESAs) #

Dane­ben gibt es die Ein­stu­fung auf Anbie­ter­ebe­ne: Ein Anbie­ter gilt als kri­ti­scher ICT-Dritt­dienst­leis­ter, wenn ein Aus­fall oder eine Beein­träch­ti­gung sei­ner Leis­tung zu einem sys­te­mi­schen Risi­ko für den Finanz­sek­tor füh­ren kann. Die­se Ein­stu­fung erfolgt durch die euro­päi­schen Auf­sichts­be­hör­den nach Art. 31. Betrof­fe­ne Anbie­ter unter­lie­gen dann der direk­ten ESA-Auf­sicht, unab­hän­gig von ihrer Rechts­form oder ihrem Hauptsitz.

Für Finanz­in­sti­tu­te bedeu­tet das: Prü­fen Sie, ob Ihre Cloud-Back­up-Pro­vi­der auf den ESA-Lis­ten kri­ti­scher ICT-Dritt­dienst­leis­ter erschei­nen, und doku­men­tie­ren Sie das Ergeb­nis im Register.

Diens­te für kri­ti­sche oder wich­ti­ge Funk­tio­nen des Insti­tuts #

Unab­hän­gig von der ESA-Ein­stu­fung gilt: Unter­stützt ein ICT-Dienst eine kri­ti­sche oder wich­ti­ge Funk­ti­on Ihres Unter­neh­mens, grei­fen die ver­schärf­ten Anfor­de­run­gen an Ver­trä­ge (Art. 30 Abs. 3), Risi­ko­be­wer­tung und Exit-Strategie.

Für Back­up-Pro­vi­der: Ein Anbie­ter, der Ihre pri­mä­re Daten­si­che­rung oder Ihr Dis­as­ter Reco­very bereit­stellt, unter­stützt nach -Logik nahe­zu immer eine kri­ti­sche oder wich­ti­ge Funk­ti­on, da der Aus­fall die­ser Funk­ti­on Ihre ope­ra­ti­ve Resi­li­enz direkt beeinträchtigt.

Kon­se­quenz: Iden­ti­fi­zie­ren Sie alle ICT-Dritt­an­bie­ter, die an Back­up, Archi­vie­rung oder Dis­as­ter Reco­very betei­ligt sind, und stu­fen Sie die bezo­ge­nen Diens­te ein. Das Ergeb­nis doku­men­tie­ren Sie im Informationsregister.

3. ICT-Dritt­an­bie­ter-Regis­ter auf­bau­en: Schritt für Schritt #

Das Infor­ma­ti­ons­re­gis­ter ist die Grund­la­ge jeder -Prü­fung. Ohne voll­stän­di­ges und aktu­el­les Regis­ter haben Sie kei­ne Com­pli­ance, unab­hän­gig davon, wie gut Ihre Ein­zel­ver­trä­ge sind.

Schritt 1: Bestands­auf­nah­me #

Erfas­sen Sie alle ICT-Dienst­leis­ter, die für Ihren Betrieb rele­vant sind. Star­ten Sie mit den Kategorien:

  • Cloud-Infra­struk­tur und Hos­ting (IaaS, PaaS)
  • Soft­ware as a Ser­vice (SaaS), Kern- und Nebensysteme
  • Back­up und Dis­as­ter Reco­very (intern und extern bereitgestellt)
  • Netz­werk- und Telekommunikationsanbieter
  • IT-Sicher­heits­dienst­leis­ter (SOC, SIEM, E)
  • War­tungs- und Sup­port-Dienst­leis­ter für Hardware
  • Rechen­zen­trum-Colo­ca­ti­on

Typi­scher Feh­ler: Nur die gro­ßen Ver­trä­ge erfas­sen und spe­zia­li­sier­te Nischen­an­bie­ter über­se­hen, zum Bei­spiel den Back­up-Soft­ware-Her­stel­ler, des­sen Agent auf jedem Ser­ver läuft, oder den Hard­ware-War­tungs­an­bie­ter mit Remo­te-Zugang zu Storage-Systemen.

Schritt 2: Min­dest-Daten­fel­der pro Anbie­ter #

Art. 28 Abs. 3 ver­langt ein Infor­ma­ti­ons­re­gis­ter auf Ebe­ne der ver­trag­li­chen Ver­ein­ba­run­gen; die tech­ni­schen Durch­füh­rungs­stan­dards der ESAs defi­nie­ren die Pflicht­fel­der. Erfas­sen Sie mindestens:

  • Name des Anbie­ters (Pflicht): voll­stän­di­ger recht­li­cher Name
  • Art der bezo­ge­nen Diens­te (Pflicht): wel­che ICT-Funk­ti­on wird erbracht?
  • Unter­stütz­te Geschäfts­funk­tio­nen (Pflicht): wel­che kri­ti­schen oder wich­ti­gen Funk­tio­nen sind abhängig?
  • Ein­stu­fung (Pflicht): unter­stützt der Dienst eine kri­ti­sche oder wich­ti­ge Funktion?
  • Land des Anbie­ters (Pflicht): Haupt­sitz, rele­vant für Rechts­rah­men und Datenschutz
  • Unter­auf­trag­neh­mer (Pflicht): rele­van­te Sub-Dienst­leis­ter des Anbieters
  • Ver­trags­be­ginn und Lauf­zeit (Pflicht): mit Kündigungsfristen
  • SLA-Kenn­zah­len (emp­foh­len): Ver­füg­bar­keit, RTO, RPO
  • Audit­rech­te ver­trag­lich ver­ein­bart (emp­foh­len): ja oder nein
  • Exit-Stra­te­gie vor­han­den (emp­foh­len): Refe­renz auf das Exit-Plan-Dokument
  • Letz­tes Review-Datum (emp­foh­len): wann wur­de der Anbie­ter zuletzt bewertet?

Schritt 3: Prio­ri­sie­rung und Pfle­ge #

Füh­ren Sie das Regis­ter in einem Sys­tem, das Ver­sio­nie­rung und Ände­rungs­his­to­rie unter­stützt. Aktua­li­sie­ren Sie es min­des­tens jähr­lich sowie anlass­be­zo­gen bei:

  • Neu­ver­trä­gen oder wesent­li­chen Vertragsänderungen
  • Sicher­heits­vor­fäl­len beim Anbieter
  • Über­nah­men oder Insol­ven­zen im Anbieterumfeld
  • Ände­rung der eige­nen Systemlandschaft

4. Ver­trags­an­for­de­run­gen nach DORA Art. 30: Was muss drin ste­hen? #

Art. 30 ist die detail­lier­tes­te Ver­trags­vor­schrift, die der euro­päi­sche Finanz­sek­tor je bekom­men hat. Prü­fen Sie bestehen­de Ver­trä­ge gegen die­se Anfor­de­run­gen und for­dern Sie Ergän­zun­gen, wo sie fehlen.

Pflicht­in­hal­te nach Art. 30 Abs. 2 und 3 DORA #

Beschrei­bung der Diens­te: Der Ver­trag muss eine voll­stän­di­ge Beschrei­bung der ICT-Diens­te ent­hal­ten, ein­schließ­lich der Unter­auf­trag­neh­mer, die wesent­li­che Tei­le der Leis­tung erbringen.

Stand­or­te der Daten­ver­ar­bei­tung: Wo wer­den Ihre Daten ver­ar­bei­tet und gespei­chert? Das muss ver­trag­lich fixiert sein, inklu­si­ve der Ver­pflich­tung, Stand­or­t­än­de­run­gen vor­ab zu kommunizieren.

Daten­zu­gang und Daten­rück­ga­be: Der Ver­trag muss regeln, wie Sie im Kri­sen­fall, bei Insol­venz des Anbie­ters oder bei Ver­trags­en­de voll­stän­di­gen Zugang zu Ihren Daten erhal­ten und die­se in einem gän­gi­gen For­mat zurückerhalten.

Ver­füg­bar­keits­ga­ran­tien und Leis­tungs­ni­veaus: SLAs sind kein Nice-to-have, sie sind -Pflicht. Defi­nie­ren Sie RTO und RPO ver­trag­lich für alle kri­ti­schen Funktionen.

Audit­rech­te: Sie müs­sen das Recht haben, den Anbie­ter selbst oder durch Drit­te zu audi­tie­ren. Ein Ver­trag ohne Audit­recht für Diens­te mit kri­ti­schen oder wich­ti­gen Funk­tio­nen ist nicht -konform.

Koope­ra­ti­ons­pflich­ten: Der Anbie­ter muss mit Ihrer zustän­di­gen Auf­sichts­be­hör­de koope­rie­ren, wenn die­se Infor­ma­tio­nen anfordert.

Kün­di­gungs­rech­te: Defi­nier­te Kün­di­gungs­grün­de, auch bei regu­la­to­risch beding­ten Been­di­gun­gen, und ange­mes­se­ne Kündigungsfristen.

Exit-Unter­stüt­zung: Der Anbie­ter muss bei der Been­di­gung des Ver­trags­ver­hält­nis­ses aktiv unter­stüt­zen: Daten­mi­gra­ti­on, Wis­sens­trans­fer, par­al­le­ler Betrieb wäh­rend der Transition.

Prüf­lis­te für bestehen­de Ver­trä­ge #

Gehen Sie Ihre bestehen­den Ver­trä­ge mit ICT-Dritt­an­bie­tern gegen die­se Lis­te durch. Fehlt ein Pflicht­in­halt, haben Sie Ver­hand­lungs­be­darf, und bei Diens­ten für kri­ti­sche oder wich­ti­ge Funk­tio­nen einen regu­la­to­ri­schen Man­gel, der in der nächs­ten BaFin-Prü­fung auffällt.

5. Exit-Stra­te­gie: War­um Cloud-Back­up-Pro­vi­der ein DORA-Risi­ko sein kön­nen #

Art. 28 Abs. 8 ver­langt Exit-Stra­te­gien für ICT-Diens­te, die kri­ti­sche oder wich­ti­ge Funk­tio­nen unter­stüt­zen. Das ist kein for­ma­ler Com­pli­ance-Bau­stein, son­dern die prak­ti­sche Kon­se­quenz aus der Erkennt­nis, dass Lock-in ein ope­ra­ti­ves Risi­ko ist.

Das Lock-in-Pro­blem bei Cloud-Back­up-Pro­vi­dern #

Cloud-Back­up-Anbie­ter erzeu­gen struk­tu­rel­len Lock-in auf meh­re­ren Ebenen:

Daten­men­ge und Egress-Kos­ten: Wer gro­ße Back­up-Daten­men­gen in der Cloud hat, braucht für den Exit Wochen bis Mona­te und zahlt erheb­li­che Daten­trans­fer­kos­ten. Die­se wirt­schaft­li­che Bar­rie­re erschwert den Exit im Kri­sen­fall massiv.

Pro­prie­tä­re For­ma­te: Vie­le Back­up-as-a-Ser­vice-Lösun­gen spei­chern Daten in her­stel­ler­spe­zi­fi­schen For­ma­ten. Ohne Lizenz des bis­he­ri­gen Anbie­ters sind die­se Daten nicht les­bar. Der Exit bedeu­tet dann Daten­ver­lust oder Neu­si­che­rung von Grund auf.

Abhän­gig­keit von Anbie­ter-Infra­struk­tur für Reco­very: Wenn ein Reco­very nur mit den Tools des Anbie­ters funk­tio­niert, ist die Wie­der­her­stel­lung bei Insol­venz des Anbie­ters oder regu­la­to­risch erzwun­ge­nem Anbie­ter­wech­sel gefährdet.

Was eine DORA-kon­for­me Exit-Stra­te­gie ent­hal­ten muss #

  • Zeit­plan: Wie lan­ge dau­ert eine voll­stän­di­ge Migra­ti­on zu einem ande­ren Anbieter?
  • Daten­por­ta­bi­li­tät: In wel­chem For­mat lie­gen die Daten vor, und kön­nen sie ohne Anbie­ter-Tools gele­sen werden?
  • Par­al­lel­be­trieb: Kann der bis­he­ri­ge Anbie­ter wäh­rend der Tran­si­ti­on weiterarbeiten?
  • Ver­ant­wort­lich­kei­ten: Wer im Unter­neh­men ist für die Exit-Pla­nung zuständig?
  • Test­zy­klus: Wann wur­de der Exit-Plan zuletzt geprobt?

6. DORA-Risi­ko­be­wer­tung: Cloud-Back­up-Pro­vi­der vs. On-Pre­mi­ses #

  • ICT-Dritt­an­bie­ter-Abhän­gig­keit: Beim Cloud-Pro­vi­der hoch durch lau­fen­de ope­ra­ti­ve Abhän­gig­keit; On-Pre­mi­ses gering, beschränkt auf Her­stel­ler für Hard­ware und Wartung.
  • Daten­sou­ve­rä­ni­tät: In der Cloud ein­ge­schränkt, die Daten lie­gen beim Anbie­ter; On-Pre­mi­ses voll­stän­dig unter eige­ner Kontrolle.
  • Exit-Auf­wand: In der Cloud hoch (Daten­mi­gra­ti­on, Egress-Kos­ten, For­mat­fra­gen); On-Pre­mi­ses gering, die Daten blei­ben im Haus.
  • Lock-in-Risi­ko: In der Cloud struk­tu­rell vor­han­den; On-Pre­mi­ses für Betriebs­da­ten nicht vorhanden.
  • Audit­recht: Gegen­über Cloud-Pro­vi­dern oft nur ein­ge­schränkt durch­setz­bar (SOC-2-Bericht statt Direkt­au­dit); On-Pre­mi­ses voll­stän­dig, eige­ne Infrastruktur.
  • Stand­ort der Daten­ver­ar­bei­tung: In der Cloud ver­trag­lich fixier­bar, aber fak­tisch schwer kon­trol­lier­bar; On-Pre­mi­ses bekannt und phy­sisch kontrolliert.
  • Ver­füg­bar­keit bei Anbie­ter­aus­fall: In der Cloud gefähr­det, das Reco­very hängt an der Anbie­ter-Infra­struk­tur; On-Pre­mi­ses nicht betroffen.
  • Ver­trags­klau­seln nach Art. 30: Bei Hypers­ca­lern nur ein­ge­schränkt ver­han­del­bar; für den lau­fen­den On-Pre­mi­ses-Betrieb nicht erforderlich.
  • Exit-Stra­te­gie nach Art. 28 Abs. 8: In der Cloud kom­plex und oft teu­er; On-Pre­mi­ses ein­fach, kei­ne exter­ne Abhängigkeit.
  • Risi­ko bei Anbie­ter-Insol­venz: In der Cloud hoch, das Reco­very ist gefähr­det; On-Pre­mi­ses nicht vorhanden.

Fazit: On-Pre­mi­ses-Spei­cher redu­ziert die Anzahl der -pflich­ti­gen ICT-Dritt­an­bie­ter-Bezie­hun­gen struk­tu­rell. Das ver­ein­facht Ihr Regis­ter, Ihre Ver­trags­ar­beit und Ihre Exit-Pla­nung und redu­ziert das ope­ra­ti­ve Risi­ko bei einem erzwun­ge­nen Anbieterwechsel.

Das bedeu­tet nicht, dass Cloud-Lösun­gen in jedem Fall unge­eig­net sind. Aber jede Cloud-Back­up-Lösung erzeugt eine ICT-Dritt­an­bie­ter-Abhän­gig­keit, die Sie voll­stän­dig nach Art. 28 bis 30 mana­gen müs­sen. Wer On-Pre­mi­ses sichert, hat die­sen Auf­wand für die lau­fen­de Daten­hal­tung nicht.

7. Der Daten­sou­ve­rä­ni­täts-Aspekt: War­um der Stand­ort der Daten zählt #

Art. 30 ver­langt, dass Ver­trä­ge die Stand­or­te der Daten­ver­ar­bei­tung fest­schrei­ben. Das ist kein büro­kra­ti­sches Detail, es hat direk­te Kon­se­quen­zen für Ihre .

Das US-CLOUD-Act-Pro­blem: Daten, die bei US-Anbie­tern gespei­chert sind, unab­hän­gig davon, in wel­chem Land die Ser­ver ste­hen, kön­nen US-Behör­den auf Grund­la­ge des CLOUD Act anfor­dern. Ein Ver­trag mit dem deut­schen Rechen­zen­trum eines US-Unter­neh­mens schützt nicht vor die­ser Zugriffsmöglichkeit.

Prak­ti­sche Kon­se­quenz für : Ihr Infor­ma­ti­ons­re­gis­ter muss den Haupt­sitz des Anbie­ters und damit des­sen Rechts­rah­men aus­wei­sen. Wenn Ihr Back­up-Anbie­ter dem US CLOUD Act unter­liegt, ist das ein doku­men­tier­tes Risi­ko, das Sie ent­we­der akzep­tie­ren, miti­gie­ren oder durch einen alter­na­ti­ven Anbie­ter eli­mi­nie­ren müssen.

On-Pre­mi­ses-Spei­cher unter eige­ner phy­si­scher Kon­trol­le, betrie­ben mit Hard­ware eines Her­stel­lers mit Sitz in der EU, eli­mi­niert die­ses Risi­ko für die lau­fen­de Daten­ver­ar­bei­tung. FAST LTA hat Fir­men­sitz und Fer­ti­gung in Mün­chen; Silent Brick Sys­te­me und Silent Cubes wer­den in Deutsch­land ent­wi­ckelt und produziert.

8. Check­lis­te für das nächs­te DORA-Audit #

Nut­zen Sie die­se Check­lis­te zur Vor­be­rei­tung auf BaFin-Prü­fun­gen oder inter­ne -Assessments.

ICT-Dritt­an­bie­ter-Regis­ter

  • Alle ICT-Dritt­an­bie­ter voll­stän­dig erfasst (kein Anbie­ter mit Sys­tem­zu­gang fehlt)
  • Ein­stu­fung der Diens­te (kri­ti­sche oder wich­ti­ge Funk­ti­on ja/​nein) durch­ge­führt und dokumentiert
  • Regis­ter inner­halb der letz­ten 12 Mona­te aktualisiert
  • Unter­auf­trag­neh­mer wesent­li­cher Anbie­ter erfasst

Ver­trags­kon­for­mi­tät nach Art. 30

  • Alle Pflicht­in­hal­te nach Art. 30 in Ver­trä­gen mit wesent­li­chen Anbie­tern vorhanden
  • Audit­rech­te ver­trag­lich verankert
  • Stand­ort der Daten­ver­ar­bei­tung ver­trag­lich fixiert
  • Daten­zu­gang und Daten­rück­ga­be bei Ver­trags­en­de geregelt
  • RTO und RPO für kri­ti­sche Funk­tio­nen ver­trag­lich festgelegt

Exit-Stra­te­gien nach Art. 28 Abs. 8

  • Exit-Stra­te­gie für jeden wesent­li­chen Anbie­ter dokumentiert
  • Zeit­plan und Kos­ten für Migra­ti­on beziffert
  • Daten­por­ta­bi­li­tät geprüft (For­mat, Tools, Abhängigkeiten)
  • Exit-Plan min­des­tens ein­mal geprobt oder im Table­top-Exer­cise geprüft

Risi­ko­über­wa­chung

  • Pro­zess für anlass­be­zo­ge­ne Neu­be­wer­tung von Anbie­tern definiert
  • Ver­ant­wort­li­che für ICT-Dritt­an­bie­ter-Moni­to­ring nament­lich benannt
  • Eska­la­ti­ons­pfad bei Sicher­heits­vor­fall beim Anbie­ter dokumentiert

Daten­sou­ve­rä­ni­tät

  • Rechts­rah­men aller wesent­li­chen Anbie­ter doku­men­tiert (EU oder Drittland)
  • US-CLOUD-Act-Risi­ko für alle rele­van­ten Anbie­ter bewertet
  • Rest­ri­si­ken aus Dritt­land-Rechts­rah­men akzep­tiert, miti­giert oder eliminiert

Wei­ter­füh­ren­de Res­sour­cen #

→ : Anfor­de­run­gen, Back­up-Pflich­ten und Buß­gel­der im Finanz­sek­tor (/de/­b­log/­do­ra-anfor­de­run­gen-finanz­sek­tor/) → Was ist Daten­sou­ve­rä­ni­tät? (/de/­b­log/­was-ist-daten­sou­ve­rae­ni­tae­t/) → EU US Data Pri­va­cy Frame­work: Was Finanz­un­ter­neh­men wis­sen müs­sen (/de/­b­log/eu-us-data-pri­va­cy-frame­wor­k/) → US Cloud Act: Was er für euro­päi­sche Unter­neh­men bedeu­tet (/de/­b­log/us-cloud-act-erklaer­t/) → Lie­fer­ket­ten­si­cher­heit nach NIS2: Hard­ware-Her­stel­ler bewer­ten (/de/­b­log/­lie­fer­ket­ten­si­cher­heit-nis2-hard­ware/)

Disclaimer

Dieser Beitrag wurde redaktionell erstellt und mit KI-Unterstützung aufbereitet. Er gibt einen allgemeinen Überblick und stellt keine Rechtsberatung dar – für Ihre konkrete Situation empfehlen wir professionellen Rat.