Regulierung & Nachweis

DORA und Cloud-Auslagerung: Was Finanzunternehmen nachweisen müssen

DORA gilt seit dem 17. Januar 2025 unmittelbar, ohne nationales Umsetzungsgesetz und ohne Übergangsfrist. Wer als Finanzunternehmen Cloud-Dienste nutzt, braucht drei Dinge belastbar: ein gepflegtes Informationsregister, Verträge mit den vorgeschriebenen Klauseln und eine Ausstiegsstrategie, die auch dann trägt, wenn niemand aussteigen will. Die Technik ist dabei der einfachere Teil, die Nachweisführung der aufwendige.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Einsteigerin in die Cloud-Administration an zwei Monitoren mit Dashboards

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Was sich gegenüber den alten Rundschreiben geändert hat

DORA ist eine Verordnung und gilt damit direkt, ohne dass ein deutsches Gesetz sie erst übersetzen müsste. Sie erfasst rund zwanzig Arten von Finanzunternehmen, von Banken und Versicherern über Zahlungsdienstleister bis zu Kapitalverwaltungsgesellschaften, und sie erfasst zusätzlich deren Dienstleister für Informations- und Kommunikationstechnik. Die BaFin hat die bisherigen Rundschreiben zu IT-Anforderungen für die von DORA erfassten Unternehmen entsprechend zurückgezogen. Was vorher aufsichtliche Erwartung war, ist jetzt unmittelbar geltendes Recht mit einer Aufsicht, die es abfragt.

Praktisch bedeutet das drei neue Pflichten mit prüfbarem Ergebnis. Erstens das Informationsregister: keine frei gestaltete Liste, sondern ein vorgegebenes Datenmodell mit verknüpften Tabellen für Verträge, Dienstleister, gestützte Funktionen und Weiterverlagerungen. Zweitens ein fester Katalog an Vertragsinhalten, der bei Diensten für kritische oder wichtige Funktionen deutlich umfangreicher ausfällt. Drittens die Ausstiegsstrategie, die als Dokument vorliegen und getestet sein muss, unabhängig davon, ob ein Wechsel geplant ist.

Der Aufwand entsteht selten in der Technik. Er entsteht dort, wo die Zuordnung fehlt: Welcher Vertrag deckt welchen Dienst ab, welche Geschäftsfunktion hängt daran, welcher Unterauftragnehmer sitzt in der Kette, und in welchem Land liegen die Daten tatsächlich. Diese Angaben verlangt das Register je Eintrag, und sie stehen in keinem Systemverzeichnis von selbst. Wer die Erfassung als Tabellenübung angeht, merkt spätestens beim zweiten Meldezyklus, dass die Pflege ohne technische Unterstützung nicht durchzuhalten ist.

Miniatur-Szene: Treppe aus drei Stufen hinauf zu einer schwebenden Cloud, Laptop und Wegweiser

Von der Cloud-Nutzung zum prüffesten Nachweis

01 Alle Dienste erfassen und je Dienst die gestützte Funktion benennen
02 Kritisch oder wichtig einstufen und die Einstufung begründen
03 Vertragsklauseln prüfen und fehlende Punkte nachverhandeln
04 Register befüllen und im vorgegebenen Format melden
05 Ausstiegsstrategie schreiben und mindestens einmal testen
06 Meldeprozess mit den vorgegebenen Fristen einmal üben

Was du mitnimmst

Die fünf Pflichten, die deine Cloud unmittelbar betreffen

DORA regelt weit mehr als Auslagerung. Für den Cloud-Betrieb sind es aber im Kern fünf Punkte, die sich abarbeiten lassen und an denen eine Prüfung ansetzt.

Kritische oder wichtige Funktion feststellen

Alles hängt an dieser Einstufung, denn sie entscheidet über den Umfang aller weiteren Pflichten. Kritisch oder wichtig ist eine Funktion, deren Ausfall die Erbringung der Finanzdienstleistung, die Erfüllung aufsichtlicher Pflichten oder die Finanzlage wesentlich beeinträchtigen würde. Die Einstufung gehört je Dienst dokumentiert, inklusive Begründung, warum ein Dienst nicht kritisch ist.

Informationsregister führen und melden

Das Register erfasst alle vertraglichen Vereinbarungen über die Nutzung von Diensten für Informations- und Kommunikationstechnik, auf Ebene des einzelnen Unternehmens und, wo einschlägig, der Gruppe. Verlangt werden unter anderem Dienstleister samt Kennung, Vertragsdaten, gestützte Funktionen, Datenstandorte und die Kette der Weiterverlagerungen. Die Aufsicht fordert es in einem vorgegebenen Format an, mindestens jährlich.

