Juli 2026
Autor des Beitrags
Daniel
Principle Consultant
Business Consulting
Veröffentlicht am
30.07.2026 von Daniel
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter

Cloud Exit als Enterprise Risk Management – Was Auditoren und Regulatoren erwarten

 

DORA, NIS2, DSGVO & Co. – Exit-Fähigkeit wird zur Compliance-Pflicht

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.

 

Der regulatorische Rahmen: Was gilt für wen

 

DORA – Digital Operational Resilience Act

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:

  • Ist Microsoft als kritischer IKT-Drittdienstleister identifiziert und dokumentiert?
  • Gibt es eine aktuelle Risikoanalyse zum Concentration Risk?
  • Liegt ein Exit-Plan vor, der die Anforderungen des Artikels 28 erfüllt?
  • Wurde der Plan getestet und wenn ja, wann und mit welchem Ergebnis?

NIS2 – Netzwerk- und Informationssicherheitsrichtlinie

 

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:

  • Sind Cloud-Anbieter als Teil der digitalen Lieferkette identifiziert und risikobewacht?
  • Gibt es einen Notfallplan für den Ausfall kritischer Cloud-Dienste?
  • Sind Verträge mit Cloud-Anbietern auf Sicherheitsanforderungen geprüft?
  • Gibt es Meldeprozesse für Cloud-bezogene Sicherheitsvorfälle?

DSGVO und Schrems II – Das ungelöste Datentransferproblem

 

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:

  • Liegt ein Transfer Impact Assessment für die Nutzung von Microsoft-Diensten vor?
  • Sind die Standardvertragsklauseln (SCCs) aktuell und korrekt eingesetzt?
  • Werden Datenkategorien und -flüsse dokumentiert (Verarbeitungsverzeichnis)?
  • Gibt es eine Strategie für den Fall, dass das aktuelle Transferabkommen erneut für ungültig erklärt wird?

BSI C5 und ISO 27001 – Portabilität als Sicherheitsprinzip

 

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:

  • Sind Cloud-Dienstleister im Risikoregister erfasst und bewertet?
  • Gibt es dokumentierte Maßnahmen zur Risikobehandlung bei Cloud-Konzentration?
  • Wurde Datenportabilität vertraglich und technisch abgesichert?
  • Gibt es ein Business-Continuity-Konzept für den Ausfall kritischer Cloud-Dienste?

Was Auditoren konkret fragen – und was sie hören wollen

 

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.“

Cloud Exit als Teil des Business Continuity Managements

 

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:

  • Szenarioplanung: Welche Exit-Szenarien sind realistisch? (Regulatorisch erzwungen, kommerziell motiviert, technisch notwendig, Sicherheitsvorfall beim Anbieter)
  • Business Impact Analysis: Welche Geschäftsprozesse sind wie lange von welchen Cloud-Diensten abhängig und was kostet ein Ausfall pro Stunde, pro Tag, pro Woche?
  • Recovery Time Objective (RTO): Wie schnell muss ein Exit vollzogen sein, damit der Betrieb aufrechterhalten werden kann?
  • Testzyklen: Wie oft werden Exit-Szenarien zumindest im Trockentest durchgespielt?

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.

Typische Audit-Findings in der Praxis

 

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.


 

Bereit für Ihren nächsten Audit?

 

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.

Sie möchten mehr Infos?

Wir sind für Sie da.

Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen?
Wir sind gerne für Sie da.

 

HEIKO WESSELS

+49 89 71040920

heiko@provectus.de

 

Zum Kontaktformular

 

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.

Zur Newsletter Anmeldung 

Blogbeitrag

Cloud Exit als Enterprise Risk Management – Was Auditoren und Regulatoren erwarten

DORA, NIS2, DSGVO & Co. erhöhen die Anforderungen an den Umgang mit Cloud-Abhängigkeiten. Wir zeigen, warum Exit-Readiness zunehmend zur Compliance-Pflicht wird und welche Nachweise Auditoren konkret erwarten.
Weiterlesen
Blogbeitrag

Typische KI-Workflows im Unternehmen: Welche Aufgaben in Chat, Agenten und Zielsysteme gehören

Gute KI-Workflows entstehen durch klare Arbeitsteilung: Wir zeigen, welches Werkzeug sich für welchen Arbeitsschritt eignet – und wie KI dadurch effizienter und wirtschaftlicher wird.
Weiterlesen
Blogbeitrag

Warum Cloud Exit kein Widerspruch zur Cloud-Strategie ist

Was bedeutet Cloud Exit wirklich? Erfahren Sie, warum Unternehmen trotz Microsoft Cloud auf Exit-Readiness setzen sollten und welche Rolle DORA, NIS2 und DSGVO spielen.
Weiterlesen
Webinar

12.500 € verbrannt und niemand merkt’s: So verhindern Managed Services Kostenfallen und Risiken

In diesem kostenlosen Webinar erfahren Sie, wie Azure-Kostenfallen entstehen, wie Fehlkonfigurationen frühzeitig erkannt werden und welche Betriebsstandards Managed Services dafür einsetzen.
Weiterlesen
Blogbeitrag

KI wirtschaftlich einsetzen: Warum nicht jede Aufgabe einen KI-Agenten braucht

Nicht jede Aufgabe braucht einen KI-Agenten – und nicht jede Automatisierung überhaupt KI. Erfahren Sie, wie Sie für jede Anforderung die passende Lösung wählen und KI wirtschaftlich, effizient und mit der richtigen Komplexität einsetzen.
Weiterlesen
Blogbeitrag

Microsoft NGO Tour 2026

Die Microsoft NGO Tour hat einmal mehr gezeigt, wie viel Potenzial in diesem Austausch steckt. Die besten Lösungen entstehen dort, wo Menschen ihr Wissen teilen, unterschiedliche Perspektiven zusammenkommen und Herausforderungen gemeinsam gedacht werden.
Weiterlesen
Blogbeitrag

Echtes Zero Trust im Citrix-Workspace mit deviceTRUST

Conditional Access prüft beim Login, deviceTRUST während der gesamten Citrix-Session: kontinuierlich und kontextbasiert. Wie du deine Citrix-Umgebung zu einem Zero-Trust-Workspace weiterentwickelst, der Security-Anforderungen und Alltag der Fachbereiche zusammenbringt.
Weiterlesen
Blogbeitrag

Secure Boot 2026: Warum Unternehmen jetzt handeln sollten

2026 laufen wichtige Secure-Boot-Zertifikate ab – erfahren Sie, warum Unternehmen ihre Systeme schon heute prüfen und vorbereiten sollten.
Weiterlesen
Blogbeitrag

KI wirtschaftlich einsetzen: Warum der richtige Workflow wichtiger ist als der Prompt

Mit der verbrauchsabhängigen Abrechnung von Microsoft Copilot Cowork wird Wirtschaftlichkeit im KI-Einsatz zur operativen Frage. Der Artikel zeigt, warum nicht der Prompt, sondern vor allem der passende Workflow über Aufwand, Transparenz und Nutzen entscheidet.
Weiterlesen
Blogbeitrag

US-Urteil zur FTC: Handlungsbedarf für Microsoft-Kunden?

Das Urteil des US Supreme Court zur FTC sorgt für neue Fragen rund um das EU-US Data Privacy Framework. Wir ordnen ein, was das für Microsoft 365, Azure und die nächsten Schritte in der Praxis bedeutet.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter