Privacy by Design und die DSGVO

Datenschutz ist eine Designeigenschaft

Sicherheit und Datenschutz überschneiden sich, sind aber nicht dasselbe. Sicherheit fragt, ob Daten vor Personen geschützt sind, die sie nicht haben sollten. Datenschutz fragt außerdem, ob die Organisation selbst die Daten überhaupt erheben sollte, was sie damit tun darf, wie lange und welche Kontrolle die Person behält, die sie beschreiben. Ein System kann frei von Sicherheitsverletzungen sein und trotzdem in die Privatsphäre eingreifen, etwa indem es den Standortverlauf jedes Kuriers für immer speichert oder Bestellhistorien stillschweigend zum Training eines Preismodells wiederverwendet.

Die Essenslieferplattform zeigt gut, warum Datenschutz eine Architekturfrage ist. Sie speichert Namen, Telefonnummern und Wohnadressen; Bestellhistorien, die über Ernährungsgewohnheiten Religion oder Gesundheit offenbaren können; Zahlungsreferenzen; und einen fortlaufenden Strom von Kurierstandorten. Diese Daten fließen von den Apps durch Dutzende von Services, Events, Caches, Logs, Analytics-Speichern und Backups und zu Auftragsverarbeitern wie dem Zahlungsanbieter, dem SMS-Gateway und dem Support-Desk-SaaS. Entscheidungen darüber, wo personenbezogene Daten gespeichert werden, über welche Schlüssel sie adressiert werden und wie sie sich finden und entfernen lassen, sind später teuer zu ändern, und genau das ist der Test für architektonische Bedeutsamkeit.

Das Recht in Kürze: DSGVO und UK GDPR

Die Datenschutz-Grundverordnung, Verordnung (EU) 2016/679, gilt seit dem 25. Mai 2018. Sie schützt personenbezogene Daten, die Artikel 4 Nummer 1 definiert als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, direkt oder indirekt, etwa mittels Zuordnung zu einem Namen, zu einer Kennnummer, zu Standortdaten oder zu einer Online-Kennung. Der Verantwortliche entscheidet über die Zwecke und Mittel der Verarbeitung und trägt die Hauptverantwortung; ein Auftragsverarbeiter verarbeitet im Auftrag des Verantwortlichen auf Grundlage eines Vertrags (Artikel 28), wie es das SMS-Gateway der Plattform tut. Die DSGVO gilt für Organisationen mit Niederlassung in der EU und nach Artikel 3 auch für andere, die Personen in der EU Waren oder Dienstleistungen anbieten oder ihr Verhalten beobachten.

Im Vereinigten Königreich wurde die DSGVO nach dem Brexit als UK GDPR beibehalten, die neben dem Data Protection Act 2018 gilt. Der Data (Use and Access) Act 2025 hat beide geändert; die meisten seiner datenschutzrechtlichen Änderungen sind am 5. Februar 2026 in Kraft getreten, darunter Änderungen bei den Rechtsgrundlagen, bei automatisierten Entscheidungen und bei internationalen Übermittlungen, und ab dem 19. Juni 2026 folgt eine Pflicht der Verantwortlichen, Datenschutzbeschwerden zu bearbeiten. Die Europäische Kommission hat ihre Angemessenheitsbeschlüsse für das Vereinigte Königreich im Dezember 2025 erneuert, sodass personenbezogene Daten weiterhin ohne zusätzliche Garantien aus der EU in das Vereinigte Königreich fließen können. Für Architekten haben beide Regelwerke dieselben Grundsätze, Rechte und Gestaltungspflichten; die Unterschiede sind Detailfragen für Juristen.

Die Höchstbußgelder für die schwersten Verstöße betragen nach der DSGVO 20 Mio. EUR oder 4 % des weltweiten Jahresumsatzes (nach der UK GDPR 17,5 Mio. GBP oder 4 %), je nachdem, welcher Betrag höher ist; häufigere Folgen sind allerdings Anordnungen, die Verarbeitung einzustellen, Reputationsschäden und die Kosten einer Neuentwicklung. Im November 2025 hat die Europäische Kommission im Rahmen eines Digital Omnibus-Pakets Änderungen der DSGVO vorgeschlagen; zum Zeitpunkt der Erstellung durchlaufen diese noch das Gesetzgebungsverfahren und ändern bisher nichts.

Rechtsgrundlagen in Kürze