Verträge nach Artikel 30 nachziehen

Für jeden Vertrag gilt ein Grundkatalog an Klauseln, für Dienste zu kritischen oder wichtigen Funktionen kommt ein zweiter, deutlich schärferer hinzu: vollständige Leistungsbeschreibung mit messbaren Zielen, uneingeschränkte Zugangs-, Einsichts- und Prüfrechte, Angaben zu Datenstandorten, Kündigungsfristen und Unterstützung beim Ausstieg. Standardverträge der großen Anbieter decken das über Zusatzvereinbarungen ab, prüfen musst du es trotzdem.

Ausstiegsstrategie schreiben und testen

Für Dienste zu kritischen oder wichtigen Funktionen verlangt DORA eine Ausstiegsstrategie mit Übergangsplan. Sie muss beantworten, wohin die Last wandert, wie lange der Wechsel dauert, was er kostet und wie die Daten in nutzbarer Form herauskommen. Ein Dokument ohne mindestens einen durchgeführten Test überzeugt in keiner Prüfung, weil die Machbarkeit gerade der springende Punkt ist.

Vorfälle einstufen und fristgerecht melden

Schwerwiegende Vorfälle in der Informationstechnik sind nach festen Kriterien einzustufen und in mehreren Stufen zu melden, von der ersten Meldung über einen Zwischenbericht bis zum Abschlussbericht. Der Prozess muss die Cloud-Anbieter einschließen, denn deren Störungsmeldungen sind oft die einzige Informationsquelle. Das gehört vor dem ersten Ernstfall geübt, nicht danach.

Konzentrationsrisiko und Weiterverlagerung

Vor Vertragsschluss ist zu bewerten, ob eine weitere Bindung an denselben Anbieter ein Klumpenrisiko erzeugt, auch mittelbar über Unterauftragnehmer. Zusätzlich benennen die europäischen Aufsichtsbehörden besonders bedeutende Anbieter und beaufsichtigen sie unmittelbar. Für dich bleibt die Pflicht, die Kette bis zu den wesentlichen Unterauftragnehmern zu kennen und im Register abzubilden.

Tutorial

Von der Einstufung bis zum geübten Meldeprozess

Die Technik ist bei DORA der einfachere Teil, aufwendig ist die Nachweisführung aus Informationsregister, Vertragsklauseln und einer Ausstiegsstrategie, die auch dann trägt, wenn niemand aussteigen will. Weil die Einstufung als kritische oder wichtige Funktion über den gesamten Aufwand entscheidet, steht sie am Anfang. Danach folgen die Bestandserfassung für das Register, die Vertragsinhalte samt technischer Durchsetzung der Zusagen, der testbare Ausstieg und zum Schluss der Meldeprozess für Vorfälle.

Schritt 1: Feststellen, welche Dienste kritische oder wichtige Funktionen stützen

Diese Einstufung ist der Hebel für den gesamten Aufwand. Sie entscheidet, welcher Vertrag nachverhandelt werden muss und für welchen Dienst eine getestete Ausstiegsstrategie nötig ist.

Der Ausgangspunkt ist nicht die Technik, sondern die Geschäftsfunktion. Beginne bei den Prozessen, ohne die das Institut seine Leistungen nicht erbringen oder seine aufsichtlichen Pflichten nicht erfüllen kann, und arbeite dich von dort zu den Systemen vor. Erst danach ordnest du die Cloud-Dienste zu. Der umgekehrte Weg, also von der Ressourcenliste zur Funktion, erzeugt hunderte Einträge ohne Aussage und übersieht gleichzeitig die Abhängigkeit, die über einen scheinbar nebensächlichen Dienst läuft.

Was je Dienst festgehalten wird

Welche Geschäftsfunktion wird gestützt und wie lange darf sie ausfallen
Einstufung als kritisch oder wichtig, mit Begründung auch bei einem Nein
Vertragsverhältnis: welcher Vertrag, welche Laufzeit, welche Kündigungsfrist
Datenstandorte für Verarbeitung und Speicherung, jeweils mit Land
Wesentliche Unterauftragnehmer und was sie beitragen
Wer im Haus fachlich zuständig ist und wer den Vertrag verantwortet

Schritt 2: Den Bestand so erfassen, dass das Register pflegbar bleibt

