Die Datenhoheit entscheidet, wer die Kontrolle behält

Fragen Sie die meisten Führungskräfte, wo ihre sensiblen Daten gespeichert sind, können sie eine Region benennen. Fragen Sie jedoch, wer diese Daten lesen, kopieren oder abschalten kann, wird die Antwort unklarer. Diese Lücke ist das eigentliche Thema von Datenhoheit – und Aufsichtsbehörden benennen das inzwischen deutlich. Am 5. November 2026 veröffentlichten die spanische Datenschutzbehörde AEPD und ihr griechisches Pendant einen gemeinsamen Leitfaden zu sicheren Verarbeitungsumgebungen, der Kontrolle als technische Tatsache und nicht als Vertragsklausel behandelt.

In derselben Woche gab es zwei Beispiele dafür, was passiert, wenn Kontrolle nur auf dem Papier existiert. Eine Koalition aus vier Generalstaatsanwälten der US-Bundesstaaten gab eine Einigung mit einem Unternehmen bekannt, dessen Überwachungssoftware einen Eindringling registrierte, aber niemanden informierte. Und ein Fall im Vereinigten Königreich zeigte, wie eine in guter Absicht veröffentlichte Tabelle versteckte Daten von rund 8.000 Mitarbeitenden nach außen trug.

Dieser Beitrag argumentiert, dass Fehler bei Souveränität, Datenschutz und Sicherheit auf eine gemeinsame Ursache zurückgehen: Jemand glaubte, eine Kontrolle sei vorhanden, aber niemand prüfte, ob sie auch wirkte. Die folgenden Abschnitte zeigen, was Aufsichtsbehörden heute erwarten, warum Standort und Kontrolle unterschiedliche Fragen sind, wie Lieferantenkonzentration beides untergräbt, was aktuelle Durchsetzungs- und Offenlegungsfälle offenbaren, wie KI-Assistenten all diese Probleme übernehmen und wie regelmäßige Prüfungen Glauben durch Kontrolle ersetzen.

Wichtige Erkenntnisse

1. Aufsichtsbehörden definieren Souveränität als Kontrolle.

Der Leitfaden von AEPD und Hellenic fordert, dass der Anbieter echte und wirksame Kontrolle behält – auch wenn ein Dritter die Infrastruktur bereitstellt. Damit wird die Frage von einer Vertragsklausel zu einer technischen Anforderung.

2. Standort beantwortet das Wo, Kontrolle das Wer.

Ein Server im richtigen Land beantwortet nicht, wer die Schlüssel besitzt, wer das System verwaltet und welche Subunternehmer auf die Daten zugreifen können.

3. Kontrollen, die nie ausgelöst werden, sind schlimmer als keine.

Eine Einigung über 13,3 Millionen Betroffene drehte sich um fehlende Multifaktor-Authentifizierung, unverschlüsselte Dateien und Überwachungssoftware, die nie auf Alarm gestellt war.

4. Daten verlassen das Unternehmen über vertraute Kanäle.

Eine routinemäßige Veröffentlichung von öffentlichen Unterlagen legte versteckte Krankheitsdaten von rund 8.000 Mitarbeitenden offen, weil niemand überprüfte, was die Tabelle enthielt.

5. KI-Assistenten übernehmen dieselben Lücken.

Neue Vorgaben der Bankenaufsicht halten Banken für KI von Drittanbietern verantwortlich. Assistenten müssen daher im Rahmen der Nutzerrechte und unter derselben Richtlinie wie Menschen agieren.

Ein europäischer Leitfaden spricht Klartext

Der Leitfaden von AEPD und der Hellenic Data Protection Authority entstand mit Beiträgen von Eurostat, Spaniens Generaldirektion für Daten, Italiens Garante und dem britischen Information Commissioner’s Office. Das ist eine bemerkenswerte Liste von Mitwirkenden für ein Dokument über Infrastruktur und signalisiert, dass Aufsichtsbehörden in mehreren Ländern inhaltlich übereinstimmen.

Der Kernpunkt: Ein Unternehmen, das für personenbezogene Daten verantwortlich ist, muss echte und wirksame Kontrolle über die Verarbeitungsumgebung behalten – auch wenn ein Dritter die Infrastruktur liefert. Ein Zertifikat auf der Website eines Anbieters reicht dafür nicht aus. Ebenso wenig eine Vertragsklausel. Der Leitfaden warnt zudem vor Abhängigkeit von einem einzigen Anbieter und weist darauf hin, dass für diese Art der Verarbeitung in der Regel eine Datenschutz-Folgenabschätzung verpflichtend ist.

