Entwickler, die nach GDPR-Code-Review-Prüfungen suchen, wollen in der Regel eines: eine kurze Liste der rechtlichen Pflichten, die tatsächlich in einem normalen Pull Request verletzt werden können – nicht ein vollständiges Handbuch für ein Datenschutzprogramm. Die Verordnung betrifft hauptsächlich Prozesse, Aufzeichnungen und organisatorische Maßnahmen. Ein kleiner, aber konstanter Teil der Pflichten betrifft den Code: Was gespeichert wird, wie lange es behalten wird, ob ein Löschpfad alle Kopien erreicht, welche Standardwerte preisgegeben werden, wie die Verarbeitung gesichert ist und wo Daten gehostet werden.
Dieser Leitfaden ist diese Übersicht. Er ist bewusst keine Anleitung zur Behebung eines einzelnen Speicherungs-Fehlers (diese findet sich unter /guides/catching-a-gdpr-retention-bug-in-code-review) und kein vertiefter Einblick in Kontrollen (diese sind unter /frameworks/gdpr zu finden). Es ist die Checkliste für den Code-Review: Welche Artikel sind zu nennen, wie sieht die Änderung aus und was kann ein Prüfer fragen, ohne zum Datenschutzbeauftragten zu werden.
Die Artikel, die sich in einem Diff widerspiegeln
Art. 5(1)(c) Datenminimierung: Eine Änderung beginnt damit, mehr personenbezogene Daten zu sammeln oder zu protokollieren, als für den Zweck erforderlich ist (vollständige Anforderungs-Bodies, vollständige Identitätsdatensätze, die in einen Nebenspeicher kopiert werden). Art. 5(1)(e) Speicherbegrenzung: Ein neuer Speicher oder Cache für personenbezogene Daten wird ohne Löschfrist eingeführt oder ein Löschfenster wird ohne Grund erweitert. Art. 17 Recht auf Löschung: Ein Löschpfad erreicht nicht Cache, Suchindex, Analytics-Export oder eine Kopie beim Auftragsverarbeiter. Art. 25 Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen: Ein personenbezogenes Feld wird standardmäßig sichtbar oder für alle Benutzer freigegeben, oder eine schützende Voreinstellung wird deaktiviert. Art. 32 Sicherheit der Verarbeitung: Verschlüsselung, Zugriffskontrolle oder Integritätsmaßnahmen für personenbezogene Daten werden geschwächt (TLS-Mindeststandard gesenkt, Token im Klartext gespeichert, Admin-Zugriff geöffnet). Art. 44 Kapitel zu Übermittlungen: Personenbezogene Daten werden in eine neue Region oder an einen Auftragsverarbeiter in einem Drittland übermittelt, ohne dass die von Ihrem Programm erwartete Übermittlungsgrundlage vorliegt.
Diese Erklärungen sind in einfacher Sprache für Entwickler formuliert, nicht im Wortlaut der Verordnung. Wenn ein Befund einen Artikel zitiert, ist dies ein Signal an den Autor und den Datenschutz-Ansprechpartner, keine Feststellung, dass die Verarbeitung rechtswidrig ist.
Praktisches Beispiel: Datenschutz durch Voreinstellungen für "Support-Konvenienz" deaktiviert
Ein Support-Team möchte Tickets schneller bearbeiten. Ein Entwickler erstellt einen Pull Request, der die Kundenprofil-API so ändert, dass alle authentifizierten Mitarbeiterrollen standardmäßig vollen Namen, E-Mail, Telefonnummer und die letzten vier Ziffern der Zahlungsdaten im Standard-Listen-Endpoint erhalten – nicht nur bei einer expliziten Anfrage mit "expand=pii". Die Änderung ist klein: Ein Serializer-Flag wird von false auf true gesetzt. Die Tests werden aktualisiert, um die erweiterte Nutzlast zu erwarten. Im Code-Review wird über die Antwortgröße und Cache-Header diskutiert. Nichts sieht wie ein Sicherheitsfehler aus; die Authentifizierung funktioniert weiterhin.
Betroffen ist Art. 25 Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen: Personenbezogene Daten werden nun standardmäßig für einen größeren Kreis interner Nutzer freigegeben als in der vorherigen Least-Privilege-Konfiguration. Die sicherere Variante behält die enge Voreinstellung bei und erfordert eine explizite, geprüfte Erweiterung für Support-Tools. Dies ist ein anderer Fehlerfall als der Speicherungs-Fehler (Art. 5(1)(e) bei einem neuen Speicher ohne Löschfrist) oder ein reines Minimierungsbeispiel für die Protokollierung (Art. 5(1)(c) bei Anforderungs-Bodies). Ein Compliance-bewusster Review verweist auf Art. 25 (und oft auf Art. 5(1)(c) als unterstützendes Prinzip) im PR, solange das Flag noch einfach rückgängig zu machen ist.
Was im Review gefragt werden kann, ohne zum Datenschutzbeauftragten zu werden
Bei jeder Änderung, die personenbezogene Daten betrifft: Welche Felder sind neu, wer kann sie standardmäßig einsehen, wie lange sie existieren und ob ein Lösch- oder Exportpfad sie noch erreicht. Bei Änderungen von Region oder Anbieter: Wohin gehen die Daten und hat der Datenschutz diesen Auftragsverarbeiter oder diese Übermittlung bereits erfasst. Bei "Bereinigungs"-PRs: Haben wir Verschlüsselung, Zugriffsprüfungen oder Audit-Logs entfernt, die personenbezogene Daten schützten (Art. 32 im weiteren Sinne).
Sie müssen die Verordnung nicht zitieren. Sie müssen den Merge verweigern, wenn die Antwort "unbekannt" lautet, bis jemand den Datenschutz-Schritt übernimmt oder die sicherere Voreinstellung wiederherstellt.
Wo heygrc ins Spiel kommt und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen, einschließlich der GDPR, wenn diese aktiviert ist, und den Artikel zu benennen, den eine Änderung möglicherweise betrifft (z. B. Art. 25 bei einer erweiterten Standard-Nutzlast). Es entscheidet nicht über die Rechtsgrundlage, führt keine Datenschutz-Folgenabschätzungen durch, pflegt kein Verarbeitungsverzeichnis, genehmigt keine Übermittlungen oder ersetzt Ihren Datenschutzbeauftragten. Ein grüner Review ist keine behördliche Freigabe.
Fehler- und Qualitätsprüfer bleiben im selben PR. Sie fragen, ob der Code korrekt ist. GDPR-Fragen prüfen, ob die Pflichten im Umgang mit personenbezogenen Daten weiterhin eingehalten werden. Führen Sie beides durch.