Der Datenschutzbeauftragte sagt immer kurz vor dem Release, dass irgendwas nicht erlaubt ist. Dann wird es richtig teuer, wie bei jedem späten Umbau der Architektur. Doch solche Schmerzen lassen sich leicht vermeiden, wenn einige wenige Prinzipien schon ab dem Beginn des Entwicklungsprozesses berücksichtigt werden.

Beim Datenschutz steht die Softwarebranche gedanklich ungefähr da, wo sie bei der Sicherheit vor zehn Jahren stand. Nach der Featureimplementierung bringt irgendjemand das Thema auf und dann wird hektisch gepatcht. Oder das Thema wird wegignoriert, bis ein Datenleck es wieder in Erinnerung bringt – zu spät. Zwar bieten erste Hochschulen Privacy Engineering als Teil von Masterstudiengängen an. Doch es fehlt ebenso an etablierten Standards, wie an nützlicher Toolunterstützung.

Dabei gibt es gute Gründe, den Datenschutz nicht links liegen zu lassen. Auf der einen Seite stehen Risiken, denn Datenschutz ist Gesetz. Verstöße können teuer werden, denn es drohen Bußgelder und Schadenersatzforderungen. Inzwischen werden solche Risiken bei Finanzierungsrunden oder Unternehmensübernahmen geprüft. Zudem schadet mangelnder Datenschutz der Reputation. Vielleicht wäre die Luca-App ja erfolgreich, wenn sie nicht einige, vollkommen vermeidbare Patzer in diesem Bereich enthielte.

Auf der anderen Seite stehen Chancen bei Kunden, die Wert auf die Privatsphäre legen. Der Messenger Signal – ursprünglich ein Nischenprodukt – hat sich vor allem wegen des Datenschutzes zu einem der Meistgenutzten entwickelt. Und manche Bereiche wie Schulen gewichten Datenschutz bei der Systemauswahl sehr hoch.

Dabei führt das deutsche Wort Datenschutz immer wieder zu Missverständnissen. Es geht nicht um den Schutz der Daten, damit befasst sich die Informationssicherheit. Vielmehr geht es um den Schutz der Personen vor Schäden, die durch die Nutzung ihrer Daten entstehen können. Offensichtlich überlappen sich diese beiden Bereiche stark, doch wer nur DevSec betreibt, macht noch nicht automatisch alles richtig.

Rechte von Menschen

Der Bezug zur Person zeigt schon, dass es nicht um jede Art von Daten geht, sondern nur um die, die sich auf einen konkreten Menschen beziehen. Ganz offensichtlich gehört dazu alles, was diesen Menschen identifiziert, zum Beispiel der Name, ein Bild oder ein Video, auf dem er zu sehen ist. Nicht ganz so offensichtlich ist, dass etwa auch die Anschrift in die Kategorie der Daten fällt, anhand derer man Personen leicht identifizieren kann. Weil es gar nicht wenige Häuser gibt, in denen nur ein Mensch lebt, kann die Anschrift eindeutig auf diesen verweisen. Ähnlich verhält es sich z. B. mit der Geräte-ID eines Smartphones, das ja auch ein sehr persönlicher Gegenstand ist.

Dem stehen anonyme Daten gegenüber, die nicht mit einer Person in Verbindung gebracht werden können. Die gute Nachricht: Anonyme Daten sind außerhalb des Geltungsbereichs des Datenschutzes, es gelten keine der folgenden Regeln. Die schlechte Nachricht ist allerdings, dass Datensätze oft weniger anonym sind, als es auf den ersten Blick erscheint. So ist eine einzelne Geo-Koordinate aus Länge und Breite mit Sicherheit anonym. Doch durch einen GPS-Track, der ein Bewegungsmuster enthält, lässt sich wahrscheinlich auf die Person schließen, etwa weil sie sich besonders häufig zu Hause aufhält. Oder wenn zu einer einzelnen Geo-Koordinate die Information bekannt ist, dass sie aus der Routenplanung eines ambulanten Pflegedienstes stammt: Dann handelt es sich wahrscheinlich um eine Adresse, die wie oben gezeigt identifizierend ist, und zwar von einer pflegebedürftigen Person. Als Faustregel gilt: Je reichhaltiger ein Datensatz ist, desto wahrscheinlicher kann die Anonymität gebrochen werden.

