Ein Server in Frankfurt, eine europäische Rechnungsadresse und eine EU-Flagge im Produktnamen: So wird Datensouveränität gern verkauft. Doch der Speicherort beantwortet nicht die entscheidenden Fragen. Wer besitzt die Administratorrechte? Welchem Rechtsraum unterliegen Betreiber, Muttergesellschaft und Unterauftragnehmer? Wer kontrolliert Verschlüsselungsschlüssel, Supportzugriffe und Backups? Und lässt sich der Dienst ohne Erlaubnis des bisherigen Anbieters wiederherstellen?
Diese Fragen sind seit dem 8. Juli 2026 Gegenstand einer gezielten Konsultation der Europäischen Kommission. Sie läuft bis zum 8. September 2026, 23:59 Uhr mitteleuropäischer Sommerzeit. Die Kommission fragt nach Datenabhängigkeiten europäischer Organisationen, Hindernissen beim Zugriff auf Daten in Drittstaaten, Schwierigkeiten beim Transfer in die EU und Risiken durch Drittstaatenzugriffe auf sensible Daten.
Das ist noch kein Gesetzgebungsverfahren mit feststehendem Ergebnis. Die Konsultation hat keine veröffentlichten Resultate, und es ist nicht belegt, dass daraus ein neuer Rechtsakt entsteht. Als politischer Anlass ist sie dennoch wertvoll: Sie zwingt Europa, über Kontrolle statt nur über Speicherorte zu reden.
Datenstandort, Rechtsraum und Kontrolle sind drei verschiedene Dinge
Der Standort sagt, wo eine Maschine steht. Der Rechtsraum beschreibt, welchen Regeln Infrastruktur, Unternehmen und Zugriffe unterliegen. Technische Kontrolle entscheidet, wer den Dienst administrieren, Schlüssel ändern, Daten exportieren und einen Wiederanlauf durchführen kann.
Diese Ebenen können auseinanderfallen. Ein Matrix-Homeserver kann in Frankreich laufen, während allein ein externer Dienstleister Zugriff auf Synapse, Datenbank, DNS und /.well-known besitzt. Ein selbstgehosteter Blog kann hinter dem eigenen Nginx stehen, während sein Backup in einem proprietären Objektspeicher von fremder Anmeldung, API und Abrechnung abhängt.
In beiden Fällen ist die Aussage „Daten liegen in Europa“ richtig und trotzdem unvollständig. Der produktive Speicherort ist europäisch, aber entscheidende Kontrollpfade bleiben ausgelagert.
Das bedeutet nicht, dass jeder externe Dienst schlecht ist. Kleine Communities können nicht jede Komponente allein betreiben. Ein seriöser Dienstleister kann stabiler und sicherer sein als ein ungepflegter Einzelserver. Souveränität verlangt nicht, jede Schraube selbst zu drehen. Sie verlangt, Abhängigkeiten zu kennen, sie bewusst zu wählen und sie wechseln zu können.
Was der Data Act bereits verlangt
Die Diskussion beginnt nicht bei null. Die Verordnung (EU) 2023/2854, der Data Act, gilt grundsätzlich seit dem 12. September 2025.
Artikel 28 verpflichtet Anbieter von Datenverarbeitungsdiensten, auf ihren Webseiten aktuell offenzulegen, welcher Jurisdiktion die für den jeweiligen Dienst eingesetzte ICT-Infrastruktur unterliegt. Sie müssen außerdem technische, organisatorische und vertragliche Maßnahmen nennen, mit denen sie internationale staatliche Zugriffe oder Transfers nicht-personenbezogener Daten verhindern wollen, soweit diese mit EU- oder nationalem Recht kollidieren würden. Die Offenlegungsseite muss auch im Vertrag genannt werden.
Artikel 32 verlangt angemessene technische, organisatorische und rechtliche Maßnahmen gegen entsprechende Drittstaatenzugriffe. Entscheidungen von Gerichten oder Behörden eines Drittstaats sind grundsätzlich nur dann anerkennungs- oder vollstreckungsfähig, wenn sie auf einem einschlägigen internationalen Abkommen beruhen. Für Situationen ohne ein solches Abkommen enthält der Artikel weitere Bedingungen.
Diese Vorschriften sind wichtig, aber sie sind kein magischer Schutzschild. Ihre praktische Wirkung hängt davon ab, ob Offenlegungen verständlich, vollständig und überprüfbar sind. Aus den allgemeinen Regeln lässt sich zudem nicht pauschal beurteilen, wie eine konkrete ausländische Anordnung, Konzernstruktur oder Cloud-Architektur rechtlich zu behandeln ist. Dafür wäre eine juristische Einzelfallprüfung nötig.
Schlüssel und Tokens sind keine Nebensache
Im Serveralltag wird aus dem abstrakten Wort Kontrolle schnell eine Liste konkreter Zugänge. Ein Synapse-Admin-Token kann weitreichende Eingriffe ermöglichen. Der DNS-Zugang bestimmt, wohin eine Domain zeigt. Ein Schlüssel entscheidet, ob ein verschlüsseltes Backup lesbar ist. Recovery-Codes entscheiden, ob eine Verwaltung nach Geräteverlust noch erreichbar ist.
Ein europäischer Matrix-Server bleibt abhängig, wenn ein früherer Betreiber noch einen gültigen Admin-Token besitzt. Eine Community bleibt handlungsunfähig, wenn nur eine Person den zweiten Faktor zum DNS-Konto kontrolliert. Ein Backup bleibt wertlos, wenn sein Schlüssel ausschließlich auf dem ausgefallenen Produktivsystem liegt.
Das Gegenmittel ist nicht die Veröffentlichung vertraulicher Details. Tokens, private Schlüssel und interne Adressen gehören nicht in öffentliche Prüfberichte. Nötig sind dokumentierte Rollen, geregelte Rotation, geschützte Notfallzugänge und eine Übergabe, die im Ausfall nicht an einem einzigen Menschen scheitert.
Redaktionelle Bewertung: Wer Schlüssel, Administratorrollen und DNS nicht kontrolliert, besitzt keine belastbare Kontrolle über den Dienst. Der Serverstandort kann dieses Defizit nicht ausgleichen.
Ein Datenexport ist noch keine Portabilität
Ein Anbieterwechsel scheitert oft nicht am Fehlen eines Exportknopfs, sondern an der Unvollständigkeit des Exports. Eine Datenbank oder ZIP-Datei enthält vielleicht Inhalte, aber nicht automatisch Identitäten, Rollen, Medien, Weiterleitungen, Konfigurationen, Schlüssel und Versionsinformationen.
Bei Matrix reicht eine Sammlung von Nachrichten und Medien nicht, wenn Raumstruktur, Berechtigungen und Identitäten nicht wiederhergestellt werden können. Bei einem Blog hilft der Datenbankdump nur teilweise, wenn Upload-Verzeichnis, Nginx-Regeln, Redirects und passende Anwendungsversion fehlen.
Zur Portabilität gehören auch Kosten und Fristen. Ein technisch möglicher Export, der durch hohe Ausleitungsgebühren oder wochenlange Wartezeit blockiert ist, taugt nicht als Notausgang. Verträge sollten deshalb festlegen:
- welche Daten und Konfigurationen exportiert werden;
- in welchen offenen oder dokumentierten Formaten der Export erfolgt;
- welche Kosten und Fristen gelten;
- ob Schlüssel und Rollen übergeben werden können;
- welche Unterstützung für den Exit geschuldet ist.
Die European Data Union Strategy spricht dabei ausdrücklich nicht für vollständige Datenautarkie. Sie verbindet Souveränität mit grenzüberschreitendem Austausch unter fairen, sicheren und mit europäischen Werten vereinbaren Bedingungen. Das ist der richtige Ausgangspunkt. Freier Datenfluss ist nicht automatisch Abhängigkeit, und Abschottung ist nicht automatisch Kontrolle.
Der Restore-Test ist der harte Nachweis
Ein vorhandenes Backup beweist zunächst nur, dass Dateien oder Dumps erzeugt wurden. Ob daraus wieder ein funktionsfähiger Dienst entsteht, zeigt erst ein Restore-Test.
Bei einem Matrix-Homeserver müssen Datenbank, Medien, Signierschlüssel, Konfiguration und Versionsstand zusammenpassen. Bei einer Webanwendung kommen Nginx, TLS-Konfiguration, Anwendungscode, Datenbank, Uploads und Secrets hinzu. Liegt ein Teil nur auf dem Produktivserver oder ist das Backup-Passwort nicht unabhängig erreichbar, bricht die Wiederherstellung genau im Störfall.
Ein Restore-Test kann in einer isolierten Umgebung stattfinden. Er sollte dokumentieren, welche Sicherung verwendet wurde, wie lange der Wiederanlauf dauerte, welche Abweichungen auftraten und welche Nutzerwege anschließend funktionierten. Ein erfolgreich erzeugter Dump und eine Prüfsumme reichen nicht: Sie zeigen weder, dass die Schlüssel passen, noch dass Login, Medien, Mail oder Föderation wieder funktionieren.
Redaktionelle Bewertung: Öffentliche Stellen und Unternehmen sollten Souveränität nicht nur mit Erklärungen oder Zertifikaten beschaffen. Ein technischer Anbieterwechsel oder Wiederanlauf muss Teil der Abnahme sein – abgestuft nach Schutzbedarf.
Open Source ist ein Werkzeug, kein Freifahrtschein
Die EU-Open-Source-Strategie vom Juni 2026 stellt offene Alternativen in den Mittelpunkt technologischer Souveränität. Sie nennt Open-Source-freundliche Beschaffung, öffentliche Verwaltungen als Ankernutzer, langfristige Wartung, Abhängigkeitsanalyse sowie Spiegel- und Fork-Fähigkeit. Zugleich benennt sie begrenzte Langzeitfinanzierung, Wartungsprobleme, geringe Sichtbarkeit und Beschaffungshürden.
Damit beschreibt die Kommission selbst die Grenze des Arguments. Offener Code kann Prüfung, Eigenbetrieb und Wechsel ermöglichen. Er finanziert aber keine Maintainer, ersetzt keine Dokumentation und garantiert keinen Restore.
Eine Community kann Synapse als offene Software betreiben und trotzdem bei Container-Registry, Monitoring, Mailversand oder Anmeldung von proprietären Diensten abhängen. Eine Behörde kann den Quellcode einer Anwendung besitzen, aber ohne reproduzierbaren Build, gepflegte Pakete und Betriebskompetenz keinen brauchbaren Fork aufsetzen.
Die angekündigte Idee eines Open Source Maintenance Instrument ist deshalb relevant. Offen sind derzeit noch konkrete Fragen zu Budget, Start, Auswahl und Dauer. Erst deren Umsetzung wird zeigen, ob aus der politischen Anerkennung verlässliche Wartungsfinanzierung entsteht.
Das Gegenargument: Souveränität kann teuer und abschottend werden
Strengere Anforderungen verursachen Aufwand. Zusätzliche Dokumentation, unabhängige Backups, Exit-Unterstützung und Restore-Tests kosten Geld. Eine pauschale Pflicht, alle Daten innerhalb der EU zu halten, könnte globale Zusammenarbeit erschweren und kleine Anbieter benachteiligen, ohne Adminrechte oder Schlüsselkontrolle zu verbessern.
Dieses Gegenargument ist berechtigt. Die Antwort sind risikogerechte Anforderungen statt einer digitalen Festung. Ein öffentlicher Veranstaltungskalender braucht nicht denselben Schutz wie Gesundheitsdaten, Verwaltungsvorgänge oder kritische Infrastruktur. Transparente Jurisdiktion, dokumentierte Unterauftragnehmer, offene Schnittstellen und ein verständlicher Export sollten dennoch zur Grundausstattung gehören.
Bewertung: Souveränität ist kontrollierte Handlungsfähigkeit
Meine Bewertung für diesen Beitrag: Europa braucht keine Datenautarkie. Es braucht die nachgewiesene Fähigkeit, Daten auszutauschen, ohne Weiterbetrieb und Regelsetzung an einen einzelnen undurchsichtigen Anbieter abzugeben.
Daraus folgen sechs brauchbare Prüfsteine:
- Jurisdiktionen von Betreiber, Konzern, Infrastruktur und Unterauftragnehmern offenlegen.
- Administratorrechte, Schlüssel, Logs und Supportzugriffe nachvollziehbar regeln.
- Daten, Identitäten und Konfigurationen vollständig exportierbar machen.
- Formate, Kosten, Fristen und Exit-Unterstützung vertraglich festhalten.
- Backups unabhängig aufbewahren und den Wiederanlauf nachweisbar testen.
- Kritische Open-Source-Komponenten langfristig warten und finanzieren.
Diese Punkte lösen nicht jeden Konflikt zwischen Datenschutz, internationalem Handel, Sicherheit und Innovation. Sie machen aber aus einem politischen Schlagwort eine überprüfbare Eigenschaft.
Fazit
Die EU-Konsultation stellt die richtige Grundfrage: Wo hängen europäische Organisationen von Datenzugängen und Kontrollpfaden außerhalb ihrer eigenen Reichweite ab? Eine belastbare Antwort darf sich nicht auf den Ort des Rechenzentrums beschränken.
Datensouveränität beginnt dort, wo Rechtsräume sichtbar, Zugriffe begrenzt, Schlüssel kontrolliert und vollständige Exporte möglich sind. Sie wird glaubwürdig, wenn ein Betreiber den Dienst unabhängig wiederherstellen kann. Open Source stärkt diesen Weg, sofern Wartung, Build-Kette und Wissen tatsächlich getragen werden.
Der Satz „Unsere Daten liegen in Europa“ ist deshalb kein Abschluss. Er ist der Beginn der Prüfung.
Quellen
- Europäische Kommission, „Targeted consultation on safeguarding the EU’s data sovereignty“, 8. Juli 2026:
https://digital-strategy.ec.europa.eu/en/consultations/targeted-consultation-safeguarding-eus-data-sovereignty - Europäische Kommission, EUSurvey zur Konsultation:
https://ec.europa.eu/eusurvey/runner/a921658b-7f28-11c5-d062-3db457c213fa - Europäische Kommission, „European Data Union Strategy“, November 2025:
https://digital-strategy.ec.europa.eu/en/policies/data-union - EUR-Lex, Verordnung (EU) 2023/2854 – Data Act, insbesondere Artikel 28, 32 und 50:
https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng - Europäische Kommission, „The EU Open Source Strategy“, Juni 2026:
https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy - Europäische Kommission, „Strengthening Europe’s Tech Sovereignty“:
https://digital-strategy.ec.europa.eu/en/policies/eu-tech-sovereignty - Europäische Kommission, COM(2026) 503:
https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy
CTA
Wer hält bei euren Diensten die Schlüssel, und wie sieht euer getesteter Rückweg aus? Diskussion:
https://treff.darknight-coffee.eu/@carrabelloy
Podcast:
https://podcast.darknight-coffee.org/pages/startseite
Blog:
https://carrabelloy.darknight-coffee.org/blog/
Wenn dir das Projekt hilft: Spendenlinks sind im Blog.