WISSEN > CLOUD INFRASTRUKTUR >DATENSTANDORT, SOUVERÄNITÄT & DATENKONTROLLE IN DER CLOUD
Warum ein Rechenzentrum in Deutschland die Souveränitätsfrage nicht beantwortet
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Datenstandort, Souveränität und Kontrolle in der Cloud
Das sollten Sie mitnehmen:
- Ein Datenstandort in Deutschland ist noch keine Souveränität.
Der Speicherort beantwortet weder die Frage nach der Rechtsordnung des Anbieters noch die nach administrativem Zugriff.
- Verschlüsselung verschiebt die Kontrollgrenze nur, wenn der Kunde die Schlüssel hält.
Entscheidend ist, welche Komponenten Klartext benötigen und wo diese betrieben werden.
- Exit-Fähigkeit gehört zur Kontrolle.
Wer Daten und Funktionen nicht mit vertretbarem Aufwand herauslösen kann, besitzt nur formale Verfügungsgewalt.
- Die Anforderungen müssen vor der Anbieterauswahl feststehen.
Datenlokalität, Jurisdiktion, Schlüsselkontrolle und Exit führen zu unterschiedlichen Architekturentscheidungen.
- Souveränität ist kein Produktmerkmal, sondern das Ergebnis mehrerer Kontrollen.
Sie muss dimensionsweise geprüft und nicht pauschal bewertet werden.
Inhaltsverzeichnis
- Was ein Datenstandort tatsächlich beschreibt
- Warum Standort und Souveränität getrennt bewertet werden müssen
- Der ICC-Fall zeigt ein anderes Risiko als den Datenzugriff
- Verschlüsselung beantwortet die Kontrollfrage nur zur Hälfte
- Privilegierte Zugriffe entscheiden über die tatsächliche Kontrolle
- Ohne Exit-Fähigkeit bleibt Kontrolle formal
- Souveränität lässt sich nicht als Produkteigenschaft einkaufen
- Was wir in aktuellen Kundengesprächen beobachten
- Eine Souveränitätsprüfung beginnt mit Anforderungen, nicht mit Anbietern
- Auch ein europäischer Anbieter löst nicht jede Abhängigkeit
- Fazit
- Quellen
Wer Unternehmensdaten in die Cloud verlagert, entscheidet mehr als die Region eines Rechenzentrums. Ein Datenstandort in Deutschland oder innerhalb der Europäischen Union beantwortet die Frage, wo Daten gespeichert und verarbeitet werden. Er beantwortet nicht, welcher Rechtsordnung der Anbieter unterliegt, wer administrativen Zugriff auf die Systeme erhalten kann, wer die kryptografischen Schlüssel kontrolliert und wie abhängig ein Unternehmen technisch von der Plattform bleibt. Für die Bewertung einer Cloud-Architektur sollten deshalb mindestens drei Dimensionen getrennt betrachtet werden: Datenstandort, Souveränität und technische Kontrolle.
Diese Unterscheidung ist keine akademische Feinheit. Auch die Europäische Kommission behandelt Cloud-Souveränität nicht als einzelne Produkteigenschaft. Ihr Cloud Sovereignty Framework bewertet sie entlang von acht Souveränitätszielen, die strategische, rechtliche und jurisdiktionelle Aspekte ebenso umfassen wie Daten und KI, Betrieb, Lieferkette, Technologie, Security und Compliance sowie ökologische Nachhaltigkeit.
1. Was ein Datenstandort tatsächlich beschreibt
Der Datenstandort beschreibt zunächst nur den geografischen Ort, an dem Daten gespeichert oder verarbeitet werden. Bei einem Cloud-Dienst lässt sich beispielsweise vereinbaren, dass Kundendaten ausschließlich in Rechenzentren in Deutschland oder innerhalb der Europäischen Union liegen. Für eine technische Bewertung reicht die Bezeichnung einer Cloud-Region jedoch nicht aus.
Zu klären ist, wo sich Primärdaten, Replikate und Backups befinden, wo Metadaten sowie Management- und Logging-Daten gehalten werden und wo die Systeme betrieben werden, die diese Daten verarbeiten. Erst diese Aufschlüsselung ergibt ein belastbares Bild der Datenlokalität. Die entscheidende Frage lautet deshalb nicht allein, wo die Daten liegen, sondern welche Daten wo liegen und wo sie verarbeitet werden. In der Praxis fällt die Antwort für Nutzdaten häufig anders aus als für Metadaten, Protokolle und Managementinformationen.
2. Warum Standort und Souveränität getrennt bewertet werden müssen
Ein Rechenzentrum besitzt einen physischen Standort. Ein Cloud-Dienst besitzt darüber hinaus Betreiber-, Unternehmens-, Vertrags- und Rechtsstrukturen. Deshalb müssen die geografische Frage nach dem Speicher- und Verarbeitungsort und die jurisdiktionelle Frage nach den anwendbaren Rechtsordnungen getrennt beantwortet werden.
Dass diese Trennung nicht theoretisch ist, zeigt der EU Data Act. Artikel 32 der Verordnung (EU) 2023/2854 behandelt ausdrücklich den staatlichen Zugriff von Drittländern auf nicht-personenbezogene Daten, die innerhalb der Union gehalten werden. Anbieter von Datenverarbeitungsdiensten müssen angemessene technische, organisatorische und rechtliche Maßnahmen treffen, um einen solchen Zugriff oder eine solche Übermittlung zu verhindern, wenn diese im Widerspruch zu Unionsrecht oder zum nationalen Recht eines Mitgliedstaates stehen würde. Der Gesetzgeber unterscheidet damit selbst zwischen dem Speicherort innerhalb der Union und möglichen Zugriffsanforderungen aus Drittstaaten. Für die Architekturplanung folgt daraus: Der geografische Datenstandort ist ein wichtiges, aber kein hinreichendes Kriterium.
Jurisdiktion wirkt bis in die technische Architektur hinein
Jurisdiktion erscheint zunächst als juristisches und nicht als technisches Thema. Für Cloud-Architekturen hat sie dennoch unmittelbare betriebliche Folgen. Ein Cloud-Dienst besteht nicht nur aus Storage und Compute, sondern ebenso aus Control Plane, Identity-Systemen, Managementzugängen, Supportprozessen, Software, Updates und weiteren Dienstleistern. Daraus entsteht eine Abhängigkeitskette, die vom eigenen Unternehmen über den Cloud-Service und dessen Betreiber bis zu dessen Konzernstruktur, Zulieferern, Technologieanbietern und den auf sie anwendbaren Rechtsordnungen reicht.
Die Europäische Kommission berücksichtigt diese Kette inzwischen ausdrücklich. Ihr Cloud Sovereignty Framework bewertet strategische, rechtlich-jurisdiktionelle, daten- und KI-bezogene, operative, lieferkettenbezogene, technologische, sicherheits- und compliancebezogene sowie ökologische Souveränität getrennt voneinander und ordnet ihnen insgesamt 48 Kriterien zu. Souveränität wird damit nicht auf den Standort eines Rechenzentrums reduziert.
3. Der ICC-Fall zeigt ein anderes Risiko als den Datenzugriff
Welche praktische Bedeutung solche Abhängigkeiten haben können, zeigte 2025 der Umgang mit US-Sanktionen gegen den Chefankläger des Internationalen Strafgerichtshofs, Karim Khan. Nach Berichten der Associated Press vom Mai 2025 verlor Khan infolge der im Februar 2025 verhängten Sanktionen den Zugriff auf sein bei Microsoft gehostetes E-Mail-Konto; die Arbeit des Gerichtshofs sei dadurch erheblich beeinträchtigt worden. Microsoft widersprach dieser Darstellung: Nach Angaben des Unternehmens wurden die Dienste für den Gerichtshof nicht eingestellt, die Umstellung des betroffenen Postfachs auf einen anderen Anbieter sei vielmehr vom Gerichtshof selbst veranlasst worden. Eine abschließende öffentliche Klärung des Sachverhalts durch den Gerichtshof liegt nicht vor. Im Oktober 2025 gab der Gerichtshof bekannt, für Büroanwendungen auf die quelloffene Plattform openDesk zu wechseln.
Für die Bewertung von Cloud-Souveränität ist der Fall aufschlussreich, darf aber nicht überinterpretiert werden. Er belegt nicht, dass ein Hyperscaler aufgrund seiner Konzernjurisdiktion automatisch auf beliebige, in deutschen Rechenzentren gespeicherte Kundendaten zugreifen kann. Er zeigt ein anderes Risiko: Ein Unternehmen kann von einem Dienst abhängig sein, dessen Betreiber aufgrund einer fremden Rechtsordnung verpflichtet oder veranlasst werden kann, seine Leistungserbringung zu verändern. Neben der Datenlokalität wird damit eine zweite Frage relevant, nämlich von welchen Unternehmen, Rechtsordnungen und technischen Komponenten die weitere Verfügbarkeit und Nutzbarkeit eines Dienstes abhängt.
4. Verschlüsselung beantwortet die Kontrollfrage nur zur Hälfte
Selbst Datenstandort und Jurisdiktion beschreiben noch nicht vollständig, wie viel Kontrolle ein Unternehmen über seine Daten besitzt. Dafür muss die technische Architektur betrachtet werden, und das wichtigste Beispiel ist die Verschlüsselung. Die Aussage, die Daten seien verschlüsselt, trägt für eine Souveränitätsbewertung nicht weit genug. Zu klären ist, wer die Schlüssel erzeugt, wer sie speichert, wer sie verwenden darf und ob der Cloud-Anbieter auf sie zugreifen kann. Ebenso zu klären ist, welche Systeme Klartextzugriff benötigen, wo diese Systeme betrieben werden, welche administrativen Rollen auf sie zugreifen können und ob entsprechende Zugriffe protokolliert und vom Kunden überprüft werden können.
Die Europäische Kommission berücksichtigt in ihrem Cloud Sovereignty Framework deshalb ausdrücklich die effektive Kontrolle des Kunden über den kryptografischen Datenzugriff sowie die Transparenz darüber, wann, wo und durch wen auf Daten zugegriffen wird.
Provider-verwaltete und kundenseitig kontrollierte Schlüssel
Bei einer vom Anbieter verwalteten Verschlüsselung können Daten auf den Speichermedien verschlüsselt sein, während die Schlüsselverwaltung Bestandteil derselben Plattform bleibt. Das schützt nicht automatisch vor jeder Form des Zugriffs über legitimierte Dienste oder administrative Ebenen. Eine Architektur, in der der Kunde die entscheidenden Schlüssel selbst kontrolliert, verschiebt die Kontrollgrenze. Vollständige Souveränität folgt daraus jedoch ebenfalls nicht: Sobald ein Cloud-Dienst Daten im Klartext verarbeiten muss, ist zu untersuchen, wo die Entschlüsselung stattfindet und welche Komponenten anschließend Zugriff auf die Klartextdaten besitzen. Die relevante Architekturfrage lautet deshalb nicht, ob die Daten verschlüsselt sind, sondern wer unter welchen technischen Bedingungen aus den verschlüsselten Daten wieder Klartext erzeugen kann.
5. Privilegierte Zugriffe entscheiden über die tatsächliche Kontrolle
Ein zweiter technischer Kontrollpunkt ist die Administration. Cloud-Kunden betrachten meist ihre eigenen Benutzer und Rollen. Für eine Souveränitätsbewertung ist ebenso relevant, welche administrativen Möglichkeiten auf Anbieterseite bestehen. Zu untersuchen sind privilegierte Provider-Rollen, Supportzugriffe, Break-Glass-Verfahren, Zugriffsgenehmigungsprozesse, Protokollierung, Auditierbarkeit und die organisatorische Trennung administrativer Funktionen.
Dabei ist zwischen Authentifizierung und Autorisierung zu unterscheiden. Eine starke Authentifizierung beantwortet, wer eine Identität nachweisen kann. Sie beantwortet nicht, welche Berechtigungen diese Identität anschließend besitzt. Souveränität verlangt deshalb auch Transparenz über privilegierte Zugriffswege, und zwar in einer Form, die der Kunde selbst nachvollziehen kann.
6. Ohne Exit-Fähigkeit bleibt Kontrolle formal
Eine häufig unterschätzte Dimension von Souveränität ist die Exit-Fähigkeit. Ein Unternehmen besitzt nur eingeschränkte technische Handlungsfreiheit, wenn seine Daten zwar formal ihm gehören, aber nicht in praktikabler Form aus einem Dienst herausgelöst werden können. Dabei sind drei Ebenen zu unterscheiden.
Datenportabilität
Zu prüfen ist, ob Daten vollständig exportiert werden können. Relevant sind nicht nur die Nutzdaten, sondern je nach Anwendung auch Metadaten und weitere Informationen, die für die Wiederherstellung der Funktion erforderlich sind. Ein Export, der Zugriffsrechte, Versionsstände oder Aufbewahrungsregeln verliert, ist technisch unvollständig.
Schnittstellen und Formate
Zu prüfen ist weiterhin, ob standardisierte beziehungsweise dokumentierte APIs und maschinenlesbare Formate verwendet werden oder ob Daten und Funktionen eng an proprietäre Mechanismen des Anbieters gebunden sind. Eine breit unterstützte Schnittstelle auf der Speicherebene erleichtert einen späteren Wechsel erheblich.
Funktionsportabilität
Selbst exportierbare Daten bedeuten nicht, dass eine Anwendung bei einem anderen Anbieter unverändert weiterläuft. Je stärker eine Architektur proprietäre Datenbanken, APIs, Identity-Dienste, Event-Systeme oder PaaS-Funktionen verwendet, desto größer wird der Migrationsaufwand.
Der EU Data Act adressiert diese Problematik ausdrücklich. Kapitel VI, die Artikel 23 bis 31, verpflichtet Anbieter von Datenverarbeitungsdiensten, Hindernisse für den Wechsel zu einem anderen Anbieter oder zurück in die eigene Infrastruktur zu beseitigen. Dazu gehören Anforderungen an exportierbare Daten, Schnittstellen, Informationen über technische Einschränkungen und die Unterstützung des Wechselprozesses. Die Regelungen gelten seit dem 12. September 2025 und nach Auffassung der Bundesnetzagentur auch für Bestandsverträge. Für Wechselentgelte gilt eine gestufte Regelung: Bis zum 12. Januar 2027 dürfen Anbieter nur noch reduzierte Entgelte erheben, die die unmittelbar mit dem Wechsel verbundenen Kosten nicht übersteigen; ab diesem Datum entfallen sie vollständig.
Der Rahmen ist allerdings in Bewegung. Der Digital Omnibus, den die Kommission am 19. November 2025 vorgelegt hat, sieht Ausnahmen von den Wechselpflichten für Verträge vor, die vor oder am 12. September 2025 geschlossen wurden, unter anderem für weitgehend kundenspezifisch angepasste Standarddienste und für Nicht-Infrastrukturdienste kleiner und mittlerer Anbieter. Das Verfahren zum Datenteil des Pakets war zum Redaktionsschluss nicht abgeschlossen; der Rat verhandelte zuletzt auf Basis eines konsolidierten Kompromisstextes. Für laufende Beschaffungen bedeutet das, dass die geltende Fassung des Kapitels VI maßgeblich bleibt, die Ausnahmetatbestände aber im Blick behalten werden sollten. Unabhängig davon beseitigen regulatorische Wechselrechte nicht automatisch die technischen Abhängigkeiten einer konkreten Anwendungsarchitektur.
7. Souveränität lässt sich nicht als Produkteigenschaft einkaufen
Die verschiedenen Dimensionen lassen sich nicht auf ein einzelnes Merkmal reduzieren. Eine Cloud-Architektur kann gleichzeitig Daten in Deutschland halten, von einem Anbieter mit Sitz außerhalb der EU betrieben werden, gespeicherte Daten verschlüsseln, die Schlüsselverwaltung beim Anbieter belassen, eine standardisierte Speicherschnittstelle anbieten und proprietäre Anwendungsdienste verwenden. Ein Urteil „souverän“ oder „nicht souverän“ wäre für eine solche Architektur zu grob. Sinnvoller ist es, die einzelnen Abhängigkeiten systematisch zu untersuchen.
Dimension
Datenstandort
Verarbeitung
Metadaten
Jurisdiktion
Administration
Verschlüsselung
Schlüsselkontrolle
Audit
Schnittstellen
Datenexport
Migration
Löschung
Lieferkette
Zu klärende Frage
Wo befinden sich Primärdaten, Replikate und Backups?
Wo werden Daten verarbeitet?
Wo werden Management-, Logging- und Metadaten gehalten?
Welchen Rechtsordnungen unterliegen Anbieter und beteiligte Unternehmen?
Wer besitzt privilegierten Zugriff auf die Systeme?
Wo und wie werden Daten verschlüsselt?
Wer kontrolliert die notwendigen Schlüssel?
Können administrative Zugriffe nachvollzogen werden?
Werden dokumentierte und portable APIs beziehungsweise Protokolle eingesetzt?
Welche Daten und Metadaten können exportiert werden?
Wie kann der Dienst zu einem anderen Anbieter oder On-Premisesübertragen werden?
Wie werden Primärdaten, Kopien und Backups nach Vertragsende behandelt?
Von welchen weiteren Unternehmen und Technologien hängt der Dienst ab?
8. Was wir in aktuellen Kundengesprächen beobachten
In unseren Cloud-Gesprächen wird Souveränität zunehmend nicht mehr ausschließlich über den Standort des Rechenzentrums diskutiert. Kunden stellen mehrere Anforderungen nebeneinander: Datenhaltung in Deutschland, Datenhaltung innerhalb der Europäischen Union, Herkunft und rechtliche Bindung des Anbieters, mögliche Zugriffs- und Einflussmöglichkeiten aus Drittstaaten, Kontrolle über die Verschlüsselungsschlüssel sowie die Möglichkeit, Daten und Dienste später wieder aus der Cloud herauszulösen.
Wir haben daraus bislang keine allgemeingültige Architekturregel wie „europäischer Anbieter statt Hyperscaler“ abgeleitet. Unsere Beobachtung ist vielmehr, dass die Aussage, die Daten lägen in Deutschland, die Souveränitätsfrage für viele Kunden nicht mehr abschließend beantwortet. Damit verändert sich auch die Anbieterbewertung. Neben Kosten, Funktion, Performance und Verfügbarkeit müssen die rechtlichen, organisatorischen und technischen Abhängigkeiten einer Plattform untersucht werden.
Das ist deshalb relevant, weil unterschiedliche Anforderungen nicht dieselbe Lösung verlangen. Ein Unternehmen, dessen primäre Vorgabe eine Datenhaltung innerhalb der EU ist, besitzt ein anderes Anforderungsprofil als ein Unternehmen, das zusätzlich die Abhängigkeit von Drittstaaten, die Schlüsselkontrolle oder die technologische Exit-Fähigkeit minimieren möchte.
9. Eine Souveränitätsprüfung beginnt mit Anforderungen, nicht mit Anbietern
Bevor Anbieter verglichen werden, sollte definiert werden, welche Form von Kontrolle tatsächlich benötigt wird. Wir arbeiten dabei mit einer gestuften Prüfreihenfolge, die bewusst mit den fachlichen Vorgaben beginnt und erst danach auf Technik und Anbieter führt.
Erst wenn diese Anforderungen definiert sind, lässt sich beurteilen, ob eine bestimmte Public-, Private- oder Hybrid-Cloud-Architektur sie erfüllt.
Stufe
Datenlokalität
Verarbeitungslokalität
Jurisdiktion
Betreiberkontrolle
Kryptografische Kontrolle
Technologische Abhängigkeit
Exit
Leitfrage
Welche Daten dürfen Deutschland oder die EU nicht verlassen?
Gilt die Vorgabe nur für persistente Speicherung oder auch für Verarbeitung, Metadaten, Backups und Managementinformationen?
Welche rechtlichen Abhängigkeiten gegenüber Drittstaaten sind akzeptabel?
Welche administrativen Zugriffsmöglichkeiten des Anbieters sind zulässig?
Wer muss die Kontrolle über die Schlüssel besitzen?
Welche proprietären Dienste dürfen eingesetzt werden?
Wie müssen Daten, Metadaten und Anwendungen migrierbar sein?
10. Auch ein europäischer Anbieter löst nicht jede Abhängigkeit
Die umgekehrte Vereinfachung wäre technisch ebenso falsch. Der Sitz eines Anbieters innerhalb der EU beantwortet nicht automatisch alle Souveränitätsfragen. Auch ein europäischer Cloud-Anbieter kann von Hardware, Firmware, Software, Plattformkomponenten oder Lieferanten aus Drittstaaten abhängig sein. Genau deshalb bewertet das Cloud Sovereignty Framework neben rechtlicher Souveränität auch Lieferketten und technologische Souveränität getrennt. Die Kommission hat bei der eigenen Cloud-Beschaffung im April 2026 entsprechend argumentiert, dass auch nicht-europäische Technologie unter definierten Betriebsbedingungen ein festgelegtes Mindestniveau an Souveränität erreichen kann. Die Herkunft des Anbieters ist damit ein mögliches Entscheidungskriterium, aber nicht die vollständige Architekturprüfung.
11. Fazit
Der Standort eines Rechenzentrums bleibt ein wichtiges Kriterium für Cloud-Architekturen. Er darf jedoch nicht mit Datensouveränität gleichgesetzt werden. Ein Unternehmen kann seine Daten ausschließlich in Deutschland speichern und trotzdem von fremden Rechtsordnungen, administrativen Zugriffsmöglichkeiten, anbieterseitiger Schlüsselverwaltung, proprietären Diensten oder externen Technologielieferanten abhängig sein. Umgekehrt lässt sich Souveränität nicht allein über die Nationalität eines Anbieters definieren, weil dessen Technologie- und Lieferkette sowie die konkrete technische Architektur ebenfalls berücksichtigt werden müssen.
Die entscheidende Frage lautet deshalb nicht, ob die Daten in Deutschland stehen, sondern wer unter welchen rechtlichen, organisatorischen und technischen Bedingungen auf Daten und Dienste einwirken kann und welche Kontrolle das Unternehmen selbst behält. Datenstandort, Drittstaatenabhängigkeit, Schlüsselkontrolle und Exit-Fähigkeit sollten deshalb als eigenständige Anforderungen in Architektur und Anbieterauswahl eingehen, nicht als nachgelagerte Prüfpunkte.
12. Quellen
Europäische Union: Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates vom 13. Dezember 2023 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung (Data Act). Kapitel VI (Art. 23–31, Wechsel zwischen Datenverarbeitungsdiensten), Kapitel VII (Art. 32, unrechtmäßiger internationaler behördlicher Zugang zu und Übermittlung von nicht-personenbezogenen Daten). Anwendbar seit 12. September 2025. EUR-Lex, https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng, abgerufen am 7. September 2026.
European Commission: Vorschlag für eine Digital-Omnibus-Verordnung, 19. November 2025, einschließlich der vorgeschlagenen Änderungen an Kapitel VI der Verordnung (EU) 2023/2854. Der Datenteil des Pakets befand sich zum Abrufzeitpunkt weiterhin im Gesetzgebungsverfahren. https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal, abgerufen am 7. September 2026.
European Commission, Directorate-General for Digital Services (DG DIGIT): Cloud Sovereignty Framework, Version 1.2.1, veröffentlicht am 20. Oktober 2025. Acht Sovereignty Objectives, Sovereignty Effectiveness Assurance Level (SEAL-0 bis SEAL-4) und gewichteter Sovereignty Score. https://commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en, abgerufen am 7. September 2026.
European Commission: Sovereign Cloud Framework explained, 1. Juni 2026. Erläuterung der 48 Kriterien in acht Kategorien sowie der SEAL-Schwellenwerte. https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en, abgerufen am 7. September 2026.
European Commission: Commission advances cloud sovereignty through strategic procurement, 17. April 2026. Anwendung des Frameworks bei der Cloud-Beschaffung der Kommission, Mindestanforderung SEAL-2. https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en, abgerufen am 7. September 2026.
Europäisches Parlament: Parlamentarische Anfrage P-002270/2025 vom Mai 2025 zu den Auswirkungen der US-Sanktionen auf die Arbeitsfähigkeit des Internationalen Strafgerichtshofs, mit Bezug auf die Berichterstattung der Associated Press vom 15. Mai 2025. https://www.europarl.europa.eu/doceo/document/P-10-2025-002270_EN.html, abgerufen am 7. September 2026.
Lawfare: When Governments Pull the Plug, 26. September 2025. Einordnung der AP-Berichterstattung und der widersprechenden Darstellung von Microsoft. https://www.lawfaremedia.org/article/when-governments-pull-the-plug, abgerufen am 7. September 2026.
JusticeInfo.net: How sanctions can weaponize US tech against the ICC, 19. März 2026. Dokumentation des Wechsels des Internationalen Strafgerichtshofs auf openDesk (ZenDiS) ab 31. Oktober 2025. https://www.justiceinfo.net/en/156691-how-sanctions-can-weaponize-us-tech-against-the-icc.html, abgerufen am 7. September 2026.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