Das bedeutet eine Verlagerung der Verantwortung. Viele Unternehmen haben sich jahrelang auf Zusicherungen verlassen: Zertifikate gesammelt, Standardverträge unterschrieben und die Bestätigung des Anbieters im Datenschutzprogramm abgelegt. Der Leitfaden verlangt nun einen anderen Nachweis: Können Sie als verantwortliches Unternehmen nachweisen, dass Sie die Kontrolle haben? Können Sie entscheiden, wer Zugriff erhält, die Konfiguration ändern und Daten verschieben oder löschen, ohne jemanden um Erlaubnis zu fragen?

Die meisten Unternehmen können nicht alle drei Fragen mit Ja beantworten. Die Kontrolle liegt meist bei den Administratoren des Cloud-Anbieters, den Technikern des Managed Service Providers oder einem Subunternehmer in dritter Reihe. Das ist kein böser Wille, sondern die natürliche Folge davon, Infrastruktur als Service einzukaufen und den Kauf mit Kontrolle gleichzusetzen.

Ein wichtiger Hinweis: Der Leitfaden ist eine aufsichtsrechtliche Veröffentlichung zu sicheren Verarbeitungsumgebungen und schafft kein neues Recht. Aber Aufsichtsbehörden beschreiben mit solchen Leitfäden, wie sie bestehendes Recht auslegen – und die Richtung ist klar. Die verantwortliche Partei muss Kontrolle nachweisen können; das Versprechen eines Anbieters reicht nicht.

Standort beantwortet das Wo, Kontrolle das Wer

Drei Begriffe werden in Führungsetagen oft vermischt. Data Residency beschreibt, wo Daten gespeichert werden. Data Localization meint Gesetze, die verlangen, dass Daten im Land bleiben. Souveränität beschreibt, wer die Kontrolle über die Daten hat – einschließlich, wer Zugriff erzwingen kann. Ein System kann die ersten beiden Anforderungen erfüllen und dennoch bei der dritten scheitern.

Stellen Sie sich ein Unternehmen vor, das Kundendaten in einem Rechenzentrum im eigenen Land speichert, das von einer Tochter eines ausländischen Anbieters betrieben wird. Die Anforderungen an Residency und Localization sind erfüllt. Doch wenn die Regierung des Anbieters den Zugriff auf Daten seiner Tochtergesellschaften erzwingen kann, ist die Kontrolle des Unternehmens nur bedingt. Das ist der Kern der Debatte um den US CLOUD Act – und der Grund, warum eine Postleitzahl im Vertrag weniger aussagt, als es scheint.

Drei Fragen machen aus einem Standortnachweis einen Kontrollnachweis. Wer hält die Verschlüsselungsschlüssel? Liegen sie beim Anbieter, können dessen Mitarbeitende oder eine gerichtliche Anordnung die Daten entschlüsseln – unabhängig vom Standort. Kundengesteuerte Verschlüsselungsschlüssel verlagern diese Macht ins Unternehmen, und Double Encryption fügt eine zweite Ebene hinzu, sodass keine Partei allein alles entschlüsseln kann.

Wer verwaltet die Umgebung? Administratoren können fast alles sehen und ändern – ihr Standort ist daher genauso wichtig wie der der Festplatten. Ein Unternehmen, das Daten im eigenen Land speichert, aber Remote-Administration von außerhalb zulässt, hat das Problem nur verlagert, nicht gelöst.

Welche Subunternehmer haben Zugriff auf die Daten? Die Zusicherungen eines Anbieters gelten selten für dessen eigene Lieferanten. In dieser Kette geht Souveränität oft verloren – ein ehrliches Third-Party-Risk-Management verfolgt sie bis zum letzten Glied.

All das macht grenzüberschreitende Übertragungen nicht unmöglich. Standardvertragsklauseln bleiben ein legitimer Bestandteil der DSGVO-Compliance. Doch eine Klausel ist nur so stark wie die Fähigkeit des Unternehmens, zu überprüfen, ob die Bedingungen tatsächlich eingehalten werden – und damit ist man wieder bei der Kontrolle.