Zwischen den anonymen und den identifizierenden Daten stehen die pseudonymen. Sie enthalten keine direkt identifizierenden Merkmale, lassen sich aber mit einer zusätzlichen Information einer Person zuordnen. Typische Beispiele sind Autokennzeichen oder IP-Adressen, bei denen der Personenbezug aus dem Provider-Log kommt. Solche Situationen gibt es häufig auch innerhalb von Systemen. Wenn im Shopsystem die Kundenaccounts (inklusive Namen) und die Bestellungen in separaten Tabellen liegen, von denen die zweite nur auf die erste verweist, sind die Bestellungen pseudonym, da die Accountdaten zur Personalisierung erforderlich sind.

Normalerweise unterscheiden Datenschützer bei ihrer Bewertung nicht zwischen identifizierenden und pseudonymen Daten. So bewerten Gerichte IP-Adressen derzeit grundsätzlich als schützenswert. Pseudonyme Daten müssen also genauso behandelt und geschützt werden wie direkt personenbezogenen.

Aus technischer Sicht ist Pseudonymität hingegen ein Graubereich, denn die Zuordnung zu einer Person kann unterschiedlich kompliziert sein. Bei den erwähnten zwei Tabellen in einem Shopsystem ist sie trivial. Doch wenn es mehrerer Stufen bedarf und die nötigen Informationen unter der Kontrolle verschiedener Organisationen stehen, kann sie nahezu unmöglich sein. In solchen Fällen kann man manche Datenbanken auch als „faktisch anonym“ betrachten. Doch diese Einschätzung sollte unbedingt vor der Implementierung mit den Datenschützern abgeklärt werden.

Dennoch ist das Konzept der pseudonymen Daten äußerst nützlich. Denn pseudonyme Daten lassen sich oft ganz leicht zu anonymen machen, indem man die Referenzen zu den identifizierenden Daten kappt. Neben dem Löschen der Verweise eignet sich dazu auch eine partielle Kopie der Daten, in die die Referenzinformationen nicht mitdupliziert werden.

Diese Anonymisierung funktioniert jedoch nur, wenn schon beim Systemdesign die identifizierenden Daten sauber isoliert werden und die Referenzen so gestaltet werden, dass ihr Fehlen das System nicht beeinträchtigt.

Mein Datenschatz

Im Datenschutz geht es also um alle nicht eindeutig anonymen Daten. Wie damit umzugehen ist, regelt in ganz Europa (und etwas darüber hinaus) die Datenschutz-Grundverordnung (DSGVO). Sie ist inzwischen Vorbild für ähnliche Gesetze, zum Beispiel in Kalifornien und Brasilien. Außerdem haben einige andere Industrienationen vergleichbare Regelungen. Alle beruhen auf denselben Grundprinzipien.

Daten sind das neue Gold. Doch wem gehört es? Die überall gleiche Antwort lautet: Daten, die sich mit einer Person verbinden lassen, gehören dieser Person. Es hilft daher, sich ein Benutzerkonto tatsächlich wie ein Bankkonto vorzustellen: Das Geld gehört dem Kontoinhaber, die Bank darf lediglich damit arbeiten.

Analog dazu darf man mit den Daten anderer Leute nur mit Erlaubnis arbeiten. Die Erlaubnis ergibt sich an manchen Stellen automatisch. So darf ein Händler die Adresse des Bestellenden selbstverständlich zum Versand der Bestellung erfragen und benutzen. Diese automatische Erlaubnis umfasst aber nur die zwingend erforderlichen Daten und die Nutzung für genau diesen Zweck. In diesem Rahmen darf der Händler also weder die Kleidergröße speichern noch die Adresse für Werbung benutzen.

Als naheliegende Lösung kann man sich immer die Erlaubnis der betroffenen Person einholen. Doch die DSGVO knüpft diese Einwilligung an eine Reihe von Bedingungen, die auch das Entwicklerteam betreffen. Die ersten wirken beim UX-Design. So muss der User explizit, separat und konkret einwilligen. Es bedarf also einer getrennten Checkbox, eine implizite Zustimmung durch Anlegen eines Accounts genügt ebenso wenig wie die Kombination der Einwilligung mit einer anderen Auswahl.

