Privacy by Design

Privacy by Design (GDPR)

1) Worum es geht und warum

Privacy by Design (PbD) ist das Prinzip, nach dem Privatsphäre von Anfang an in ein Produkt eingebettet ist: in Geschäftsanforderungen, Architektur, Code, Prozesse und Betrieb. In Bezug auf die DSGVO manifestiert sich dies in „privacy by design and by default“ (Minimierung der Gebühren, Standardeinstellungen - so privat wie möglich, Transparenz und Rechenschaftspflicht).

• Minimierung der Erhebung und Verarbeitung personenbezogener Daten (PD).
• Gewährleistung der Rechtmäßigkeit, Transparenz, Korrektheit, Begrenzung der Ziele und Fristen.
• Reduzieren Sie Risiken (technisch und rechtlich), vereinfachen Sie Audits und die Nachweisbarkeit von Compliance.

2) Rollen, Rechtsgrundlagen und Grundsätze der DSGVO

2. 1 Rollen

Controller: Definiert die Zwecke/Mittel der Verarbeitung.
Prozessor: Verarbeitet die PD im Auftrag des DPA-Auftragsverarbeiters.
Betroffene Person (Data Subject): natürliche Person, zu der die PD gehört.
DSB (Datenschutzbeauftragter): auf Anfrage - unabhängige Kontrolle und Beratung.

2. 2 Rechtsgrundlage (Auswahl und Dokumentation)

Zustimmung, Vertrag, berechtigtes Interesse, gesetzliche Verpflichtung, lebenswichtige Interessen, öffentliche Aufgabe. Für jeden - den Zweck, die Daten, die Aufbewahrung, die Möglichkeit des Widerrufs (für die Zustimmung).

2. 3 Grundsätze der Verarbeitung (Art. 5)

Legalität, Fairness, Transparenz

Zweckbindung

Datenminimierung

Genauigkeit

Speichereinschränkung

Integrität und Vertraulichkeit

Rechenschaftspflicht (accountability) - die Fähigkeit, die Einhaltung zu beweisen.

3) PbD-Prozess im SDLC (Referenzrahmen)

1. Einleitung: Formulierung der Verarbeitungszwecke und Rechtsgrundlagen, Zweck des Dateneigentümers und DPO-Punktes.
2. Die Kartierung der Daten (Data Mapping): die Quellen → die Felder → das vertrauliche Modell → wohin fließen → wer liest → wo → die Frist bewahrt werden.
3. Risikobewertung/DPIA: LINDDUN-Modell für Bedrohungen der Privatsphäre, Folgenabschätzung, Minderungsmaßnahmen.
4. Architektonische Lösungen: Auswahl von Minimierungs-, Pseudonymisierungs-, Verschlüsselungs- und Abgrenzungsschemata.
5. Anforderungen an UX/Zustimmungen/Benachrichtigungen: verständliche Texte, granular consent, default-Einstellung.
6. Implementierung: Private Defaults, sichere Telemetrie, Protokollierung ohne Geheimnisse/PII.
7. Verifizierung: Datenschutztests, statische Analyse, private Einheitentests, DPIA-Protokolle.
8. Betrieb: DSAR-Prozesse, Retention und Löschung, Incident Monitoring, Lieferantenrevue.
9. Regelmäßige Überprüfung: re-DPIA bei Änderung der Ziele/Technologien.

4) PbD-Konstruktionsmuster

4. 1 Minimierung und Zerlegung

Sammeln Sie nur die notwendigen Felder; progressive Profilierung anwenden.
ID und Inhalt trennen: Kommunikationsschlüssel getrennt aufbewahren (Token/Referenz).

4. 2 Pseudonymisierung und Anonymisierung

Pseudonymisierung: Speichern Sie die reale ID separat; die Arbeitsschicht sieht das Token.
Anonymisierung: Verwenden Sie k-Anonymität, l-Vielfalt, t-Schließung; Für die Analyse - differentielle Privatsphäre (ε -budget).

4. 3 Zugriffskontrolle und Rollenteilung

PoLP, ABAC/RBAC, segregation of duties, separate Loops für Admins und Analysten.
Die. Maßnahmen: mTLS, SSO/OIDC, Scoped-Token, temporäre Accounts für den PD-Zugang.

