DSGVO und Privacy-by-Design im Code-Review mit Claude

1. Privacy-by-Design als technische Pflicht, nicht als Option

Artikel 25 der DSGVO verlangt, dass Datenschutz durch technische Gestaltung und durch datenschutzfreundliche Voreinstellungen sichergestellt wird, und zwar von der ersten Entwurfsentscheidung an, nicht nachträglich als Ergänzung. In der Praxis bedeutet das: Ein Entwicklerteam trägt technische Mitverantwortung dafür, dass ein neues Feature nicht mehr personenbezogene Daten verarbeitet, speichert oder überträgt, als für den konkreten Zweck erforderlich ist.

Die Herausforderung im Alltag ist, dass diese Anforderung selten explizit in einem Ticket steht. Ein Feature-Request wie Exportfunktion für Bestellhistorie hinzufügen enthält für sich genommen keinen Hinweis darauf, dass auch Zweckbindung, Aufbewahrungsfrist und Löschkonzept mitgedacht werden müssen. Genau hier kann ein systematisches Code-Review mit Claude helfen, diese Aspekte routinemäßig sichtbar zu machen, statt sie dem Zufall zu überlassen.

2. Fehlende Pseudonymisierung und Anonymisierung erkennen lassen

Ein wiederkehrendes Muster ist, dass personenbezogene Daten dort im Klartext verarbeitet oder geloggt werden, wo eine Pseudonymisierung technisch möglich wäre, etwa in Analytics-Events, Fehlerprotokollen oder Debug-Ausgaben. Claude lässt sich gezielt anweisen, jede Stelle zu identifizieren, an der Felder wie E-Mail-Adresse, Name oder IP-Adresse in ein Logging-Statement, ein Analytics-Event oder eine externe API-Anfrage einfließen, ohne dass zuvor eine Pseudonymisierung stattfindet.

Besonders aufschlussreich ist die Suche nach Log-Statements, die komplette Objekte ausgeben, etwa ein Nutzerobjekt in einer Exception-Behandlung, statt gezielt nur die für die Fehlersuche notwendigen, nicht personenbezogenen Felder. Dieses Muster entsteht häufig unbeabsichtigt, wenn während der Entwicklung ein ganzes Objekt zu Debug-Zwecken geloggt wird und die Zeile nach Abschluss der Arbeit im Code verbleibt.

# Claude Code: gezielt nach unpseudonymisierten personenbezogenen Daten suchen
claude "Durchsuche src/ nach Log-, Analytics- und Fehler-Statements, die Felder
wie email, name, ip_address, phone oder ähnliche personenbezogene Daten
im Klartext enthalten. Liste Datei, Zeile und betroffenes Feld auf und
schlage jeweils eine Pseudonymisierung oder ein Hashing-Verfahren vor."

3. Zu lange oder fehlende Aufbewahrungsfristen im Code aufspüren

Die DSGVO verlangt in Artikel 5 eine Speicherbegrenzung: personenbezogene Daten dürfen nur so lange gespeichert werden, wie es für den jeweiligen Zweck erforderlich ist. Im Code äußert sich eine Verletzung dieses Grundsatzes selten als offensichtlicher Fehler, sondern meist als Abwesenheit: eine Datenbanktabelle ohne jede Ablauflogik, ein fehlender Cronjob zur Bereinigung, oder ein Soft-Delete-Flag, das gesetzt wird, ohne dass jemals ein tatsächlicher Löschvorgang folgt.

Claude kann bei einem Datenmodell-Review gezielt danach fragen, welche Tabellen personenbezogene Daten enthalten und ob im umgebenden Code, in Migrationen oder in geplanten Jobs eine Löschlogik zu diesen Tabellen existiert. Häufig zeigt sich dabei, dass zwar ein created_at-Feld vorhanden ist, aber keine einzige Stelle im Code jemals darauf basierend etwas löscht, was ein klares Indiz für eine fehlende Umsetzung der Speicherbegrenzung ist.

4. Löschroutinen vollständig prüfen: Kaskaden und Backups nicht vergessen

Eine vorhandene Löschfunktion allein garantiert noch keine vollständige Löschung. Häufig bleiben referenzierte Datensätze in verknüpften Tabellen, in Caching-Schichten, in Suchindizes oder in asynchronen Event-Streams zurück, weil die Löschkaskade unvollständig implementiert wurde. Claude kann angewiesen werden, ausgehend von einer Löschfunktion alle Stellen im Code zu identifizieren, an denen dieselbe Entität dupliziert, gecacht oder in ein weiteres System repliziert wird.

Ein oft übersehener Bereich sind Backups und Exportdateien, die außerhalb des regulären Datenmodells liegen und deshalb von einer Löschroutine gar nicht erfasst werden. Auch wenn Claude Backup-Strategien nicht eigenständig prüfen kann, hilft eine gezielte Nachfrage im Review dabei, diese Lücke überhaupt erst sichtbar zu machen, sodass sie anschließend organisatorisch adressiert werden kann.

5. Eine konkrete Prompt-Vorlage für das DSGVO-Review

Für ein wiederholbares Review lohnt sich eine feste Prompt-Struktur, die pro Pull Request dieselben vier Fragen systematisch beantwortet: Welche personenbezogenen Daten werden neu verarbeitet? Ist eine Pseudonymisierung technisch möglich und umgesetzt? Existiert eine erkennbare Aufbewahrungsfrist? Ist die Änderung von einer bestehenden Löschroutine erfasst? Die folgende Vorlage lässt sich direkt in einen Slash-Command für Claude Code überführen.

