Es gibt eine Frage, die in Audit-Gesprächen zunehmend auftaucht und die viele IT-Verantwortliche noch immer überrascht: „Haben Sie einen dokumentierten Exit-Plan für Ihre kritischen Cloud-Dienstleister?“
Vor drei Jahren war diese Frage eine Rarität. Heute ist sie Standard. Und in regulierten Branchen, also Finanzdienstleistungen, kritische Infrastrukturen, Gesundheitswesen etc., ist sie längst keine freundliche Anregung mehr, sondern eine prüfbare Anforderung mit Konsequenzen.
Was sich verändert hat: Die Regulatorik hat aufgeholt. Europäische Gesetzgeber haben erkannt, dass die Abhängigkeit von wenigen großen Cloud-Anbietern ein systemisches Risiko darstellt. Nicht nur für einzelne Unternehmen, sondern für ganze Branchen und kritische Infrastrukturen. Die Antwort darauf ist ein wachsendes Geflecht an Vorschriften, die Exit-Readiness explizit einfordern.
Dieser Blog-Beitrag gibt einen strukturierten Überblick über die relevantesten Rahmenwerke und erklärt, was sie konkret bedeuten, wenn der Auditor vor der Tür steht.
Keine Zeit zum Lesen?
Dann hören Sie sich den Beitrag einfach an. Unsere Hörversion vermittelt Ihnen die wichtigsten Inhalte kompakt und verständlich – ideal für unterwegs oder zwischendurch.
DORA ist seit Januar 2025 in der EU verpflichtend anwendbar und richtet sich primär an Finanzunternehmen: Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister, Kreditinstitute und deren IKT-Dienstleister. Der Anwendungsbereich ist deutlich breiter als viele zunächst angenommen haben.
DORA adressiert Cloud-Abhängigkeiten auf zwei Ebenen, die für das Thema Exit-Readiness direkt relevant sind:
Concentration Risk ist eines der Kernkonzepte. DORA verlangt, dass Finanzunternehmen aktiv bewerten und dokumentieren, ob eine übermäßige Abhängigkeit von einzelnen IKT-Drittdienstleistern besteht und welche Risiken daraus entstehen. Ein Unternehmen, das seine gesamte digitale Infrastruktur auf Microsoft aufgebaut hat, ohne Fallback-Optionen oder eine dokumentierte Exit-Strategie, hat per Definition ein Concentration-Risk-Problem im Sinne von DORA.
Exit-Strategien für kritische IKT-Dienstleister sind nach DORA explizit zu dokumentieren. Artikel 28 des Gesetzes verlangt, dass Finanzunternehmen für kritische Drittanbieter einen schriftlichen Exit-Plan vorhalten, einschließlich Zeitplanung, Verantwortlichkeiten, Migrationsszenarien und Nachweis der technischen Umsetzbarkeit. Dieser Plan muss nicht bedeuten, dass der Ausstieg geplant ist. Er muss bedeuten, dass er möglich ist und, dass das Unternehmen das belegen kann.
Für Unternehmen, die Microsoft als kritischen IKT-Dienstleister eingestuft haben, und das sollten alle tun, bei denen Microsoft substanzielle Teile ihrer IT-Landschaft darstellen, ist ein dokumentierter Exit-Plan damit keine Option, sondern Pflicht.
Was Auditoren unter DORA prüfen:
NIS2 ist die überarbeitete und erheblich erweiterte Fassung der ursprünglichen NIS-Richtlinie aus dem Jahr 2016. Sie gilt seit Oktober 2024 und erstreckt sich auf deutlich mehr Sektoren als ihr Vorgänger: Energie, Verkehr, Bankwesen, Gesundheitswesen, digitale Infrastruktur, öffentliche Verwaltung, Raumfahrt und viele weitere.
Im Kontext von Cloud-Abhängigkeiten und Exit-Readiness sind zwei Aspekte von NIS2 besonders relevant:
Lieferkettensicherheit ist ein zentrales NIS2-Thema. Unternehmen müssen nicht nur ihre eigene IT-Sicherheit nachweisen, sondern auch die Sicherheit ihrer digitalen Lieferkette bewerten und steuern. Ein Cloud-Anbieter wie Microsoft ist Teil dieser Lieferkette und Abhängigkeiten von ihm sind als Lieferkettenrisiken zu behandeln. Das bedeutet: Risikoanalyse, vertragliche Absicherung, Monitoring und im Fall kritischer Abhängigkeiten eine Notfallplanung.
Incident Response und Ausfallsicherheit verlangen, dass Unternehmen nachweisen können, wie sie im Falle eines Ausfalls eines Cloud-Dienstes weiteroperieren können. Wer keine Fallback-Lösung und keinen dokumentierten Notfallplan hat, erfüllt diese Anforderung nicht.
NIS2 unterscheidet zwischen „wesentlichen“ und „wichtigen“ Einrichtungen, mit unterschiedlichen Anforderungsniveaus. Aber auch für „wichtige“ Einrichtungen ist der Erwartungsrahmen substanziell und die Aufsichtsbehörden haben in mehreren Mitgliedstaaten signalisiert, dass sie aktiv prüfen werden.
Was Auditoren unter NIS2 prüfen:
Die DSGVO ist seit 2018 in Kraft und trotzdem bestehen in vielen Unternehmen noch erhebliche Unsicherheiten, wenn es um den Einsatz US-amerikanischer Cloud-Dienste geht. Das hat einen Grund: Die Rechtslage ist tatsächlich komplex und hat sich mehrfach verändert.
Der Kern des Problems ist der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) von 2018. Er verpflichtet US-Unternehmen, darunter Microsoft, Google und Amazon, dazu, US-Behörden auf Anfrage Zugang zu gespeicherten Daten zu gewähren. Unabhängig davon, in welchem Land diese Daten physisch gespeichert sind. Also auch dann, wenn Ihre Daten in Microsofts Rechenzentrum in Frankfurt liegen.
Der Schrems-II-Entscheid des Europäischen Gerichtshofs aus dem Jahr 2020 hat den Privacy Shield (das bis dahin gültige Transferabkommen zwischen EU und USA) für ungültig erklärt, weil US-Überwachungsgesetze keine ausreichenden Garantien für europäische Datenschutzrechte bieten. Seither müssen Unternehmen, die personenbezogene Daten in die USA übermitteln (oder US-Anbieter nutzen, die theoretisch Zugriff auf diese Daten haben), ein sogenanntes Transfer Impact Assessment (TIA) durchführen.
Das EU-US Data Privacy Framework, das 2023 in Kraft getreten ist, hat eine neue rechtliche Grundlage für Datentransfers geschaffen. Microsoft ist als zertifizierter Anbieter registriert. Das entspannt die Situation, aber löst sie nicht vollständig. Erstens steht eine erneute Klage vor dem EuGH nicht aus (Schrems III ist bereits in Diskussion). Zweitens ändert das Framework nichts an der grundsätzlichen Reichweite des CLOUD Act.
Für Unternehmen bedeutet das konkret: Die DSGVO-Prüfung der Microsoft-Nutzung ist eine laufende Aufgabe, keine einmalige Zertifizierung. Und Exit-Readiness, also die Fähigkeit, im Zweifelsfall auf EU-ansässige Anbieter umzusteigen, ist ein relevantes Instrument der Datenschutz-Risikosteuerung.
Was Auditoren und Datenschutzbehörden prüfen:
Der BSI Cloud Computing Compliance Criteria Catalogue (C5) ist ein deutsches Prüfschema, das das Bundesamt für Sicherheit in der Informationstechnik entwickelt hat. Es richtet sich an Cloud-Anbieter, wird aber zunehmend auch als Anforderungsrahmen für Cloud-Nutzer herangezogen, insbesondere im öffentlichen Sektor und in regulierten Branchen.
C5 enthält explizite Anforderungen an Datenportabilität und Reversibilität: Cloud-Anbieter müssen sicherstellen, dass Kunden ihre Daten vollständig und in strukturierter Form exportieren können. Für Cloud-Nutzer bedeutet das die Verantwortung, diesen Export auch tatsächlich zu planen, zu testen und zu dokumentieren.
ISO 27001, der internationale Standard für Informationssicherheits-Managementsysteme, adressiert Cloud-Abhängigkeiten indirekt, aber substanziell. Die Norm verlangt eine vollständige Risikobehandlung und Cloud-Konzentration ist ein identifizierbares, bewertbares und behandlungspflichtiges Risiko. Wer ISO 27001 implementiert und Cloud-Exit-Risiken nicht im Risikoregister erfasst hat, hat eine Lücke im ISMS.
Was Auditoren unter C5 und ISO 27001 prüfen:
Theorie ist das eine. Was passiert wirklich, wenn der Auditor im Raum sitzt?
Aus der Praxis lassen sich die relevantesten Fragen auf drei Kernbereiche verdichten:
„Haben Sie einen dokumentierten Exit-Plan für Ihre kritischen Cloud-Dienstleister?“
Die richtige Antwort ist nicht: „Wir vertrauen Microsoft.“ Die richtige Antwort ist ein Dokument, das Scope, Szenarien, Zeitschätzungen, Verantwortlichkeiten und Migrationsschritte enthält und das zeigt, dass Ihr Unternehmen die Frage ernsthaft durchgedacht hat.
Was Auditoren nicht akzeptieren: mündliche Versicherungen, allgemeine Hinweise auf Microsoft-eigene Business-Continuity-Maßnahmen oder den Verweis auf SLAs des Anbieters. SLAs regeln, was Microsoft im Falle eines Ausfalls tut, nicht, was das Unternehmen selbst tun kann.
„Können Sie Ihre Daten innerhalb von X Wochen migrieren?“
Diese Frage zielt auf operative Exit-Fähigkeit ab. Auditoren wollen eine realistische Zeitschätzung sehen, keine theoretische. Idealerweise unterlegt durch einen getesteten Export-Prozess, zumindest durch eine fundierte Schätzung auf Basis einer Datenkartierung.
Die kritische Folgefrage lautet oft: „Haben Sie das jemals getestet?“ Wer hier „Nein“ sagen muss, hat ein Problem, auch wenn der Plan auf dem Papier plausibel klingt. Ein ungetesteter Exit-Plan ist für Auditoren ein signifikanter Schwachpunkt.
„Welche Abhängigkeiten bestehen zu einem Single-Cloud-Anbieter und wie managen Sie dieses Risiko?“
Hier geht es um Concentration Risk im Sinne von DORA und NIS2. Auditoren erwarten nicht zwingend, dass Unternehmen Multi-Cloud-Strategien fahren, aber sie erwarten, dass das Risiko der Abhängigkeit bewusst ist, bewertet wurde und in einem Maßnahmenplan mündet.
Akzeptable Antworten: eine dokumentierte Risikoanalyse, ein priorisierter Maßnahmenplan, regelmäßige Reviews. Nicht akzeptabel: „Das war noch nie ein Thema“ oder „Das betrifft uns nicht.“
Business Continuity Management (BCM) ist der organisatorische Rahmen, der sicherstellt, dass ein Unternehmen auch unter widrigen Bedingungen handlungsfähig bleibt. Cloud-Ausfälle, Anbieterwechsel und regulatorisch erzwungene Migrationen sind Szenarien, die in jeden ernsthaften BCM-Prozess gehören.
In der Praxis ist die Integration von Cloud-Exit-Szenarien in das BCM jedoch noch die Ausnahme. Viele Unternehmen haben BCM-Konzepte, die Rechenzentrumsausfälle, Ransomware-Angriffe oder Naturkatastrophen abdecken, aber keinen Plan für den Fall, dass ein Cloud-Anbieter ausfällt, seinen Service einstellt oder unter regulatorischen Druck gerät.
Eine vollständige BCM-Integration des Cloud-Exit-Themas umfasst:
Wer BCM ernst nimmt, kommt an diesen Fragen nicht vorbei. Und wer Exit-Readiness in den BCM-Prozess integriert, schlägt zwei Fliegen mit einer Klappe: Er ist operativ resilienter und er kann das gegenüber Auditoren strukturiert nachweisen.
Aus der Beratungspraxis lassen sich einige Muster erkennen, die in Audits immer wieder auftauchen, anonymisiert, aber repräsentativ:
Finding 1: Fehlender oder veralteter Exit-Plan Ein mittelgroßes Finanzdienstleistungsunternehmen kann im DORA-Audit keinen dokumentierten Exit-Plan vorweisen. Es existiert ein allgemeines Notfallkonzept, das Cloud-Dienste aber nur am Rande erwähnt. Das Finding wird als „wesentliche Lücke“ eingestuft. Nachbesserungsfrist: 6 Monate.
Finding 2: Concentration Risk nicht im Risikoregister Ein Industrieunternehmen mit ISO-27001-Zertifizierung hat in seinem Risikoregister keine spezifischen Einträge zur Cloud-Abhängigkeit von Microsoft. Die Abhängigkeit ist faktisch hoch (M365, Azure, Dynamics 365), aber nie als eigenständiges Risiko formalisiert worden. Das Finding führt zu einem Korrekturmaßnahmenplan, der eine vollständige Risikoanalyse und Maßnahmenplanung vorsieht.
Finding 3: Kein Transfer Impact Assessment für Microsoft Ein Unternehmen im Gesundheitsbereich nutzt Microsoft 365 für die Verwaltung sensibler Patientendaten. Ein TIA für die Microsoft-Nutzung wurde nie erstellt – man verlässt sich auf die Microsoft-eigenen Datenschutzdokumente. Der Datenschutzbeauftragte stuft das als kritisches Finding ein.
Finding 4: Ungetesteter Datenexport Ein Versicherungsunternehmen gibt im Audit an, dass ein Datenexport aus Microsoft 365 „technisch möglich“ sei. Auf Nachfrage stellt sich heraus, dass der Export-Prozess nie vollständig getestet wurde und für mehrere Dienste (insbesondere Teams und SharePoint-Metadaten) keine dokumentierte Vorgehensweise existiert. Das Finding wird als mittleres Risiko eingestuft, da die Grundlage vorhanden, aber nicht verifiziert ist.
Finding 5: Fehlende vertragliche Exit-Klauseln Ein Unternehmen hat seinen Microsoft-Vertrag nie auf Exit-relevante Klauseln geprüft: Kündigungsfristen, Datenlöschfristen, Exportrechte, Supportverpflichtungen in der Übergangsphase. Im Audit stellt sich heraus, dass einige dieser Klauseln unklar oder für das Unternehmen nachteilig formuliert sind. Das Finding führt zu einer Vertragsüberprüfung durch externe Rechtsanwälte.
Fazit
Regulatorik macht Exit-Readiness zur Pflicht, unabhängig von der Exit-Entscheidung
Die zentrale Botschaft dieses Beitrags ist so einfach wie wichtig: Exit-Readiness ist keine strategische Option für mutige IT-Leiter. Sie ist eine regulatorische Anforderung für immer mehr Unternehmen, in immer mehr Branchen, mit immer konkreteren Prüfanforderungen.
Das bedeutet nicht, dass jedes Unternehmen sofort einen vollständigen Exit-Plan erstellen muss. Es bedeutet, dass der Weg dorthin, also Transparenz über Abhängigkeiten, Risikoanalyse, erste Maßnahmen etc. jetzt beginnen sollte. Denn wer wartet, bis der Auditor fragt, hat bereits zu lange gewartet.
Der gute Ausblick: Die meisten Anforderungen lassen sich mit überschaubarem Aufwand erfüllen, wenn man strukturiert vorgeht. Ein dokumentierter Exit-Plan muss kein 200-seitiges Werk sein. Eine Risikoanalyse muss kein Großprojekt sein. Und ein Transfer Impact Assessment ist ein bekanntes, handhabbares Format.
Was es braucht, ist der erste Schritt: eine ehrliche Bestandsaufnahme dessen, wo man steht.
Ob DORA-Vorbereitung, NIS2-Gap-Analyse oder DSGVO-Review für Ihre Microsoft-Nutzung – wir unterstützen Sie dabei, strukturiert, pragmatisch und ohne unnötigen Aufwand audit-tauglich zu werden.
→ Sprechen Sie mit uns über Ihre nächste Audit-Vorbereitung
Ein erstes Gespräch kostet Sie 30 Minuten – und gibt Ihnen einen klaren Überblick darüber, wo Ihre größten Lücken liegen und was Sie als nächstes tun sollten.
Im dritten Teil unserer Serie geht es um die praktische Umsetzung:
Wir zeigen Ihnen, welche konkreten Maßnahmen Sie heute ergreifen können – ohne große Investitionen und ohne Exit-Entscheidung.
Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an
Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.