Artikel 6 erlaubt eine Verarbeitung nur auf einer von sechs Rechtsgrundlagen: Einwilligung, Erfüllung eines Vertrags mit der Person, rechtliche Verpflichtung, lebenswichtige Interessen, Wahrnehmung einer Aufgabe im öffentlichen Interesse oder berechtigte Interessen, sofern nicht die Interessen und Rechte der Person überwiegen. Besondere Kategorien von Daten, etwa Gesundheitsdaten oder religiöse Überzeugungen, brauchen zusätzlich eine Bedingung nach Artikel 9. Die Rechtsgrundlage wird je Zweck gewählt, nicht je System, und sie verändert, was die Architektur leisten muss. Auf der Essenslieferplattform wird die Lieferadresse zur Erfüllung des Vertrags verarbeitet; Rechnungen werden aufbewahrt, um eine rechtliche Verpflichtung aus dem Steuerrecht zu erfüllen; die Betrugsprüfung stützt sich typischerweise auf berechtigte Interessen; und Marketing-E-Mails brauchen in der Regel eine Einwilligung, für die zusätzlich die Vorschriften zur elektronischen Werbung gelten.

Die Einwilligung hat die strengsten Mechanismen. Nach Artikel 7 muss der Verantwortliche nachweisen können, dass die Einwilligung erteilt wurde; sie muss sich auf einen bestimmten Zweck beziehen, und ihr Widerruf muss so einfach sein wie ihre Erteilung. Deshalb kann eine Einwilligung keine einzelne boolesche Spalte sein: Das System braucht einen Append-only-Nachweis darüber, wozu die Person eingewilligt hat, wann, über welchen Kanal und auf welchen Wortlaut hin, und jeder Consumer muss einen Widerruf zeitnah beachten.

{
  "event": "ConsentGiven",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "noticeVersion": "privacy-notice-2026-09",
  "wording": "Send me offers from restaurants near me",
  "channel": "ios-app 7.3.0",
  "method": "unticked checkbox, user ticked",
  "at": "2026-10-03T18:22:41Z"
}
{
  "event": "ConsentWithdrawn",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "channel": "email unsubscribe link",
  "at": "2026-10-19T07:05:12Z"
}

Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen

Artikel 25 macht Privacy by Design zur Rechtspflicht. Artikel 25 Absatz 1, Datenschutz durch Technikgestaltung, verlangt vom Verantwortlichen, sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung geeignete technische und organisatorische Maßnahmen wie die Pseudonymisierung zu treffen, die die Grundsätze wirksam umsetzen, unter Berücksichtigung des Stands der Technik, der Implementierungskosten, der Art und der Zwecke der Verarbeitung sowie der Risiken. Artikel 25 Absatz 2, durch datenschutzfreundliche Voreinstellungen, verlangt, dass durch Voreinstellung nur die für den jeweiligen bestimmten Zweck erforderlichen Daten verarbeitet werden; das gilt für die Menge der erhobenen Daten, den Umfang ihrer Verarbeitung, ihre Speicherfrist und ihre Zugänglichkeit; insbesondere dürfen Daten nicht ohne Eingreifen der Person einer unbestimmten Zahl von Personen zugänglich gemacht werden. Die Leitlinien 4/2019 des Europäischen Datenschutzausschusses zu Artikel 25 geben praktische Beispiele.

Das Recht hat die Idee von Ann Cavoukian übernommen, der Information and Privacy Commissioner von Ontario, die Privacy by Design in den 1990er-Jahren entwickelte und 2009 ihre sieben Grundprinzipien veröffentlichte; die internationale Konferenz der Datenschutzbeauftragten hat sie 2010 gebilligt. Sie sind nach wie vor eine nützliche Checkliste für Design-Reviews.

Rechte, die die Architektur unterstützen muss

Bei den Rechten der betroffenen Personen wird Datenschutzrecht am unmittelbarsten zu Systemanforderungen. Ein Verantwortlicher muss in der Regel innerhalb eines Monats nach Eingang eines Antrags reagieren; bei komplexen oder zahlreichen Anträgen kann die Frist um weitere zwei Monate verlängert werden (Artikel 12 Absatz 3), und er muss die Daten der Person finden können, wo immer sie liegen. In einem System aus zwanzig Services, fünf SaaS-Auftragsverarbeitern und einem Data Warehouse ist das ohne gepflegte Datenlandkarte unmöglich: das Verzeichnis von Verarbeitungstätigkeiten, das Artikel 30 ohnehin verlangt, so nah am Code geführt, dass es zutrifft. Nach den britischen Änderungen von 2025 muss ein Verantwortlicher bei der Beantwortung eines Auskunftsersuchens nur angemessene und verhältnismäßige Suchen durchführen, was eine gute Datenlandkarte schnell macht.

Datenschutz-Folgenabschätzungen