Zudem muss der User aktiv zustimmen. Die Checkbox darf also nicht als Default schon ausgewählt sein. Außerdem muss er wissen, worauf er sich einlässt, und zwar klar und konkret. Bei der Einwilligungs-Checkbox muss also in verständlicher Sprache stehen, welche Daten zu welchem Zweck wie lange genutzt werden sollen. Ein deutlich beschrifteter Link oder ausklappbarer Text genügen. Schließlich muss die Einwilligung genauso leicht zu widerrufen sein, wie sie gegeben wurde. Bei all dem kann sich der UX-Designer an den etablierten Cookie-Bannern oder den Einwilligungsdialogen der Betriebssysteme von Mobiltelefonen orientieren.

Doch damit nicht genug: Auch an das Backend gibt es Anforderungen. Zunächst muss die Einwilligung nachvollziehbar sein. Ein Flag oder besser noch ein Protokoll stellen also das Minimum dar. Empfehlenswert ist auch ein vorbereiteter Report für den Fall, dass der User sich wundert, ob er denn diese Einwilligung tatsächlich erteilt hat. Und das Flag muss natürlich auch wirken. Wenn die Einwilligung fehlt, dürfen die daran geknüpften Verarbeitungen nicht stattfinden.

Größere Mühe macht oft der Widerruf. Denn der User darf laut DSGVO seine Einwilligung jederzeit zurücknehmen. Von diesem Zeitpunkt darf die zuvor erlaubte Datennutzung nicht mehr weitergehen. Es müssen also alle beteiligten Systeme, Datenbanken und Microservices auf diese Statusänderung vorbereitet sein.

Neben der Vertragserfüllung und der Einwilligung gibt es einige weitere Gründe, aus denen die Arbeit mit den Daten fremder Leute erlaubt sein kann. Allen ist gemein, dass der Betroffene über die Datenarten, den Zweck und einige andere Details vorab informiert werden muss. Es empfiehlt sich daher, schon beim Entwurf neuer Features diejenigen ins Boot zu holen, die Nutzungsbedingungen und Datenschutzerklärungen verantworten. Die passende Rechtsgrundlage kann von diesen Verantwortlichen dann konstruiert werden und gleichzeitig können sie helfen, die daraus resultierenden Anforderungen an die Implementierung zu formulieren.

Weniger ist mehr – Datenminimierung

Ein weiteres gemeinsames Prinzip ist die Datenminimierung. Die Verarbeitung soll sich auf die erforderlichen Daten beschränken. Das bringt auch Vorteile bei der Sicherheit, denn Daten, die gar nicht erst im System sind, müssen nicht gesichert werden. Zudem skalieren Designs, die sparsam mit Daten umgehen, oft besser.

Wer also schon beim Design auf unnötige Daten verzichtet, erspart sich später einige Nacharbeiten. Das englische Credo lautete: „Personal data is not an asset, but a liability.“ Entsprechend sollten die Entwickler im Rahmen ihrer PDCA-Zyklen gewohnheitsmäßig prüfen, ob sie wirklich noch alle Datenarten brauchen, und beherzt minimieren.

Die erste Leitfrage lautet dabei, ob nicht weniger Daten über die Personen ausreichen. Dazu hinterfragt man für jede Datenart, für jede Tabellenspalte oder jede Eigenschaft eines Objekts, ob sie wirklich benötigt wird, um die Funktion des Systems zu erfüllen. In der anderen Richtung lohnt es sich, zu prüfen, ob nicht die Daten von weniger Personen genügen. So kann ein System vielleicht Teile seiner Funktion ganz ohne Nutzeraccount anbieten und die Nutzung anonym auswerten.

Bei der Definition der Schnittstellen zwischen (Teil-)Systemen lässt sich die Datenminimierung besonders wirksam einbauen. Das empfangende System sollte Daten, die es nicht benötigt, gar nicht erst bekommen.

Wer einen Schritt weiter gehen möchte, wägt ab, ob er einzelne Datenarten nur für eine Funktion benötigt, die weniger wertvoll ist als der Aufwand für die korrekte Handhabung der Daten. So stellte ein Anbieter von Lernsoftware fest, dass er identifizierende Daten der Schülerinnen nur benötigte, um sie nach dem Log-in mit ihren Namen zu begrüßen. Der Verzicht auf ein kleines bisschen Personalisierung an dieser Stelle machte Vieles einfacher. Denn das System arbeitet jetzt nicht mehr mit den besonders schutzbedürftigen Daten von Minderjährigen, sondern nur noch mit pseudonymen Daten, zu deren Auflösung das Klassenbuch nötig ist.

Kann das weg? Datenlöschung

