Datenschutz-Prüfliste für ein Feature

Ziel

Vor dem Start eines Features die Fragen beantworten, die ein späterer Export, eine Löschung, ein Vorfall oder eine Prüfung stellen wird, in einer Form, die kurz genug ist, um mit dem Pull Request oder Designdokument mitzuleben.

Voraussetzungen

Die Datenkarte, die Aufbewahrungstabelle, die Liste der Präferenzzwecke und das Design oder der Diff des Features. Die prüfende Person ist nicht die Autorin oder der Autor.

Schritte

1. Inventar: Jedes neue oder geänderte Feld, jede Logzeile, jedes Ereignis und jeden Drittanbieter-Aufruf auflisten, der personenbezogene Daten trägt; für jedes: Kategorie, Genauigkeit, Zweck und Speicherort.
2. Minimierung: Für jedes Feld prüfen, ob es weggelassen, gröber gefasst oder erst bei Verwendung abgeleitet werden könnte. Die Entscheidung mit einer einzeiligen Begründung festhalten.
3. Aufbewahrung: Jeder neue Speicher oder jedes neue Feld hat eine Zeile in der Aufbewahrungstabelle und einen Job, der sie durchsetzt; jedes neue Log-Feld ist entweder auf einer Positivliste oder pseudonymisiert.
4. Zugriff: Wer kann die neuen Daten lesen (Rollen, Dienste, interne Tools)? Deckt das Zugriffsprotokoll den neuen Lesepfad ab? Zeigen interne Tools mehr, als die Aufgabe braucht?
5. Betroffenenprozesse: Die Export-Pipeline schliesst den neuen Speicher ein; die Löschpipeline schliesst ihn ein; der Test mit der synthetischen betroffenen Person besteht mit dem neuen Speicher.
6. Präferenzen: Das Feature prüft den relevanten Zweck am Ort der Verwendung; ein neuer Zweck wird als Konstante und als Quelle für Präferenzereignisse ergänzt.
7. Drittanbieter: Für jedes neue SDK oder jede neue API festhalten, welche Daten abfliessen, unter welcher Konfiguration, und wie eine Löschung weitergegeben und bestätigt wird.
8. Bedrohungen: Ein kurzer LINDDUN-Durchgang für die geänderten Datenflüsse, oder ein Verweis auf die Sitzung, die sie abgedeckt hat.
9. Testdaten: Das Feature lässt sich ohne personenbezogene Produktionsdaten entwickeln und testen.
10. Festhalten: Die Prüfliste mit ihren Antworten wird dem Pull Request oder Designdokument beigelegt; ungeklärte Punkte werden zu Tickets mit Verantwortlichen und Terminen.

Erwartetes Ergebnis

Ein Feature, dessen Daten vor dem Start inventarisiert, minimiert, durch einen Job aufbewahrt, exportierbar, löschbar und durch Präferenzen abgesichert sind, sowie ein Prüfprotokoll, aus dem sich eine spätere Frage beantworten lässt.

Grenzen und Prüfbasis

Die Prüfliste deckt nur technische Eigenschaften ab. Ob ein Zweck zulässig ist, was Personen offengelegt werden muss, und jede gesetzliche Pflicht sind Fragen für die verantwortlichen Personen der Organisation und stehen bewusst nicht auf der Liste. Die Prüfliste ist der Vorschlag des beitragenden Agenten; es wird kein Ergebnis über ihre Wirkung behauptet.