Warum Cloud-Abhängigkeit für deutsche Unternehmen zum Betriebsrisiko wird

Was der Cloud-Befund für Unternehmen bedeutet

Die eigentliche Aussage hinter der Heise-Meldung ist nicht, dass Cloud grundsätzlich falsch wäre. Das Problem beginnt dort, wo aus effizienter Cloud-Nutzung eine schwer steuerbare Abhängigkeit wird. Wenn geschäftskritische Anwendungen, Identitäten, Backups, Integrationen und Betriebswissen an wenige Plattformen oder sogar an eine einzelne Region gekoppelt sind, wird ein technisches Komfortmodell schnell zu einem Geschäftsrisiko.

Der Anlass dafür ist belastbar genug, um ernst genommen zu werden: Heise verweist auf eine Lünendonk-Studie, nach der 83 Prozent der befragten Unternehmen ein einseitiges Abschalten oder Einschränken kritischer Cloud-Services für realistisch halten. Gleichzeitig haben nur 57 Prozent eine Exit-Strategie. Anders gesagt: Ein relevanter Teil der befragten Organisationen sieht das Risiko, hat aber keinen ausformulierten Plan B. Das ist weniger eine Technikpanne als ein Führungsproblem.

Für viele Unternehmen ist die kritische Frage deshalb nicht mehr "Nutzen wir Cloud?", sondern: Welche Teile unseres Betriebs dürfen wie lange ausfallen, und welche echte Ausweichoption existiert dann noch? Diese Frage ist härter, als sie klingt. Denn ein Cloud-Ausfall bedeutet oft nicht nur, dass ein Server kurz nicht erreichbar ist. Häufig hängen daran auch Anmeldung, API-Verbindungen, Monitoring, Datenzugriff, Deployments und externe Partnerprozesse.

Gerade deshalb ist die Cloud-Debatte heute enger mit Geschäftskontinuität verknüpft als noch vor wenigen Jahren. Was früher als Architekturentscheidung galt, wird zunehmend zu einer Frage von Steuerbarkeit, Nachweisbarkeit und Krisenfähigkeit. Das sieht man nicht nur an Ausfallmeldungen, sondern auch daran, dass Aufsicht und Politik das Thema inzwischen explizit unter Resilienz, Souveränität und Drittparteirisiko einordnen.

Kurz gesagt:

• Ereignis: Die aktuelle Heise-Einordnung greift eine Studie auf, in der viele Unternehmen Cloud-Abhängigkeit bereits als realistisches Risikoszenario bewerten.
• Bedeutung: Gefährlich ist nicht die Cloud selbst, sondern fehlende Ausweichfähigkeit bei kritischen Abhängigkeiten.
• Nächste Prüffrage: Welche Kernprozesse in Ihrem Unternehmen würden bei einem Ausfall von Identität, DNS, API-Zugriff oder einer Provider-Region zuerst stehenbleiben?

Welche Quellen diese Einordnung tragen

Wichtig ist, die Meldung nicht zu überdehnen. Die zitierte Studie ist ein Stimmungsbild aus 155 befragten Entscheidern aus DACH-Unternehmen und kein vollständiger Marktüberblick über die gesamte deutsche Wirtschaft. Sie ist trotzdem relevant, weil sie einen Punkt sichtbar macht, den viele IT-Verantwortliche aus dem Alltag kennen: Exit-Fähigkeit wird gern behauptet, aber selten real getestet.

Dazu kommen belastbare Primär- und Behördenquellen. Die Deutsche Bundesbank beschreibt zusammen mit der BaFin Cloud-Auslagerungen ausdrücklich als Thema, das überwacht, kontrolliert und im bestehenden Aufsichtsrahmen gesteuert werden muss. In der überarbeiteten Aufsichtsmitteilung wurden Kapitel zu sicherer Anwendungsentwicklung, IT-Betrieb in der Cloud sowie zur Überwachung und Kontrolle von Cloud-Auslagerungen ergänzt. Außerdem wird dort bereits auf DORA verwiesen, das seit Januar 2025 anzuwenden ist. Das macht klar: Cloud-Risiko ist nicht mehr nur ein Architekturthema, sondern ein Governance-Thema.

Als aktuelles Praxisbeispiel taugt das Cloudflare-Postmortem vom 20. Februar 2026. Dort führte ein Bug in einer automatisierten Bereinigungsroutine dazu, dass BYOIP-Präfixe und abhängige Bindings fälschlich entfernt wurden. Für den Leser ist weniger der Spezialfall entscheidend als die Lehre daraus: Auch hochautomatisierte Plattformen können durch fehlerhafte Prozesse in einen Störungsmodus geraten, und Wiederherstellung ist nicht automatisch sofort trivial.

Ergänzend lohnt der Blick auf die Anbieterperspektive. AWS betont auf seiner Resilienz-Seite selbst, dass Unternehmen RTO- und RPO-Ziele definieren, Schwachstellen per Fault Injection testen, Backups absichern und Wiederherstellung über Zonen oder Regionen hinweg nachweisbar machen sollten. Das ist kein neutraler Beweis für Marktrisiken, aber ein nützlicher Hinweis darauf, welche Art von Absicherung selbst große Plattformen für nötig halten.