Zur Datenminimierung gehört auch die zeitliche Komponente; personenbezogene Daten dürfen nur so lange vorgehalten werden, wie es die Erfüllung der vereinbarten Zwecke erfordert. Systeme sollten daher möglichst automatisch die Daten verwerfen, die sie nicht mehr benötigen. Dabei ist ein genauer Blick nötig. Bei einer Supportanfrage sind die Kontaktdaten überflüssig, wenn das Problem endgültig gelöst ist. Doch der Inhalt bleibt für den Wissenstransfer, Statistiken oder als Featurefeedback relevant. Auch an dieser Stelle fährt besser, wer im vorneherein identifizierende von anonymisierbaren Daten getrennt hat.

Systemdesign und Implementierung müssen also eine Möglichkeit zum Verwerfen von Datensätzen einbauen. Doch das Entwicklerteam kann und sollte normalerweise nicht allein entscheiden, welche Daten wann gelöscht werden. Bei zu langer Speicherung drohen Bußgelder, eine zu kurze Speicherung kann andere Gesetze verletzen. So gilt in Deutschland die Pflicht, Rechnungen zusammen mit der begleitenden Dokumentation 10 Jahre aufzubewahren, bei der Entsorgung nuklearer Abfälle beträgt die Frist 300 000 Jahre. Solche Randbedingungen kann das Entwicklerteam nicht auf dem Schirm haben, sodass hier Compliancebeauftragte, Datenschützer oder Rechtsberater als Stakeholder eingebunden werden sollten.

Als gute Strategie hat es sich hier erwiesen, ein Archivsystem klar getrennt vom produktiven System aufzusetzen. Das Archivprojekt setzt dann die Aufbewahrungsfristen mit dem Compliancevertreter im System um. Das Produktivsystem liefert alle aufbewahrungspflichtigen Datensätze dort ab und implementiert selbst nur die technisch sinnvollen, möglichst kurzen Speicherzeiten.

Löschen vs. Anonymisieren

Für das Verwerfen nicht mehr benötigter Datensätze gibt es zwei mögliche Methoden: löschen oder anonymisieren. Wirksames Löschen ist ein Thema für sich und von der eingesetzten Speichertechnik abhängig. Das Augenmerk der Entwickler sollte darauf liegen, mit der zentralen Löschfunktion wirklich alle Kopien in allen Systemen zu erwischen, in denen die Daten nicht mehr vonnöten sind.

Eine vereinfachende Ausnahme stellen dabei die Back-ups dar. Nach der üblichen Rechtsprechung in Deutschland muss dort nicht gelöscht werden. Die Sicherungskopien können unverändert bleiben. In diesem Falle muss jedoch der Restore-Prozess so gestaltet werden, dass die betreffenden Datensätze gleich wieder aus dem Livesystem gelöscht werden.

Besonders effizient lassen sich verschlüsselte Daten löschen, denn es genügt, den Schlüssel zu verlieren. Verschlüsselung dient also nicht nur direkt der Sicherheit, sondern unterstützt auch bei der Umsetzung des Datenschutzes.

Alternativ können die Daten auch wirksam anonymisiert werden. Doch bloß eine ID durch ihren Hash zu ersetzen, ist keine Anonymisierung. Denn das unterbindet nur die Zuordnung in eine Richtung. Wer Zugang zur ID-Datenbank erhält, kann den Hash nachrechnen und die darüber referenzierten Daten doch wieder der Person zuordnen. Die Daten sind also weiterhin bloß pseudonym.

Schutzziele

Aus den Datenschutzprinzipien ergeben sich Schutzziele, die jede Implementierung anstreben soll. Das bekannteste ist die Vertraulichkeit, also dass die Daten nicht in die falschen Hände gelangen. Meist denkt man dabei nur an externe Hacker. Doch genauso wichtig ist ein sauberes Rollen- und Rechtekonzept, das dem Need-to-Know-Prinzip folgt. Wer bestimmte Datenarten für seine Aufgaben nicht benötigt, sollte sie auch gar nicht zu sehen bekommen. So sind die Kontaktdaten der einzelnen Kunden bei der statistischen Auswertung des Kaufverhaltens irrelevant. Dem Data Analyst sollten sie daher verborgen bleiben.

Wie die Vertraulichkeit sind auch Integrität (Korrektheit, Vollständigkeit) und Verfügbarkeit Schutzziele, die Datenschutz und Informationssicherheit teilen. Bei der technischen Umsetzung unterscheiden sich personenbezogene nicht von anderen Daten und das Sicherheitskonzept sollte sie entsprechend berücksichtigen.

