Datenschutz durch Technikgestaltung ist eine rechtliche Anforderung und im Softwarebau vor allem eine Frage des Zeitpunkts. Nach der Fertigstellung eingebauter Datenschutz ist teuer und meist unvollständig; früh eingebauter kostet fast nichts.
Was die Anforderung verlangt
Der Verantwortliche hat bereits zum Zeitpunkt der Festlegung der Mittel und bei der Verarbeitung selbst geeignete technische und organisatorische Massnahmen zu treffen, um die Grundsätze wirksam umzusetzen.
Hinzu kommt die Anforderung datenschutzfreundlicher Voreinstellungen: Standardmässig dürfen nur die Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind.
Für ein Produkt heisst das konkret: Die Voreinstellung ist die sparsamste Variante, nicht die funktionsreichste. Wer mehr Datenverarbeitung will, schaltet sie ein — nicht umgekehrt.
Die Entscheidungen, die früh fallen
Drei Festlegungen prägen den gesamten späteren Aufwand und sind nachträglich schwer zu ändern.
Erstens das Datenmodell: Welche Felder werden überhaupt erhoben. Jedes Feld, das nicht existiert, muss nicht geschützt, nicht gelöscht und nicht in einer Auskunft ausgewiesen werden. Die wirksamste Massnahme ist, weniger zu erheben.
Zweitens die Trennung der Mandanten. Wird sie in der Datenbank erzwungen oder in der Anwendung gefiltert. Der Unterschied entscheidet darüber, ob ein einzelner Programmierfehler zu einem Datenabfluss führt.
Drittens die Region. Wo liegen Datenbank, Sicherungen, Protokolle und die Werkzeuge des Supports. Ein Wechsel später bedeutet eine Migration mit Ausfallzeit.
Löschbarkeit muss im Modell vorgesehen sein
Die Anforderung, ein Konto samt Daten löschen zu können, klingt selbstverständlich und ist es im Datenmodell nicht. Wo Daten über viele Tabellen verteilt sind, in Protokollen stehen, in Analysewerkzeugen liegen und in Sicherungen fortbestehen, ist Löschung ein Vorhaben.
Früh eingeplant bedeutet es: Ein Feld, das die Zugehörigkeit zu einer Person eindeutig macht, konsequent durchgezogen — und eine Liste aller Orte, an denen personenbezogene Daten landen können.
Zu Sicherungen: Eine sofortige vollständige Löschung ist bei laufenden Backups technisch nicht möglich. Das ist unproblematisch, wenn die Aufbewahrungsdauer benannt und begründet ist, und ein Mangel, wenn die Erklärung etwas anderes behauptet.
Protokolle sind die unterschätzte Datenquelle
Anwendungsprotokolle enthalten regelmässig personenbezogene Daten, ohne dass das beabsichtigt war: Adressen in Anfragepfaden, E-Mail-Adressen in Fehlermeldungen, vollständige Anfrageinhalte in Fehlerberichten.
Zwei Massnahmen genügen meist. Erstens eine Filterung, die bekannte Felder unkenntlich macht, bevor sie ins Protokoll gelangen. Zweitens eine begrenzte Aufbewahrungsdauer, die tatsächlich durchgesetzt wird.
Pseudonymisierung und Auswertung
Wo Daten für Auswertungen gebraucht werden, lohnt die Frage, ob dafür der Personenbezug nötig ist. Häufig genügt eine aggregierte oder pseudonymisierte Form.
Pseudonymisierung hebt den Personenbezug nicht auf — die Daten bleiben personenbezogen, solange eine Zuordnung möglich ist. Sie ist aber eine anerkannte Schutzmassnahme und verringert das Risiko im Fall eines unbefugten Zugriffs erheblich.
Was das im Alltag der Entwicklung bedeutet
Der wirksamste Einzelschritt ist eine Frage im Prüfprozess neuer Funktionen: Werden hier personenbezogene Daten erhoben, verarbeitet oder weitergegeben, und wenn ja, welche und wohin.
Diese eine Frage verhindert das häufigste Muster — dass ein Drittdienst eingebunden wird, ohne dass jemand die Auftragsverarbeitung, die Datenschutzerklärung oder das Verzeichnis anpasst.
Sie kostet Sekunden und ersetzt einen erheblichen Teil dessen, was sonst in einer nachträglichen Prüfung aufwendig aufgearbeitet werden muss.