practice

Data Flow Diagrams

Where data goes, who holds it and which boundaries it crosses — the artefact that answers privacy, residency and threat-modelling questions.

data-flowprivacythreat-modellingresidencytrust-boundaries

Definition

A data flow diagram traces information rather than control: what data exists, where it is stored, how it moves, and — critically — which trust and jurisdictional boundaries it crosses.

Why architects need it specifically

Three questions are unanswerable without it, and all three are increasingly consequential:

  • Privacy. Where does personal data live, and everywhere it has been copied. Without this, deletion and subject access requests are archaeology exercises.
  • Residency. Does any data cross a jurisdictional boundary it should not? This is a routing and placement question that no component diagram surfaces.
  • Threat modelling. Trust boundary crossings are where attacks happen. A data flow diagram with boundaries marked is the standard input to a threat model.

What to mark

  • Data classification per flow — personal, confidential, public.
  • Trust boundaries — the network, organisational and jurisdictional lines the data crosses.
  • Stores, including the ones people forget: caches, logs, backups, search indexes, warehouses, third-party processors, and analytics tools.
  • Third parties, which are a store and a boundary crossing at once.
  • Retention per store, since the same data has different lifetimes in different places.

The forgotten stores are where the value is. Most privacy failures are not in the primary database; they are in a log, an export, or a vendor tool nobody mapped.

The threat-modelling use

For each trust boundary crossing, ask what could go wrong: spoofing, tampering, information disclosure, denial of service, elevation of privilege. That structured walk over a data flow diagram is the most productive form of threat modelling available, and it takes a couple of hours.

Failure scenarios

  • Only the primary store mapped, missing caches, logs, backups and vendors.
  • No trust boundaries marked, so the diagram cannot support a threat model.
  • Drawn for an audit and never updated, so it describes the system as designed rather than as built.
  • Classification missing, so it is unclear which flows matter most.

Interview question

"A regulator asks where a specific customer's personal data is held. What artefact answers that, and what does it need to include?"