Datenschutz & IT-Compliance
Eine technische Datenflussanalyse beschreibt nicht nur einen einzelnen Datensatz. Sie rekonstruiert, welche Daten zwischen Systemen, Komponenten, Schnittstellen, Speichern und externen Diensten tatsächlich oder nachweisbar fließen.
Kurzantwort
Für eine belastbare Rekonstruktion müssen Systemgrenze, Datenquellen, Datenelemente, Verarbeitungsschritte, Schnittstellen, Speicherorte, Kopien, technische Zielsysteme und vorhandene Nachweise miteinander verbunden werden.
NIST verwendet im Privacy Framework den Begriff der Data Actions, um technische Vorgänge mit Daten strukturiert zu betrachten. Für eine Systemanalyse können solche Vorgänge als Knoten einer nachvollziehbaren Verarbeitungskette dokumentiert werden.
Eine praktikable Untersuchungskette lautet: Systemgrenze → Datenquelle → Datenelement → Data Action → Schnittstelle → Verarbeitung → Speicher → Weitergabe → Löschung beziehungsweise Retention → Nachweis → Aussagegrenze.
1. Eine Datenflussanalyse benötigt zunächst eine Systemgrenze
Bevor Datenflüsse rekonstruiert werden, muss bestimmt werden, welche Anwendung, Plattform, Organisationseinheit oder technische Umgebung überhaupt Untersuchungsgegenstand ist.
Ohne eine solche Grenze bleibt offen, welche Komponenten zur Prüfung gehören und welche lediglich als externe Systeme betrachtet werden.
2. Ein Datenfluss ist mehr als die Herkunft eines einzelnen Datensatzes
Die Herkunft eines konkreten Datenbestands beantwortet eine andere Frage als die Rekonstruktion eines gesamten Verarbeitungssystems.
Ein Datenfluss kann mehrere Quellen, Zwischensysteme, Verarbeitungsschritte, Speicherorte und technische Zielsysteme umfassen.
3. Datenquellen bilden die Eingangspunkte der Rekonstruktion
Eine Quelle kann beispielsweise ein Endgerät, eine Datenbank, eine Datei, ein Formular, eine API, ein Messsystem, ein Drittdienst oder ein anderes Informationssystem sein.
Entscheidend ist, dass die konkrete technische Quelle nachvollziehbar bezeichnet wird.
4. Datenelemente sollten konkreter als „die Daten“ beschrieben werden
Für eine belastbare Datenflussdarstellung sollte möglichst erkennbar sein, welche Felder, Attribute, Payloads oder sonstigen Datenelemente übertragen oder verarbeitet werden.
Ein pauschaler Pfeil mit der Beschriftung „Daten“ ist für viele technische Prüfungen zu unbestimmt.
5. NIST verwendet Data Actions zur Beschreibung von Datenverarbeitung
Im NIST Privacy Framework werden technische Vorgänge mit Daten als Data Actions strukturiert betrachtet.
Für eine gutachterliche Rekonstruktion können solche Aktionen beispielsweise erfassen, dass Daten erhoben, gespeichert, verändert, verwendet, übertragen, offengelegt oder gelöscht werden.
6. Verarbeitungsschritte müssen in ihrer Reihenfolge bestimmt werden
Eine Datenflussdarstellung sollte nicht nur Systeme aufzählen, sondern auch zeigen, welche Verarbeitung zwischen Eingang und Ausgang stattfindet.
Dazu können Validierung, Mapping, Filterung, Anreicherung, Aggregation, Transformation oder Ableitung neuer Werte gehören.
7. Schnittstellen sind eigene technische Übergabepunkte
API-Aufrufe, Message Queues, Dateiübertragungen, Datenbankverbindungen, Webhooks oder andere Schnittstellen können eigenständige Übergabepunkte eines Datenflusses bilden.
Schnittstellenprotokoll, Richtung und beteiligte Systeme gehören deshalb zur Rekonstruktion.
8. Logische Funktion und konkrete Systemkomponente sind zu unterscheiden
Eine Dokumentation kann beispielsweise von „CRM“, „Analytics“ oder „Authentifizierung“ sprechen.
Für eine technische Prüfung kann zusätzlich relevant sein, welche konkrete Anwendung, Instanz, Datenbank oder Cloud-Komponente diese Funktion tatsächlich ausführt.
9. Die Richtung eines Datenflusses muss nachvollziehbar sein
Bei jeder Verbindung sollte erkennbar sein, welches System sendet und welches System empfängt.
Bidirektionale Kommunikation sollte nicht ohne weitere Prüfung als ein einziger undifferenzierter Pfeil dargestellt werden.
10. Speicherorte sind eigenständige Stationen des Datenflusses
Daten können in relationalen Datenbanken, Objektspeichern, Dateisystemen, Suchindizes, lokalen Geräten, Cloud-Speichern oder anderen technischen Speichern liegen.
Ein Speicherort sollte deshalb nicht lediglich als Eigenschaft eines Verarbeitungsschritts behandelt werden.
11. Auch temporäre Speicher und Caches können relevant sein
Nicht jede Datenkopie befindet sich in einem dauerhaft vorgesehenen Primärspeicher.
Temporäre Dateien, Caches, Session-Speicher, Warteschlangen oder Arbeitsspeicherstrukturen können je nach Fragestellung Teil des technischen Datenflusses sein.
12. Logs und Telemetrie können zusätzliche Datenflüsse erzeugen
Anwendungen erzeugen häufig Protokoll-, Monitoring- oder Telemetriedaten.
Dabei können ursprünglich verarbeitete Werte, Identifikatoren, Fehlerdetails oder Metadaten in ein separates Logging- oder Monitoring-System gelangen.
13. Abgeleitete Daten sind neue technische Datenobjekte
Durch Berechnung, Klassifikation, Aggregation oder Profilbildung können aus Eingangsdaten neue Werte entstehen.
Eine Datenflussanalyse sollte deshalb nicht nur übertragene Rohdaten, sondern auch technisch erzeugte Ableitungen berücksichtigen.
14. Identifikatoren und Pseudonyme verändern nicht automatisch den Datenfluss
Wird ein ursprünglicher Identifikator durch einen anderen Wert, Token oder technischen Schlüssel ersetzt, besteht weiterhin ein Verarbeitungsschritt und möglicherweise eine Zuordnungsbeziehung.
Ob daraus rechtlich eine Anonymisierung oder Pseudonymisierung folgt, ist eine gesonderte Frage.
15. Metadaten können einen eigenen Untersuchungsgegenstand bilden
Zeitstempel, Gerätekennungen, Header, Statuscodes, Herkunftsinformationen oder technische Kontextdaten können unabhängig vom eigentlichen Nutzinhalt entstehen.
Sie sollten nicht allein deshalb ausgeblendet werden, weil sie organisatorisch als „Metadaten“ bezeichnet werden.
16. Exporte und Kopien erweitern den tatsächlichen Datenbestand
CSV-Exporte, Reports, lokale Downloads, manuelle Kopien oder Zwischendateien können zusätzliche Datenbestände erzeugen.
Für eine vollständige Rekonstruktion ist deshalb zu prüfen, ob der dokumentierte Primärspeicher tatsächlich der einzige Speicherort ist.
17. Backups und Archive sind vom operativen Primärspeicher zu unterscheiden
Eine operative Löschung aus einer Anwendung bedeutet technisch nicht automatisch, dass dieselben Daten zeitgleich aus Backups oder Archiven verschwinden.
Backup- und Archivsysteme können daher eigene Stationen einer technischen Datenflussanalyse bilden.
18. Externe Dienste bilden technische Zielsysteme
Daten können an Hosting-Anbieter, Analyseplattformen, Kommunikationsdienste, Zahlungsdienste, SaaS-Anwendungen oder andere externe Systeme übertragen werden.
Für den technischen Befund ist zunächst festzustellen, welche Verbindung tatsächlich besteht und welche Daten sie transportiert.
19. Ein technischer Empfänger ist nicht automatisch eine rechtliche Rollenbestimmung
In einer technischen Darstellung kann ein System oder ein externer Dienst als Ziel beziehungsweise Empfänger einer Übertragung bezeichnet werden.
20. Cloud-Systeme können mehrere technische Verarbeitungsebenen besitzen
Eine Cloud-Anwendung kann aus Frontend, API, Datenbank, Objektspeicher, Logging, Backup und weiteren Diensten bestehen.
Der Produktname allein beschreibt deshalb nicht zwingend den vollständigen technischen Datenfluss.
21. Batch-Verarbeitung und ereignisgetriebene Verarbeitung unterscheiden sich
Ein nächtlicher Export besitzt einen anderen Ablauf als eine kontinuierliche Event- oder Streaming-Verarbeitung.
Frequenz, Trigger und zeitliche Reihenfolge sollten deshalb zur Datenflussbeschreibung gehören.
22. Eingehende und ausgehende Schnittstellen sollten getrennt erfasst werden
Ein System kann Daten aus mehreren Quellen beziehen und gleichzeitig andere Daten an weitere Systeme ausgeben.
Beide Richtungen können unterschiedliche Datenfelder, Protokolle und Ausführungsbedingungen besitzen.
23. Konfiguration kann den tatsächlichen Datenfluss verändern
Feature Flags, Routingregeln, Mandantenkonfiguration, Umgebungsvariablen oder andere Einstellungen können bestimmen, welcher Datenpfad tatsächlich genutzt wird.
Quellcode allein belegt deshalb nicht immer den im untersuchten Zeitraum aktiven Datenfluss.
24. Zugriffsberechtigung und tatsächlicher Datenfluss sind unterschiedliche Fragen
Die Möglichkeit, auf einen Datenbestand zuzugreifen, beweist nicht, dass dieser Zugriff tatsächlich stattgefunden hat.
Umgekehrt kann ein beobachteter Datenfluss zusätzliche Fragen zu Berechtigungen und Schutzmaßnahmen auslösen.
25. Retention und Löschung gehören zum technischen Lebenszyklus
Bei einer Datenflussanalyse kann relevant sein, wann Daten aus operativen Systemen, Zwischenspeichern, Logs, Exporten oder Backups entfernt werden.
Dokumentierte Löschregeln und tatsächlich beobachtbares technisches Verhalten sollten dabei getrennt werden.
26. Ein Datenflussdiagramm ist zunächst eine Behauptung über das System
Eine vorhandene Architekturzeichnung oder Data Map kann eine wichtige Untersuchungsgrundlage sein.
Sie beweist jedoch nicht allein, dass das produktive System exakt entsprechend dieser Darstellung arbeitet.
27. Technische Nachweise können die dokumentierte Kette stützen
Je nach System können beispielsweise Konfigurationsdateien, API-Spezifikationen, Datenbankschemata, Logs, Deployment-Unterlagen, Netzwerkdaten oder Cloud-Konfigurationen zur Rekonstruktion beitragen.
Die konkrete Beweiskraft hängt jeweils von Datenstand, Zeitraum und Vollständigkeit des Nachweises ab.
28. Laufzeitbeobachtungen können von der Dokumentation abweichen
Ein System kann technisch anders konfiguriert sein, als es eine ältere Dokumentation beschreibt.
Werden solche Abweichungen festgestellt, sollten Soll-Darstellung und beobachteter Ist-Datenfluss getrennt dokumentiert werden.
29. Fehlende Dokumentation ist selbst ein technischer Befund
Wenn Schnittstellen, Speicherorte oder externe Übertragungen nicht ausreichend dokumentiert sind, kann dies die Rekonstruktion begrenzen.
Aus einer Dokumentationslücke folgt jedoch nicht automatisch, dass ein bestimmter Datenfluss tatsächlich stattgefunden hat.
30. Fehlende Laufzeitnachweise begrenzen die historische Aussage
Eine aktuelle Konfiguration kann zeigen, wie ein System heute eingerichtet ist.
Ohne historische Logs, Versionen oder andere zeitbezogene Nachweise kann daraus nicht zwingend auf einen früheren Systemzustand geschlossen werden.
31. Artikel 7 betrachtet dagegen den konkreten Datenbestand
Der Beitrag „Daten als Untersuchungsgegenstand“ konzentriert sich auf Identität, Herkunft, Datenstand, Transformation und Reproduzierbarkeit eines konkreten Datenbestands.
Die hier behandelte Datenflussanalyse betrachtet dagegen die Verbindungen zwischen mehreren technischen Komponenten und Datenstationen.
32. Datenqualität ist ebenfalls ein eigener Prüfbereich
Ein vollständig rekonstruierter Datenfluss beweist nicht, dass die übertragenen Daten vollständig, korrekt, konsistent oder aktuell sind.
Solche Eigenschaften benötigen eine gesonderte Datenqualitätsprüfung.
33. Schutzmaßnahmen und Datenflüsse beantworten unterschiedliche Fragen
Verschlüsselung, Zugriffskontrollen, Netzsegmentierung oder andere Schutzmaßnahmen können einen Datenfluss absichern.
Ob diese Maßnahmen angemessen implementiert sind, ist jedoch von der reinen Rekonstruktion des Datenpfads zu trennen.
34. Ein Datenfluss sagt noch nicht, ob Daten personenbezogen sind
Technisch können Datenfelder, Identifikatoren und Verknüpfungen beschrieben werden.
35. Rechtmäßigkeit und technische Existenz eines Datenflusses sind zu trennen
Ein technischer Befund kann zeigen, dass Daten von System A über eine bestimmte Schnittstelle an System B übertragen werden.
Daraus folgt nicht automatisch, ob diese Verarbeitung rechtlich zulässig ist oder auf welcher Rechtsgrundlage sie beruht.
36. Auch eine verschlüsselte Übertragung bleibt ein Datenfluss
TLS, VPN oder andere Transportverschlüsselung verändert die technische Schutzwirkung einer Übertragung.
Die Verbindung zwischen Sender und technischem Zielsystem bleibt dennoch Bestandteil der Datenflussrekonstruktion.
37. Ein vollständiges Datenflussdiagramm beweist keine Compliance
Eine nachvollziehbare Data Map kann Transparenz über technische Verarbeitung schaffen.
Sie beantwortet jedoch nicht automatisch, ob sämtliche technischen, organisatorischen, vertraglichen oder rechtlichen Anforderungen eingehalten werden.
38. Unbekannte Komponenten gehören ausdrücklich in die Aussagegrenze
Nicht jeder Datenpfad lässt sich vollständig rekonstruieren.
Fehlende Logs, nicht verfügbare Cloud-Konfigurationen, unzugängliche Drittsysteme oder nicht dokumentierte Exporte sollten als konkrete Untersuchungsgrenzen benannt werden.
39. Mehrere Nachweisarten sollten zeitlich miteinander verbunden werden
Architekturunterlagen, Quellcode, Konfiguration, Logs und Datenbankschemata können unterschiedliche Zeitstände besitzen.
Eine belastbare Rekonstruktion sollte deshalb festhalten, welcher Nachweis welchen Zeitraum beziehungsweise Systemstand betrifft.
40. Praktische Dokumentationsstruktur einer Datenflussanalyse
- technische Fragestellung,
- Systemgrenze und untersuchter Zeitraum,
- Systeme und Komponenten,
- Datenquellen,
- Datenelemente beziehungsweise Payloads,
- Data Actions beziehungsweise Verarbeitungsschritte,
- Schnittstellen und Protokolle,
- Flussrichtung,
- Transformationen und Ableitungen,
- operative Speicherorte,
- temporäre Speicher und Caches,
- Logs und Telemetriesysteme,
- Exporte und manuelle Kopien,
- Backups und Archive,
- externe Zielsysteme beziehungsweise Dienste,
- Ausführungsfrequenz oder Trigger,
- Retention- beziehungsweise Löschverhalten,
- zugrunde liegende Nachweise,
- Abweichungen zwischen Dokumentation und Ist-Zustand,
- offene beziehungsweise nicht nachweisbare Pfade,
- Aussagegrenzen.
Konstruiertes Beispiel
Eine Webanwendung nimmt über ein Formular Kundendaten entgegen.
Die Anfrage wird zunächst an eine API übertragen. Dort werden einzelne Felder validiert und anschließend in einer Datenbank gespeichert.
Parallel erzeugt die Anwendung technische Logeinträge. Ein nächtlicher Prozess überträgt ausgewählte Felder an ein externes Analysesystem. Zusätzlich existieren tägliche Datenbank-Backups.
Eine technische Rekonstruktion würde diese Pfade getrennt erfassen: Formular → API → Datenbank, API → Logging, Datenbank → Analyseexport und Datenbank → Backup.
Anschließend wäre für jeden Pfad zu dokumentieren, welche Datenelemente, Systeme, Schnittstellen, Zeitbezüge und Nachweise tatsächlich festgestellt werden konnten.
Der Befund entscheidet dabei nicht, ob einzelne Daten rechtlich personenbezogen sind oder ob eine Verarbeitung datenschutzrechtlich zulässig ist.
Das Beispiel ist vollständig konstruiert und stellt kein reales Mandat, keine Datenschutzberatung und keine gerichtliche Beauftragung dar.
Quellen und fachliche Grundlage
- Offizielle NIST-Publikation National Institute of Standards and Technology: NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0 . Fachliche Grundlage zu Privacy Engineering, Data Processing, Data Actions und Data Processing Ecosystem. Geprüft am 20.09.2026.
- Offizielle NIST-Ressource NIST: Getting Started with the NIST Privacy Framework . Ergänzende Grundlage zur Erfassung und Darstellung von Datenverarbeitung und Datenflüssen. Geprüft am 20.09.2026.
- Offizielle NIST-Terminologie NIST CSRC: Data Action . Terminologische Grundlage für technische Handlungen beziehungsweise Vorgänge mit Daten. Geprüft am 20.09.2026.
- Offizielle NIST-Terminologie NIST CSRC: Data Processing . Terminologische Grundlage zur technischen Datenverarbeitung. Geprüft am 20.09.2026.
- Offizielle NIST-Publikation National Institute of Standards and Technology: NISTIR 8062 – An Introduction to Privacy Engineering and Risk Management in Federal Systems . Ergänzende Grundlage zu Privacy Engineering, Datenverarbeitung und technischen Privacy-Risiken. Geprüft am 20.09.2026.
- Offizielle NIST-Publikationsseite NIST CSRC: NISTIR 8062 – Final . Publikations- und Versionsnachweis. Geprüft am 20.09.2026.
- Eigene fachliche Einordnung Die Kette Systemgrenze → Datenquelle → Datenelement → Data Action → Schnittstelle → Verarbeitung → Speicher → Weitergabe → Löschung beziehungsweise Retention → Nachweis → Aussagegrenze dient hier als methodische Struktur einer technischen Datenflussanalyse.
Weiterführende Beiträge
Wie Schutzmaßnahmen an Systemen und Verarbeitungspunkten auf tatsächliche Implementierung, Konfiguration, technische Wirksamkeit und Nachweisbarkeit untersucht werden können, erläutert Technische und organisatorische Maßnahmen technisch prüfen: Umsetzung, Wirksamkeit und Nachweis .
Wie ein konkreter Datenbestand nach Herkunft, Datenstand, Transformation und Reproduzierbarkeit bestimmt wird, erläutert Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit .
Wie Vollständigkeit, Eindeutigkeit, Konsistenz, Genauigkeit und Aktualität eines bestimmten Datenbestands untersucht werden können, erläutert Datenqualität technisch prüfen .
Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.
Zur technischen Eingrenzung einer gerichtlichen oder anwaltlichen Fragestellung siehe Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .
Datenflüsse technisch rekonstruieren
Wenn Quellen, Schnittstellen, Verarbeitungsschritte, Speicherorte, externe Zielsysteme oder Löschpfade eines IT-Systems technisch nachvollzogen werden sollen, können zunächst Systemgrenze, Datenpfade, Nachweise und Aussagegrenzen fachlich eingegrenzt werden.
IT-Compliance & Datenethik ansehen