Data Protection
A data-flow diagram is a claim about how a system processes data. A technical reconstruction tests that claim against configuration, code, interfaces, runtime evidence and storage states. The result describes what data moves where, when and under which technical conditions.
Short answer
The examination first fixes the system boundary and identifies relevant data sources, data elements and processing actions. It then follows transfers through APIs, queues, files, databases, analytics services, backups and external providers, including copies that may not appear in the primary architecture diagram.
Technical existence and legal permissibility are separate questions. A reconstructed flow can establish that certain data was transmitted or stored under defined conditions; it does not by itself determine whether that processing was lawful, necessary or compliant.
1. Define the examination scope and system boundary
A data-flow analysis needs a boundary before it needs a diagram
The system boundary identifies which applications, environments, tenants, networks and external services are included. Without this boundary, the same data element can appear to “leave the system” or remain internal depending on how the architecture is framed.
Relevant data sources are then inventoried: user input, imported files, sensors, upstream APIs, identity providers, databases and generated telemetry. Each source is related to the concrete data elements or categories that enter the examined processing chain.
Processing actions are ordered chronologically or causally where possible. Collection, transformation, enrichment, analysis, storage, disclosure and deletion are different technical events and should not be collapsed into one generic “processing” box.
2. Trace paths, storage and technical handovers
Direction and duplication matter
For each material path, the examination records source, destination, protocol or interface, data content and trigger. Bidirectional synchronisation is distinguished from one-way export; batch transfers are distinguished from event-driven calls.
Copies can expand the actual data estate beyond the primary database. Temporary files, message queues, caches, log stores, search indexes, analytics platforms and exports can retain data even when the original application record is deleted.
External services are represented as concrete technical destinations where possible. DNS names, API endpoints, account or tenant identifiers, SDK configuration and network observations can support the mapping more strongly than vendor names alone.
3. Examine external systems, configuration and lifecycle
Configured destinations can differ from assumed destinations
Configuration determines which service instance or region actually receives data. Environment variables, deployment manifests, API keys, webhook targets, SDK settings and cloud-resource identifiers can therefore be relevant evidence.
The lifecycle includes creation, update, replication, archival, backup and deletion. A flow that is active only during onboarding differs from a continuous telemetry flow; a temporary processing store differs from a long-term archive.
Where a third-party service performs additional processing that cannot be observed directly, the technical conclusion is limited to the supported interface and configuration evidence rather than asserting an unseen internal flow.
4. Compare documentation with runtime evidence
A diagram is not proof of execution
Architecture diagrams, records of processing and interface documentation describe intended or documented behaviour. Runtime evidence such as network traces, application logs, API gateway logs, message metadata or database activity can support whether those paths were actually used.
Code and configuration can show that a path exists while logs can show whether it was exercised in the examined period. Conversely, a log entry can show an event without fully revealing the payload unless logging captured the relevant fields.
The reconstruction labels evidence by type and time reference. This helps distinguish current architecture from historical processing and prevents present-day configuration from being projected backwards without support.
5. Keep technical findings separate from legal assessment
Existence of a flow is not a legal conclusion
A technical examination can identify that an identifier, payload or file was transmitted to a defined endpoint and can describe the protection mechanisms observed on that path. It can also identify retention or deletion behaviour in the examined systems.
Whether the data is personal data in a legal sense, whether a legal basis exists, whether the transfer is necessary or whether a recipient role is legally correct are separate assessments. Technical evidence can support those assessments but does not replace them.
The report therefore uses precise technical language such as “observed transfer”, “configured destination” or “recoverable copy” and avoids converting those findings automatically into compliance labels.
6. Document time reference, evidence and limitations
The final map should be auditable
A practical record lists data element or category, source, processing step, interface, destination, storage location, trigger, time reference, evidence and known retention or deletion behaviour. Important uncertainty is visible rather than buried in a footnote.
If logs are incomplete or payloads are encrypted beyond the available observation point, the report states what can and cannot be established. A destination can be confirmed even when the exact payload content remains uncertain.
This evidence-backed map can then serve as a technical basis for security, data-protection or contractual review without claiming those separate evaluations have already been completed.
Is the technical conclusion sufficiently supported?
- Is the system boundary defined for the examined environment and period?
- Are concrete data sources and relevant data elements identified?
- Are processing actions and transfer directions distinguishable?
- Are caches, logs, exports, backups and other copies included where relevant?
- Are external destinations tied to endpoints, configuration or runtime evidence?
- Is current configuration separated from historical processing claims?
- Are documented flows checked against technical evidence where available?
- Does the report separate technical existence and protection of flows from legal permissibility?
Constructed example
Documentation states that a web application sends only pseudonymous analytics events to an external platform. Runtime inspection shows that one event also contains a stable account identifier added by a client-side SDK. The reconstruction records the endpoint, event type, identifier and configuration responsible for the field.
The technical report establishes the observed transmission and identifies the responsible integration. It does not decide whether the transmission is lawful or whether the identifier has a particular legal classification.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Official NIST publication NIST Privacy Framework Version 1.0, used for privacy engineering concepts, data processing, data actions and the data processing ecosystem. Open source.
- Official NIST resource NIST Getting Started with the Privacy Framework, supplementary guidance for identifying and representing data processing and flows. Open source.
- Official NIST terminology NIST CSRC: Data Action, used for technical actions or operations performed with data. Open source.
- Official NIST terminology NIST CSRC: Data Processing, used for technical data-processing terminology. Open source.
- Official NIST publication NISTIR 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems. Open source.
- Official NIST publication page NIST CSRC publication page for NISTIR 8062, used as publication and version evidence. Open source.
- Author methodological framing System boundary → data source → data element → data action → interface → processing → storage → disclosure → deletion/retention → evidence → limitation is used as the reconstruction chain.
Further reading
- Data Transfers and Interfaces
- Technical Implementation of Data Minimisation
- Deletion, Retention and Access Rights
- Pseudonymisation and Anonymisation
Critical review and methodological limitation
A technically convincing data-flow diagram is still only as strong as its evidence and time reference. Current code and configuration can show possible paths, while runtime records are needed to support claims about actual use in a disputed period.
The examination also avoids treating an observed flow as a complete privacy assessment. Legal categories, roles, necessity and lawful basis remain separate questions.
- Boundary: define which systems and environments are included.
- Evidence: distinguish documented, configured and actually observed flows.
- Legal separation: report technical processing without converting it automatically into a compliance conclusion.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
Data Ethics & IT Compliance
Technical examination of documented data-protection, fairness, transparency and compliance-related implementation requirements.
Explore this assessment service