Data Flow Mapping for Security and Privacy: Method

An inventory tells you where data sits; only a data flow map tells you where it moves, who moves it, across which boundaries and under which controls. Breaches, unlawful transfers and failed DPIAs usually happen in the movement: an integration nobody documented, an export to a supplier, a support team abroad with remote access. This guide gives a practical method for mapping data flows that serves both security (threat modelling, egress control, detection) and privacy (DPIA descriptions, international transfers, records of processing), with a flow record template you can use as-is. It is for security architects, privacy teams and engineers. Building the inventory and the Article 30 record itself is covered in the Data Mapping and ROPA Guide; this page starts where that one stops.

Key takeaways

The flow is the unit of record. Map each movement of data as its own record: source, destination, data, channel, identity, boundary and control, linked back to the systems and processing activities in your inventory.
Trust boundaries are where risk concentrates. Every flow that crosses a network zone, an organisation, a jurisdiction or a privilege level needs a named control and an owner.
One map, two uses. The same diagram elements (external entities, processes, data stores, data flows, trust boundaries) feed a threat model and a DPIA description of how data is collected, stored, used and shared.
Machine identities move most of the data. Service accounts, API keys and OAuth grants are the "who" on most flows; record them, or the map misses the access path an attacker will use.
A map that is not maintained is a liability. Tie updates to change management and verify flows against network, identity and egress telemetry at least yearly.

Data map, data flow map and data flow diagram

Artefact	Answers	Typical owner	Main use
Data inventory or data map	What data do we hold, where, and why?	Privacy and data governance	Record of processing, retention, classification
Data flow map (register)	Where does each dataset move, by what channel and identity, across which boundary?	Joint: privacy, security architecture, system owners	Transfers, supplier risk, egress control, DPIA input
Data flow diagram (DFD)	How do processes, stores and external entities exchange data in one system?	Engineering and security architecture	Threat modelling, design review
Network flow diagram	Which hosts and ports talk to each other?	Network and infrastructure teams	Firewall rules, segmentation

NIST CSF 2.0 asks for the third and fourth together in ID.AM-03: representations of authorised network communication and internal and external data flows are maintained. NIST SP 800-53 adds CM-13 Data Action Mapping for the privacy view and AC-4 Information Flow Enforcement for the control view. The ICO's documentation guidance calls the starting point an information audit or data-mapping exercise and insists records are granular and linked, not a generic list of data types.

Notation that works for both teams

OWASP's threat modelling guidance says a model should show trust boundaries, data flows, data stores, processes and the external entities that interact with the system, with a high-level overview for complex systems and more detailed diagrams of components. Microsoft's Threat Modeling Tool uses the same five element types:

Element	Examples	What to record for privacy	What to record for security
External entity (external interactor)	Customers, suppliers, identity providers, partner APIs	Data subject category or recipient; controller or processor role	How it authenticates; whether you control it
Process	Applications, services, batch jobs, AI agents	Purpose of processing	Running identity and privileges
Data store	Databases, buckets, caches, configuration files, logs	Data categories, retention rule	Encryption, access model, backup copies
Data flow	HTTPS API calls, SFTP, SMB, message queues, email, exports	Sharing or transfer; lawful basis carried	Protocol, encryption in transit, credential used
Trust boundary	Internet edge, organisation, jurisdiction, cloud account, user and kernel mode	Restricted transfer if it crosses a border to a separate organisation	Control enforcing the boundary

Microsoft's tool lets you mark an element out of scope with a reason, and notes this is not recommended. The same applies to maps: record exclusions explicitly rather than leaving elements off.

The flow record template

Keep one row per flow in a register (a spreadsheet works to start; a CMDB or privacy platform later). These fields cover the questions security, privacy and audit ask most often.

