Was passiert eigentlich, wenn die EU von einem Tag auf den anderen keinen Zugriff mehr auf zentrale US-Internetdienste hat. Diese Frage wird seit Jahren diskutiert, inzwischen kommt sie im Mainstream an und erreicht endlich dort die Aufmerksamkeit, wo sie hingehört, in die strategische Steuerung von Organisationen. Denn es geht längst nicht mehr nur um Datenschutz oder einzelne Rechtsakte, sondern um Resilienz, Handlungsfähigkeit und die bewusste Steuerung kritischer Abhängigkeiten.

Cloud Infrastrukturen, E-Mail-Systeme, Kollaborationstools, Identitätsdienste, Sicherheitsplattformen, Zahlungsdienste. Ein großer Teil der digitalen Wertschöpfung in Europa hängt direkt oder indirekt von US-Anbietern ab, rechtlich, technisch und operativ. Spätestens seit den wiederkehrenden Diskussionen um Cloud Act, Schrems II, geopolitische Spannungen und digitale Souveränität ist klar, dass das kein theoretisches Gedankenspiel mehr ist, sondern ein realistisches Risikoszenario.

Die eigentliche Frage ist daher nicht, ob ein solcher Bruch eintritt, sondern wie vorbereitet Organisationen darauf sind.

• Gibt es einen Plan B?
• Gibt es dokumentierte Exit-Strategien?
• Gibt es europäische Alternativen, die nicht nur funktional, sondern auch organisatorisch und wirtschaftlich tragfähig sind?
• Und vor allem, wird dieses Risiko überhaupt auf Geschäftsleitungsebene adressiert?

Digitale Resilienz beginnt nicht bei Firewalls oder Zertifikaten, sondern bei strategischen Abhängigkeiten. Wer heute über Informationssicherheit, Business Continuity oder NIS2 spricht, muss auch über technologische Souveränität sprechen. Plan B ist kein Zeichen von Misstrauen. Plan B ist professionelles Risikomanagement. Die Zeit, sich diese Fragen zu stellen, ist nicht erst dann, wenn Dienste plötzlich nicht mehr erreichbar sind.

Warum physische Rechenzentren in der EU nicht automatisch Unabhängigkeit bedeuten

Ein häufiger Einwand lautet, dass viele Serverfarmen physisch außerhalb des direkten Zugriffs der USA stehen und Hyperscaler wie Azure, AWS oder Google sonst gar nicht global arbeiten könnten. Das stimmt insofern, als dass Standortentscheidungen einzelne Risiken reduzieren können. Aber sie lösen die strukturelle Abhängigkeit nicht automatisch. Steuerung, Identität, Updates, Policy Änderungen, Schlüsselverwaltung, Support und wirtschaftliche Druckmittel bleiben häufig in der Hand des Anbieters und damit potenziell politisch oder regulatorisch angreifbar. Wer sich nur auf den Standort verlässt, unterschätzt die Abhängigkeiten in der operativen Kontrolle und in der Liefer- und Betriebskette.

Wie sähe eine Nicht-Abhängigkeit aus

In der Praxis ist das kein „Entweder-Oder“, sondern die bewusste Entscheidung, welche Kernfunktionen auch bei einem harten Bruch weiterlaufen müssen und wie man das sicherstellt. Nicht Abhängigkeit bedeutet vor allem Portabilität und Wiederanlauf. Daten müssen vollständig exportierbar sein, Schnittstellen standardisiert, Abhängigkeiten zu proprietären Plattformdiensten begrenzt und Exit Strategien nicht nur dokumentiert, sondern technisch vorbereitet und regelmäßig geübt.

Ein Plan B ist erst dann belastbar, wenn er realistisch hinterlegt ist, in Zeit, Kosten, Personal und Technik. Wer Exit Strategien nur als Vertragstext, Auditpunkt oder Folie im Vendor-Management führt, hat im Ereignisfall keinen Plan, sondern eine Hoffnung.

Wohin diese Diskussion gehört

Diese Diskussion muss dorthin, wo Risikoakzeptanz und Budgets entschieden werden, in die Geschäftsleitung, ins Risikomanagement und in die Compliance, nicht nur in die IT. Solche Abhängigkeiten gehören als eigenständige Szenarien in Business Continuity und Krisenplanung, in die Steuerung von Drittparteien und Lieferketten sowie in das Informationssicherheitsmanagement. Ziel ist, daraus überprüfbare Anforderungen abzuleiten, etwa Wiederanlaufzeiten, Datenrückführbarkeit, alternative Betriebsverfahren, Audit und Nachweisrechte, klare Zuständigkeiten für Identität und Schlüssel sowie eine belastbare Backup Strategie, die auch bei Plattformproblemen funktioniert.

Daten und Informationsintegrität als systemimmanentes Thema

Mindestens genauso interessant ist in diesem Zusammenhang die Frage nach Daten und Informationsintegrität, weil sie systemimmanent ist. Je stärker eine Organisation von einer einzigen Toolchain abhängt, von Identität über Logging bis zur Update Kette, desto größer ist das systemische Risiko durch Manipulation, fehlerhafte Updates, kompromittierte Signaturen oder unbemerkte Policy Änderungen.

Integrität wird belastbar, wenn Kontrollen und Nachweise unabhängig funktionieren. Dazu gehören nachvollziehbare Signaturen und Prüfpfade, unveränderbare Backups, getrennte Administrations und Schlüsselrollen, Protokollierung außerhalb der Plattform sowie regelmäßige Wiederherstellungstests. Integrität heißt nicht, dass man vertraut, sondern dass man prüfen und im Ernstfall belegen kann.

„Think global, act local“ – und warum der zweite Teil oft fehlt

„Think global, act local“ passt deshalb sehr gut. Bequemlichkeit und kurzfristige Effizienz haben bei vielen Entscheidern den zweiten Teil verdrängt. Und jetzt haben oder besser kriegen wir das Ergebnis serviert.

Plan B ist eben kein Misstrauen und keine Ideologie, sondern professionelles Risikomanagement. Entscheidend ist die klare Leitfrage:

Welche Funktionen müssen wir unter allen Umständen selbst kontrollieren können, und welche Abhängigkeiten sind bewusst akzeptiert, weil sie transparent bewertet, vertraglich abgesichert und technisch beherrscht werden?

Alles andere ist unternehmerisches Risiko, aber eben nur dann, wenn es bewusst getragen wird.

Inzwischen taucht dieses lange verschobene Thema, ein grauer Schwan, vermehrt in meinen und unseren wöchentlichen und monatlichen „IT-Wo wir stehen Jour-Fixes“ mit Kunden auf.

Immer mehr unserer Kunden fragen nach alternativen Wegen. Genau diese Nachfrage ist der Moment, in dem aus Souveränität ein umsetzbares Programm werden kann.