Das Register lebt von der Verknüpfung zwischen Vertrag, Dienst und Funktion. Die Rohdaten dafür holst du dir aus der Cloud selbst, statt sie abzutippen.

Bestand aus Azure ziehen

az extension add --name resource-graph

az graph query -q "
  Resources
  | project name, type, location, subscriptionId,
            funktion = tostring(tags['dora-funktion']),
            einstufung = tostring(tags['dora-einstufung'])
  | order by type asc
" --first 1000 -o table

# Ressourcen ohne Zuordnung sind die eigentliche Arbeitsliste
az graph query -q "
  Resources
  | where isempty(tags['dora-funktion'])
  | summarize anzahl = count() by type
" -o table

Zwei verpflichtende Kennzeichen genügen für den Anfang: die gestützte Geschäftsfunktion und die Einstufung. Die zweite Abfrage liefert genau die Lücken, und diese Liste ist der Arbeitsvorrat, den ein Prüfer sonst selbst erstellt.

Dasselbe in AWS

aws resourcegroupstaggingapi get-resources \
  --region eu-central-1 \
  --tag-filters Key=dora-funktion \
  --query 'ResourceTagMappingList[].[ResourceARN,Tags[?Key==`dora-funktion`].Value|[0]]' \
  --output table

# Pflichtkennzeichen durchsetzen statt hinterherlaufen
aws organizations create-policy \
  --type TAG_POLICY \
  --name dora-pflichtkennzeichen \
  --content file://tag-policy.json

Kennzeichnungsrichtlinien und entsprechende Azure-Richtlinien verhindern, dass neue Ressourcen ohne Zuordnung entstehen. Ohne diese Durchsetzung ist das Register vier Wochen nach der ersten Erfassung wieder unvollständig.

Was das Register je Eintrag verlangt

Angabe	Woher sie kommt	Typische Lücke
Dienstleister mit eindeutiger Kennung	Vertragsverwaltung, Rechtsträgerkennung des Anbieters	Konzerngesellschaft im Vertrag weicht von der genutzten Einheit ab
Vertragsdaten, Laufzeit, Kündigungsfrist	Einkauf und Rechtsabteilung	Rahmenvertrag vorhanden, die tatsächlich genutzten Leistungen sind nicht zugeordnet
Art der bezogenen Leistung	Technische Bestandsaufnahme	Sammelposten wie Cloud-Dienste ohne Aufschlüsselung
Gestützte Funktion und Einstufung	Fachbereich zusammen mit dem Risikomanagement	Fehlt vollständig oder ist nicht begründet
Standorte von Verarbeitung und Speicherung	Regionseinstellungen und Anbieterangaben	Sicherungen und Protokolldaten liegen in einer anderen Region als die Produktion
Wesentliche Unterauftragnehmer	Anbieterangaben, Zusatzvereinbarungen	Kette endet beim direkten Anbieter, obwohl darunter weitere sitzen

Schritt 3: Verträge und technische Leitplanken zusammenbringen

Was der Vertrag zusagt, muss technisch auch durchgesetzt sein. Eine Klausel zum Datenstandort ohne passende Richtlinie hält keiner Prüfung stand.

Vertragsinhalte, die bei kritischen Funktionen hinzukommen

Vollständige Leistungsbeschreibung mit messbaren ZielenOhne messbare Ziele lässt sich weder eine Verletzung feststellen noch ein Kündigungsrecht begründen. Allgemeine Verfügbarkeitsversprechen reichen dafür nicht.
Angaben zu den Ländern der Verarbeitung und SpeicherungDas Register verlangt diese Angabe je Eintrag. Fehlt sie im Vertrag, bleibt nur die Selbstauskunft des Anbieters, und die ist im Zweifel nicht belastbar.
Uneingeschränkte Zugangs-, Einsichts- und PrüfrechteDie Aufsicht muss diese Rechte ebenfalls ausüben können. Ein Vertrag, der nur Berichte statt Prüfungen zulässt, erfüllt die Anforderung nicht.
Regelungen zur Weiterverlagerung und zur Anzeige von ÄnderungenWechselt ein wesentlicher Unterauftragnehmer, muss das Register nachgezogen werden. Ohne Anzeigepflicht erfährst du davon nicht.
Kündigungsfristen und Unterstützung beim AusstiegDie Ausstiegsstrategie ist nur so gut wie die vertraglich zugesagte Mitwirkung. Ohne zugesagte Übergangsunterstützung wird aus dem Plan eine Absichtserklärung.
Mitwirkung bei Vorfällen und bei bedrohungsgeleiteten TestsMeldefristen laufen ab dem Zeitpunkt der Kenntnis. Ohne vertraglich zugesagte Information des Anbieters kannst du sie nicht einhalten.

