Die europäische Cloud-Frage ist nicht, wo der Server steht
Ein Standort kann wahr sein und die Frage trotzdem offenlassen
In jeder Diskussion über Cloud-Lösungen kommt ein vertrauter Moment. Jemand fragt, wo die Daten gespeichert werden. Jemand anderes antwortet mit dem Namen einer europäischen Stadt. Die Runde entspannt sich ein wenig. Die Antwort mag vollkommen korrekt sein, und sie kann sehr viel bedeuten. Die Geografie beeinflusst Latenz, physische Sicherheit, Stromversorgung, Resilienzplanung, Beschäftigung, öffentliche Rechenschaftspflicht und die rechtlichen Rahmenbedingungen eines Dienstes. Eine öffentliche Behörde, die bestimmte Aufzeichnungen innerhalb eines festgelegten Hoheitsgebiets halten muss, hat allen Grund, diese Frage zu stellen. Das Problem beginnt, wenn der Stadtname alle übrigen Fragen der Vereinbarung beantworten soll.
Ein Server steht irgendwo. Ein Dienst tut das nicht. Ein Dienst ist eine Beziehung zwischen juristischen Personen, Menschen mit Administratorrechten, Softwarekomponenten, Hardwareanbietern, Verträgen, Supportteams, Netzwerken, Verschlüsselungsvereinbarungen, Subunternehmen und der Kundschaft, die von dem Ergebnis abhängt. Das Gebäude ist ein materieller Teil dieser Beziehung. Es verrät nicht, wer von anderer Stelle eine privilegierte Anweisung erteilen kann, welche Unternehmensgruppe die Betreibergesellschaft kontrolliert, welche Rechtsordnung einen Anbieter erreichen kann, ob sich ein Subauftragsverarbeiter geändert hat oder was die Kundschaft bei Vertragsende mitnehmen kann.
Das ist kein Argument gegen europäische Rechenzentren oder europäische Anbieter. Es ist ein Argument dagegen, eine nützliche Antwort Arbeit verrichten zu lassen, die sie nicht leisten kann. Bei der europäischen Cloud-Frage geht es nicht darum, ob ein Server auf europäischem Boden stehen kann. Es geht darum, ob die Organisation, die den Dienst nutzt, die gesamte Vereinbarung so weit verstehen und kontrollieren kann, wie es die jeweilige Aufgabe erfordert. Der Standort gehört zu dieser Antwort. Er kann nicht die ganze Antwort sein, so wenig wie eine Firmenadresse verrät, wer die Schlüssel zu den Konten besitzt.
Diese Unterscheidung ist dort am wichtigsten, wo die Cloud gewöhnliche, folgenreiche Arbeit verrichtet. Eine Kommunalverwaltung kann Korrespondenz, Fallakten und öffentliche Informationen in einer gehosteten Umgebung halten. Ein Hersteller kann Entwürfe und Betriebsdaten halten. Eine Forschungsgruppe kann einen Datensatz halten, der nicht ohne Weiteres verschoben werden kann. Ein Krankenhaus kann Dienste nutzen, die personenbezogene Daten berühren. Keines dieser Beispiele braucht einen dramatischen Ausfall oder einen Spionageroman, um ernst zu werden. Die alltägliche Frage ist einfacher: Wer hat praktische Befugnis über ein System, das Teil der Arbeitsfähigkeit der Organisation geworden ist?
Europäisches Recht und europäische Leitlinien behandeln dies zunehmend als Frage von Nachweisen, Rollen und Wechselmöglichkeiten statt als Frage beruhigender Begriffe. Der Data Act gibt Kundinnen und Kunden Rechte und Anbietern Pflichten beim Wechsel, bei exportierbaren Daten und bei Schnittstellen für Datenverarbeitungsdienste. Der EDPS sagt seit Langem, dass europäische Institutionen, die Cloud-Dienste nutzen, für ihre Datenschutzpflichten verantwortlich bleiben. ENISAs Arbeit zum Cloud-Risiko benennt Lock-in und rechtliche Risiken als zu bewertende Punkte. Das sind keine identischen Instrumente, und sie schaffen keine einheitliche Cloud-Doktrin. Zusammen weisen sie in eine nützliche Richtung: Kontrolle muss beschrieben werden, nicht nur angedeutet.
Der Kartenpunkt und die Steuerungsebene
Die Sprache der Cloud macht die Unterscheidung oft schwerer sichtbar. Das Wort Cloud erinnert an ein Wettersystem: groß, fern und vielleicht unvermeidlich. In der Praxis hat ein Cloud-Dienst eine Steuerungsebene und eine Arbeitsebene. Die Arbeitsebene ist der Ort, an dem eine Arbeitslast läuft, Daten gespeichert werden, Anfragen verarbeitet und Ergebnisse zurückgegeben werden. Die Steuerungsebene ist die Gesamtheit der Mechanismen, über die Identitäten verwaltet, Richtlinien geändert, Software aktualisiert, Kapazitäten zugewiesen, Support geleistet, Aufzeichnungen abgerufen und Systeme gestoppt oder wiederhergestellt werden. Beide Ebenen können technisch verteilt sein. Beide können Organisationsgrenzen überschreiten.
Eine Standortangabe spricht in der Regel zuerst über die Arbeitsebene. Sie kann besagen, wo sich ein bestimmter Datenspeicher, eine virtuelle Maschine oder eine Region befindet. Diese Information sollte präzise genug sein, um nützlich zu sein. Sie sollte angeben, was sie abdeckt, welche Datenkategorien sie betrifft, wie Änderungen mitgeteilt werden und ob Sicherungskopien, Protokolle, Supportinformationen und abgeleitete Daten derselben Regel folgen. Eine Aussage, die lediglich Europa nennt, ohne eine Grenze zu ziehen, ist eher der Ausgangspunkt für eine Frage als eine Antwort. Europa ist ein großer Ort, und die Architektur von Diensten liebt Ausnahmen.
Die Kontrollebene stellt eine andere Reihe von Fragen. Wer kann einen Administrator anlegen oder entfernen? Wer genehmigt einen Notfalleingriff? Wer betreibt den Identitätsdienst? Wer kann Diagnoseinformationen einsehen? Welches Unternehmen pflegt die Software, die die Plattform zum Funktionieren bringt? Welche juristische Person erhält eine Anfrage einer Behörde? Welcher Unterauftragnehmer darf Support übernehmen? Welche Partei kann eine Dienstbeschreibung ändern oder eine Funktion einstellen? Ein Kunde kann sich jeden Tag anmelden und dennoch keinen unabhängigen Weg haben, auch nur eine dieser Fragen zu beantworten.
Das bedeutet nicht, dass Kunden erwarten sollten, jedes physische Gerät selbst zu betreiben. Das können sie in der Regel nicht, und die meisten müssen es auch nicht. Es geht darum, Delegation sichtbar zu machen. Delegierter Betrieb kann verantwortungsvoll und effizient sein, wenn die übertragenen Befugnisse definiert, überwacht und widerrufbar sind. Er wird zu einem Souveränitätsproblem, wenn der Kunde nur ein vertragliches Etikett für die Kontrolle hat, während der Anbieter die Personen, Schnittstellen, Aufzeichnungen und das technische Wissen behält, die zur Ausübung dieser Kontrolle nötig sind. Ein Vertrag, der in der Praxis nicht nutzbar ist, ist ein dekoratives Objekt mit guter Typografie.
Für einen Käufer ist die praktische Konsequenz klar. Behalten Sie die Standortfrage. Stellen Sie die Kontrollfrage daneben. Fragen Sie, wo die Arbeitslast liegt, und fragen Sie dann, wer ihre Bedingungen ändern kann. Fragen Sie, wo die Daten verarbeitet werden, und fragen Sie dann, wer Zugang zum administrativen Weg hat. Fragen Sie, wo die Sicherungskopie aufbewahrt wird, und fragen Sie dann, wer sie wiederherstellen kann und unter welcher Autorität. Die Antworten können zufriedenstellend sein. Sie können eine Abhängigkeit offenlegen, die bewusst akzeptiert werden muss. Beides ist besser, als zu entdecken, dass ein Punkt auf einer Karte die Arbeit eines Betriebsmodells verrichtet hat.
Eigentum ist kein administratives Detail
Eigentum wird manchmal als eine separate Debatte über Flaggen, Börsen und nationalen Stolz behandelt. Es ist konkreter als das. Eigentum kann bestimmen, wer den Vorstand ernennt, wer einen Verkauf genehmigt, wer Investitionen lenkt, wem geistiges Eigentum gehört, welche Konzernrichtlinien gelten und welche Einheit letztlich entscheidet, ob ein Dienst ein Geschäftsfeld bleibt. Ein Kunde braucht keine vereinfachte Regel, dass nur eine Eigentumsstruktur akzeptabel ist. Er muss die Struktur jedoch kennen, bevor er die Vereinbarung als unabhängig bezeichnet.
Die Unternehmensorganisation beeinflusst auch, was ein Cloud-Versprechen bedeutet. Eine Marke kann lokal sein, während der Dienst von einer anderen Einheit betrieben wird. Eine europäische Tochtergesellschaft kann mit einem europäischen Kunden einen Vertrag schließen, während eine Gruppe anderswo wesentliche Software, Sicherheitsbetrieb, Support, Abrechnung, Datenanalyse oder Führungsbefugnis bereitstellt. Ein lokaler Partner kann echte wertvolle Implementierungsarbeit leisten und dennoch von einer Plattform abhängen, die er nicht verändern kann. Keine dieser Vereinbarungen ist automatisch unangemessen. Es sind unterschiedliche Kontrollvereinbarungen, und sie sollten durch ein gemeinsames Logo und eine lokale Telefonnummer nicht gleich aussehen.
The relevant question is not whether a buyer can find a foreign connection somewhere in a long supply chain. Modern technology is interconnected, and purity tests are not a procurement method. The question is where a dependency becomes decisive. Which entity can change the contract? Which entity controls the service's intellectual property? Which entity can make a support commitment? Which entity has the credentials or knowledge needed to recover the function? Which entity can be bought, sanctioned, reorganised or instructed in a way that changes the customer's position? Those are questions about actual leverage.
Ownership also changes. An acquisition, a funding round, a restructuring or an internal transfer can alter the control picture without moving a single server. A location clause written at signature may remain factually correct while the organisational facts around it have changed. That is why a serious cloud file needs a change process. The customer should know which change has to be disclosed, who will assess its effect, what evidence must be updated and which authority can pause a new data flow while the assessment is made. It is not glamorous work. Neither is checking the oil in a car, which is perhaps why people remember it after the engine complains.
In its 2018 cloud guidelines, the EDPS emphasised that EU institutions remain responsible for their data-protection obligations when they use cloud computing services and should secure an equivalent level of protection to other infrastructure models. That is not a demand that every institution own everything. It is a reminder that outsourcing a function does not outsource the duty to understand the arrangement. The duty makes ownership relevant because responsibility cannot be exercised through a diagram that omits the party with the practical power.
Legal reach is not erased by a European address
Jurisdiction is often the most uncomfortable layer because it resists the simple answer. A contract may select a governing law and a court. Those choices matter. They do not make other legal powers disappear. Legal reach may follow an entity, an establishment, a service provider, a corporate group, a person with access, a hardware vendor or the location and nature of particular data. The exact analysis depends on facts and law. A blog post cannot settle it for a real organisation, and a procurement template cannot replace proper advice where the risk is material.
The useful discipline is to separate a legal question from a geographic statement. A data centre in the European Union tells us where equipment is situated. It does not by itself tell us which entities can be compelled, which authorities might make a request, what notification is possible, or whether a provider has obligations under another legal order. Treating the two as equivalent can produce a false sense of closure. The buyer may have satisfied a residency requirement while leaving the legal analysis entirely unperformed.
The EDPB's final guidelines on the interplay between Article 3 GDPR and Chapter V international transfers are helpful precisely because they resist shortcuts. They distinguish the territorial scope of the GDPR from the question whether a processing operation is an international transfer. That distinction does not provide an all-purpose conclusion about every cloud arrangement. It does show why phrases such as EU-based or GDPR-covered cannot carry every legal inference a buyer may want to make. The data-protection analysis follows the actual processing and actors.
Der Data Act bringt eine verwandte Frage in die Akte zu Cloud-Diensten ein. Sein Kapitel VII betrifft unrechtmäßigen internationalen staatlichen Zugriff auf und die Übermittlung von nicht personenbezogenen Daten, die in der Union gespeichert sind. Die Verordnung verlangt von Anbietern von Datenverarbeitungsdiensten, in den in Artikel 32 beschriebenen Umständen angemessene technische, organisatorische und rechtliche Maßnahmen zu ergreifen, einschließlich vertraglicher Maßnahmen. Sie verspricht nicht, dass ein Anbieter jede externe Anfrage verschwinden lassen kann. Sie verlangt eine disziplinierte Reaktion auf einen Konflikt, der nicht durch einen Marketingbegriff weggewünscht werden kann.
Für Kunden besteht die unmittelbare Arbeit in einer Nachweiskarte. Identifizieren Sie die Vertragspartei, die Anbietereinheiten, die wesentliche Teile des Dienstes betreiben, die Orte, an denen Daten und Verwaltung stattfinden, die angegebenen Rechtsordnungen, den Weg für den Empfang von und die Anfechtung von Anfragen, die Meldepflichten und die rechtliche Beratung, die für die jeweilige Arbeitslast erforderlich ist. Markieren Sie, was bekannt ist, was vom Anbieter angegeben wird, was vertraglich zugesichert ist und was noch untersucht werden muss. Eine Karte mit einem Datum und einer Lücke ist nützlicher als ein immerwährender Zusicherungsabsatz.
Operative Kontrolle ist der Punkt, an dem ein Versprechen real wird
Operative Kontrolle ist die Fähigkeit, ein System durch eine definierte Befugnis und einen definierten Mechanismus dazu zu bringen, etwas zu tun oder damit aufzuhören. Sie umfasst alltägliche Dinge: ein Konto erstellen, eine Netzwerkrichtlinie ändern, einen Schlüssel rotieren, ein Backup wiederherstellen, eine Freigabe genehmigen, einen Mandanten isolieren, einen Administrator abziehen, ein Protokoll prüfen und einen Datensatz exportieren. Keine dieser Handlungen ist ein Souveränitätszertifikat. Zusammen zeigen sie, ob Kunde und Anbieter eine verständliche Aufgabenteilung haben.
Eine Cloud-Vereinbarung ist schwach, wenn jede folgenreiche Handlung mit einer E-Mail an eine allgemeine Supportadresse endet. Support ist wichtig, und fachkundiger Support kann einer der guten Gründe sein, einen verwalteten Dienst zu nutzen. Aber eine kritische Organisation sollte zwischen einem Supportweg und einem Befugnisweg unterscheiden. Ein Supportweg ist die Art, wie der Anbieter hilft. Ein Befugnisweg ist die Art, wie der Kunde eine Handlung, für die er verantwortlich bleibt, einleiten, genehmigen, beobachten und aufzeichnen kann. Die beiden können in einem Ticket zusammenlaufen. Sie sollten nicht verwechselt werden.
Betrachten wir einen eindeutig hypothetischen Fall. Ein europäisches Forschungskonsortium nutzt eine gehostete Analyseumgebung für ein sensibles, aber rechtmäßiges Projekt. Es hat einen Vertrag für die europäische Region und eine dokumentierte Datenspeicherung. Während einer internen Überprüfung möchte das Konsortium eine bestimmte Pipeline aussetzen, die zugehörigen Aufzeichnungen aufbewahren und verhindern, dass eine neue Datenquelle angebunden wird, bis die Überprüfung abgeschlossen ist. Die nützlichen Fragen sind nicht, ob sich ein imaginärer Betreiber heldenhaft verhält. Sie sind, ob das Konsortium eine benannte Rolle hat, die die Änderung anordnen kann, ob die Plattform einen kontrollierten Mechanismus bereitstellt, ob die Handlung aufgezeichnet wird und ob abhängige Abläufe sichtbar sind, bevor der Schalter verwendet wird.
Das hypothetische Beispiel ist bewusst ruhig gehalten, weil gewöhnliche Befugnis der Punkt ist. Ein Dienst muss nicht ausfallen, damit der Kunde Kontrolle benötigt. Eine Datenschutzprüfung, Zweckänderung, Beschaffungsentscheidung, Vertragsstreitigkeit, Sicherheitsbedenken oder Personalabgang können alle eine begrenzte Handlung erfordern. Wenn niemand weiß, wer sie vornehmen darf, oder wenn der Kunde nicht prüfen kann, was die Handlung bewirkt hat, ist das Problem nicht, dass die Cloud geheimnisvoll ist. Das Problem ist, dass das Betriebsmodell nie vervollständigt wurde.
Gute betriebliche Kontrolle ist nicht zwangsläufig zentralisiert. Eine große Institution kann Zuständigkeiten auf einen Serviceverantwortlichen, eine Sicherheitsfunktion, eine Datenschutzstelle, ein Betriebsteam und einen Lieferanten verteilen. Eine solche Aufteilung kann das Risiko verringern, dass eine einzelne Person allein eine schädliche Entscheidung trifft. Entscheidend ist, dass die Zuständigkeitsgrenze klar erkennbar ist. Jede Rolle sollte wissen, was sie veranlassen darf, was sie genehmigen darf, was sie dokumentieren muss, wann sie eskalieren muss und wie die Organisation vorgeht, wenn die übliche Person nicht verfügbar ist. Die Cloud ist nicht von der Governance ausgenommen, nur weil ihr Dashboard übersichtlich ist.
Die Subunternehmerlinie ist Teil des Dienstes
Die meisten Cloud-Dienste werden nicht von einem einzigen Unternehmen mit einem einzigen Gebäude und einem einzigen Software-Stack erbracht. Sie können Infrastrukturanbieter, Netzbetreiber, Managed-Security-Dienste, Support-Partner, Zahlungsabwickler, Software-Wartungsunternehmen, Identitätsdienste, Hardware-Hersteller und spezialisierte Subunternehmer umfassen. Eine komplexe Kette ist kein Beleg für Versagen. Sie ist ein Grund, die Kette zu beschreiben. Der Kunde muss wissen, wo wesentliche Abhängigkeiten beginnen, was diese tun dürfen und wie eine Änderung kommuniziert wird.
Die datenschutzrechtliche Terminologie von Verantwortlichem und Auftragsverarbeiter ist hier nützlich, sollte aber kein Ersatz für Verständnis werden. Eine Auftragsverarbeiterliste kann Organisationen benennen, die personenbezogene Daten im Auftrag eines Lieferanten verarbeiten. Sie beantwortet möglicherweise nicht jede betriebliche Frage zu Software-Lieferung, Hardware-Support, Fernadministration, Telemetrie, Incident Response oder Unternehmensbefugnissen. Umgekehrt kann ein technisches Inventar Komponenten auflisten, aber auslassen, wer gegenüber dem Kunden eine vertragliche Pflicht hat. Die beiden Sichtweisen müssen gemeinsam gelesen werden, statt als konkurrierende Dokumente zu dienen.
Die Cloud-Leitlinien des EDPS empfehlen eine klare Zuweisung von Verantwortlichkeiten und die Beachtung der Rollen der an Cloud-Diensten beteiligten Parteien. Dieses praktische Anliegen bleibt aktuell, weil komplexe Bereitstellungsmodelle den Eindruck erwecken können, Verantwortung sei in der Architektur aufgegangen. Das ist sie nicht. Jemand entscheidet weiterhin über den Zweck einer Verarbeitung. Jemand legt weiterhin die technischen Bedingungen fest. Jemand akzeptiert weiterhin einen Subunternehmer. Jemand muss weiterhin erklären, was geschehen ist, wenn sich ein System ändert. Komplexität kann erklären, warum die Antwort Zeit braucht. Sie macht die Frage nicht unangemessen.
Es gibt einen brauchbaren Test für die Wesentlichkeit. Wenn ein Lieferant morgen aus der Vereinbarung verschwände, würde der Dienst dann eine Funktion verlieren, die der Kunde benötigt, eine Sicherheitseigenschaft verlieren, den Zugriff auf einen Datensatz verlieren oder die Fähigkeit zur Migration verlieren? Wenn die Antwort ja lautet, gehört dieser Lieferant in die Kontrollübersicht. Die Übersicht muss nicht jeden Widerstand offenlegen oder jede Geschäftsbeziehung öffentlich machen. Sie muss aber Abhängigkeiten zeigen, die die Fähigkeit des Kunden verändern, die Arbeit zu steuern. Eine versteckte Abhängigkeit ist keine clevere Abstraktion. Sie ist ein künftiges Gespräch mit einem etwas anderen Ton.
Die Kontrolle über Subunternehmer hängt auch von der Zeit ab. Der Käufer sollte wissen, wie neue Auftragsverarbeiter und wesentliche betriebliche Lieferanten eingeführt werden, welche Ankündigungsfrist gilt, welches Einspruchs- oder Bewertungsverfahren Anwendung findet und wie eine Änderung dokumentiert wird. Eine statische Liste ist besser als keine Liste. Eine aktuelle, überprüfbare Liste ist besser, weil sie anerkennt, dass ein Dienst bei Vertragsunterzeichnung nicht eingefroren ist. Die Organisation kann die Abhängigkeiten nicht steuern, von deren Eintreffen ihr nicht mitgeteilt wurde.
Hardware hat eine Politik und eine betriebliche Konsequenz
Es ist verlockend, die Analyse an der Softwareschnittstelle enden zu lassen. Der Dienst funktioniert, das Dashboard ist in der richtigen Sprache, die Vereinbarung nennt eine europäische Region, und die Infrastruktur darunter wirkt zu entfernt, um von Nutzen zu sein. Doch Hardware und ihre Lieferkette können entscheidend sein, wenn es auf Verfügbarkeit, Vertraulichkeit, Wartung, Reparatur, Kapazität oder Kontinuität ankommt. Die Frage ist nicht, ob ein Kunde jeden Chip prüfen sollte. Die Frage ist, ob der Kunde weiß, von welchen Abhängigkeiten der gewählte Dienst abhängt und was geschieht, wenn sich eine davon ändert.
Genau hier verdient die Unterscheidung zwischen souveränem Anspruch und Selbstversorgung besondere Aufmerksamkeit. Europa ist Teil globaler Lieferketten. Keine ernsthafte Organisation kann jeden Halbleiter, jedes Kabel, jeden Server, jede Firmware-Komponente, jedes Betriebssystem und jedes Werkzeug innerhalb einer einzigen Beschaffungsgrenze herstellen. Das wäre auch für jede Arbeitslast kein sinnvoller Maßstab. Praktische Souveränität ist die Fähigkeit, Abhängigkeiten zu erkennen, Bedingungen um sie herum zu setzen, wo nötig Alternativen vorzuhalten und nicht so zu tun, als sei eine unverzichtbare externe Komponente nicht unverzichtbar.
Hardware-Abhängigkeiten können die Cloud-Kontrolle über Kapazitätszuweisung, Wartungszugriff, Software-Updates, Ersatzwege und vertrauenswürdige Komponenten beeinflussen. Sie können auch die Machbarkeit einer Migration beeinträchtigen. Eine Arbeitslast, die um eine bestimmte verwaltete Funktion, eine spezifische Beschleuniger-Umgebung oder eine undokumentierte Integration herum entwickelt wurde, ist möglicherweise nur in dem Sinne technisch portierbar, wie ein Klavier portierbar ist, wenn jemand anbietet, es sechs Treppen hochzutragen. Das Substantiv stimmt. Der Plan ist unvollständig.
Die Cloud-Risikobewertung der ENISA ist inzwischen eine ältere Veröffentlichung, aber ihre Warnung vor Lock-in, rechtlichem Risiko und Kontrollverlust ist nicht altmodisch geworden. Das technische Vokabular hat sich seit ihrem Erscheinen mehrfach geändert. Die zugrunde liegende Frage nicht: Was verliert der Kunde, wenn sich der Dienst ändert, die Beziehung endet oder eine Abhängigkeit sich nicht wie erwartet verhält? Eine Risikobewertung verlangt von einem Käufer nicht, jeden verwalteten Dienst abzulehnen. Sie fordert den Käufer auf, Abhängigkeiten Konsequenzen zuzuordnen, bevor die Abhängigkeit zum Notfall wird.
Eine hardwarebewusste Cloud-Datei kann verhältnismäßig bleiben. Halten Sie die Architektur auf der Ebene fest, die für die Arbeitslast von Bedeutung ist. Identifizieren Sie alleinige Abhängigkeiten und Einzelpunkte operativen Wissens. Legen Sie die Vertragsbedingungen dar, die Kontinuität und Migration betreffen. Fragen Sie, welcher Support-Pfad für Sicherheitsupdates oder Wiederherstellung erforderlich ist. Prüfen Sie, ob eine Ersatzumgebung dieselben proprietären Komponenten benötigt. Das Ziel ist kein Museumskatalog. Es ist ein nüchternes Bild der Dinge, die verfügbar bleiben müssen, damit die Organisation ihre Arbeit fortsetzen kann.
Exit ist eine Fähigkeit, kein Download-Button
Die aufschlussreichste Cloud-Frage ist oft, was geschieht, wenn der Kunde gehen möchte. Gehen kann bedeuten, zu einem anderen Anbieter zu wechseln, eine Funktion in eine lokale Umgebung zurückzuholen, die Architektur zu ändern, den Dienst zu reduzieren oder ihn einzustellen. Ein Kunde kann manchmal eine Datenbank exportieren und den Dienst dennoch nicht wieder aufnehmen können. Die Funktion kann auch von Konfiguration, Identitäten, Schlüsseln, Protokollen, Berechtigungen, Automatisierung, Modellen, Bewertungsmaterial, Datenherkunft, Integrationsregeln und dem operativen Wissen abhängen, das die Teile zusammenarbeiten lässt.
Der Data Act ist in diesem Punkt ungewöhnlich konkret. Seine Wechselbestimmungen verlangen, dass Verträge Rechte und Pflichten rund um den Wechsel und die Portierung exportierbarer Daten und digitaler Assets festlegen. Er legt eine normale Höchstdauer der Übergangsphase von 30 Kalendertagen nach der maßgeblichen Kündigungsfrist fest, erlaubt jedoch in definierten Fällen technischer Undurchführbarkeit einen abweichenden Zeitraum, vorbehaltlich bestimmter Bedingungen. Er befasst sich auch mit offenen Schnittstellen und Interoperabilität. Die Verordnung gibt Käufern etwas Wertvolles: einen rechtlichen Grund, den Weg zu erfragen, bevor sie ihn brauchen.
The limits are just as important. The Data Act does not make every digital asset transferable, does not require a provider to disclose protected intellectual property or trade secrets, and does not guarantee functional equivalence at a destination. A provider can meet legal duties while a migration remains difficult. A buyer can have an export right while lacking the people, budget or destination needed to use it. This is why exit should be treated as a capability shared between contract, architecture and organisation, rather than a promise made by one line in an order form.
A credible exit file records the target service type, the data and assets that are exportable, their formats, the procedure for obtaining them, the expected continuity conditions, the retrieval period, the destination assumptions and the parts of the function that cannot simply move. It identifies who will validate that the exported material is usable. It records what logs and evidence must survive. It names the authority that can accept the switch or decide that it is not yet safe to complete. This is less exciting than a migration announcement. It is much more likely to make the announcement true.
Testing matters. A small, bounded exercise can reveal whether a format is merely available or actually usable, whether an identity can be recreated without altering permissions, whether a key can be transferred under the right authority, whether records retain their meaning, and whether a reduced service can continue while the full service moves. This is not a claim that every organisation must rehearse a complete cloud exit every month. The scope should reflect the consequence of interruption. It is a claim that an untested exit is an intention, not yet an option.
What a European cloud assessment should contain
A useful assessment begins by naming the function, not the supplier. What work is the service expected to support? What data, records, rights, continuity needs and public consequences are involved? A low-consequence collaboration tool and a system holding sensitive operational records do not need identical controls. Starting with the workload prevents an organisation from applying a large sovereignty label to a small and specific decision, or from treating a critical service as if it were another office subscription.
Then make a location statement with a boundary. State where the relevant working plane is expected to operate, what data categories it covers, which copies and diagnostics are included, which transfers are allowed, how the position is evidenced and how changes are notified. If the supplier can only make a broad regional statement, record that limitation. A buyer is allowed to distinguish between a precise commitment and a general commercial description. The distinction is not hostile. It is what contracts are for.
Next make an entity and authority map. Record the contracting entity, group entities with a material role, named processors or subprocessors where relevant, the roles that can administer the service, the escalation path, the identity and key arrangements, and the customer authority that remains after outsourcing. Include the legal and technical evidence that supports each entry. Do not write provider or customer where a particular entity, role or mechanism is known. General nouns are very good at concealing specific absences.
Fügen Sie eine Abhängigkeitsübersicht hinzu. Diese sollte wesentliche Software-, Hardware-, Netzwerk-, Support- und Integrationsabhängigkeiten enthalten, den Änderungspfad für jede einzelne sowie die Folgen eines Verlusts oder einer Veränderung. Sie muss nicht die Zukunft vorhersagen. Sie muss den aktuellen Entwurf hinterfragbar machen. Wenn eine Abhängigkeit akzeptabel ist, halten Sie fest, warum. Wenn sie nicht akzeptabel ist, nennen Sie die Ablehnungsbedingung. Wenn sie unbekannt ist, lösen Sie das Unbehagen nicht auf, indem Sie sie als geringes Risiko bezeichnen. Unbekannt ist ein echter Status, und er führt oft zur nächsten Arbeitsaufgabe.
Hängen Sie schließlich den Ausstiegs- und Überprüfungsnachweis an. Erfassen Sie die geltenden Vertragsbestimmungen, Exportverfahren, durchgeführten Tests, festgestellten Lücken, Korrekturmaßnahmen, das Überprüfungsdatum und die Ereignisse, die eine Neubewertung auslösen. Es geht nicht darum, einen perfekten Ordner zu erstellen. Es geht darum, ein lebendiges Kontrollprotokoll zu führen, das einen Personalwechsel, eine Dienstaktualisierung, eine Vertragsverlängerung und den Tag übersteht, an dem jemand schnell eine unangenehme Entscheidung treffen muss. Ein Bericht, der nicht aktualisiert werden kann, wird zu Geschichte mit angehängter Rechnung.
Was die öffentliche Auftragsvergabe fragen kann, ohne vorzugeben, alles zu lösen
Öffentliche Auftraggeber haben einen besonderen Grund, auf diesen Nachweisen zu bestehen, weil sie oft Verantwortungen tragen, die nicht enden, wenn ein Vertrag unterzeichnet ist. Sie können gegenüber Bürgern rechenschaftspflichtig sein, öffentlichen Aufzeichnungspflichten unterliegen, für wesentliche Funktionen verantwortlich sein oder erklären müssen, warum eine Entscheidung angemessen war. Das bedeutet nicht, dass die öffentliche Auftragsvergabe jede ausländische Abhängigkeit beseitigen kann oder dass eine nationale Präferenz ein Ersatz für eine technische Bewertung ist. Es bedeutet, dass die Ausschreibung Fragen stellen kann, die die Vereinbarung sichtbar machen, bevor sie sich verfestigt.
Eine verhältnismäßige Ausschreibung kann nach den Stellen fragen, die wesentliche Teile des Dienstes erbringen, nach den beanspruchten geografischen und rechtlichen Grenzen, nach dem Rollen- und Berechtigungsmodell, nach dem Prozess für Subunternehmerwechsel, nach dem Support- und Störungsweg, nach den für den Kunden aufbewahrten Nachweisen, nach dem Export- und Wechselverfahren sowie nach den Bedingungen, unter denen ein Kunde die Nutzung aussetzen, einschränken oder beenden kann. Sie kann die Qualität der Antworten bewerten, statt ein Adjektiv zu belohnen. Ein Anbieter, der sein eigenes Betriebsmodell kennt, sollte es ohne Nebelmaschine erklären können.
Es gibt Abwägungen. Mehr Nachweise können eine Beschaffung verlängern. Einige Anforderungen können die Zahl der Angebote verringern. Ein kleiner Anbieter hat möglicherweise weniger Kapazität, um aufwendige Dokumentation zu erstellen, selbst wenn sein Kontrollmodell stark ist. Ein Bestandsanbieter kann einen ausgezeichneten technischen Dienst haben, aber einen Ausstiegspfad, der verhandelt werden muss. Das sind keine Argumente, die Fragen auszulassen. Es sind die Tatsachen, die ein Auftraggeber benötigt, um zu entscheiden, welche Kosten akzeptabel sind: die Kosten für Nachweise und Alternativen jetzt oder die Kosten der Abhängigkeit später.
Die Arbeit der Europäischen Kommission zur Cloud-Souveränität hat diese Richtung in Beschaffungsbegriffen sichtbar gemacht, aber Auftraggeber müssen nicht auf ein universelles Gütesiegel warten. Sie können ihre eigene Risikogrenze festlegen und Nachweise verlangen, die dazu passen. Eine öffentliche Bibliothek, eine Forschungseinrichtung, eine städtische Abteilung und ein Betreiber kritischer Infrastruktur werden nicht dieselbe Schwelle verwenden. Das sollten sie auch nicht. Der Maßstab ist, ob die Anforderungen der Funktion folgen, fair veröffentlicht werden, einheitlich bewertet werden können und die Fähigkeit des Kunden bewahren, zu erklären, was er gewählt hat.
Das ist das leisere Versprechen der europäischen Cloud-Politik. Sie kann das Gespräch vom Nationalitäten-Theater wegbewegen und hin zur Steuerung von Beziehungen. Die europäische Antwort muss keine versiegelte technologische Insel sein. Sie kann ein erwachsenerer Markt sein, in dem Behauptungen über Standort, Kontrolle, Recht und Ausstieg getrennte Behauptungen sind, die mit getrennten Nachweisen untermauert werden. Gegenseitige Abhängigkeit verschwindet nicht, wenn sie benannt wird. Es wird möglich zu entscheiden, wo sie erträglich ist.
Die Kontrollen antworten einander nicht
Es lohnt sich, einer letzten Abkürzung zu widerstehen. Starke Verschlüsselung beantwortet keine Eigentumsfrage. Kundeneigene Schlüssel können bestimmte Zugriffsrisiken verringern und eine wichtige Kontrolle sein, aber sie legen für sich genommen nicht fest, wer den Dienst betreibt, wer die Plattform kontrolliert, welche Informationen in Metadaten sichtbar bleiben oder ob der Kunde die Funktion verlagern kann. Eine gute Ausstiegsklausel beantwortet keine Zuständigkeitsfrage. Eine europäische Muttergesellschaft beantwortet keine Frage zur Hardware-Unterstützung. Jede Kontrolle hat eine Aufgabe. Jede sollte daraufhin bewertet werden, welche Aufgabe sie tatsächlich erfüllt.
Aus diesem Grund sollte eine Cloud-Entscheidung auch „nicht genug“ sagen können, ohne theatralisch zu werden. Ein Käufer mag die Standortzusage für angemessen halten, aber die Änderungsmitteilung für zu vage. Er mag einen Unterauftragsverarbeiter akzeptieren, aber einen klareren Befugnisweg verlangen. Er mag eine ausländische Hardware-Abhängigkeit akzeptieren, aber auf einem dokumentierten Ersatzplan bestehen. Er mag entscheiden, dass ein bestimmter Dienst für eine bestimmte Datenkategorie ungeeignet ist, während er für eine andere geeignet bleibt. Differenzierung ist kein Versagen bei der Entscheidung. Sie ist die Voraussetzung dafür, auf der Grundlage von Belegen zu entscheiden und nicht auf der Grundlage von Markenbekanntheit.
Die Arbeit wird leichter, wenn die Belege nahe an der Entscheidung gehalten werden. Legen Sie die Datenstandort-Aussage nicht in ein System, den Vertrag in ein anderes, die Zugriffsprüfung in ein Postfach und den Ausstiegsplan in die Erinnerung von jemandem. Verknüpfen Sie sie mit dem Dienstdatensatz und geben Sie dem Datensatz einen Verantwortlichen. Wenn sich eine Anforderung ändert, sollte die Organisation in der Lage sein, die Belege zu finden, die betroffene Grenze zu identifizieren und zu entscheiden, ob der Dienst fortgeführt werden kann. Das ist Governance in ihrer wenigsten glamourösen und nützlichsten Form.
Eine kurze Anmerkung von uns
Unser Bericht The Sovereignty Illusion verwendet fünf praktische Linsen für eine ähnliche Frage: Eigentum, Technologie, Kapital, Infrastruktur und rechtliche Risiken. Das ist unser Forschungsrahmen, keine rechtliche Einordnung und kein Nachweis, dass ein bestimmter Dienst die Bedürfnisse eines Kunden erfüllt. Sein nützlicher Beitrag ist eine Gewohnheit der Aufmerksamkeit. Wenn eine Cloud-Behauptung vollständig klingt, fragen Sie, welche dieser Linsen sie tatsächlich abgedeckt hat und welche außerhalb des Rahmens bleiben.
Diese Gewohnheit prägt auch, wie wir unsere eigene Arbeit beschreiben. Eine Souveränitätsbehauptung sollte durch Bereitstellung, Vertrag und Betriebsverantwortung begrenzt sein, nicht zu einem Versprechen aufgebläht werden, das eine Produktseite nicht halten kann. Der Kunde, die Arbeitslast und das vereinbarte Kontrollmodell entscheiden weiterhin, was ehrlich gesagt werden kann. In einem Bereich voller großer Substantive ist Zurückhaltung keine Marketing-Unannehmlichkeit. Sie ist Teil der Belege.
Die Frage nach dem Städtenamen
Der europäische Standort bleibt eine Frage, die sich zu stellen lohnt. Er kann eine rechtliche Anforderung, eine betriebliche Anforderung, eine Wahl der Belastbarkeit, eine Wahl der physischen Sicherheit oder ein Ausdruck öffentlicher Verantwortung sein. Ein Käufer sollte sich nicht schämen zu fragen, wo ein System läuft. Er sollte die Frage einfach in Gesellschaft stellen. Wem gehört die Einrichtung, die zählt? Wer hat die Betriebsbefugnis? Welche Rechtsordnungen können die Vereinbarung erreichen? Welche Unterauftragsverarbeiter und Komponenten sind wesentlich? Was kann der Kunde prüfen, stoppen, verlagern und bewahren?
Diese Fragen machen Cloud-Computing nicht weniger nützlich. Sie machen die Nutzung von Cloud-Computing bewusster. Sie ersetzen eine Atmosphäre der Beruhigung durch eine Datei, die geprüft werden kann. Sie geben Anbietern eine faire Gelegenheit, die Kontrollen zu zeigen, die sie aufgebaut haben, und Käufern eine faire Möglichkeit, eine nützliche Grenze von einer leeren Behauptung zu unterscheiden. Am wichtigsten ist, dass sie die Möglichkeit bewahren, den Kurs zu ändern, bevor eine Abhängigkeit zu einem Vorwurf wird.
Die europäische Cloud-Frage dreht sich also nicht darum, wo der Server steht. Sie dreht sich darum, wo die Kontrolle liegt, wenn das System geändert werden muss. Ein Rechenzentrum kann Teil der Antwort sein. Ein europäischer Vertrag kann Teil der Antwort sein. Ein europäischer Anbieter kann Teil der Antwort sein. Die Antwort wird erst glaubwürdig, wenn die Organisation den Weg von Ort zu Eigentum, von Eigentum zu rechtlicher Reichweite, von rechtlicher Reichweite zu Betriebsbefugnis und von Befugnis zu einem erprobten Ausweg nachvollziehen kann. Dieser Weg ist weniger einprägsam als eine Flagge neben einem Gebäude. Er ist auch der Punkt, an dem die Arbeit beginnt.
Quellen
- Cloud Computing, Europäischer Datenschutzbeauftragter. Verwendet für die Cloud-Leitlinienposition des EDPS, dass EU-Organe für ihre Datenschutzpflichten verantwortlich bleiben und einen gleichwertigen Schutz gewährleisten sollten.
- EDPB publishes three guidelines following public consultation, Europäischer Datenschutzausschuss, 24. Februar 2023. Verwendet für Umfang und Zweck der endgültigen Leitlinien zu Artikel 3 DSGVO und Kapitel V zu internationalen Übermittlungen.
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Verwendet für die Bestimmungen zu Wechsel, Export, Kontinuität, Interoperabilität und internationalem behördlichem Zugriff für Datenverarbeitungsdienste.
- Cloud Computing Risk Assessment, Agentur der Europäischen Union für Cybersicherheit. Verwendet für den Rahmen der Risikobewertung zu Lock-in, rechtlichem Risiko und Kontrollverlust.
- The Sovereignty Illusion, Dweve. Verwendet ausschließlich für den offengelegten Fünf-Linsen-Forschungsrahmen von Dweve.