Field	Content	Example
Flow ID and name	Stable identifier and short description	FLOW-042 CRM to marketing platform nightly sync
Source and destination	System or entity, with inventory IDs	CRM (SYS-011) to email marketing SaaS (SUP-207)
Data categories	From your classification scheme; flag special category data	Name, email, consent flags, purchase history
Volume and frequency	Records per run, schedule or event-driven	About 200,000 records nightly
Purpose and processing link	The processing activity in the record of processing	PROC-07 direct marketing
Channel and protocol	API, file transfer, queue, email, manual	HTTPS REST API, TLS 1.2 or later
Identity used	Service account, API key, OAuth app, user	OAuth client "crm-sync" with contacts.write scope
Boundaries crossed	Zone, organisation, cloud account, country	Internet; organisation; UK to US
Transfer mechanism	Where a restricted transfer applies	Adequacy regulations or IDTA, with transfer risk assessment reference
Controls	Encryption, allow-listing, DLP, minimisation, logging	Field-level minimisation, IP allow list, API audit logs to SIEM
Owners	Business owner and technical owner	Head of marketing; CRM platform lead
Evidence and review	Last verified date and how	Verified against API logs, March

Method: mapping flows step by step

Pick a scope. One business function or one system, not the whole organisation. Start where the risk is: customer data platforms, HR, payments, or a system heading for a DPIA. The ICO suggests working from broad to narrow, beginning with a function such as HR or sales.
Seed from the inventory. Pull systems, stores and processing activities from the data map, and suppliers from the processor register.
Draw the level 0 view. One process for the system, its external entities and its main stores, with trust boundaries. Agree it with the system owner in one session.
Interview and walk the integrations. Ask the ICO's plain questions (why, about whom, what, shared with whom, how long, how secured), then go through integration settings, scheduled jobs, OAuth grants, API keys and export features. Integrations are where undocumented flows hide.
Verify with telemetry. Compare the draft against firewall and proxy logs, cloud flow logs, identity provider sign-ins for service principals and SaaS audit logs. Any traffic or token use not on the map is either a missing flow or a finding.
Record each flow in the template above and link it to the processing activity, supplier and risk register entries.
Assess. For each flow crossing a boundary, check the control, the transfer mechanism and whether a DPIA or threat model needs updating.
Publish and maintain. Store diagrams and register where engineers can update them, and add "new or changed data flow" as a question in change and procurement workflows.

Pilot with one system for two to four weeks, measure how long a flow takes to record and verify, then plan the rest of the estate from that rate. If the template proves too heavy, drop optional fields rather than skipping verification.

Using the map for privacy

DPIA descriptions: the ICO says a DPIA must describe the nature, scope, context and purposes of processing, including how you collect, store and use the data and who you share it with. A level 1 diagram and the flow records for the system answer most of that directly. See the DPIA Guide.
International transfers: the ICO defines a restricted transfer as sending personal information to, or making it accessible to, a separate organisation outside the UK. Remote access by an overseas support provider counts, so map access flows as well as data copies. Each restricted transfer needs adequacy regulations, an appropriate safeguard such as the IDTA, the Addendum or binding corporate rules (with a transfer risk assessment), or an exception. See the Transfer Impact Assessment (TIA) Template.
Minimisation: comparing fields sent with fields used at the destination is the quickest minimisation win most organisations have.
Rights requests and retention: flows show every copy that an erasure request or retention rule must reach.

Using the map for security

Threat modelling: OWASP suggests using the STRIDE categories as prompts against the components, data flows and trust boundaries in the model. Flows crossing a boundary attract tampering, information disclosure and spoofing questions first. See the Threat Modelling Guide.
Egress control: approved flows become the allow list for proxies, firewalls and cloud egress rules (AC-4, SC-7). Anything else leaving the estate is suspicious by definition.
Detection: the map gives a baseline for exfiltration analytics. Volume or destination changes on a mapped flow, and any unmapped destination, map to ATT&CK T1567 Exfiltration Over Web Service, T1048 Exfiltration Over Alternative Protocol and T1537 Transfer Data to Cloud Account.
Supplier risk: flows to suppliers show which vendors hold which data, and what to revoke when a vendor is breached (CA-3 Information Exchange, SA-9 External System Services).

Where identity fits