Regionsbindung technisch durchsetzen

# Azure: Richtlinie auf der Verwaltungsgruppe, nicht je Abonnement
POLICY=$(az policy definition list \
  --query "[?displayName=='Allowed locations'].name" -o tsv)

az policy assignment create \
  --name dora-nur-eu \
  --scope "/providers/Microsoft.Management/managementGroups/finanz-root" \
  --policy "$POLICY" \
  --params '{"listOfAllowedLocations":{"value":["germanywestcentral","westeurope"]}}'

# AWS: Sperre ueber eine Dienstkontrollrichtlinie
aws organizations create-policy \
  --type SERVICE_CONTROL_POLICY \
  --name dora-nur-eu \
  --content file://scp-eu.json

Die Richtlinie gehört auf die oberste Ebene, damit sie sich in einem einzelnen Konto nicht aushebeln lässt. Denk daran, dass globale Dienste wie Identitätsverwaltung, Abrechnung und Unterstützungsanfragen ausgenommen werden müssen, sonst blockierst du dich selbst.

scp-eu.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NurEuropaeischeRegionen",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "sts:*", "organizations:*", "account:*",
        "support:*", "health:*", "budgets:*", "ce:*", "cur:*",
        "cloudfront:*", "route53:*", "waf:*", "shield:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
        }
      }
    }
  ]
}

Die Ausnahmeliste ist nötig, weil diese Dienste keiner Region zugeordnet sind und über einen festen Endpunkt angesprochen werden. Teste die Richtlinie zuerst in einem eigenen Testkonto, ein zu weit gefasstes Verbot sperrt sonst auch die Verwaltung aus. Wichtig: Auch Abrechnung und Kostenanalyse melden sich in us-east-1 an. Wer budgets und ce in der Ausnahmeliste vergisst, verliert nach dem Ausrollen den Blick auf die eigene Rechnung.

Schritt 4: Die Ausstiegsstrategie testbar machen

Ein Ausstiegsplan ohne Test ist ein Aufsatz. Der Test beantwortet die einzigen Fragen, die im Prüfungsgespräch gestellt werden: Wie lange, zu welchem Preis, mit welchem Ergebnis.

Daten in nutzbarer Form herausholen

# AWS: Objektspeicher vollstaendig ausleiten und Dauer messen
time aws s3 sync s3://prod-dokumente /mnt/exit-test/dokumente --only-show-errors

# Datenbank in einem herstellerneutralen Format sichern
aws rds create-db-snapshot \
  --db-instance-identifier kernbank-prod \
  --db-snapshot-identifier exit-test-2026-07
pg_dump --format=custom --no-owner --dbname="$PROD" --file=/mnt/exit-test/kernbank.dump

# Azure: derselbe Test auf der anderen Seite
az storage blob download-batch \
  --account-name stprodfinanz \
  --source dokumente \
  --destination /mnt/exit-test/dokumente

Miss die Dauer und rechne sie auf die vollständige Datenmenge hoch. Genau diese Zahl gehört in die Ausstiegsstrategie, zusammen mit der Feststellung, welche Daten nur in einem anbietereigenen Format vorliegen und deshalb vorher umgewandelt werden müssen.

Ausstiegsarchiv unveränderlich ablegen

# AWS: Objektsperre mit fester Aufbewahrung
# Object Lock setzt aktivierte Versionierung voraus
aws s3api put-bucket-versioning --bucket protokoll-eu-2026 \
  --versioning-configuration Status=Enabled

aws s3api put-object-lock-configuration \
  --bucket exit-archiv-finanz \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 90 } }
  }'

# Azure: Unveraenderlichkeit auf Containerebene
az storage container immutability-policy create \
  --account-name starchivfinanz \
  --resource-group rg-archiv \
  --container-name exit-archiv \
  --period 90

Im Sperrmodus lässt sich die Aufbewahrung auch mit Vollzugriff nicht verkürzen. Das ist beabsichtigt und heißt zugleich, dass ein zu großzügig gesetzter Zeitraum echte Speicherkosten verursacht, die niemand vorzeitig beenden kann. Achtung: Der Modus COMPLIANCE ist unumkehrbar. Die Aufbewahrung laesst sich weder verkuerzen noch aufheben, auch nicht mit Root-Zugang, und der Bucket laesst sich fuer die volle Frist nicht leeren.