4. 4 Verschlüsselung und Isolierung

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Separate Schlüssel pro Mieter/Dataset; Krypto-Löschung für das „Recht auf Vergessen“.

4. 5 Retention und Entfernung

Explizite Politik TTL pro Bereich/Ziele; Auto-Purge in Pipelines; „zweiphasige“ Entfernung (logisch → physisch).
Für Backups gibt es separate Schlüssel und kurze Speicherfenster für persönliche Snapshots.

4. 6 Private Telemetrie und Logging

Standardmäßig ohne PII; Token/Hash mit Salz verwenden.
Maskierung/Tokenisierung empfindlicher Felder auf dem Producer.

4. 7 UX Privatsphäre und Zustimmung

Granular consent nach Kategorien (Analytik, Marketing, Personalisierung).
„Private Defaults“: Alles nicht kritisch - aus, bis man zugestimmt hat.
Klare Option „Einwilligung widerrufen“ und Just-in-Time-Benachrichtigung bei neuer Nutzung.

5) DPIA und LINDDUN (kurz)

DPIA (Data Protection Impact Assessment): erforderlich bei hohem Risiko (groß angelegte Überwachung, Bewertung, neue Technologie). Besteht aus Beschreibung der Verarbeitung, Notwendigkeit/Verhältnismäßigkeit, Risikobewertung, Minderungsmaßnahmen.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Für jede Bedrohung gibt es Gegenmaßnahmen (Minimierung, Pseudonymisierung, DP, Transparenz, Zustimmungsmanagement, Audit).

6) Grenzüberschreitende Übertragungen

Ermitteln Sie die Speicher-/Zugriffsorte der Lieferanten.
SCC (Standardvertragsklauseln) verwenden und Transfer Impact Assessment durchführen.
Techniker: Ende-zu-Ende-Verschlüsselung, Client-Kryptographie für besonders sensible Daten, Einschränkung des Fernzugriffs.

7) Lieferanten und Verarbeiter (Vendor Management)

DPA/verschachtelte Verarbeiter, technische und organisatorische Maßnahmen, Unterverarbeiter unter Kontrolle.
Regelmäßige Reviews und Audits; das Recht auf Inspektion; Exit/Migrationsplan (Datenexport).

8) Betroffenenrechte (DSAR)

Zugriff, Berichtigung, Löschung, Einschränkung, Portabilität, Widerspruch, nicht Gegenstand von AADM (Profiling/Automatisierung) zu sein.
SLA und Automatisierung: Anfrage-Tracking, Identitätsnachweis, Antwortprotokoll.
Technische Haken im Produkt: schnelle Suche und Export nach ID; kaskadierte Entfernung durch Retentionen.

9) Automatisierte Entscheidungen und Profiling (Art. 22)

Wenn Entscheidungen mit „signifikanter Wirkung“ von einer Maschine getroffen werden - um das Recht auf menschliches Eingreifen, Erklärbarkeit und Transparenz von Merkmalen zu gewährleisten.
Log-Pfad und Versionierung von Modellen; Beschwerdeverfahren.

10) Verarbeitungssicherheit (Art. 32) und Vorfälle (Art. 33/34)

Risikoorientierte Maßnahmen: Verschlüsselung, Integrität, Resilienz, Recovery-Pläne (RTO/RPO).
PD-Vorfälle: Erkennungsprozess → Triage → Risikobewertung → Benachrichtigung der Regulierungsbehörde ≤ 72 Stunden (falls erforderlich) und Probanden (bei hohem Risiko).
Separates Playbook, Kontaktliste DPO/Anwälte, Benachrichtigungsvorlagen.

11) Datenschutz und ML/Analytik

Data Governance Sets: Datenleitung, Lizenzen/Grundlagen, Einwilligungen.
Techniken: differenzielle Privatsphäre, föderiertes Lernen, sichere Aggregation, Minimierung von Daten.
Schutz vor Angriffen: Membership/Model Inversion - regelmäßige Bewertung von Lecks, ε, Rauschen/Clip.
Synthetische Daten - nur mit der Überprüfung der fehlenden Wiederherstellung von Personen.

12) Architekturdiagramme (Muster)

12. 1 „Zweikreis“ -Identifikationsarchitektur