Die politische Großwetterlage geht in dieselbe Richtung. Die EU-Kommission hat am 17. April 2026 vier parallele Verträge für souveräne Cloud-Dienste vergeben und dies ausdrücklich mit Diversifizierung, Resilienz und dem Vermeiden einer Überabhängigkeit von einem einzelnen Anbieter verbunden. Das ist kein Argument gegen Public Cloud, aber ein klares Signal dafür, wie Institutionen heute über strategische Cloud-Abhängigkeit denken.

Welche Ausfälle wirklich ins Geschäft schlagen

Cloud-Risiko wird oft zu eng als Rechenzentrums- oder Serverfrage verstanden. In der Praxis brechen meist zuerst die indirekten Ketten.

Da ist zunächst die Identitätsebene: Wenn SSO, IAM oder angebundene Verzeichnisdienste gestört sind, kommen Mitarbeiter nicht in Systeme, Admins nicht in Konsolen und automatisierte Prozesse nicht an ihre Berechtigungen. Ein Unternehmen kann dann funktional stehen, obwohl die eigentliche Anwendung technisch noch läuft.

Als Nächstes folgt die Namens- und Erreichbarkeitsebene. Wenn DNS, Routing oder Netzwerkkonfigurationen klemmen, wirkt der Ausfall für Nutzer wie ein Komplettstillstand. Genau deshalb ist ein Grundverständnis von Abhängigkeiten in der Auflösung und Erreichbarkeit wichtig; wer das intern besser einordnen will, findet dazu im Guide DNS einfach erklärt: Website oder E-Mail haken? einen guten Einstieg.

Dann gibt es die Anwendungskette. Ein CRM kann formal erreichbar sein, aber trotzdem praktisch ausfallen, wenn Authentifizierung, Dateispeicher, Messaging, Observability oder ein externes API-Gateway nicht verfügbar sind. Gerade SaaS-Stacks bestehen selten aus einem einzigen Dienst, sondern aus vielen gekoppelten Diensten. Wer besser verstehen will, warum solche Integrationen so störanfällig sein können, kann das mit API einfach erklärt: So verbinden sich Tools greifbarer machen.

Hinzu kommt die Betriebs- und Recovery-Ebene. Viele Teams haben zwar Backups, aber keine getestete Wiederherstellung unter realen Zeitvorgaben. Oder sie betreiben Multi-Region, hängen aber trotzdem am selben Identitätsdienst, demselben Supportpfad oder denselben Datenformaten. Dann steigt die gefühlte Verfügbarkeit, ohne dass echte Geschäftskontinuität entsteht.

Entscheidend ist deshalb der Unterschied zwischen hochverfügbar und ausweichfähig. Hochverfügbarkeit hilft gegen viele technische Ausfälle. Ausweichfähigkeit beantwortet dagegen die härtere Frage: Kommt der Betrieb auch dann zurück, wenn die primäre Betriebsannahme nicht mehr gilt?

Wo Cloud-Risiko zu Sicherheitsrisiko wird

Cloud-Abhängigkeit ist nicht nur ein Verfügbarkeitsthema. Sie wird spätestens dann zum Sicherheitsrisiko, wenn Zugriffsmodelle, Drittparteien, Betriebsprozesse und Nachweise unklar sind.

Erstens geht es um Zugriff und Kontrolle. Wer darf in einem Störungsfall noch was? Gibt es Break-Glass-Konten, getrennte Administrationspfade, lokale Exportmöglichkeiten, dokumentierte Freigaben und unabhängige Wiederherstellungswege? Wenn hier alles an einem einzigen Identitäts- oder Kontrollpfad hängt, ist nicht nur die Verfügbarkeit fragil, sondern auch die Handlungsfähigkeit des Teams.

Zweitens geht es um Drittparteirisiken. Kaum ein Cloud- oder SaaS-Betrieb besteht heute nur aus einem Anbieter. Externe Authentifizierung, CDN, DNS, Storage, Ticketing, Security-Tools, Observability und Entwicklerdienste bilden eine Lieferkette. Fällt ein Glied aus oder ändert sich ein Vertrags- oder Zugriffsrahmen abrupt, kann das weit über einen einzelnen Dienst hinausreichen.

Drittens wird das Thema über Governance und Nachweisbarkeit scharf. Genau hier setzt die Aufsicht an. Die Bundesbank formuliert klar, dass Cloud-Auslagerungen überwacht und gesteuert werden müssen und dass der bestehende Aufsichtsrahmen konsequent zu nutzen ist. Für regulierte Unternehmen ist das unmittelbar relevant. Für nicht regulierte Unternehmen ist es ein starkes Vorbild dafür, wie professionelles Drittparteien- und Betriebsrisiko heute gedacht wird.

Wer also nur auf SLA-Prozente schaut, verpasst den Kern. Ein guter SLA-Wert ersetzt weder Exit-Fähigkeit noch getestete Wiederherstellung, noch die Fähigkeit, kritische Daten und Prozesse unabhängig von einem einzelnen Betriebsmodell weiterzuführen.