Ein Anbieter ist ein Single Point of Failure

Der AEPD-Leitfaden warnt vor Abhängigkeit von einem einzigen Anbieter. Die Kiteworks-Studie aus der Region mit dem stärksten Souveränitätsdruck zeigt, warum diese Warnung praxisrelevant ist. In der Kiteworks 2026 Data Security and Compliance Risk: Data Sovereignty in the Middle East berichteten 44 Prozent der Befragten im Nahen Osten von einem souveränitätsbezogenen Vorfall – verglichen mit 32 Prozent in Europa und 23 Prozent in Kanada.

Die Verteilung der Vorfälle ist aufschlussreich: 22 Prozent waren behördliche Untersuchungen, 20 Prozent Souveränitätsverletzungen, 19 Prozent Drittanbieterfehler, 15 Prozent Regierungsanfragen und 13 Prozent unautorisierte Übertragungen. Das Problembewusstsein ist hoch (74 Prozent), und 93 Prozent sagen, dass Souveränitätsanforderungen ihre Arbeit beeinflussen. Das Wissen um das Problem verhindert es nicht.

Viele dieser Kategorien führen auf einen Anbieter zurück. Drittanbieterfehler sind offensichtlich, aber auch Regierungsanfragen, unautorisierte Übertragungen und manche Sicherheitsvorfälle hängen davon ab, was ein Anbieter erreichen kann und wer ihn dazu zwingen kann. Konzentration verschärft das Risiko: Hält ein Anbieter Daten, Schlüssel und Administration, kann ein Ausfall, eine Anordnung oder ein Vorfall alles betreffen.

Die gleiche Umfrage ergab, dass 48 Prozent die regionale Cloud-Nutzung ausbauen wollen, 33 Prozent nennen geopolitische Instabilität als Grund. Workloads zu einem regionalen Anbieter zu verlagern, kann Risiken verringern – aber auch eine neue Abhängigkeit schaffen, wenn nur ein Anbieter durch einen anderen ersetzt wird. Regionales Hosting ändert die Adresse des Risikos, nicht das Bedürfnis nach Kontrolle.

Resilienz gehört in dieselbe Diskussion. Ein Exit-Plan, der nie geprobt wurde, bleibt Hoffnung. Die Frage ist, ob das Unternehmen Daten, Schlüssel und Richtlinien innerhalb eines akzeptablen Zeitfensters in eine andere Umgebung verschieben könnte – und ob das jemals getestet wurde. Wenn Aufsichtsbehörden nach Abhängigkeit von einem Anbieter fragen, meinen sie genau diese Probe.

Eine Kontrolle, die existiert, aber nicht auslöst

Die erste Fehlerquelle ist das Vertrauen in Zusicherungen eines Anbieters. Die zweite ist das Vertrauen in eigene Tools, ohne sie zu testen. Am 6. November 2026 gab die Generalstaatsanwältin von New York eine Einigung mit Perry Johnson & Associates und vier verbundenen Unternehmen bekannt – gemeinsam mit Connecticut, Michigan und New Jersey. Die Summe beträgt bis zu 10 Millionen US-Dollar, davon mindestens 300.000 garantiert und 9,7 Millionen abhängig von weiteren Bedingungen. Der Vorfall betraf rund 13,3 Millionen Menschen, darunter etwa 4,2 Millionen New Yorker.

Die Fakten sind eindeutig: Im März 2023 nutzte ein Eindringling die Zugangsdaten eines Mitarbeitenden. Remote-Zugriff war nicht durch Multifaktor-Authentifizierung geschützt. Dateien mit geschützten Gesundheitsdaten waren unverschlüsselt. Die Software eines Unternehmens zeichnete die Aktivitäten des Eindringlings auf, war aber nicht so konfiguriert, dass sie jemanden alarmierte. Der Vorfall wurde erst zwei Monate später entdeckt, als die Angreifer Kontakt aufnahmen.

Jede Kontrolle in dieser Geschichte existierte in irgendeiner Form. Es gab Protokollierungssoftware, Remote-Zugriff, Dateien. Was fehlte, war die Konfiguration, die jede Kontrolle wirksam gemacht hätte. Multifaktor-Authentifizierung fehlte an der entscheidenden Stelle. Verschlüsselung fehlte bei den Dateien. Und ein Alarm fehlte bei dem Tool, das alles überwachte.

