DORA und Microsoft 365: Drittanbieter-Risikomanagement in 6 Schritten
DORA (Digital Operational Resilience Act) ist seit Januar 2025 für Finanzunternehmen verbindlich. Microsoft 365 ist in jedem Finanzunternehmen ein kritischer ICT-Drittanbieter. Artikel 28 verlangt eine vollständige Risikoanalyse mit Konzentrationsrisiko, Subprozessoren-Liste und Exit-Strategie. Dieser Artikel zeigt das DORA-konforme Mapping in sechs Schritten.
Warum Microsoft eine kritische Auslagerung ist
DORA Artikel 28 unterscheidet zwischen "kritischen" und nicht-kritischen ICT-Drittanbietern. Kritisch ist ein Drittanbieter, dessen Ausfall die Geschäftsfortführung wesentlich beeinträchtigen würde. Microsoft 365 fällt in praktisch jedem Finanzunternehmen unter diese Kategorie.
Die DORA-Anforderung ist nicht "Microsoft prüfen". Microsoft hat als designierter kritischer ICT-Drittanbieter selbst aufsichtliche Pflichten. Die Anforderung an Sie als Finanzunternehmen ist: dokumentieren, dass Sie Microsoft als Risiko verstanden haben, das Konzentrationsrisiko bewertet haben und einen Exit-Pfad skizziert haben.
Das ist nicht trivial, aber strukturiert machbar. Sechs Schritte führen zur DORA-konformen Dokumentation.
ICT-Drittanbieter-Register anlegen
Das Register ist die zentrale Dokumentation aller ICT-Drittanbieter. Pro Drittanbieter werden mindestens diese Felder dokumentiert: Name, Service-Beschreibung, Kritikalität (kritisch/nicht-kritisch), Vertragsdaten, DPA-Status, EU Data Boundary-Status, Subdienstleister, Risiko-Bewertung, Exit-Strategie-Reifegrad.
Microsoft wird als kritischer ICT-Drittanbieter klassifiziert. Pro M365-Service (Exchange, SharePoint, Teams, Defender, Purview) wird ein Sub-Eintrag im Register angelegt, weil die Service-Levels und Subdienstleister pro Service differieren können.
Aktion: ICT-Drittanbieter-Register als SharePoint-Liste oder dediziertes Tool anlegen, Microsoft als kritischen Drittanbieter eintragen, pro M365-Service Sub-Eintrag pflegen.
EU Data Boundary aktivieren
EU Data Boundary stellt sicher, dass Customer Data in der EU verarbeitet und gespeichert wird. Das ist seit 2024 verfügbar und sollte bei jedem Finanzunternehmen aktiviert sein. Aktivierung über die Microsoft 365 Admin Center Compliance-Einstellungen.
Wichtig: EU Data Boundary deckt Customer Data ab, nicht alle Diagnose-Daten und Service-Generated-Data. Diese können weiterhin in nicht-EU-Regionen verarbeitet werden. Die Einschränkungen sind in der Microsoft EU Data Boundary Documentation transparent dokumentiert und werden im DORA-Register vermerkt.
Aktion: EU Data Boundary aktivieren, Konfigurationsstand im Register dokumentieren, Einschränkungen bei Diagnose-Daten transparent erfassen.
Customer Lockbox dokumentieren
Customer Lockbox bietet die Möglichkeit, Microsoft-Support-Zugriffe auf Tenant-Daten explizit zu genehmigen. Ohne Lockbox kann Microsoft-Support im Notfall ohne explizite Kunden-Genehmigung auf Customer Data zugreifen. Mit Lockbox ist jeder solche Zugriff genehmigungspflichtig und auditierbar.
Lockbox ist in E5 lizenziert und in den meisten Finanzunternehmen empfohlen. Der Genehmigungs-Workflow wird mit drei bis fünf Personen besetzt, die in 2-Stunden-Reaktionszeit verfügbar sind. Längere Reaktionszeiten würden Microsoft-Support praktisch blockieren.
Aktion: Customer Lockbox aktivieren, Approver-Pool mit 3 bis 5 Personen aufstellen, 2-Stunden-Reaktionszeit-Vereinbarung treffen, Konfiguration im Register dokumentieren.
Konzentrationsrisiko bewerten
DORA verlangt eine Bewertung des Konzentrationsrisikos: was passiert, wenn Microsoft als zentraler ICT-Drittanbieter ausfällt? Die Bewertung ist nicht trivial, weil Microsoft 365 in modernen Finanzunternehmen oft tief in alle Geschäftsprozesse integriert ist.
Die pragmatische Bewertung: pro Geschäftsprozess wird die Microsoft-Abhängigkeit eingestuft (vollständig abhängig / teilweise abhängig / nicht abhängig). Für vollständig abhängige Prozesse wird eine Continuity-Strategie skizziert: was tun wir bei mehrtägigem Ausfall, wie kommunizieren wir mit Kunden, welche manuellen Prozesse aktivieren wir.
Aktion: Geschäftsprozess-Inventar erstellen, Microsoft-Abhängigkeit pro Prozess bewerten, Continuity-Strategie für vollständig abhängige Prozesse skizzieren.
Exit-Strategie skizzieren
DORA verlangt eine Exit-Strategie für kritische ICT-Drittanbieter. Bei Microsoft ist das anspruchsvoll, weil eine echte Migration weg von M365 in einem mittleren Finanzunternehmen 12 bis 24 Monate dauert.
Die DORA-konforme Exit-Strategie ist nicht "wir migrieren in 6 Monaten weg". Es ist ein dokumentierter Plan, der zeigt, dass eine Migration grundsätzlich möglich wäre, mit groben Zeitfenstern, alternativen Anbietern (Google Workspace, andere Cloud-Office-Suites) und Daten-Export-Verfahren.
Wichtig: Exit ist nicht das gleiche wie Continuity. Continuity beantwortet "was tun bei Ausfall", Exit beantwortet "was tun bei Vertragsende oder Anbieter-Wechsel-Notwendigkeit".
Aktion: Exit-Strategie als 3- bis 5-Seiten-Doku erstellen, alternative Anbieter benennen, Daten-Export-Verfahren grob skizzieren, im Register verlinken.
Vorfallsmeldeprozess nach Artikel 18
DORA Artikel 18 verlangt Meldung größerer ICT-Vorfälle an die zuständige Aufsicht. Die Meldeschwellen sind in den RTS (Regulatory Technical Standards) definiert. Bei M365-relevanten Vorfällen muss klar sein: wer erkennt den Vorfall, wer bewertet die Schwelle, wer meldet wann an die BaFin.
Der Prozess wird typisch über Microsoft Sentinel mit Defender-Alerts gespeist. Sentinel-Incidents werden nach SOC-Triage in die ICT-Vorfallsmeldepflicht-Bewertung eingeführt. Die Bewertung erfolgt nach den RTS-Schwellen. Bei meldepflichtigen Vorfällen wird in 4 Stunden initial gemeldet, in 72 Stunden detailliert.
Aktion: Sentinel-Incident-Routing in den ICT-Vorfallsmeldeprozess integrieren, RTS-Schwellen pro Vorfallstyp dokumentieren, 4-Stunden- und 72-Stunden-Eskalationspfad konfigurieren.
Faustregel: DORA ist anders als BaFin-Audit. Es geht nicht primär um technische Härtung, sondern um Nachweis. Wer eine ordentliche Konfiguration nicht dokumentiert, hat keine Konfiguration im DORA-Sinne.
Die sechs Schritte lassen sich in 4 bis 6 Wochen abarbeiten. Der größte Aufwand liegt in den Schritten 4 (Konzentrationsrisiko) und 5 (Exit-Strategie), weil hier organisatorische und Geschäftsprozess-Analysen erforderlich sind. Die technischen Schritte 2, 3 und 6 sind in Tagen umsetzbar. Wer DORA-Vorbereitung als technisches Projekt versteht, unterschätzt sie. Wer sie als organisatorisches Projekt mit technischer Umsetzung versteht, schafft sie in der gegebenen Zeit.
Audit & Dokumentation
Wir bauen mit Ihnen das DORA-konforme ICT-Drittanbieter-Register für Microsoft und alle weiteren kritischen Cloud-Anbieter. Inklusive Konzentrationsrisiko-Analyse und Exit-Strategie.
Zur DORA-Vorbereitung