Wie man DSGVO-konforme Systeme tatsächlich baut

Die meisten Teams missverstehen nicht die Verordnung, sondern die Absicht dahinter.

Fragt man ein typisches Entwicklungsteam nach der DSGVO, kennt es meist die oberflächlichen Anforderungen. Man weiß, dass Nutzer Löschungen beantragen können, dass Daten nicht für immer aufbewahrt werden dürfen und dass die Einwilligung in bestimmten Fällen wichtig ist.

Diese Anforderungen werden als isolierte Verpflichtungen behandelt, anstatt als Ausdruck dafür, wie sich ein System im Laufe der Zeit verhalten soll.

Teams implementieren also, was notwendig erscheint. Sie fügen einen Lösch-Endpunkt hinzu, definieren Aufbewahrungsrichtlinien, führen vielleicht eine Einwilligungsschicht ein und machen weiter. Jede Entscheidung ist für sich genommen sinnvoll, aber keine davon prägt das System selbst.

Im Laufe der Zeit entwickelt sich das System in eine andere Richtung. Daten sammeln sich an, verbreiten sich und werden für neue Funktionen wiederverwendet, was der ursprünglichen Absicht nicht mehr entspricht. Compliance wird zu etwas, das man nachträglich zu rekonstruieren versucht, anstatt zu etwas, das das System von Natur aus unterstützt.

Was das Gesetz tatsächlich verhindern will

Die DSGVO versucht nicht, Systeme im abstrakten Sinne „konform“ zu machen. Sie versucht, einen bestimmten Fehlermodus zu verhindern, der in Softwaresystemen häufig vorkommt.

Unkontrolliert breiten sich personenbezogene Daten aus. Sie werden mit vager Begründung gesammelt, in Protokolle und sekundäre Systeme kopiert, für neue Funktionen wiederverwendet und lange nach ihrem ursprünglichen Zweck aufbewahrt. Im Laufe der Zeit wird es schwierig, grundlegende Fragen zu beantworten, wo Daten gespeichert sind, warum sie existieren und was mit ihnen geschieht.

Das Gesetz ist darauf ausgelegt, genau das zu stoppen.

So betrachtet, fühlen sich die Regeln nicht mehr getrennt an. Sie alle schränken ein, wie sich Daten innerhalb eines Systems entwickeln dürfen. Daten sollten einen Grund haben, sie sollten sich nicht leise in etwas anderes verwandeln, sie sollten nicht länger leben als beabsichtigt und sie sollten nicht an Orten landen, die man nicht berücksichtigt hat.

Das bedeutet „Privacy by Design und by Default“ wirklich

„Privacy by Design und by Default“ ist nichts, was man später hinzufügt. Es bedeutet, dass diese Einschränkungen in das System integriert sind und auch dann noch gelten, wenn später niemand mehr daran arbeitet.

In der Praxis zeigt sich das in den Standardeinstellungen.

Wenn Ihr System standardmäßig vollständige Request-Bodies protokolliert, Daten standardmäßig unbegrenzt aufbewahrt und Daten uneingeschränkt an Integrationen weitergibt, dann ist es standardmäßig nicht konform.

Das Gegenteil ist das, was das Gesetz erwartet.

Wenn Sie Ihr System bereitstellen und nichts weiter tun, sollte es nur die Daten sammeln, die es benötigt. Protokolle sollten keine Rohdaten enthalten, es sei denn, dies ist ausdrücklich erforderlich. Daten sollten ablaufen, es sei denn, etwas verlängert aktiv ihre Lebensdauer. Integrationen sollten nur das erhalten, was sie benötigen, nicht alles, was verfügbar ist.

Diese Ergebnisse sollten nicht von Disziplin oder Aufräumarbeiten abhängen. Sie sollten das Verhalten des Systems sein, wenn niemand aufpasst.

Und das wird im Code entschieden.

Wie Systeme von dieser Absicht abweichen

Systeme verstoßen selten in einem offensichtlichen Schritt gegen diese Absicht. Sie driften ab.

Ein Entwickler fügt ein Feld hinzu, weil es später nützlich sein könnte. Anstatt z. B. „is_verified“ zu speichern, speichert das System vollständige Identitätsdaten, weil sie möglicherweise in Zukunft benötigt werden. Dieses Feld wird Teil einer Request-Payload, die protokolliert wird. Die Protokollierung wird einmal konfiguriert, sodass alles hineinkommt – E-Mails, Identifikatoren, Rohdaten.

Später werden dieselben Daten in ein Analyse-Tool exportiert, weil sie bereits verfügbar sind. Monate später werden sie in einer Funktion wiederverwendet, die niemand ursprünglich geplant hat.

Daten, die einst einen engen Zweck hatten, existieren nun an mehreren Orten, werden auf unvorhergesehene Weise verwendet und haben kein klares Ende.

Das gleiche Muster zeigt sich bei der Protokollierung. Sie beginnt als Beobachtbarkeit, bedeutet aber in der Praxis oft die Protokollierung vollständiger Payloads, da dies der einfachste Weg zur Fehlersuche ist. Zu diesem Zeitpunkt hören Protokolle auf, nur operative Daten zu sein, und werden zu einem parallelen Datenspeicher – einem, der schwerer zu kontrollieren ist und oft länger aufbewahrt wird als primäre Daten.

Integrationen schaffen eine weitere Ebene. Ein Drittanbieter-Dienst empfängt Daten, weil es bequem ist, sie weiterzuleiten. Aber jetzt folgen diese Daten einem anderen Lebenszyklus: andere Aufbewahrung, anderer Zugriff, andere Sichtbarkeit. Aus Sicht Ihres Systems sind sie weg. Aus rechtlicher Sicht nicht.

