Verträge können das Gesetz nicht aushebeln: Warum Datensouveränität architektonisch und nicht vertraglich gewährleistet sein muss

Einleitung

Jeder Anbieter-Vertrag für Cloud-Services enthält Klauseln zum Datenschutz: Vertraulichkeitsvereinbarungen, Auftragsverarbeitungsverträge, Zusagen zum Datenstandort. Diese Klauseln sind wichtig, und kein Unternehmen sollte einen Vertrag ohne sie unterzeichnen. Was sie jedoch nicht leisten können, ist zu beeinflussen, was passiert, wenn ein Gericht oder eine Behörde den Anbieter rechtmäßig zur Herausgabe gespeicherter Daten verpflichtet.

Diese Lücke überrascht Rechts- und Compliance-Teams oft erst im Nachhinein. Ein Vertrag bindet die beiden unterzeichnenden Parteien. Eine rechtmäßige Anordnung bindet den Anbieter gegenüber einer dritten Partei – der ausstellenden Behörde – und diese Verpflichtung fragt den Kunden nicht um Erlaubnis. Wenn beides kollidiert, gilt das Gesetz, und die Datenschutzklausel dient nur noch als Nachweis guter Absicht, nicht als Verteidigung. Dieser Artikel zeigt, warum Zusagen zur Datensouveränität architektonisch und nicht nur vertraglich durchgesetzt werden müssen – und wie dieser Unterschied in der Praxis aussieht.

Erkenntnis 1: Vertragliche Zusagen eines Anbieters können eine rechtmäßige Herausgabeanordnung nicht aushebeln. Wenn ein Gericht oder eine Behörde die Offenlegung verlangt, besteht die Verpflichtung zur Befolgung unabhängig von der Vereinbarung mit dem Kunden.

Erkenntnis 2: Verträge binden zwei Parteien; eine rechtliche Anordnung betrifft eine dritte Partei, die vom Vertrag nicht erfasst wird. Ein Auftragsverarbeitungsvertrag hat in einem Verfahren zwischen Anbieter und Behörde keine Gültigkeit.

Erkenntnis 3: Ein Anbieter, der die Entschlüsselungsschlüssel besitzt, kann gezwungen werden, diese zu verwenden. Wenn ein Anbieter technisch in der Lage ist, Kundendaten zu entschlüsseln, kann eine rechtmäßige Anordnung genau diese Fähigkeit einfordern.

Erkenntnis 4: Wird dem Anbieter die technische Möglichkeit zur Entschlüsselung entzogen, entfällt das Risiko vollständig. Kann ein Anbieter Daten auch auf Anordnung nicht entschlüsseln, kann er nur Chiffretext, aber keine lesbaren Informationen herausgeben.

Erkenntnis 5: Zusagen zur Datensouveränität müssen architektonisch durchgesetzt werden, nicht nur durch Vertragsklauseln. Eine durch Infrastrukturdesign abgesicherte Zusage gilt unabhängig vom Inhalt einzelner Dokumente.

Zusammenfassung

Rechts- und Compliance-Teams betrachten vertragliche Datenschutz-Zusagen von Anbietern oft als wichtigsten Schutz gegen unbefugten Datenzugriff. Diese Annahme bricht zusammen, sobald eine rechtmäßige Herausgabeanordnung ins Spiel kommt, denn sie schafft eine Verpflichtung zwischen Anbieter und dritter Behörde, die der Kundenvertrag nicht außer Kraft setzen kann. Der einzig verlässliche Schutz ist technischer Natur: eine Architektur, in der der Anbieter nicht in der Lage ist, lesbare Daten zu liefern – selbst wenn er rechtlich zur Herausgabe verpflichtet wird. Damit wird Datensouveränität von einer verhandelten Vertragsklausel zu einer Eigenschaft, die in die Bereitstellung selbst eingebaut sein muss.

Warum vertragliche Datenschutz-Zusagen strukturelle Grenzen haben

Ein Vertrag ist eine Vereinbarung zwischen zwei Parteien über ihre gegenseitigen Verpflichtungen. Ein Auftragsverarbeitungsvertrag, eine Vertraulichkeitsklausel oder eine Souveränitätszusage im Rahmenvertrag wirken nur innerhalb dieser Zweierbeziehung. Keine davon kann eine dritte Partei binden, die nie unterzeichnet hat – und eine Behörde, die eine rechtmäßige Anordnung an einen Anbieter richtet, ist genau eine solche dritte Partei.

Was eine rechtmäßige Herausgabeanordnung tatsächlich ändert

Wenn eine Behörde mit Zuständigkeit für einen Anbieter eine gültige Anordnung zur Offenlegung von Daten erlässt, die sich im Besitz, Gewahrsam oder unter Kontrolle des Anbieters befinden, ergibt sich die Verpflichtung zur Befolgung aus dem Recht dieser Jurisdiktion – nicht aus dem Kundenvertrag. Das ist das gleiche Prinzip, das Gesetze wie den US CLOUD Act begründet. Ein Anbieter, der eine gültige Anordnung verweigert, um die Erwartungen des Kunden zu schützen, bringt sich selbst in rechtliche Schwierigkeiten. In der Praxis wird ein Anbieter der Anordnung nachkommen und die Folgen für die Kundenbeziehung später behandeln. Der Vertrag ist nicht gescheitert, weil der Anbieter nachlässig war, sondern weil er dieser Art von Verpflichtung nie standhalten konnte.

Warum sich das Risiko auf die Schlüsselverwaltung konzentriert