Userrechte

Neben den allgemeinen Grundsätzen gibt die DSGVO jedem User auch einige konkrete Rechte. Wer personenbezogene Daten verarbeitet, muss diese Rechte erfüllen können, doch oft hapert es aufgrund falscher Architekturentscheidungen an dieser Stelle.

Da ist zunächst das Auskunftsrecht: Auf Anfrage muss der Betroffene eine vollständige und genaue Liste aller mit seiner Person verknüpften Daten erhalten. Auch hier reicht es nicht, nur die identifizierenden Daten zu nennen. In die Auskunft gehören alle mit der Person verknüpften Daten aus allen Systemen. In letzter Zeit mehren sich die Urteile, die unvollständige Auskünfte nicht nur mit einem Bußgeld versehen, sondern den Betroffenen auch Schadensersatz zusprechen.

Auch die Löschung nicht mehr benötigter Daten kann ein Betroffener verlangen. Wer keine automatische Löschung implementiert hat, benötigt spätestens für eine solche Anfrage einen Prozess oder eine Funktion, die wirklich alle relevanten Daten erfasst. Auch hier sind in Deutschland Back-ups ausgenommen. Ähnlich sieht es bei der Berichtigung aus: Der User hat das Recht dazu, dass falsche Daten auf seinen Hinweis hin korrigiert werden – alle Kopien in allen Systemen.

Löschung und Berichtigung sind nicht nur im eigenen System umzusetzen. Falls Daten weitergegeben wurden, etwa an Zahlungsdienstleister, liegt es beim Verarbeiter, diese ebenfalls zu informieren. Eventuell lässt sich das über APIs automatisieren. Doch häufiger braucht es dafür einen definierten Prozess.

Schließlich darf der User verlangen, dass alle seine Daten zwar nicht gelöscht, aber nur noch eingeschränkt genutzt werden. Das kann zum Beispiel im Zuge einer Korrektur nötig sein, solange die Daten geprüft werden.

Ob die Anfragen im Einzelnen berechtigt sind, liegt sicher nicht bei den Entwicklern. Doch ihr System muss in der Lage sein, ihnen nachzukommen. Somit liegt die Datenminimierung auch im Eigeninteresse, denn was nicht da ist, muss auch nicht gelöscht oder korrigiert werden und kann in einer Auskunft nicht fehlen. Zudem hilft ein sauberes und dokumentiertes Design, den Überblick über die Datenarten und ihre Speicherorte zu behalten.

Datenleck

Selbst bei konsequent sicherer Entwicklung und Betrieb kann es zu einem Datenleck kommen. Das muss gar nicht durch einen Hackerangriff geschehen, auch an falsche Empfänger versandte Daten fallen beispielsweise in diese Kategorie. Und nicht nur der Verlust der Vertraulichkeit stellt einen Vorfall dar, auch die versehentliche Löschung oder falsche Änderungen verstoßen gegen die Schutzziele Verfügbarkeit bzw. Integrität. Gerade IT-ferne interne Nutzer zeigen große Kreativität bei der Produktion solcher Fehler.

Wenn der Fall der Fälle eintritt und eventuell auch personenbezogene Daten betrifft, läuft die Uhr. Denn unter gewissen Bedingungen ist eine Meldung an die zuständige Aufsichtsbehörde nötig, und zwar innerhalb von 72 Stunden, nachdem das Problem aufgefallen ist. Die Entscheidung über eine solche Meldung liegt in der Regel bei der Geschäftsführung, beraten durch den Datenschutzbeauftragten. Damit diese Personen innerhalb der Frist reagieren können, gehört zumindest der Datenschutzverantwortliche recht weit vorne in die Informationskette, die der Operator im Notfall aktiviert.

In der Abwicklung einer solchen Meldung kann die Datenschutzbehörde anordnen, alle betroffenen Personen über den Vorfall zu informieren. Sofern sich nicht nachvollziehen lässt, wessen Daten Opfer des Vorfalls wurden, muss diese Information schlimmstenfalls über Massenmedien an alle potenziell Betroffenen verbreitet werden – ein enormer Reputationsverlust. Der lässt sich vermeiden, wenn schon in der Designphase festgelegt wurde, wessen Daten wo liegen und verbleiben. Ein klares Bild darüber erspart hektische Forensik.

USA