Artikel 35 verlangt eine Datenschutz-Folgenabschätzung (DSFA) vor einer Verarbeitung, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Personen zur Folge hat, insbesondere bei systematischem und umfassendem Profiling mit erheblichen Auswirkungen, bei umfangreicher Verarbeitung besonderer Kategorien von Daten oder von Daten über strafrechtliche Verurteilungen und Straftaten sowie bei systematischer umfangreicher Überwachung öffentlich zugänglicher Bereiche. Die Aufsichtsbehörden veröffentlichen Listen weiterer Fälle; die fortlaufende Standortverfolgung von Kurieren und die algorithmische Steuerung ihrer Arbeit sind typische Kandidaten. Eine DSFA beschreibt die Verarbeitung und ihre Zwecke, bewertet Notwendigkeit und Verhältnismäßigkeit, bewertet die Risiken für die Personen und hält die Abhilfemaßnahmen fest; bleibt ein hohes Risiko bestehen, muss der Verantwortliche vor Beginn die Aufsichtsbehörde konsultieren (Artikel 36).

Architekten sollten eine DSFA als Datenschutz-Gegenstück zum Bedrohungsmodell aus Abschnitt 8.2 behandeln, zur selben Zeit und auf Basis desselben Datenflussdiagramms erstellt. Das an der KU Leuven entwickelte LINDDUN-Framework leistet für Datenschutzbedrohungen, was STRIDE für Sicherheitsbedrohungen leistet, mit Kategorien wie Linking, Identifying, Detecting, Data Disclosure und Unawareness. Die Schlussfolgerungen der DSFA werden zu Architekturanforderungen wie Standortverläufe werden 30 Tage nach der Lieferung gelöscht, die sich testen lassen.

Internationale Übermittlungen und Datenresidenz

Kapitel V der DSGVO beschränkt Übermittlungen personenbezogener Daten in Länder außerhalb des Europäischen Wirtschaftsraums. Eine Übermittlung ist zulässig, wenn die Kommission ein angemessenes Schutzniveau des Landes festgestellt hat (Artikel 45), wenn geeignete Garantien wie die Standarddatenschutzklauseln der Kommission bestehen (Artikel 46) oder im Rahmen eng begrenzter Ausnahmen (Artikel 49). Nachdem der Gerichtshof den EU-US-Datenschutzschild (Privacy Shield) im Urteil Schrems II vom Juli 2020 für ungültig erklärt hatte, erfordern Übermittlungen auf Basis von Vertragsklauseln eine Prüfung des Rechts im Zielland; das EU-US Data Privacy Framework, dessen Angemessenheit im Juli 2023 festgestellt wurde, deckt Übermittlungen an US-Unternehmen ab, die sich danach zertifizieren, und hat im September 2025 eine erste Klage vor dem Gericht der EU überstanden (Latombe/Kommission), wobei weitere Verfahren, einschließlich eines etwaigen Rechtsmittels zum Gerichtshof, die Lage noch ändern könnten.

Daraus folgen zwei architektonische Punkte. Erstens ist eine Übermittlung nicht nur eine Datenbank in einer anderen Region: Fernzugriff durch ein Support-Team im Ausland, die Unterauftragsverarbeiter eines SaaS-Auftragsverarbeiters und ein anderswo gehosteter Logging-Dienst zählen ebenfalls, daher muss die Datenlandkarte festhalten, wo Daten gespeichert sind und von wo aus auf sie zugegriffen wird. Zweitens lassen sich Anforderungen an die Datenresidenz, ob gesetzlich, vertraglich oder selbst gewählt, am einfachsten mit regionalen Deployment-Zellen erfüllen: Jede Region hält die personenbezogenen Daten und Schlüssel ihrer Kunden, globale Services sehen nur pseudonyme Referenzen, und die Replikation zwischen Regionen ist explizit und geprüft. Datenresidenz nachträglich in eine einzige globale Datenbank einzubauen, gehört zu den teuersten Änderungen, vor denen eine Plattform stehen kann; deshalb gehört sie zu den früh erfassten Randbedingungen.

Minimierung, Pseudonymisierung und Anonymisierung

Die am billigsten zu schützenden personenbezogenen Daten sind die, die Sie nie erheben. Minimierung zeigt sich in kleinen Entscheidungen: ein Ü18-Flag statt eines Geburtsdatums, ein Postleitzahlbezirk statt einer vollständigen Adresse für Analytics, eine maskierte Telefonnummer, die über die Plattform weitergeleitet wird, statt dem Kurier die Nummer des Kunden preiszugeben, und Standortabfragen nur während einer laufenden Lieferung.