# .claude/commands/dsgvo-review.md als Slash-Command hinterlegt
claude "/dsgvo-review $ARGUMENTS"

# Inhalt von dsgvo-review.md:
# Analysiere den Diff auf folgende vier Punkte:
# 1. Neue oder veränderte personenbezogene Datenfelder auflisten.
# 2. Prüfen, ob Pseudonymisierung/Anonymisierung technisch möglich wäre.
# 3. Prüfen, ob eine Aufbewahrungsfrist im Datenmodell oder Code erkennbar ist.
# 4. Prüfen, ob eine bestehende Löschroutine die neuen Felder/Tabellen erfasst.
# Ausgabe als Tabelle mit Feld, Fundstelle, Risiko und technischem Vorschlag.

6. Grenze zur Rechtsberatung: Was Claude nicht leisten kann

So nützlich technische Hinweise sind, Claude kann keine Rechtsberatung leisten und keine verbindliche Aussage darüber treffen, ob eine konkrete Datenverarbeitung im Sinne der DSGVO rechtmäßig ist. Fragen zur Rechtsgrundlage nach Artikel 6, zur Zulässigkeit einer Interessenabwägung oder zur Angemessenheit einer Aufbewahrungsfrist für einen bestimmten Geschäftszweck erfordern eine rechtliche Bewertung durch eine Datenschutzbeauftragte oder einen spezialisierten Juristen.

Der sinnvolle Rahmen ist deshalb eine klare Aufgabenteilung: Claude identifiziert technische Ansatzpunkte und macht sie im Code-Review sichtbar, während die rechtliche Einordnung, ob ein gefundenes Muster tatsächlich einen Verstoß darstellt und welche Frist konkret angemessen ist, bei der Rechtsabteilung oder externen Beratung verbleibt. Diese Trennung sollte im Team explizit kommuniziert werden, damit ein technischer Hinweis nicht fälschlich als rechtliche Freigabe missverstanden wird.

7. Integration in den bestehenden Review-Prozess

Damit ein DSGVO-Review nicht bei jedem Pull Request erneut manuell angestoßen werden muss, bietet sich eine Kennzeichnung per Label oder Pfadfilter an: Änderungen an Verzeichnissen mit Nutzerdaten, Zahlungsinformationen oder Kommunikationsdaten lösen automatisch den zusätzlichen Review-Schritt aus, während reine Frontend-Änderungen ohne Datenbezug ihn nicht durchlaufen müssen. Das hält den Mehraufwand gezielt auf die Bereiche begrenzt, in denen er tatsächlich relevant ist.

Die Ergebnisse sollten dokumentiert und nicht nur im Pull-Request-Kommentar verworfen werden, insbesondere bei größeren Vorhaben, die später ohnehin eine Datenschutz-Folgenabschätzung benötigen. Ein archiviertes Claude-Review kann dabei als technische Vorarbeit dienen, auf die eine Datenschutzbeauftragte im Rahmen der Folgenabschätzung zurückgreift, statt die technische Analyse komplett neu beginnen zu müssen.

8. Ein Beispiel aus der Praxis: unbegrenzte Aufbewahrung in einer Support-Tabelle

In einem realistischen Szenario fügt ein Pull Request eine neue Tabelle support_tickets hinzu, die Name, E-Mail-Adresse und den vollständigen Nachrichtenverlauf eines Supportvorgangs speichert. Weder das Datenmodell noch der begleitende Code enthalten eine Angabe darüber, wie lange diese Daten aufbewahrt werden sollen. Ein Standard-SAST-Scanner meldet hier keinen Treffer, weil syntaktisch alles korrekt ist.

Claude kann bei einem gezielten DSGVO-Review genau diesen fehlenden Zeitbezug benennen und konkret vorschlagen, ein resolved_at-Feld zu ergänzen und einen geplanten Job zu implementieren, der abgeschlossene Tickets nach einer im Team festzulegenden Frist automatisch löscht oder anonymisiert. Die konkrete Fristlänge selbst muss weiterhin fachlich und rechtlich festgelegt werden, aber der technische Lösungsvorschlag verkürzt den Weg dorthin erheblich.

9. Checkliste für Entwicklerteams und Fazit

Eine kompakte Checkliste für den Alltag: Bei jeder neuen Tabelle mit personenbezogenen Daten prüfen, ob eine Aufbewahrungsfrist definiert ist. Bei jedem neuen Logging- oder Analytics-Aufruf prüfen, ob eine Pseudonymisierung möglich wäre. Bei jeder neuen Löschfunktion prüfen, ob Caches, Suchindizes und verknüpfte Tabellen mit erfasst sind. Diese drei Punkte lassen sich gut als wiederkehrender Claude-Prompt im Review-Workflow verankern.

Claude ersetzt keine Datenschutzbeauftragte und keine Rechtsberatung, verkürzt aber deutlich den Weg von einer vagen Ahnung, dass ein Feature datenschutzrechtlich relevant sein könnte, zu einer konkreten, technisch begründeten Liste von Fundstellen. Genau diese Vorarbeit ist es, die Privacy-by-Design im Entwickleralltag praktisch umsetzbar macht, statt es als abstraktes Rechtsprinzip auf der Ticket-Ebene stehen zu lassen.

10. Zusammenfassung

11. FAQ: DSGVO und Privacy-by-Design im Code-Review: Das Wichtigste auf einen Blick