DSGVO im Produktbetrieb: Datenflüsse sichtbar machen
Datenschutz beginnt nicht mit dem fertigen Formular. Er beginnt mit einer Karte, auf der ein Team sehen kann, welche Information wohin fließt und warum.
Redaktion Techspiegel5 Min. Lesezeit
DatenschutzEU-RegulierungVerwaltungSchwerpunkt: Daten ohne Nebel

Inhalt dieses Beitrags
Ein Betrieb kann eine Datenschutzerklärung auf der Website haben und trotzdem nicht sagen, wohin die Supportanfrage wandert, die ein Kunde mit angehängtem Screenshot schickt. Die Datenschutz-Grundverordnung fragt nicht nach Dokumenten, sondern nach Verarbeitungen: welcher Zweck, welche Daten, welche Empfänger, wie lange. Wer diese vier Angaben nicht zusammenbekommt, hat kein Formularproblem, sondern eine Lücke im Prozess. Dieser Leitfaden folgt einem fiktiven Produktprozess und den Stellen, an denen Teams regelmäßig hängen bleiben. Eine Rechtsberatung ersetzt er nicht, und er behauptet an keiner Stelle, dass ein Werkzeug als solches konform ist.
Welche Daten braucht der Prozess?
Die Reihenfolge entscheidet über den Aufwand. Wer mit der Liste der Datenbankfelder beginnt, diskutiert über Technik. Wer mit dem Zweck beginnt, kann Felder streichen. Der Zweck ist die Frage, die ein Kunde beantworten könnte: Wofür brauchen Sie diese Angabe, und was passiert, wenn sie fehlt?
Die Karte hat fünf Stationen: Erhebung, Verarbeitung, Speicherung, Übergabe an Dritte, Löschung. Jede Station bekommt vier Angaben: Zweck, Datenkategorien, Empfänger, Dauer. Dazu kommt die Rechtsgrundlage nach Artikel 6 und ein Name. Eine Station ohne Namen ist eine Meinung.
Zwei Datensorten werden dabei fast immer übersehen. Die erste sind Protokolldaten: IP-Adressen, Nutzerkennungen, Gerätekennungen, Zeitstempel. Der Satz „das sind doch nur technische Daten“ hält nicht, denn technische Daten lassen sich in aller Regel auf eine Person beziehen. Die zweite sind Anhänge: Screenshots, gescannte Lieferscheine, E-Mails, hochgeladene Tabellen. In ihnen steckt oft mehr, als das Formular vorsieht.
Formal ist das Verzeichnis von Verarbeitungstätigkeiten nach Artikel 30 der Ort, an dem diese Angaben landen. Praktisch ist die Karte die Arbeitsfassung, aus der das Verzeichnis entsteht. Wer umgekehrt anfängt, füllt eine Tabelle, die niemand liest. Wo die Grenze zwischen Anlagendaten und personenbezogenen Daten verläuft, ist gerade in der Fertigung fließend; wie schnell aus einem Messwert ein Beschäftigtendatum wird, beschreibt der Beitrag darüber, wie Datenschutz im Maschinenraum anfängt.
Die Übersicht in diesem Beitrag ordnet diese Stationen als Datenweg. Sie ist ein Arbeitsmittel für das Team und kein Nachweis gegenüber einer Aufsicht.
Arbeitsvorlage
Datenflusskarte für einen Produktprozess
Die Karte ist bewusst als Tabelle gebaut, weil sie sich so leichter pflegen lässt als in einer Zeichenanwendung. Sie beantwortet für jede Datenart vier Fragen: wozu, auf welcher Grundlage, an wen und wie lange.
- Schritt 1
Erhebung
Welche Angaben entstehen im Produkt, und ist jede einzelne nötig?
- Schritt 2
Übergabe
Wer bekommt die Daten, und auf welcher Grundlage?
- Schritt 3
Supportzugang
Wer sieht im Fehlerfall mehr als im Normalbetrieb?
- Schritt 4
Löschung
Wann verschwinden die Daten, und wer stößt das an?
| Datenart | Zweck | Typische Grundlage | Empfänger | Löschung |
|---|---|---|---|---|
| Kontodaten | Vertrag erfüllen und abrechnen | Vertrag | intern, Steuerberatung | nach Ablauf der Aufbewahrungsfrist |
| Nutzungsdaten | Funktion verbessern | Einwilligung oder berechtigtes Interesse | intern | nach festgelegter Frist |
| Fehlerberichte | Störungen beheben | berechtigtes Interesse | intern, Support | kurz, meist wenige Wochen |
| Supportanhänge | Anfrage bearbeiten | Vertrag oder berechtigtes Interesse | Supportteam | nach Abschluss der Anfrage |
| Testdaten | Entwicklung und Prüfung | keine, weil keine echten Daten vorgesehen sind | intern | sofort nach dem Test |
Das dargestellte Verfahren ist ein fiktives Beispiel und beschreibt kein bestimmtes Produkt und kein bestimmtes Unternehmen. Die Angaben zur Rechtsgrundlage sind eine typische Zuordnung und keine Prüfung des Einzelfalls.
Zur amtlichen Orientierung dient im Beitrag die Broschüre des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit zu DSGVO und BDSG. Sie ersetzt keine individuelle Rechtsberatung.
Weitere Grundlage: Veröffentlichungen der Datenschutzkonferenz und der Landesdatenschutzbehörden sowie Fachliteratur zu datenschutzfreundlicher Technikgestaltung.
Wer sieht die Supportdaten?
Die Supportanfrage ist die Stelle, an der ein Produkt seine Datenhaltung verliert. Der Kunde hängt einen Screenshot an, eine Mitarbeiterin öffnet den Fall, ein externer Dienstleister sieht mit, und der Fall bleibt Jahre im Ticketsystem. Wer diese Kette nicht aufschreibt, kann später weder Auskunft noch Löschung ordentlich beantworten.
Der Zugriff gehört an eine Rolle und nicht an eine Person. Ein Sammelkonto, das drei Beschäftigte nutzen, lässt sich später nicht auswerten, und genau diese Auswertung verlangt die Rechenschaftspflicht. Der Zugriff selbst ist ein Datum: Wer wann welchen Kundendatensatz geöffnet hat, gehört ins Protokoll. Wer Fernzugriff auf Kundenanlagen hat, sollte vor jedem Fall fragen, ob er ihn für diesen Fall braucht. Konten, Mehrfaktor-Anmeldung und die Frage, wer einen Zugang sofort sperren darf, sind zuerst Sicherheitsfragen; die Grundlagen dazu stehen im Beitrag darüber, wie ein Betrieb ohne eigenes Security-Team sicher bleibt.
Sobald ein Dienstleister auf die Daten zugreift, braucht es einen Vertrag zur Auftragsverarbeitung nach Artikel 28: Weisungsbindung, Liste der Unterauftragnehmer, Löschung nach Vertragsende, Meldung von Vorfällen. Der Vertrag muss zu der Kette passen, die tatsächlich existiert, sonst beschreibt er einen Prozess, den niemand fährt. Ob ein Modell lokal oder beim Dienstleister läuft, ist dieselbe Frage nach Datenweg und Abhängigkeit; die Abwägung dazu steht im Beitrag darüber, ob ein Modell lokal oder in der Cloud laufen soll.
Aus der Karte folgen auch die Antworten, die ein Betrieb nach außen geben muss. Eine Auskunftsanfrage verlangt, alle Stationen zu nennen, an denen Daten zu einer Person liegen. Eine Löschanfrage verlangt, dieselben Stationen wiederzufinden, einschließlich der Kopie im Supportsystem und der Sicherung. Wer die Karte hat, beantwortet beides in Stunden. Wer sie nicht hat, befragt vier Abteilungen und findet am Ende drei von fünf Stationen. Deshalb gehören zu jeder Station eine Speicherdauer und ein Löschweg, und der Zweck allein reicht nicht.
Wann ist ein Testdatensatz nicht mehr harmlos?
Der Testdatensatz ist der Klassiker unter den offenen Flanken. Er entsteht, weil jemand eine Kopie aus der Produktion zieht, damit die neue Funktion überhaupt etwas anzuzeigen hat. Damit wandern echte Namen, echte Vorgangsnummern und echte Anhänge in eine Umgebung, die meist schlechter kontrolliert wird als die Produktion.
Pseudonymisierung ist keine Anonymisierung. Solange ein Merkmal existiert, über das sich ein Datensatz wieder zuordnen lässt, bleibt die Verarbeitung personenbezogen und der Testdatensatz damit ein Fall für dieselben Regeln. Harmlos wird er nicht durch die Umgebung, sondern durch den Inhalt: erfundene Namen, unbrauchbare Nummern, keine Anhänge, kein Bezug zu einem echten Vorgang.
Vier Regeln halten das im Zaum: eine benannte Person je Testsystem, eine feste Löschfrist, eine dokumentierte Entscheidung, wenn Produktionsdaten kopiert werden, und ein Zugriffskreis, der nicht größer ist als in der Produktion. Der letzte Punkt wird oft umgedreht, weil Testsysteme gern offener sind als der Ernstfall. Sobald ein Werkzeug Unternehmensdokumente erst lesbar macht oder Zusammenfassungen erzeugt, wächst die Zahl der Kopien weiter; was dabei mit Verträgen und Angeboten passiert, beschreibt der Beitrag darüber, wie Unternehmensdaten erst lesbar werden.
Wo endet die amtliche Orientierung?
Für den Einstieg gibt es amtliche Orientierung, die den Einzelfall nicht ersetzt. Die Informationsbroschüre des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit zu DSGVO und BDSG beschreibt Aufbau und Pflichten in verständlicher Form; die Broschüre des BfDI zu DSGVO und BDSG (öffnet in einem neuen Tab) ist eine solche Orientierung. Sie ist keine individuelle Rechtsberatung, sie kennt den eigenen Prozess nicht, und für die meisten privaten Unternehmen ist ohnehin eine Landesaufsicht zuständig und nicht der Bundesbeauftragte. Beschlüsse der Datenschutzkonferenz helfen bei der Auslegung, binden aber kein Gericht.
Ein Satz gehört deshalb in jede Produktentscheidung: Kein Werkzeug ist als solches konform. Konform oder nicht konform ist eine Verarbeitung mit einem Zweck, einem Zugriffskreis und einer Löschfrist. Ein Anbieter kann belegen, dass er verschlüsselt, protokolliert und löscht; ob der eigene Prozess rechtmäßig ist, sagt dieser Beleg nicht. Zertifikate sind Hinweise auf Maßnahmen, keine Feststellung über den eigenen Fall.
Wer KI-Funktionen einsetzt, hat daneben ein zweites Regelwerk im Haus. Was dort gilt und was noch Übergang ist, sortiert der Beitrag darüber, was die KI-Verordnung im Arbeitsalltag verlangt. Für die Datenfrage bleibt es trotzdem bei den vier Angaben je Station.
Was am Ende offen bleibt
Die Karte beantwortet nicht, ob eine Verarbeitung rechtmäßig ist. Sie beantwortet, wo diese Frage noch offen ist, und verwandelt ein ungutes Gefühl in eine Liste mit Namen und Fristen. Das ist der Punkt, an dem Datenschutz aufhört, ein Dokument zu sein, und Arbeit wird.
Offen bleibt die Löschung. Sie wird am häufigsten zugesagt und am seltensten geprüft. Eine Löschroutine, die niemand getestet hat, ist eine Absicht. Wer wissen will, ob sie trägt, löscht einen Datensatz und sucht ihn anschließend in der Produktion, im Testsystem, im Backup und im Ticketsystem. Findet er ihn an einer dieser Stellen wieder, ist die Karte an dieser Stelle falsch. Darin liegt die Grenze des Verfahrens: Eine Datenflusskarte macht Löschung überprüfbar, sie macht sie nicht selbstverständlich.