Auch wenn das Marketing von Cloud-Anbietern diesen Umstand nicht offen ansprechen möchte, findet die Verarbeitung in Rechenzentren statt, die ganz physisch an irgendeinem Ort stehen. Die DSGVO verlangt, dass an diesem Ort dasselbe Schutzniveau besteht wie hier. Das umfasst die EU und zusätzlich den Europäischen Wirtschaftsraum (Norwegen, Island, Liechtenstein). Genauso gut sind Staaten, in denen die Europäische Kommission den Datenschutz geprüft und als angemessen anerkannt hat. Solche Angemessenheitsbeschlüsse gelten derzeit für ein gutes Dutzend Länder, unter anderen Großbritannien, Japan und Uruguay. Auch in diesen Ländern darf man also genauso verarbeiten lassen wie in der EU.

Ein wichtiges Land fehlt in dieser Liste: die USA. Denn im sogenannten Schrems-II-Urteil stellt der Europäische Gerichtshof fest, dass dort das Niveau nicht passt, weil Bundesbehörden in einer Weise auf Daten zugreifen dürfen, die die Rechte der Betroffenen nicht sicherstellt. Damit sind die USA aus Datenschutzsicht ein Drittland wie Burundi oder Afghanistan. Personenbezogene Daten dürfen nur dorthin gelangen, wenn sie zusätzlich gesichert sind, zum Beispiel durch Verschlüsselung.

US-Cloud-Anbieter reagieren darauf mit dem Ausbau ihrer Kapazitäten in Europa. Microsoft will bis Ende 2022 ein „EU Data Boundary for the Microsoft Cloud“ [1] genanntes Projekt umsetzen und dann sämtliche Azure Services aus europäischen Rechenzentren anbieten. Schon jetzt sollte man beim Buchen von Azure Services einen Verarbeitungsort in der EU wählen und auf Dienste, die es dort noch nicht gibt, möglichst verzichten.

Doch auch mit dieser Ortsbeschränkung lässt sich Azure (wie alle US-Clouds) derzeit nicht vollständig rechtssicher für personenbezogene Daten nutzen. Denn amerikanische Stellen können aufgrund mehrerer Gesetze Konzerne mit Hauptsitz in den USA zwingen, Daten von ihren Tochterunternehmen in die USA zu holen. Die sorgfältige Begrenzung auf Europa ist damit aus rechtlicher Sicht hinfällig, denn ein Export in die USA lässt sich nicht ausschließen. Gegenwärtig laufen Verhandlungen zwischen den Aufsichtsbehörden und Microsoft sowie zwischen der EU und den USA, um diese weltfremde Situation zu beheben. Doch ein Ergebnis ist noch nicht absehbar.

Verschlüsselung behebt das Problem nur, wenn die Daten beim Cloud-Dienstleister nie in unverschlüsselter Form vorliegen. Eine bloße Storage Encryption reicht also nicht aus. Und der Dienstleister darf auch keine Möglichkeit haben, die Daten selbst zu entschlüsseln, denn auch dazu kann er in den USA gezwungen werden. Der Schlüssel muss also beim Auftraggeber bleiben, ein Key Vault bei demselben Dienstleister hebelt das Konzept aus. Die einzig saubere Lösung heißt bei Microsoft „Hold Your Own Key“ (HYOK) [2].

Für das Entwicklerteam heißt das, dass es derzeit nicht allein über den Einsatz von US-Clouds entscheiden kann. Da solche Dienstleister gegenwärtig ein Risiko für das ganze Unternehmen darstellen, muss darüber auch jemand entscheiden, der für ein solches Risiko unterschreiben darf.

An den Entwicklern liegt es, diese Entscheidung gut vorzubereiten. Dazu gehört die ernsthafte und dokumentierte Prüfung von datenschutzfreundlichen Alternativen, zum Beispiel europäische Cloud-Dienstleister oder die clientseitige Verschlüsselung aller personenbezogenen Daten.

Proaktiv umsetzen

Der Datenschutz steht also keineswegs im Weg von Big-Data-Analysen oder datengetriebenen Geschäftsmodellen, wenn man ihn beim Design der Systeme von Anfang an berücksichtigt. Dabei gilt es, nur wenige Prinzipien im Blick zu behalten. Datenminimierung, Trennung identifizierender Daten und ein vollständiges Dateninventar stehen dabei an oberster Stelle.

Links & Literatur

[1] https://blogs.microsoft.com/eupolicy/2021/05/06/eu-data-boundary/

[2] https://docs.microsoft.com/en-us/azure/information-protection/plan-implement-tenant-key