Schritt 5: Vorfälle erkennen, einstufen und fristgerecht melden

Die Meldefristen laufen ab der Kenntnis, nicht ab der Analyse. Deshalb entscheidet die Erkennung darüber, ob der Prozess überhaupt einhaltbar ist.

Auf sicherheitsrelevante Änderungen aufmerksam werden

# Azure: Meldung bei administrativen Aenderungen
az monitor activity-log alert create \
  --name dora-administrativ \
  --resource-group rg-governance \
  --scope "/subscriptions/$SUB" \
  --condition category=Administrative \
  --action-group ag-sicherheitsteam

# AWS: Regel fuer Anmeldungen ohne mehrstufige Authentifizierung
aws events put-rule \
  --name dora-konsolenanmeldung \
  --event-pattern file://anmeldung.json

aws events put-targets \
  --rule dora-konsolenanmeldung \
  --targets Id=1,Arn=arn:aws:sns:eu-central-1:123456789012:sicherheitsteam

Die Meldung an ein Postfach genügt nicht. Es braucht eine benannte Rufbereitschaft, die die Einstufung vornehmen darf, denn die erste Frist läuft in Stunden und nicht in Werktagen.

Meldeprozess, der die Fristen hält

Einstufungskriterien vorab festlegen und im Werkzeug hinterlegenDie Frist für die Erstmeldung bemisst sich an der Einstufung als schwerwiegender Vorfall. Wer die Kriterien erst im Ernstfall diskutiert, verliert die entscheidenden Stunden.
Erstmeldung, Zwischenbericht und Abschlussbericht als Vorlagen vorbereitenNach den technischen Standards folgen die Meldungen in mehreren Stufen mit eigenen Fristen. Vorlagen mit Pflichtfeldern verhindern Rückfragen der Aufsicht und damit weiteren Zeitverlust.
Meldewege des Cloud-Anbieters kennen und im Vertrag verankernBei einer Störung beim Anbieter bist du auf dessen Information angewiesen. Ohne zugesagte Benachrichtigung erfährst du es aus dem Statusportal, und das ist zu spät.
Rufbereitschaft mit Entscheidungsbefugnis benennenDie Einstufung ist eine Entscheidung, keine Analyse. Sie muss auch nachts und am Wochenende von jemandem getroffen werden dürfen.
Den Ablauf einmal jährlich als Trockenübung durchspielenErst die Übung zeigt, ob Kontaktdaten stimmen, Zugänge zum Meldeportal funktionieren und die Vorlagen ausfüllbar sind. Genau danach fragt eine Prüfung.
Bedrohungsgeleitete Tests einplanen, wo sie verlangt sindFür identifizierte Unternehmen sind fortgeschrittene Tests in mehrjährigem Abstand vorgesehen. Sie brauchen Vorlauf, Budget und die vertragliche Mitwirkung der Anbieter.

Für die technische Umsetzung der Erkennungs- und Nachweisseite sind die Sicherheitsdienste beider großer Anbieter der übliche Weg, also Microsoft Defender for Cloud mit Sentinel auf der einen und die Kombination aus CloudTrail, Config, Security Hub und GuardDuty auf der anderen Seite. Wenn ihr zusätzlich ein anerkanntes Testat für die genutzten Dienste braucht, lohnt der Blick auf das BSI-C5-Testat, das viele Prüfer als Nachweis für die Anbieterseite akzeptieren.

Passende Kurse

Kurse zu DORA und Cloud-Auslagerung bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

SC-100 Training: Microsoft Cybersecurity Architect (SC-100T00) 4 Tage Präsenz nächster Termin 07.09.2026 Zum Kurs AZ-500 Training: Microsoft Azure Security Technologies (AZ-500T00-A) 4 Tage Präsenz nächster Termin 05.10.2026 Zum Kurs AWS Security Governance at Scale 1 Tag Präsenz nächster Termin 25.09.2026 Zum Kurs Cloud Operations on AWS 3 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle Azure-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest AZ-500 Quiz - Azure Security Engineer Bereite dich auf die AZ-500 Prüfung vor. Teste dein Wissen zu Azure-Sicherheit, Identity und Netzwerk. Quiz starten

Gut zu wissen