Kontur A (PDS - Personal Data Store): Real Identification Data (RID), Zugriff - stark eingeschränkt, Schlüssel/Verschlüsselung/Audit.
Kontur B (Operational): Geschäftsdaten mit Token; Kommunikation über einen Token-Broker mit Limits und Audits.

12. 2 Zustimmungsbus (Consent Service)

Ein zentralisierter Dienst, der Versionen von Einwilligungen und Historie speichert.
SDK: 'can _ use (category, purpose)' - entscheidet im laufenden Betrieb; alles wird protokolliert.

12. 3 Retentionsrichtlinien als Code

YAML-Konfiguration: → Feldentität → TTL → Aktion bei Ablauf (Anonymisierung/Löschung/Vergröberung).
Der Planer führt den Job aus, das Reporting liegt dem DSB vor.

13) Mini-Rezepte

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Dokumentation und Rechenschaftspflicht

ROPA (Records of Processing Activities) - Register der Vorgänge: Zweck, Rechtsgrundlage, Kategorien von Daten/Subjekten, Übermittlungen, Aufbewahrungsfristen, Maßnahmen.
Richtlinien: Datenschutz, Cookies, Informationshinweise im Produkt (in verständlicher Sprache).
Mitarbeiterschulung und jährliche Revue.

15) Häufige Fehler

Sammlung „nur für den Fall“ und Lagerung „für immer“.
Zustimmung als alleinige Grundlage, obwohl Vertrag/berechtigtes Interesse angemessen ist.
„Leere“ Cookie-Banner ohne echte Schalter.
Keine Datenabbildung und keine DSAR-Bereitschaft.
Protokolle mit PII, ungesicherte Backups, Mischung aus RID und Betriebsdaten.
Keine Lieferantenkontrolle und keine grenzüberschreitenden Transfers.

16) Checklisten

• Der Zweck der Verarbeitung und die Rechtsgrundlage sind festgelegt; aktualisiert ROPA.
• Datenmapping und DPIA (falls erforderlich) durchgeführt.
• Minimierung, Pseudonymisierung, Verschlüsselung (unterwegs/im Ruhezustand) implementiert.
• Zustimmungen - granular, mit verständlicher UX; Defaults sind privat.
• Retentionsrichtlinien als Code konfiguriert; Löschung/Anonymisierung geprüft.
• Logs/Telemetrie - ohne PII; Maskierung aktiviert.
• DSAR-Hooks und Export vorbereitet.
• Teamschulung und Genehmigung durch den DSB durchgeführt.

• Vierteljährliche Überprüfung der Retentionen und Rechtsgrundlagen.
• Regelmäßige Prüfung von Prozessoren/Unterprozessoren.
• Überwachung von Vorfällen und Alarmbereitschaft ≤ 72 Stunden
• Überarbeitung der DPIA bei Prozess-/Technologieänderungen.
• Speicherung von Compliance-Artefakten (DPIA, ROPA, Testberichte).

17) FAQ

F: Ist es möglich, den Einwilligungen vollständig „zu entkommen“?
A: Manchmal ja (Vertrag/gesetzliche Verpflichtung/berechtigtes Interesse), aber nur bei strikter Notwendigkeit und bei Abwägung der Interessen. Marketing und unkritische Analytik - erfordern meistens Zustimmung.

F: Reicht die Pseudonymisierung aus?
A: Nein, es sind immer noch persönliche Daten. Um den Anwendungsbereich der DSGVO zu verlassen, ist eine zuverlässige Anonymisierung erforderlich (überprüft auf die Unmöglichkeit einer erneuten Identifizierung).

F: Was ist mit ML und Personalisierung?
A: Minimieren Sie Fiches, verwenden Sie DP/Federated-Ansätze, protokollieren Sie Entscheidungen, sichern Sie das Recht auf menschliches Eingreifen und verzichten Sie auf Profiling.

F: Was tun bei einem Konflikt zwischen Geschäft und Privatsphäre?
A: Umgestaltung der Sammlung (progressives Profiling), Umstellung auf Aggregate/Synthetik, Neubewertung der Rechtsgrundlage, Angebot einer Option ohne Tracking.

• „Management von Geheimnissen“
• „At Rest Verschlüsselung“
• „Verschlüsselung im Transit“
• „Audit und unveränderliche Protokolle“
• „Signieren und Verifizieren von Anfragen“
• „Schlüsselmanagement und Rotation“