Dieser Fehler taucht selten in Compliance-Checklisten auf, weil dort nur gefragt wird, ob eine Kontrolle existiert. Die Einigung stellt eine andere Frage: Ist jede Kontrolle so konfiguriert, dass sie auch auslöst? Die geforderten Reformen umfassen ein Sicherheitsprogramm und ein Incident-Response-Protokoll, Multifaktor-Authentifizierung, Passwortmanagement, Verschlüsselung, Asset-Management, jährliche HIPAA-Risikoanalysen sowie Richtlinien für Erhebung, Nutzung, Aufbewahrung und Löschung von Daten. Viele davon betreffen den Betrieb, nicht den Besitz. Sie verlangen, dass regelmäßig geprüft wird, ob die Maßnahmen noch funktionieren.

Für regulierte Daten ist das im HIPAA Security Rule und der Erwartung an laufende Risikoanalysen verankert. Die praktische Lehre gilt aber weit über das Gesundheitswesen hinaus: Ein Audit-Log, das alles aufzeichnet, aber nie einen Alarm auslöst, ist ein Tagebuch. Ein Monitoring-Tool ist nur dann eine Kontrolle, wenn eine benannte Person dessen Meldungen erhält und darauf reagieren soll.

Daten können durch eine unbeobachtete Tür abfließen

Nicht jeder Datenverlust ist ein Angriff. Ein Fall, den Jackson Lewis am 9. Dezember 2025 analysierte, beschreibt, wie Royal Cornwall eine Tabelle als Antwort auf eine Anfrage nach dem Informationsfreiheitsgesetz veröffentlichte. Die Datei enthielt versteckte Daten zu Krankheitsausfällen von rund 8.000 aktuellen und ehemaligen Mitarbeitenden. Nach Bekanntwerden wurde die Datei entfernt, das Veröffentlichungsprotokoll ausgesetzt und eine Regel eingeführt, dass Tabellen vor Veröffentlichung komplett deaktiviert werden müssen.

Bemerkenswert ist, wie alltäglich der Kanal war: Die Veröffentlichung öffentlicher Unterlagen ist ein vertrauter, genehmigter Weg für den Abfluss von Daten. Niemand wollte etwas stehlen. Das Unternehmen wusste einfach nicht, was die eigene Datei enthielt – weil sensible Daten in versteckten Tabellen lagen, die die veröffentlichende Person nie sah.

Das ist ein Souveränitätsproblem ebenso wie ein Datenschutzproblem. Ein Unternehmen, das nicht weiß, was eine Datei enthält, weiß auch nicht, wohin deren Inhalte gelangt sind, wer sie lesen kann oder welches Recht gilt. Datenklassifizierung ist die Kontrolle, die diese Fragen beantwortet, und Data Loss Prevention setzt Klassifizierung an der Schwelle zur Datenfreigabe durch. Beides wirkt unscheinbar – bis es fehlt.

In diesem Fall war die Lösung eine Prozessänderung – und das war sinnvoll. Die bessere Frage ist jedoch, warum eine Regel zu versteckten Tabellen erst nach einem Vorfall eingeführt wurde. Jedes Unternehmen, das Dokumente veröffentlicht, Dateien mit Partnern teilt oder Daten an Aufsichtsbehörden sendet, steht vor derselben Herausforderung. Der Test ist einfach, wird aber selten durchgeführt: Nehmen Sie eine Stichprobe ausgehender Dateien und prüfen Sie, was jede enthält, das der Absender nicht teilen wollte.

Für personenbezogene und Gesundheitsdaten ist die Antwort unter PII- und PHI-Regeln besonders relevant. Eine Kontrolle, die nur funktioniert, wenn die veröffentlichende Person daran denkt, ist eine Gewohnheit – und Gewohnheiten versagen an stressigen Tagen.

KI-Assistenten übernehmen all diese Probleme