Häufige Fragen zu DORA und Cloud-Auslagerung

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Ist jede Cloud-Nutzung automatisch eine Auslagerung nach DORA?

Nein, DORA arbeitet nicht mit dem alten Auslagerungsbegriff, sondern erfasst alle vertraglichen Vereinbarungen über Dienste der Informations- und Kommunikationstechnik. Damit gehört auch der kleine Speicherdienst ins Register, unabhängig davon, ob er früher als Auslagerung eingestuft worden wäre. Der entscheidende Unterschied liegt eine Stufe weiter: Stützt der Dienst eine kritische oder wichtige Funktion, greifen die zusätzlichen Vertragsanforderungen, die Pflicht zur Ausstiegsstrategie und die vorvertragliche Risikobewertung. Deshalb ist die Einstufung je Dienst der Arbeitsschritt, der über den gesamten Aufwand entscheidet.

Was gehört konkret in das Informationsregister?

Das Format ist vorgegeben und besteht aus mehreren verknüpften Tabellen. Erfasst werden unter anderem das eigene Unternehmen, die Dienstleister mit eindeutiger Kennung, die einzelnen vertraglichen Vereinbarungen mit Laufzeit und Kündigungsfrist, die Art der bezogenen Leistung, die gestützten Geschäftsfunktionen samt Einstufung, die Länder der Verarbeitung und Speicherung sowie die Kette wesentlicher Unterauftragnehmer. Die häufigste Lücke sind nicht fehlende Verträge, sondern die fehlende Verknüpfung zwischen Vertrag, technischem Dienst und Geschäftsfunktion. Genau diese Verknüpfung lässt sich nur mit einem verpflichtenden Kennzeichnungskonzept in der Cloud dauerhaft pflegen.

Wie sieht eine Ausstiegsstrategie aus, die einer Prüfung standhält?

Sie beantwortet vier Fragen belegbar. Wohin wandert die Last, also welcher andere Anbieter oder welche eigene Umgebung kommt in Frage. Wie lange dauert der Wechsel, gemessen an einem echten Testabzug und nicht geschätzt. Was kostet er, inklusive der Entgelte für ausgehenden Datenverkehr und der doppelten Betriebskosten während des Übergangs. Und wie kommen die Daten in einem nutzbaren Format heraus, insbesondere dort, wo anbietereigene Dienste im Spiel sind. Dazu gehört ein Übergangsplan mit Verantwortlichkeiten und mindestens ein durchgeführter Test, dessen Ergebnis dokumentiert ist.

Wie greifen DORA und NIS2 ineinander?

DORA ist für Finanzunternehmen das speziellere Recht und verdrängt insoweit die entsprechenden Anforderungen aus NIS2 im Bereich der Informations- und Kommunikationstechnik. Doppelte Nachweise sind also nicht nötig. Aufwendig wird es in Konzernen mit gemischtem Zuschnitt, etwa wenn eine Bank und ein Dienstleister im selben Verbund sitzen: Dann fällt die eine Gesellschaft unter DORA, die andere unter das nationale NIS2-Recht. In diesem Fall gehört die Abgrenzung je Gesellschaft schriftlich festgehalten, weil sonst weder Meldewege noch Zuständigkeiten eindeutig sind. Technisch lassen sich beide Regime mit denselben Maßnahmen bedienen.

Reicht ein BSI-C5-Testat des Anbieters als Nachweis?

Es hilft, ersetzt aber nichts. Ein C5-Testat deckt die Anbieterseite ab und beantwortet viele Fragen zu Betrieb, Sicherheit und Standorten, die du sonst selbst prüfen müsstest. Es trifft aber keine Aussage darüber, wie du den Dienst nutzt, ob deine Verträge die geforderten Klauseln enthalten, ob dein Register vollständig ist und ob eine Ausstiegsstrategie existiert. Genau diese Punkte sind deine eigene Pflicht und werden auch bei dir geprüft. Sinnvoll ist das Testat deshalb als Baustein der Anbieterbewertung, nicht als Ersatz für die eigene Nachweisführung.

Quellen

Zuletzt geprüft am 28. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.

Rückmeldung aus dem Kurs „Ansible Kompaktkurs“

“

Der Kurs hat sein Ziel erreicht. Der Trainer konnte die Inhalte gut rüberbringen und der Praxisanteil und die Übungsumgebung war sehr gut.

Rückmeldung aus dem Kurs „Terraform mit Azure – Der kompakte Praxiskurs für Ihren Cloud-Erfolg“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.