Warum die Implementierung „der Regeln“ nicht ausreicht

Wenn Teams diese Dynamik nicht verstehen, versuchen sie, die Compliance am Rande zu beheben.

Sie bauen Löschmechanismen, ohne zu wissen, wo sich Daten befinden. Eine „Benutzer löschen“-Funktion entfernt den Hauptdatensatz, lässt aber Protokolle unberührt, Analysedaten intakt und Drittsysteme unverändert. Sie definieren Aufbewahrungsrichtlinien, ohne alle Speicherorte zu kontrollieren. Die Datenbank bereinigt Daten möglicherweise nach 30 Tagen, aber Protokolle behalten sie ein Jahr lang, weil das die Standardkonfiguration ist. Sie führen Einwilligungsprozesse ein, ohne sie mit der tatsächlichen Datennutzung abzugleichen. Die Benutzeroberfläche spiegelt das eine wider, während das System darunter weiterhin auf die gleiche Weise funktioniert.

Von außen sieht das gut aus.

In Wirklichkeit adressiert dies nicht das Kernproblem. Wenn sich Daten bereits verbreitet haben, wird die Löschung unvollständig. Wenn sie in Protokolle oder externe Tools kopiert werden, wird die Aufbewahrung inkonsistent. Wenn der Zweck nicht darin reflektiert wird, wie Daten strukturiert und verwendet werden, wird die Einschränkung ihrer Nutzung schwierig.

Das System erscheint konform, verhält sich aber auf eine Weise, die der Absicht des Gesetzes widerspricht.

Was sich ändert, wenn man die Absicht versteht

Für einen Entwickler geht es bei der Umstellung nicht darum, mehr Regeln zu lernen. Es geht darum zu erkennen, was im Laufe der Zeit nicht passieren darf.

Daten sollten sich nicht über ihren ursprünglichen Zweck hinaus ausdehnen. Sie sollten sich nicht in Teile des Systems duplizieren, die nie dafür bestimmt waren, sie zu verarbeiten. Sie sollten nicht länger leben als der Grund für ihre Erhebung. Und sie sollten nicht wiederverwendet werden, ohne dass diese Änderung explizit ist.

Sobald man das erkennt, fühlen sich die Anforderungen nicht mehr willkürlich an. Sie werden zu Leitplanken, die das System vor dem Abdriften bewahren.

Das ändert die Art und Weise, wie Entscheidungen getroffen werden.

Das Hinzufügen eines Feldes ist nicht mehr trivial, da man entscheiden muss, ob man den Rohwert tatsächlich benötigt oder ob eine abgeleitete Version ausreicht. Die Protokollierung ist nicht mehr nur Fehlersuche, da man entscheiden muss, ob diese Payload überhaupt vorhanden sein muss. Die Integration eines anderen Systems ist kein einfacher Shortcut mehr, da man verstehen muss, welche Daten man sendet und warum.

Nichts davon verlangsamt Sie. Es macht die Konsequenzen nur im Moment der Entscheidungsfindung sichtbar.

Frühes Beheben ist wichtig

Diese Dynamiken sind am einfachsten zu handhaben, wenn das System klein ist und die Datenflüsse einfach sind.

In diesem Stadium ist es noch möglich, Fragen wie „Wo landet dieses Feld?“ oder „Wie würden wir diesen Benutzer vollständig löschen?“ ohne großen Aufwand zu beantworten.

Mit wachsendem System potenzieren sich die Entscheidungen. Daten werden dupliziert, Abhängigkeiten steigen und die Kosten für Änderungen steigen. Die Behebung von Problemen wird nicht mehr lokal, sondern systemisch. Das Entfernen eines einzelnen Datensatzes kann Änderungen in mehreren Diensten, Pipelines und Integrationen erfordern.

Deshalb fühlt sich die DSGVO bei reifen Systemen schwierig an. Nicht weil die Anforderungen komplex sind, sondern weil das System nie mit diesen Einschränkungen im Hinterkopf entworfen wurde.

Wie das Bauen mit dem Gesetz tatsächlich aussieht

Das Bauen unter Berücksichtigung der DSGVO bedeutet nicht, Entwickler zu Rechtsexperten zu machen. Es bedeutet, Systeme zu entwerfen, die der natürlichen Tendenz von Daten widerstehen, sich auszubreiten und anzusammeln.

In der Praxis bedeutet das, dass Sie wissen, was mit Daten passiert, nachdem Sie sie eingeführt haben. Sie wissen, wohin sie fließen, wo sie gespeichert werden und wie sie entfernt werden können. Sie vermeiden die Einführung von Daten, die Sie später nicht verfolgen oder löschen können. Sie treffen bewusste Entscheidungen darüber, was protokolliert, was geteilt und was aufbewahrt wird.

Daten gelangen aus einem klaren Grund in das System. Ihre Bewegung ist beabsichtigt. Ihre Lebensdauer ist begrenzt. Und ihre Entfernung ist möglich, ohne das System rückentwickeln zu müssen.

Wenn diese Eigenschaften vorhanden sind, ist Compliance nicht mehr etwas, das man nachträglich zusammensetzt. Es spiegelt sich bereits im Verhalten des Systems wider.

Die meisten Teams scheitern bei der DSGVO nicht, weil sie sie ignorieren. Sie scheitern, weil sie nie verstanden haben, was sie verhindern wollte – und bis sie es merken, ist das System bereits zu weit abgedriftet.