Alles oben Gesagte gilt auch für KI-Assistenten – und die Bankenaufsicht hat das erkannt. Am 5. November 2026 berichtete American Banker, dass das OCC unverbindliche Leitlinien zur Aufgabenübertragung an KI-Agenten veröffentlicht hat, gegliedert in sechs Säulen: Zweck, potenzielle Risiken, Kontrollen, menschliche Aufsicht, Resilienz und Tests. Banken müssen den Zweck jedes KI-Systems, autorisierte Nutzer, Datenberechtigungen und Befugnisse dokumentieren. Sie bleiben für KI von Drittanbietern verantwortlich – und je autonomer das System, desto strenger die Kontrollen.

Im Souveränitätskontext heißt das: Ein Assistent, der Dokumente liest und Aktionen ausführt, ist ein neuer Kanal für Datenbewegungen – und übernimmt die Kontrollprobleme aller Systeme, die er berührt. Läuft er auf der Infrastruktur eines Anbieters, gilt die Anbieterfrage. Greift er auf nie klassifizierte Dateien zu, gilt die Klassifizierungslücke. Wird seine Aktivität von einem Tool protokolliert, das niemand überwacht, gilt die Alarmierungslücke.

Die Lösung ist Parität, kein Sonderprogramm. Assistenten sollten im Rahmen der Rechte der Person agieren, die sie unterstützen, und nach denselben Richtlinien und im gleichen Audit-Log wie Menschen geführt werden. Wer für KI eine eigene Regelwelt schafft, wird erleben, dass sich die Kontrollen auseinanderentwickeln – und genau diese Lücke wird von Aufsichtsbehörden hinterfragt. Banken bleiben für KI von Drittanbietern verantwortlich; die praktische Frage ist, ob die Bank ihre eigene Richtlinie auf einen Assistenten anwenden kann, den sie nicht selbst gebaut hat.

Deshalb passt auch der zero trust data exchange-Ansatz: Verifizierung erfolgt an jedem Übergabepunkt, für jeden Akteur – egal ob Mitarbeitender, Partner oder Assistent – und die Organisation behält die Richtlinienhoheit. Das Prinzip, das die Kontrollfrage der AEPD beantwortet, beantwortet auch die Delegationsfrage des OCC.

Zwei falsche Antworten auf Souveränität

Die erste falsche Antwort: Alles ins eigene Haus holen. Das wirkt wie maximale Kontrolle und ist für wenige Workloads sinnvoll. Für die meisten Unternehmen tauscht man damit jedoch eine Schwäche gegen eine andere, denn Aufbau und Betrieb jeder Umgebung erfordern Fähigkeiten und Ressourcen, die nur wenige haben. Schwache Betriebsführung führt zu genau den fehlenden Alarmen und unverschlüsselten Dateien, die oben beschrieben wurden. Kontrolle ist nicht gleichbedeutend mit Besitz aller Server.

Die zweite falsche Antwort: Zusicherungen kaufen und es dabei belassen. Zertifikate, Bestätigungen und Vertragsklauseln haben ihren Wert, aber der AEPD-Leitfaden macht klar, dass sie echte Kontrolle nicht ersetzen. Wer bei Papierkram stehen bleibt, dokumentiert Absicht – und die Aufsicht verlangt mehr.

Entscheidend ist, ob das Unternehmen die entscheidenden Hebel hält – unabhängig vom Standort der Infrastruktur. Das heißt: Schlüssel besitzen, Richtlinien setzen, Logs einsehen und Daten bewegen können. Diese vier Anforderungen kann man auf der Infrastruktur eines Anbieters erfüllen – und im eigenen Haus verfehlen.

Das Versagen zu benennen hilft: Nennen Sie das Muster, das nur auf Papier existiert, „Assurance Theater“ – ein Programm, das Sicherheit vortäuscht, statt Kontrolle zu prüfen. Eine ungetestete Kontrolle ist eine schlafende Kontrolle: vorhanden, aber wirkungslos. Beides ist häufig und taucht in Präsenz-Audits nicht auf.

Wie Kiteworks Kontrolle dorthin bringt, wo die Daten sind

Das Kiteworks Control Plane orientiert sich an den vier oben genannten Anforderungen. Es läuft als Single-Tenant-Instanz, sodass Daten und Schlüssel eines Kunden nicht mit denen anderer vermischt werden. Es setzt Double Encryption ein und bietet Geofencing sowie Datenhoheitskontrollen, mit denen Unternehmen festlegen, wo Inhalte abgerufen und ausgetauscht werden dürfen. Eine Policy Engine und ein Audit-Log steuern und dokumentieren, wie sensible Inhalte bewegt werden – egal ob durch Mitarbeitende, Partner oder KI-Agenten.