Die Pseudonymisierung (Artikel 4 Nummer 5) verarbeitet Daten so, dass sie ohne Hinzuziehung zusätzlicher Informationen, etwa eines Schlüssels, die gesondert aufbewahrt und geschützt werden, nicht mehr einer Person zugeordnet werden können. Ein Keyed Hash (HMAC) der Kunden-ID, dessen Schlüssel beim Account-Team liegt, erlaubt dem Analytics-Team, Bestellungen je Kunde zu zählen, ohne zu sehen, wer die Kunden sind. Sie ist eine wertvolle Schutzmaßnahme, die Artikel 25 ausdrücklich nennt, doch Erwägungsgrund 26 stellt klar, dass pseudonymisierte Daten, die durch Heranziehung zusätzlicher Informationen einer Person zugeordnet werden könnten, weiterhin personenbezogene Daten sind. In EDSB/SRB (Rechtssache C-413/23 P, 4. September 2025) hat der Gerichtshof eine Nuance ergänzt: Ob Daten personenbezogen sind, wird aus der Sicht dessen beurteilt, der sie hält; pseudonymisierte Daten sind daher für einen Empfänger, der keine vernünftigen Mittel zur Re-Identifizierung hat, möglicherweise keine personenbezogenen Daten, bleiben es aber für den Verantwortlichen, der den Schlüssel hält, und der Verantwortliche muss die Menschen weiterhin über solche Empfänger informieren. Die Leitlinien 01/2025 des EDSA zur Pseudonymisierung beschreiben, wie man sie gut umsetzt.

Die Anonymisierung geht weiter: Die Daten beziehen sich nicht mehr auf eine identifizierbare Person, unter Berücksichtigung aller Mittel, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, um jemanden zu identifizieren, und dann gilt die DSGVO nicht mehr. Echte Anonymisierung ist schwer. Namen zu entfernen genügt nicht, wenn die Kombination aus Postleitzahl, Geburtsdatum und Geschlecht die meisten Menschen identifiziert oder wenn der Standortverlauf eines einzelnen Kuriers verrät, wo er wohnt. Aggregation mit Unterdrückung kleiner Fallzahlen, Generalisierung und für Statistiken Differential Privacy sind die üblichen Techniken, und das Ergebnis sollte gegen realistische Re-Identifizierungsversuche getestet werden.

Aufbewahrung und Löschung über alle Kopien hinweg

Speicherbegrenzung braucht einen Aufbewahrungsplan: für jede Datenkategorie, wie lange sie aufbewahrt wird, warum und was am Ende geschieht (Löschung, Anonymisierung oder Archivierung). Pläne funktionieren nur, wenn Systeme sie automatisch durchsetzen: TTLs auf Cache- und Key-Value-Einträgen, zeitlich partitionierte Tabellen, deren alte Partitionen gelöscht werden, Lifecycle-Regeln im Objektspeicher, Aufbewahrungseinstellungen für Logs und geplante Jobs, deren Erfolg überwacht wird.

Am schwierigsten ist die Löschung dort, wohin personenbezogene Daten durchsickern. Caches und Suchindizes brauchen explizites Entfernen und Neuindizieren, mit TTLs als Absicherung. Analytics-Speicher sollten pseudonyme Referenzen halten, damit sich Zeilen finden und löschen lassen, oder die Daten sollten schon beim Eingang anonymisiert werden. Event-Logs und Event-Sourcing-Speicher sind von Natur aus unveränderlich; die übliche Technik ist Crypto-Shredding, bei dem die Felder jeder Person mit einem eigenen Schlüssel verschlüsselt werden und der Schlüssel vernichtet wird, wie in Abschnitt 7.5 beschrieben, oder personenbezogene Daten werden aus Events herausgehalten und nur Referenzen gespeichert. Anwendungslogs sollten keine personenbezogenen Daten enthalten, die nicht benötigt werden; darauf kommt Abschnitt 8.8 zurück. Backups lassen sich meist nicht bearbeiten; das britische Information Commissioner’s Office akzeptiert, dass Daten in Backups verbleiben, bis diese nach einem festgelegten Plan überschrieben werden, sofern sie bis dahin der Nutzung entzogen sind und die Person klar erfährt, was geschehen wird; wird ein Backup jemals wiederhergestellt, müssen die Löschungen erneut angewendet werden, wofür die Liste der gelöschten IDs aufbewahrt werden muss. Schließlich müssen Auftragsverarbeiter zur Löschung angewiesen werden, da sie nur auf Weisung des Verantwortlichen handeln (Artikel 28), und andere Empfänger müssen informiert werden (Artikel 19); die Löschung muss also über deren APIs das SMS-Gateway, den Support-Desk und die Marketingplattform erreichen.