Der konkrete Risikopunkt ist die Verwaltung der Verschlüsselungsschlüssel. Hält ein Anbieter die Schlüssel zur Entschlüsselung von Kundendaten, ist diese Fähigkeit selbst ein Vermögenswert, den eine rechtmäßige Anordnung erreichen kann. Die Anordnung muss den Anbieter nicht zu neuen Fähigkeiten zwingen – sie verlangt nur die Nutzung bereits vorhandener Möglichkeiten. Deshalb entscheidet die Schlüsselverwaltung, nicht allein die Verschlüsselung, darüber, was eine Herausgabeanordnung tatsächlich bewirken kann.

Wie das Entfernen der Entschlüsselungsfähigkeit des Anbieters die Lücke schließt

Wenn sich das Risiko darauf konzentriert, was der Anbieter technisch tun kann, liegt dort auch die Lösung. Ein Unternehmen kann sich nicht aus einer gültigen Anordnung herausverhandeln – aber es kann sicherstellen, dass die Befolgung keine verwertbaren Daten liefert.

Chiffretext ohne Schlüssel sind keine lesbaren Daten

Wenn der Kunde seine eigenen Verschlüsselungsschlüssel hält – meist integriert mit einem Hardware-Sicherheitsmodul und nicht innerhalb der Infrastruktur des Anbieters – besitzt der Anbieter nur verschlüsselte Daten, die er selbst nicht entschlüsseln kann. Eine rechtmäßige Anordnung, die den Anbieter zur Herausgabe zwingt, führt weiterhin zur Übergabe. Die Anordnung wurde erfüllt. Herausgegeben wurde jedoch nur Chiffretext – weil der Anbieter nie im Besitz lesbarer Daten war.

Warum dies ein architektonischer Fakt ist, keine Richtlinie

Dieser Unterschied ist entscheidend, weil er nicht von den Absichten des Anbieters, den Argumenten der Rechtsabteilung oder der Bereitschaft zum Rechtsstreit abhängt. Entscheidend ist, ob der Anbieter technisch überhaupt in der Lage ist, die Daten zu entschlüsseln. Eine Richtlinie kann widerrufen, umgedeutet oder unter Druck aufgehoben werden. Eine architektonische Begrenzung dessen, was ein System technisch leisten kann, ist keine Position, von der der Anbieter abweichen könnte – denn es gibt schlicht keine Fähigkeit, die erzwungen werden könnte.

Wie sich Souveränitätszusagen schaffen lassen, die rechtlichem Druck standhalten

Für Rechts- und Compliance-Abteilungen verändert sich damit die Fragestellung bei der Prüfung von Datenschutz-Zusagen eines Anbieters. Es geht nicht mehr nur um die vertraglichen Zusagen, sondern darum, was passiert, wenn eine gültige Anordnung eintrifft, die diesen Zusagen widerspricht. Verfügt der Anbieter weiterhin über die technischen Mittel, um lesbare Kundendaten herauszugeben, oder wurde diese Fähigkeit vollständig aus der Beziehung entfernt? Die Antwort erfordert die Prüfung der Bereitstellungsarchitektur und des Schlüsselmanagements zusätzlich zum Vertrag – nicht anstelle davon, denn der Vertrag bleibt für alles außer Herausgabeanordnungen relevant: Haftungsverteilung, Benachrichtigung bei Datenschutzverstößen, Prüfungsrechte und tägliche Pflichten. Was der Vertrag nicht leisten kann, ist die Architektur im entscheidenden Moment zu ersetzen, in dem die Souveränität tatsächlich auf dem Prüfstand steht.

Wie eine Data Control Plane Souveränitätszusagen durchsetzbar macht

Eine Data Control Plane schließt diese Lücke, indem sie Schlüsselverwaltung und Bereitstellungsjurisdiktion zu Eigenschaften der Architektur macht – nicht zu Vertragsklauseln, die eine Anordnung umgehen kann. Sie steuert jede Send-, Sharing- und Zugriffsaktion über alle Kanäle hinweg, über die Daten bewegt werden – einschließlich E-Mail, Filesharing, APIs und KI-Agents – und das auf einer Infrastruktur, deren Jurisdiktion und Schlüsselverwaltung der Kunde, nicht der Anbieter, kontrolliert.

Kiteworks integriert kundeneigene Verschlüsselungsschlüssel über ein Hardware-Sicherheitsmodul, sodass der Anbieter Kundendaten nicht entschlüsseln kann – unabhängig davon, was eine künftige Anordnung verlangt. Die Bereitstellung erfolgt auf Single-Tenant-Architektur, wobei Unternehmen wählen, ob sie On-Premises, in ihrer eigenen Cloud-Umgebung oder auf einer dedizierten Hosted-Instanz betreiben. Das bedeutet: Die Jurisdiktion über die Infrastruktur bestimmt der Kunde, nicht der Anbieter. Darauf aufbauend erzwingen datenbewusste zero-trust-Kontrollen jede Send-, Sharing- und Zugriffsaktion, und jede Aktion wird in einem manipulationssicheren, uneingeschränkten Audit-Trail erfasst, der direkt in SIEM-Tools eingespeist wird. So erhalten Rechts- und Compliance-Teams eine dokumentierte Übersicht darüber, welche Kontrollen zu welchem Zeitpunkt unabhängig von Vertragsklauseln aktiv waren.

Unternehmen, die ihre eigenen Souveränitätszusagen an diesem Standard testen möchten, statt sich auf Verträge unter rechtlichem Druck zu verlassen, können get back in CTRL – und erleben, wie kundengesteuerte Schlüsselverwaltung und Bereitstellungsjurisdiktion auf ihre bestehenden Anbieterbeziehungen angewendet werden.