For most flows the "who" is a non-human identity: an integration's OAuth client, a service account running an ETL job, an API key in a SaaS connector or an AI agent calling a tool. The Salesloft Drift breach shows why this field matters: stolen OAuth tokens for a chatbot's Salesforce integration let the attacker bulk-export records from hundreds of organisations, and the activity looked like legitimate API access. A flow register that recorded "Drift to Salesforce, OAuth app, scopes, owner" would have told each victim within minutes what to revoke and what data was exposed. Record the credential type, scopes, owner and rotation date for every flow, and reconcile the register against your NHI inventory. See the Service Account Inventory Template.

Choosing depth and tooling

Situation	Approach	Trade-off
Small organisation, mostly SaaS	One register in a spreadsheet, one level 0 diagram per key SaaS, flows taken from integration and OAuth settings	Cheap and fast; relies on people keeping it current
Mid-size with own applications	Register plus DFDs for systems in scope of DPIAs or threat models, drawn in a diagram tool or threat modelling tool	Good depth where it matters; uneven coverage elsewhere
Large or regulated estate	Privacy or governance platform for the register, automated discovery and lineage, DFDs for high-risk systems, telemetry-based verification	Best coverage; tools find stores and pipelines but rarely the purpose or the legal basis, which still need people

Detection and measurement

Coverage: percentage of in-scope systems with a verified flow map.
Unmapped flows found: number of flows discovered in telemetry or audits that were not in the register, trending down.
Boundary controls: percentage of boundary-crossing flows with a named control and owner.
Transfers covered: percentage of restricted transfers with a documented mechanism and, where needed, a transfer risk assessment.
Freshness: median age since each flow was last verified, against a 12-month target.
Identity linkage: percentage of flows whose credential appears in the NHI inventory with an owner.

Framework mapping

Requirement	Source	What the flow map provides
Data flows maintained	NIST CSF 2.0 ID.AM-03; ID.AM-07 data inventories	The register and diagrams
Data action mapping	NIST SP 800-53 CM-13; PM-5(1) Inventory of PII	Privacy view of each flow
Flow enforcement and boundaries	NIST SP 800-53 AC-4, SC-7	Allow list of approved flows
External exchanges and suppliers	NIST SP 800-53 CA-3, SA-9	Supplier flows with agreements and owners
Privacy impact assessment	NIST SP 800-53 RA-8; UK GDPR Article 35	Description of collection, storage, use and sharing
Records of processing	UK GDPR and EU GDPR Article 30	Recipients and transfers linked to each processing activity
Information transfer	ISO/IEC 27001:2022 Annex A 5.14	Rules and agreements per transfer channel

Common failure patterns

Mapping systems, not movements: a list of applications with "shares data with marketing" gives no channel, identity or boundary, so it cannot drive a control.
Interviews only: people describe intended flows; exports, scripts, test copies and SaaS connectors appear only in telemetry and integration settings.
Missing access flows: remote support access and admin consoles reached from abroad are left off because no file is copied, yet the ICO treats making data accessible as a transfer.
No identity on the flow: the register cannot answer which token to revoke when a supplier is breached.
A one-off project: the map is accurate on delivery day and wrong six months later because change management never asks about new flows.
Scope by exclusion: awkward elements such as logs, backups and analytics pipelines are quietly left off, though they often hold the most copies.

Practitioner checklist

Agree the five DFD element types and a trust boundary list (zones, organisations, cloud accounts, countries) with security and privacy.
Adopt the flow record template and link each record to inventory, processing activity and supplier IDs.
Start with one high-risk system and draw level 0 and level 1 views with the owner.
Walk integration settings, OAuth grants, API keys and scheduled exports, not only interviews.
Verify every map against network, cloud flow, identity and SaaS audit telemetry.
Name a control and owner for every boundary-crossing flow.
Record the transfer mechanism and transfer risk assessment for each restricted transfer, including remote access.
Record the credential, scopes and owner for every flow and reconcile with the NHI inventory.
Feed approved flows into egress allow lists and exfiltration baselines.
Add a data flow question to change, procurement and DPIA screening, and re-verify yearly.

Data flow mapping for security and privacy: a method, a flow record template and review rules