Datenschutz & Datensicherheit
Datenminimierung ist technisch nicht durch die bloße Existenz einer Richtlinie nachgewiesen. Systeme sammeln Felder, erzeugen Metadaten, schreiben Logs, replizieren Daten und behalten Backups. Eine technische Untersuchung macht sichtbar, welche Daten für welchen Prozesspfad tatsächlich anfallen und welche Mechanismen ihre Begrenzung umsetzen.
Kurzantwort
Ausgangspunkt ist ein konkreter Verarbeitungs- oder Funktionspfad. Für ihn werden Eingaben, persistierte Felder, Übermittlungen, Logs, Caches und abgeleitete Daten inventarisiert. Anschließend wird geprüft, welche Felder technisch erforderlich sind, welche optional oder historisch bedingt erscheinen und welche Minimierungsmechanismen tatsächlich wirksam sind. Die rechtliche Erforderlichkeitsbewertung bleibt getrennt.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Dateninventar am realen Prozesspfad aufbauen
Eine abstrakte Datenkategorie wie „Nutzungsdaten“ ist für eine technische Prüfung zu grob. Erfasst werden konkrete Felder, Identifikatoren, Zeitstempel, Geräteinformationen, Payloads und abgeleitete Merkmale entlang eines definierten Funktionspfads.
Dabei werden nicht nur Primärdaten betrachtet. Logs, Caches, Suchindizes, Analyseevents und Backups können zusätzliche Kopien oder Metadaten erzeugen, die in der Hauptdatenbank nicht sichtbar sind.
2. Technische Nutzung eines Feldes nachweisen
Für jedes relevante Feld wird untersucht, welche Komponente es liest, schreibt, überträgt oder als Entscheidungsgrund nutzt. Code-Suche, Schemaanalyse, Telemetrie und reproduzierbare Tests können zeigen, ob ein Feld funktional benötigt oder nur mitgeführt wird.
Ein ungenutztes Feld ist ein technischer Hinweis, aber noch keine rechtliche Schlussfolgerung. Ebenso kann ein technisch genutztes Feld rechtlich nicht automatisch als erforderlich gelten. Beide Ebenen bleiben getrennt.
3. Datenerhebung bereits an der Quelle begrenzen
Technische Minimierung kann früh ansetzen: optionale Formularfelder nicht erfassen, API-Payloads beschränken, Telemetrie reduzieren oder sensible Inhalte vor Übertragung filtern. Solche Maßnahmen verhindern Datenentstehung statt sie nur später zu löschen.
Die Begutachtung prüft, ob die dokumentierte Konfiguration dem realen Verhalten entspricht. Feature Flags oder unterschiedliche Clientversionen können dazu führen, dass nur ein Teil der Nutzer minimierte Datenpfade verwendet.
4. Speicherung, Retention und Kopien berücksichtigen
Auch wenn eine Anwendung ein Feld nicht mehr aktiv nutzt, kann es in historischen Tabellen, Data Warehouses, Backups oder Logsystemen weiter vorhanden sein. Datenminimierung ist daher mit Datenlebenszyklus und Aufbewahrung technisch verbunden.
Die Untersuchung dokumentiert, welche Speichersysteme und Replikate zum Scope gehören. Nicht zugängliche Backups oder externe Dienste werden als Begrenzung benannt, statt ihre Bereinigung zu unterstellen.
5. Pseudonymisierung und Aggregation differenziert bewerten
Pseudonyme Kennungen, Hashes und Aggregationen können Risiken reduzieren, sind aber technisch unterschiedlich reversibel oder verknüpfbar. Entscheidend sind Zusatzwissen, Schlüsselmaterial, Granularität und verfügbare Querverbindungen.
Der technische Bericht beschreibt diese Eigenschaften, ohne eine pauschale rechtliche Einstufung als anonym oder personenbezogen vorzunehmen. Wo Re-Identifikationsmöglichkeiten relevant sind, werden sie als technische Bedingungen dokumentiert.
6. Minimierungsbefund revisionsfähig formulieren
Neue Features, SDKs und Logging-Einstellungen können den Datenumfang verändern. Ein Befund wird deshalb an Version, Konfiguration und Testzeitpunkt gebunden.
Wird später ein Feld entfernt oder eine Telemetrie reduziert, ist dies ein Revisionsanlass. Frühere technische Feststellungen bleiben für den damaligen Stand gültig, werden aber nicht auf den neuen Zustand übertragen.
Ein sinnvoller Gegencheck besteht darin, einzelne Felder in einer kontrollierten Umgebung wegzulassen oder zu maskieren und zu beobachten, welche Funktion tatsächlich ausfällt. Solche Tests können technische Abhängigkeiten sichtbar machen, ersetzen aber nicht die fachliche oder rechtliche Entscheidung, ob eine alternative Implementierung zumutbar oder erforderlich ist.
Bei Analytics- und Telemetriesystemen sollte zusätzlich die Granularität betrachtet werden. Eine hohe Ereignisauflösung, langlebige Identifikatoren oder frei kombinierbare Attribute können wesentlich mehr Verknüpfungsmöglichkeiten schaffen als aggregierte Kennzahlen. Die technische Beschreibung sollte daher nicht nur Felder zählen, sondern auch zeitliche und relationale Verknüpfbarkeit berücksichtigen.
Technische Minimierung lässt sich außerdem an Default-Konfigurationen prüfen. Ein System kann zwar optionale Felder technisch erlauben, sie aber standardmäßig deaktivieren oder nur nach bewusster Aktivierung erfassen. Für die tatsächliche Datenpraxis sind deshalb Standardwerte, Rollout-Varianten und bestehende Mandantenkonfigurationen relevant, nicht nur die theoretisch mögliche Maximalerfassung.
Ist ein technisch genutztes Feld automatisch „notwendig“?
Nein. Technische Nutzung zeigt, dass eine Implementierung das Feld aktuell verwendet.
Ob dieselbe Funktion mit weniger Daten oder einem anderen Design erreichbar wäre, kann technisch als Alternative untersucht werden.
Die datenschutzrechtliche Erforderlichkeit und Verhältnismäßigkeit ist davon getrennt zu beurteilen.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist der untersuchte Funktions- oder Verarbeitungspfad klar abgegrenzt?
- Sind konkrete Felder, Metadaten, Logs und abgeleitete Daten inventarisiert?
- Ist je relevantem Feld die tatsächliche technische Nutzung nachvollziehbar?
- Sind Erhebung, Speicherung und Übermittlung getrennt betrachtet?
- Sind Backups, Replikate, Caches und Analyseplattformen soweit relevant einbezogen?
- Sind Pseudonymisierung und Aggregation nach ihrer technischen Verknüpfbarkeit beschrieben?
- Bleiben technische Nutzung und datenschutzrechtliche Erforderlichkeit klar getrennt?
Konstruiertes Beispiel
Ein Kontaktformular übermittelt neben Name und Nachricht zusätzlich Browser-Sprache, interne Kampagnen-ID und vollständige Referrer-URL. Die Untersuchung prüft, welche Felder von der eigentlichen Kontaktfunktion verwendet werden und welche nur für Analysezwecke anfallen. Die rechtliche Bewertung dieser Zwecke bleibt getrennt.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche Rechtsquelle DSGVO Artikel 5 Absatz 1 Buchstabe c nennt den Grundsatz der Datenminimierung. Quelle öffnen.
- NIST-Rahmenwerk NIST Privacy Framework als freiwilliger Rahmen zur Identifikation und Behandlung von Privacy Risks. Quelle öffnen.
- Technische Sicherheitsreferenz OWASP API Security Top 10 2023 unter anderem zu übermäßiger Datenexposition und Autorisierungsrisiken in APIs. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Datenflüsse technisch rekonstruieren
- Löschung, Aufbewahrung und Zugriffsrechte prüfen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich Datenschutz & Datensicherheit
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Compliance