Das beantwortet auch die Paritätsfrage: Der Kiteworks Secure MCP Server ermöglicht es KI-Assistenten wie Claude und Copilot, mit Unternehmensinhalten zu arbeiten, während sie die Berechtigungen des jeweiligen Nutzers übernehmen. Rollen- und attributbasierte Kontrollen gelten für jede KI-Aktion. Zugangsdaten werden im Keychain des Betriebssystems gehalten und nie an das Modell weitergegeben. Das Audit-Log speist das SIEM des Unternehmens. Kiteworks Compliant AI setzt diese Governance für Unternehmen um, die Aufsichtsbehörden nachweisen müssen, wie KI regulierte Daten verarbeitet.

Für Unternehmen mit Souveränitätsanforderungen bieten Data Sovereignty Compliance-Funktionen und eine zentrale Policy Engine der verantwortlichen Partei einen konkreten Nachweis für die Aufsicht. Menschen und Agenten liegen auf einer Ebene – eine Regeländerung gilt für alle Akteure und erscheint in einem gemeinsamen Protokoll.

Kein Produkt ersetzt die nachfolgend beschriebene Überprüfung. Aber eine Plattform, die Schlüssel, Richtlinien und Logs unter die Kontrolle des Kunden stellt, macht die Überprüfung nachvollziehbar.

Kontrolle vierteljährlich überprüfen

Eine vierteljährliche Überprüfung lässt sich an einem halben Tag durchführen und beantwortet die Fragen, die Aufsichtsbehörden und Einigungen immer wieder stellen. Beginnen Sie mit den Schlüsseln: Listen Sie alle Systeme mit sensiblen Daten auf und dokumentieren Sie, wer die Verschlüsselungsschlüssel hält. Jede Antwort „der Anbieter“ ist ein Befund.

Testen Sie dann Alarme: Wählen Sie drei Kontrollen, die Ihre Tools bieten – etwa fehlgeschlagene Multifaktor-Anmeldung, Massendownload oder Login aus neuem Land – und lösen Sie jeden Fall in einer Testumgebung aus. Dokumentieren Sie, ob eine benannte Person benachrichtigt wurde und wie schnell. Eine Kontrolle, die in ein unbeachtetes Postfach meldet, hat nicht ausgelöst.

Stichproben ausgehender Dateien: Ziehen Sie zwanzig Dokumente, die das Unternehmen im letzten Quartal verlassen haben – per E-Mail, Filesharing, öffentliche Unterlagen oder Partnerportale – und prüfen Sie sie auf versteckte Tabellen, Metadaten und personenbezogene Daten, die der Absender nicht teilen wollte.

Kartieren Sie die Kette Ihrer beiden wichtigsten Anbieter – bis zu Subunternehmern und Administratoren – und notieren Sie, wer wo Zugriff hat. Fragen Sie, ob Sie innerhalb eines definierten Zeitfensters aussteigen könnten. Ist die Antwort unbekannt, planen Sie die Probe.

Überprüfen Sie abschließend KI-Assistenten: Für jeden Assistenten dokumentieren Sie, wessen Berechtigungen er nutzt, auf welche Systeme er zugreift und wo seine Aktivitäten protokolliert werden. Weichen die Antworten von denen für einen menschlichen Nutzer mit derselben Aufgabe ab, beheben Sie die Differenz.

Fassen Sie die Ergebnisse auf einer Seite zusammen und senden Sie sie an die Verantwortlichen für Datenschutz, Sicherheit und Einkauf. Wiederholen Sie das in 90 Tagen und vergleichen Sie. Ein wiederholter Befund zeigt, dass ein Problem dokumentiert, aber nicht gelöst wird.

Erfahren Sie, wie Sie mit eigenen Schlüsseln, Richtlinien und Logs Souveränität nachweisbar machen – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag  
  Datenhoheit: Best Practice oder regulatorische Pflicht?
• eBook  
  Datenhoheit und DSGVO
• Blogbeitrag  
  Vermeiden Sie diese Fallstricke bei der Datenhoheit
• Blogbeitrag  
  Best Practices für Datenhoheit
• Blogbeitrag  
  Datenhoheit und DSGVO [Verständnis von Datensicherheit]