Digitale Souveränität – warum das mehr ist als Compliance!
“Anders als bei so manchen regulatorischen Themen geht es nicht darum, Regelkonformität nachzuweisen, sondern um eine echte intrinsische Motivation, sich gegen konkrete Risiken wirklich effizient abzusichern, nicht nur auf dem Papier.”
Europa hat es, offen gesagt, ein Stück weit versemmelt. Wobei man es Europa auch nicht wirklich vorwerfen kann. Denn nachdem man mit den Verträgen von Maastricht 1992 und Amsterdam 1997 erst auf einem guten Weg war, scheiterte 2004, vor inzwischen mehr als zwanzig Jahren, der Verfassungsvertrag und beerdigte damit die Ambitionen in Richtung eines echten europäischen Föderalstaats. Das Ergebnis: eine Währungsunion ohne echte Fiskalunion, ein Binnenmarkt ohne gemeinsame Wirtschaftspolitik, keine koordinierte Industriestrategie, keine gemeinsame Technologiepolitik. Was Europa stattdessen kann – und auch sehr, sehr gründlich betrieben hat –, ist regulieren. Das hat inzwischen auch die Kommission selbst erkannt, wie die laufenden “Omnibus”-Initiativen zum Bürokratieabbau zeigen. Es mag dahinstehen, in welchem Umfang dies für den gegenwärtigen Befund ursächlich ist. Klar ist aber: Europa verfügt heute über so gut wie keine eigene digitale Infrastruktur von Gewicht. Weder Hardware, noch Software oder – heute weit wichtiger – IT-Services kommen in nennenswertem Umfang aus Europa selbst.
Dass sich die geopolitischen Rahmenbedingungen inzwischen verändert haben, kam auch nicht wirklich überraschend. Wer beobachtet hat, wie transatlantische Verlässlichkeit über die Jahre erodiert ist, weiß: Digitale Abhängigkeit von außereuropäischen Anbietern ist kein abstraktes Risiko. Sie ist inzwischen ein ganz konkretes operatives Problem.
Und damit rückt das Thema Digitale Souveränität in den Mittelpunkt – mit einer Besonderheit, die für die compliance-erprobten Europäer durchaus ungewohnt ist: Anders als bei so manchen regulatorischen Themen geht es nicht darum, Regelkonformität nachzuweisen, sondern um eine echte intrinsische Motivation, sich gegen konkrete Risiken wirklich effizient abzusichern, nicht nur auf dem Papier. Es geht darum, handlungsfähig zu bleiben und Notfallszenarien wirklich durchzuspielen. Kurz: nicht darum, sich irgendwo beschweren zu können, wenn einem der Stecker gezogen wird – sondern sicherzustellen, dass man dann schlicht weiterarbeiten kann.
Digitale Souveränität ist also nicht als Compliance-Übung zu verstehen, sondern als Frage der Überlebensfähigkeit und Funktionsfähigkeit eines Unternehmens – gegen Bedrohungen, die man vielleicht vor fünf Jahren noch nicht ernst genommen oder schlicht nicht gesehen hat. Zusätzliche Brisanz erhält das Thema dadurch, dass in den vergangenen Jahren immer mehr Dienste in die Cloud verlagert wurden.
Doch es gibt durchaus Lichtblicke am Horizont. Zum einen lässt sich heute vieles wieder selbst betreiben – weil die dafür notwendige Infrastruktur handhabbar geworden ist, da zumindest in einigen Bereichen die Hardware-Infrastruktur schneller gewachsen ist als die technischen Anforderungen. Zum anderen gibt es inzwischen viele ausgereifte Lösungen in Form von Open-Source-Software, die das, was vor fünf Jahren noch als Rocket Science galt, heute zur Commodity gemacht haben – von Office-Suiten über kollaborative Plattformen bis hin zu Datenbankinfrastruktur und Cloud-Umgebungen.
Was konkret zu tun ist, lässt sich auf drei Schritte herunterbrechen. Zunächst eine ehrliche Bestandsaufnahme: Welche IT-Systeme, Anwendungen und Daten sind inventarisiert? Wer sind die wesentlichen Dienstleister, einschließlich ihrer Subunternehmer? Wie sehen Laufzeiten, Kündigungsrechte und Exit-Regelungen aus, und welchem Rechtsregime unterliegen die eigenen Daten? Dann folgt die Gap-Analyse: Wo bestehen kritische Abhängigkeiten und Ausfallszenarien? Wo droht Vendor Lock-in durch proprietäre IT und fehlende Wechseloptionen? Wer hat tatsächlich Kontrolle über die eigenen Daten – und wer nur das Gefühl davon? Und schließlich ein konkreter Mitigation Plan: priorisiert nach Kritikalität, mit vertraglicher Nachsteuerung bei SLAs und Exit-Regelungen, Multi-Provider-Ansätzen und offenen Standards zur Reduzierung von Abhängigkeiten.
Aus rechtlicher Sicht ist man dem Thema dabei keineswegs ausgeliefert – im Gegenteil: Es bestehen erhebliche Steuerungsmöglichkeiten, die man allerdings auch nutzen muss. Wichtig ist jedoch zu wissen, dass dabei einiges anders läuft als bei klassischen Softwareprojekten. Wer Open-Source-Software strategisch einsetzen will, sollte auf der Klaviatur spielen können, die dazugehört: Upstream Contributions, Community Support, Forking und Patching dürfen dann keine Fremdwörter sein. Es würde an dieser Stelle den Rahmen sprengen, das im Einzelnen auszuführen. Entscheidend ist, dass man grundsätzlich versteht, wie freie Software einem helfen kann und wie man sie so nutzt, dass man sich nicht mehr Arbeit macht als nötig – und dabei auch begreift, dass das Zurückspielen eigener Beiträge an die Community kein Verlust ist, sondern letzterer nützt und einem damit am Ende auch selbst zugutekommt.
Dabei mag manches auf den ersten Blick kontraintuitiv wirken – was in der Praxis jedenfalls immer wieder zu beobachten ist. Was vor zehn, fünfzehn Jahren noch als Standard bei IT-Verträgen galt, ist heute schlichtweg nicht mehr zeitgemäß, teilweise sogar falsch, etwa mit Blick auf Rechtseinräumung, den Umgang mit Forking und die Frage, was zu schützenswerter IP und zu schützenswertem Know-how zählt.
Es bleibt zu hoffen, dass man nie wird feststellen müssen, ob man sich auf diese Szenarien gut genug vorbereitet hat. Doch trotz allem: Wer heute keine Antwort auf die Frage hat, ob sein Unternehmen in drei Monaten noch handlungsfähig wäre, wenn ein zentraler Anbieter ausfällt oder den Dienst einstellt, sollte sich diese Frage spätestens jetzt stellen.
Hendrik Schöttle, München