Gerald Boyne ist IT-Security-Architekt und -Berater mit langjähriger Erfahrung in der Modernisierung komplexer IT-Landschaften. Er begleitet mittlere und große Unternehmen bei Fragen rund um Cloud-Migration, Sicherheitsarchitektur und Lieferantenmanagement – stets mit Blick auf das Zusammenspiel von Technologie, Regulierung und geopolitischem Risiko. Zuvor war er mehrere Jahre bei AWS tätig und kennt daher die Perspektive eines führenden Hyperscalers aus erster Hand.
Alle reden von digitaler Souveränität – aber kaum jemand fragt: Wer kann sie sich überhaupt leisten? Darüber habe ich mit IT-Sicherheitsexperte Gerald Boyne gesprochen.
Gregor: Worum geht es den meisten Unternehmen, wenn sie über digitale Souveränität nachdenken?
Gerald: Souveränität bedeutet für sie in der Regel Handlungsfähigkeit. Unternehmen wollen in Krisensituationen aus eigener Kraft entscheiden und handeln können. Das bedeutet zum Beispiel: Ich behalte die Hoheit über meine Daten, und ich stelle sicher, dass kein externer Anbieter oder auch Angreifer meinen Betrieb einfach stoppen kann – weder durch das Abschalten einer Software noch durch das Kündigen eines Services.
Souveränität ist also nicht gleichbedeutend mit völliger technologischer Unabhängigkeit. Es geht darum, kritische Abhängigkeiten zu erkennen und Alternativen vorzuhalten. Ein Unternehmen muss so aufgestellt sein, dass es bei einem Ausfall oder einer politischen Entscheidung nicht sofort in seiner Existenz bedroht ist.
„Souveränität heißt im Kern Handlungsfähigkeit – ich muss auch in der Krise selbst entscheiden und handeln können.“
Gregor: Welche kritische Abhängigkeiten gibt es denn typischerweise für ein – sagen wir – mittelkritisches, mittelgroßes Unternehmen in Europa?
Gerald: Typische Risiken gibt es dort, wo ein Unternehmen komplett von einem Anbieter abhängig ist. Nehmen wir proprietäre Software: Wird der Anbieter verkauft oder abgewickelt, dann kann es sein, dass der Weiterbetrieb dessen Software technisch (wie bei der Abkündigung von Oracles Sun Solaris) oder wirtschaftlich (wie bei der massiven Preiserhöhung von VMware-Lizenzen nach der Broadcom-Übernahme) nicht mehr möglich ist. Das Gleiche gilt in der Cloud – wenn ein Anbieter den Betrieb des Services einstellt oder den Vertrag kündigt, kann die eigene IT im schlimmsten Fall in kritisch kurzer Zeit nicht mehr arbeiten. Dazu sollte man sich seine Verträge genau ansehen, in denen die zeitliche Vorlaufszeit geregelt sein sollte.
Dazu kommen Risiken, die man klassisch kennt: Lieferkettenunterbrechungen (wie bei den Chip-Engpässen während der Corona-Pandemie), Sicherheitsprobleme (wie bei Log4j) oder auch ganz praktische Dinge wie ein Brand (wie beim Großbrand im OVH-Rechenzentrum in Straßburg 2021) oder eine Überschwemmung im Rechenzentrum. All das kann meine Handlungsfähigkeit massiv beeinträchtigen.
Im Kern heißt das: Souveränität verliere ich überall dort, wo ein Dritter bestimmen kann, ob mein Betrieb morgen noch läuft.
Gregor: Welche konkreten Risikoszenarien müssen Unternehmen also durchspielen?
Gerald: Man muss sehr konkret unterscheiden. Ein Szenario ist, dass ein Vertrag gekündigt wird – dann greifen bestimmte vertragliche Fristen, und ich habe vielleicht 30 oder 60 Tage, um zu reagieren.
„Ein Vertrag kann mir 60 Tage Zeit geben – ein gestoppter Lizenzdienst trifft mich übermorgen.“
Ein anderes Szenario ist, dass ein Anbieter den Lizenz- oder Servicedienst einfach stoppt – dann kann das übermorgen passieren. Darüber hinaus gibt es weitere Szenarien, die Unternehmen berücksichtigen müssen: etwa, wenn ein Anbieter aufgekauft oder abgewickelt wird und damit proprietäre Software nicht mehr weiterbetrieben werden kann; wenn Backups unsicher sind oder selbst in Gefahr geraten; oder wenn klassische Infrastruktur-Risiken eintreten – wie ein Brand, eine Überschwemmung oder Kühlprobleme im Rechenzentrum, was gerade in den heißen Sommern vermehrt zu einem realen Risiko wird.
Hinzu kommen auch geopolitische und wirtschaftliche Risiken, etwa ein Zollstreit oder Handelskonflikte, die den Zugang zu Technologien plötzlich einschränken und die Handlungsfähigkeit massiv beeinträchtigen können.
Das Entscheidende ist: Man darf diese Risiken nicht abstrakt behandeln.
Gregor: Was meinst du mit abstrakt? Was wäre denn konkret?
Abstrakt wäre, wenn ich einfach sage „wir brauchen Krisenmanagement“ oder „wir müssen resilient sein“. Konkret heißt: Ich schaue mir jede einzelne IT-Komponente an und spiele durch, was passiert, wenn genau dieser Dienst morgen ausfällt. Kann ich dann noch arbeiten? Habe ich eine getestete Alternative? Ist mein Backup wirklich sicher gegen einen externen Angriff geschützt? Nur so bekomme ich ein szenariobasiertes Bild – ob es um proprietäre Software, einen Cloud-Dienst oder ganz praktische Risiken wie einen Rechenzentrumsbrand geht.
„Bei großen geopolitischen Szenarien muss man auch Marktreaktionen und das Verhalten von Regierungen berücksichtigen.“
Bei den großen geopolitischen Szenarien wiederum reicht es nicht, nur auf die eigene IT zu schauen. Da muss man auch berücksichtigen, wie sich externe Akteure verhalten – also etwa Anbieter, Regierungen oder Regulierungsbehörden – und welche Marktreaktionen eine Krise zusätzlich verschärfen könnten. Ein Beispiel: Wenn es einen China/Taiwan-Krieg gäbe, würden sicher Compute-Kapazitäten sehr knapp werden und das für alle Akteure gleichzeitig.
Gregor: Ok, jetzt habe ich die Risiken durchgespielt, was mache ich dann?
Gerald: Dann geht es darum, die Handlungsfähigkeit im Szenario wirklich herzustellen. Und das unterscheidet sich je nach Risiko. Für manche Szenarien reicht es, ein klares Konzept zu haben – etwa wenn ein Vertrag vom Lieferanten gekündigt wird und ich Zeit habe zu reagieren. Da brauche ich keinen kompletten Parallelbetrieb im Standby, sondern einen sauberen durchführbaren Migrationsplan zu einem alternativen Lieferanten mit vergleichbarem technischem Portfolio.
Für andere Szenarien muss ich aber tatsächlich etwas vorhalten, zum Beispiel durch Redundanz. Wenn ein Anbieter morgen früh den Lizenzdienst abstellen könnte, dann hilft mir ein Papierkonzept nicht weiter. In so einem Fall brauche ich ein für ein Kernsystem ein getestetes Ersatzsystem oder zumindest vorbereitete Infrastruktur und natürlich auch technische Zugriffe auf die Daten.
Und dann gibt es die geopolitischen Extremszenarien, wie eine Totalblockade durch die USA. Das ist sehr unwahrscheinlich, hätte aber maximalen Schaden zur Folge – weil in diesem Moment auf einen Schlag ganze IT-Landschaften stillstehen könnten. ? Wir haben dazu keine Erfahrungswerte, also müssen wir uns damit strategisch beschäftigen. Hier stellt sich die Frage: Will ich dafür enorme Redundanzen aufbauen was zu sehr hohen Kosten führt, oder entscheide ich unternehmerisch, dieses Risiko nur zu beobachten und mit Frühwarnsystemen abzusichern, natürlich wieder abhängig von der Kritikalität der Anwendung.
„Die Kunst besteht darin zu entscheiden: Wo reicht ein Plan, wo brauche ich mehr.“
Die Kunst besteht darin, zu entscheiden: Wo reicht ein Plan – wo brauche ich echte Redundanz – und wo ist das Risiko so groß, dass es wirtschaftlich gar nicht vollständig abgesichert werden kann? Genau dort entstehen die Kosten und der organisatorische Aufwand.
Gregor: Wenn wir also Handlungsfähigkeit in allen relevanten Szenarien anstreben, scheint digitale Souveränität möglich, auch in Europa. Aber was würde uns diese Art von Selbstbestimmung denn kosten?
Gerald: Souveränität kostet substanziell Geld. Zuerst kommt die Basisanalyse – ein Projekt, das Transparenz über Abhängigkeiten schafft. Dann folgen Detailprojekte: bessere Backups, getestete Notfallumgebungen, alternative Systeme. Und genau hier liegt ein wesentlicher Kostentreiber: Diese Maßnahmen binden Schlüsselpersonal, das im Tagesgeschäft ohnehin schon stark ausgelastet ist. In kleinen IT-Teams bedeutet das oft, dass andere Vorhaben liegenbleiben. Viele Unternehmen müssen deshalb externe Spezialisten hinzuziehen – was zusätzliche Kosten verursacht und zugleich das Risiko birgt, dass das entscheidende Wissen nicht im eigenen Haus bleibt.
Die zweite Kostendimension entsteht, wenn man Architektur verändern muss. Viele IT-Landschaften sind historisch „spaghettimäßig“ verwoben. Will man dort ein minimales Überlebenssystem vorbereiten, landet man schnell bei einem kompletten Re-Architecture-Programm – mit doppelter Hardware, zusätzlichen Teams und monatelangen Tests parallel zum laufenden Betrieb.
„Viele unterschätzen, wie stark Souveränitätsprojekte das Unternehmen belasten können.“
Am besten lässt sich das mit Häusern vergleichen: Stell dir vor, wir haben in San Francisco günstige Häuser gebaut und merken plötzlich – oh, hier gibt es Erdbeben. Soll ich jetzt alles abreißen und komplett erdbebensicher neu bauen? Oder reicht es, ein zweites, kleineres Domizil vorzuhalten, in das ich im Notfall mit meiner Familie ziehen kann? Beides hat seinen Preis. Genau diese Abwägung müssen Unternehmen treffen.
Gregor: Das klingt nach einem Mammutprogramm, das eher nur Großunternehmen oder Behörden stemmen können. Aber David Heinemeier Hansson hat sich ja scheinbar mit spielender Leichtigkeit von Abhängigkeiten befreit.
Gerald: Ja, David Heinemeier Hansson ist ein gutes Beispiel. Er hat mit seiner Firma Basecamp AWS verlassen, sich ein paar Dell-Server gekauft und in kürzester Zeit ein eigenes Rechenzentrum aufgebaut. Das ging schnell, weil seine Systeme modern, entkoppelt und von einem starken Entwicklerteam getragen waren. Wer so aufgestellt ist, kann sich tatsächlich relativ leicht bewegen. Aber das ist die Ausnahme. Die meisten Unternehmen haben historisch gewachsene, stark verknüpfte und viel diversere IT-Landschaften gepaart mit klassischen Geschäftsmodellen und einer klassischen Workforce. Dort ist der Migrationsweg eben nicht so trivial.
„Die meisten Firmen haben historisch gewachsene IT-Landschaften – da ist Unabhängigkeit kein Sprint, sondern ein Mammutprogramm.“
Gregor: Was rätst Du denn deutschen Kleinstunternehmen? Diese machen ja fast 90% aller Unternehmen aus und beschäftigen etwa 3,5 Millionen Menschen …
Gerald: Für Kleinstunternehmen wie einen kleinen Versandhandel oder eine Medienagentur lohnt es sich natürlich nicht, ein eigenes Redundanzsystem aufzubauen oder teure Dienstleister einzubinden. Da reicht es, die Basics im Griff zu haben: Backups, Passwörter, Updates – und vielleicht eine einfache Alternative, falls das Kassensystem einmal ausfällt. Anders sieht es bei kleineren Mittelständlern mit individuellen eigenen Anwendungen aus. Dort ist es sinnvoll, kritische Abhängigkeiten systematisch zu prüfen und für die wichtigsten Kernanwendungen Alternativen oder Partner zu haben. Wichtig ist, die Balance zu finden: so viel Vorsorge wie nötig, aber nicht mehr als wirtschaftlich tragfähig ist.
Gregor: Vielen Dank für Deine Zeit!