Welche Absicherung in der Praxis etwas bringt

Nicht jede Gegenmaßnahme ist automatisch sinnvoll. Vor allem ist Multi-Cloud kein Allheilmittel. Zwei komplexe Abhängigkeiten sind nicht automatisch besser als eine gut verstandene. Wenn Teams, Datenmodelle, Sicherheitsregeln und Betriebspfade nicht mitwachsen, erhöht Multi-Cloud vor allem die Komplexität.

Sinnvoller ist eine nüchterne Priorisierung nach kritischem Pfad. Wo hängt Umsatz, Serviceerbringung oder Compliance wirklich an einem Dienst? Wo ist Wiederanlaufzeit geschäftlich hart begrenzt? Und wo reicht ein geordneter manueller Notbetrieb für einige Stunden oder Tage?

Echte Resilienz beginnt meist mit einfachen, aber unbequemen Fragen: Sind Backups unabhängig genug? Ist Wiederherstellung getestet? Gibt es einen lesbaren Notfallprozess? Können Daten exportiert werden? Ist klar, welche Integrationen beim Wechsel oder Ausfall zuerst brechen? Existieren für kritische Funktionen alternative Kommunikations-, Freigabe- oder Betriebswege?

Gerade die Anbieterquellen zeigen, worauf es praktisch hinausläuft: definierte RTO/RPO-Ziele, dokumentierte Wiederherstellungswege, Tests unter realistischen Störungsannahmen und sichtbare Nachweise. Das ist weniger spektakulär als eine große Souveränitätsdebatte, im Alltag aber oft wirksamer.

Einige Unternehmen landen dabei bewusst bei Hybridmodellen statt bei radikalen Exit-Plänen. Das kann sinnvoll sein, wenn besonders kritische Daten, Steuerungsebenen oder Notfallfunktionen bewusst getrennt werden, während weniger sensible oder weniger kritische Workloads weiter in der Public Cloud laufen. Die entscheidende Frage lautet dann nicht "on-prem oder cloud?", sondern: Welche Teile müssen unabhängig bleiben, damit der Rest notfalls verkraftbar ausfällt?

Welche Quellen diese Einordnung nicht hergeben

So wichtig das Thema ist: Die verfügbare Quellenlage erlaubt keine saubere Pauschalaussage über "die deutsche Wirtschaft" insgesamt. Die Heise-Meldung deutet ein strukturelles Problem an, aber ohne Vollzugriff auf den deutschen Originalartikel und ohne vollständigen Datensatz der Studie sollte man die Zahlen nicht als allgemeingültige Marktstatistik lesen.

Ebenso wichtig: Ein einzelnes Incident-Postmortem beweist nicht, dass Cloud grundsätzlich unsicher oder unzuverlässig wäre. Es zeigt nur, wie real Betriebsfehler, Automatisierungsrisiken und verzögerte Wiederherstellung selbst bei großen Plattformen bleiben.

Auch die Aufsichtsquellen haben Grenzen. Bundesbank und BaFin sprechen aus der Perspektive beaufsichtigter Unternehmen, vor allem im Finanzsektor. Für Mittelstand und andere Branchen sind diese Dokumente deshalb nicht eins zu eins rechtsverbindlich. Sie sind aber ein sehr starkes Signal dafür, wie professionelles Cloud-Risikomanagement heute erwartet wird.

Die sauberste Schlussfolgerung lautet daher: Nicht jede Cloud-Nutzung ist ein Betriebsrisiko. Zum Risiko wird sie dort, wo kritische Abhängigkeiten bestehen, aber weder technisch noch vertraglich noch organisatorisch belastbar abgesichert sind.

Was offen bleibt und nicht überzogen werden sollte

Die angemessene Management-Antwort auf die aktuelle Debatte ist weder Panik noch Verdrängung. Cloud bleibt für die meisten Unternehmen sinnvoll, oft sogar alternativlos produktiv. Aber sie sollte nicht mehr als bloße Einkaufs- oder Modernisierungsentscheidung behandelt werden.

Sobald ein Unternehmen zentrale Prozesse in die Cloud legt, entscheidet es auch über Abhängigkeiten: von Identität, Betriebswegen, Lieferketten, Vertragsmechanik und Wiederherstellungsfähigkeit. Genau dort entsteht das eigentliche Betriebsrisiko.

Die praktikable Konsequenz lautet daher nicht "raus aus der Cloud", sondern raus aus unbelegten Annahmen. Wer seine kritischen Pfade kennt, Wiederherstellung unter realen Bedingungen testet, Ausweichprozesse dokumentiert und Konzentrationsrisiken bewusst steuert, macht aus Cloud-Nutzung ein tragfähiges Betriebsmodell statt eine stille Wette auf Dauerverfügbarkeit.

Für Entscheider ist das die wichtigste Verschiebung: Cloud ist heute weniger eine reine Infrastrukturfrage als eine Führungsfrage über Resilienz, Verantwortung und Handlungsspielraum im Störungsfall.