Die DSGVO tritt am 25. Mai 2018 in Kraft. Juristen kümmern sich um Einwilligungen und Verträge. Aber wer kümmert sich um die technische Umsetzung? Datenverschlüsselung at Rest, Audit-Logs, Recht auf Löschung in einem System mit 30 verknüpften Tabellen — das ist unsere Welt.
Was die DSGVO tatsächlich technisch erfordert¶
Artikel 25 spricht von „Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen” (Privacy by Design and by Default). Artikel 32 verlangt „geeignete technische und organisatorische Maßnahmen”. Was bedeutet das in der Praxis? Die Verordnung ist bewusst vage — sie schreibt keine konkreten Technologien vor. Aber die Auditpraxis wird sich schnell etablieren.
Aus unserer Erfahrung bei der Vorbereitung von Enterprise-Systemen auf die DSGVO identifizieren wir 5 zentrale technische Bereiche, die jedes IT-System, das personenbezogene Daten verarbeitet, adressieren muss.
1. Verschlüsselung — At Rest und In Transit¶
In Transit: TLS 1.2 mindestens, idealerweise TLS 1.3. Keine selbstsignierten Zertifikate in der Produktion. mTLS für Service-to-Service-Kommunikation. Let’s Encrypt eliminiert die Ausrede „Zertifikate sind teuer”.
At Rest: AES-256 für Datenbanken und Speicher. Azure SQL hat Transparent Data Encryption (TDE) standardmäßig. PostgreSQL erfordert pgcrypto oder Dateisystem-Level-Verschlüsselung. Vergessen Sie nicht die Backups — verschlüsselte Produktion und unverschlüsseltes Backup ist wie eine verschlossene Tür mit offenem Fenster.
2. Pseudonymisierung und Anonymisierung¶
Die DSGVO erwähnt Pseudonymisierung ausdrücklich als empfohlene Maßnahme. Der Unterschied ist entscheidend: Pseudonymisierung ist umkehrbar (ein Schlüssel existiert), Anonymisierung ist unumkehrbar (Daten hören auf, personenbezogene Daten zu sein).
In der Praxis: Die Produktionsdatenbank verwendet pseudonymisierte Identifikatoren. Die Mapping-Tabelle (Pseudonym → echte Identität) liegt in einem separaten Speicher mit strengerem Zugang. Analysesysteme arbeiten mit anonymisierten Daten — k-Anonymity, l-Diversity für statistische Ausgaben.
3. Recht auf Löschung — Technischer Horror¶
Artikel 17 — Recht auf Vergessenwerden. Klingt einfach. Die Umsetzung ist ein Albtraum. Ein Benutzer im CRM-System hat Einträge in 15 Tabellen, 3 Microservices, 2 Analysesystemen, 5 Backups und einem Elasticsearch-Index.
Unser Ansatz: Data Subject Registry — zentrales Verzeichnis aller Orte, an denen personenbezogene Daten eines bestimmten Betroffenen gespeichert sind. Jedes System implementiert einen DELETE-Endpoint. Der Orchestrator durchläuft das Verzeichnis und ruft die Löschung in der richtigen Reihenfolge auf (respektiert Foreign Keys).
Für Backups: nicht aus Backups löschen (technisch unmöglich bei Tape/Immutable Storage). Stattdessen „Crypto Shredding” — Daten in Backups sind mit einem Pro-Subject-Schlüssel verschlüsselt. Schlüssel löschen = Daten sind unlesbar.
4. Audit-Logs und Nachweisbarkeit¶
Die DSGVO erfordert die Fähigkeit, Compliance nachzuweisen. Das bedeutet Protokollierung: wer auf welche personenbezogenen Daten zugegriffen hat, wann, warum und was damit gemacht wurde. Aber Vorsicht — das Audit-Log selbst enthält personenbezogene Daten (wer = Mitarbeiter, was = Daten des Betroffenen).
Lösung: strukturierte Audit-Logs mit Verweis auf den Betroffenen (keine Kopie der Daten). Zentrales Log-Management (ELK Stack, Splunk). Unveränderlicher Speicher — Logs können nicht rückwirkend geändert werden. Log-Aufbewahrung entspricht dem Zweck — typischerweise 1-3 Jahre.
- Jeder API-Aufruf protokolliert: user_id, action, resource_type, resource_id, timestamp
- Sensible Werte werden nicht protokolliert — nur Referenzen
- Export von Logs für die Datenschutzbehörde im maschinenlesbaren Format
5. Datenportabilität — Maschinenlesbarer Export¶
Artikel 20 — Betroffene haben das Recht, ihre Daten in einem „strukturierten, gängigen und maschinenlesbaren Format” zu erhalten. In der Praxis: JSON- oder CSV-Export aller personenbezogenen Daten. API-Endpoint, der ein vollständiges Datenpaket für einen bestimmten Betroffenen generiert.
Implementieren Sie dies als asynchrone Operation — die Generierung des Exports für Benutzer mit umfangreicher Historie kann Minuten dauern. E-Mail-Benachrichtigung mit Download-Link. Link mit begrenzter Gültigkeit (24-48h) und einmaliger Nutzung.
Consent Management — Die technische Seite¶
Einwilligungen sind nicht nur Checkboxen auf Websites. Technisch benötigen Sie: Einwilligungsdatensätze mit Zeitstempel und Textversion, API zur Überprüfung gültiger Einwilligungen vor der Verarbeitung, Mechanismus zum Widerruf der Einwilligung mit Weitergabe an alle Systeme.
Consent Store als separater Microservice. Jede Verarbeitung personenbezogener Daten überprüft zunächst eine gültige Einwilligung. Widerrufene Einwilligung löst ein Event aus — Downstream-Systeme reagieren mit dem Stopp der Verarbeitung.
Privacy by Design in der Praxis¶
Datenminimierung: Erfassen Sie nur, was Sie benötigen. Jedes Feld in der Datenbank sollte einen dokumentierten Zweck haben. Geburtsdatum statt Personalausweisnummer (wenn Sie keine Personalausweisnummer benötigen). E-Mail statt Telefonnummer (wenn Sie nicht anrufen werden).
Datenaufbewahrung: automatische Datenlöschung nach Ablauf des Zwecks. Bestellung erfüllt → personenbezogene Daten nach gesetzlicher Aufbewahrungsfrist löschen (typischerweise 10 Jahre für Buchhaltungsbelege). Scheduler, der täglich abgelaufene Datensätze überprüft.
Die DSGVO ist kein Projekt — sie ist ein Prozess¶
Die technische Umsetzung der DSGVO ist keine einmalige Aufgabe. Sie ist ein architektonisches Prinzip, das jedes neue System und jede Änderung an bestehenden Systemen durchdringen muss. Privacy by Design bedeutet, von der ersten Codezeile an an Datenschutz zu denken — nicht ihn als Nachgedanken vor dem Audit hinzuzufügen.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns