A data flow diagram (DFD) is a map of how data moves through a system — where it enters, where it is processed, where it rests, and where trust changes as it travels. In threat modeling, the DFD is the foundational artifact: you cannot reason systematically about what could go wrong until you can see how data flows and where it crosses from one level of trust to another. A DFD is deliberately simple, built from just four element types — external entities, processes, data stores, and data flows — plus trust boundaries drawn around groups of them. That simplicity is the point. The diagram is not architecture documentation; it is a thinking tool whose job is to make the trust boundaries visible, because trust boundaries are where the overwhelming majority of threats live.
Why It Matters
Threat modeling without a diagram tends to produce either a blank stare or an unstructured list of worries. The DFD converts "what could go wrong?" from an open-ended question into a systematic walk over concrete elements. Once every data flow and trust boundary is on the page, you can go element by element and ask what threats each attracts — turning a vague exercise into a repeatable one that different people can perform and get comparable results.
The trust boundary is the reason DFDs earn their place. A trust boundary is any point where data or requests move between different levels of trust: the edge between the internet and your API, between your application and its database, between one tenant and another, between your code and a third-party service. These crossings are where validation is forgotten and where tampering and spoofing happen. A DFD makes every crossing explicit, which is why it is the starting point for structured methods like STRIDE. Draw the boundaries, and the threats practically enumerate themselves.
How to Do It
A DFD uses four element types, and each attracts a characteristic set of threats. The table pairs them.
| DFD element | What it represents | Threats it tends to attract |
|---|---|---|
| External entity | Users, other systems outside your control | Spoofing, repudiation |
| Process | Code that transforms or routes data | Tampering, elevation of privilege |
| Data store | Databases, files, caches, queues | Tampering, information disclosure |
| Data flow | Data moving between elements | Tampering, disclosure, denial of service |
| Trust boundary | A line where trust level changes | Concentrates all of the above |
Build the diagram in steps:
- Identify the external entities. Start at the edges: who and what interacts with the system from outside your control — users, partner systems, third-party APIs. These are your sources of untrusted input.
- Map the processes. Add the components that receive, transform, and route data: services, functions, and handlers. Keep them at a consistent level of abstraction.
- Add the data stores. Mark everywhere data comes to rest — databases, caches, file storage, message queues — since resting data attracts disclosure and tampering threats.
- Draw the data flows. Connect the elements with arrows showing how data actually moves, and label each flow with what data it carries. The labels matter; "user record" and "session token" attract different threats.
- Draw the trust boundaries. This is the payoff step. Enclose groups of elements that share a trust level and draw a boundary wherever trust changes. Every arrow that crosses a boundary is a place to stop and threat-model.
- Walk each element and boundary for threats. With the map complete, go element by element and boundary by boundary, asking what could go wrong at each — using STRIDE or a similar checklist to stay systematic.
Pick the right altitude. A single diagram covering the whole system at high level is the usual starting point; drill into a lower-level DFD only for the areas where the risk warrants the detail. Too much detail buries the trust boundaries you are trying to see.
Common Pitfalls
- Too much detail. A DFD that documents every function and field becomes architecture noise, and the trust boundaries — the whole point — get lost. Keep it as simple as the analysis allows.
- Missing trust boundaries. A DFD without boundaries is just a flow chart. The boundaries are where the threat modeling actually happens; omit them and the diagram does no security work.
- Unlabeled flows. An arrow that does not say what data it carries cannot be threat-modeled properly, because the sensitivity of the data determines which threats matter.
- Drawing the intended flow only. DFDs should capture how data actually moves, including error paths and administrative back channels, not just the clean happy path shown to stakeholders.
- A diagram that never changes. The system evolves and the DFD goes stale, so the threat model built on it quietly becomes fiction. The diagram is only useful if it tracks reality.
How It Connects to Supply Chain Security
Data flow diagrams get more valuable — and more often incomplete — once you account for the supply chain. Every third-party dependency, external API, and managed service in your system is a data flow crossing a trust boundary, and each is easy to leave off the diagram precisely because you did not write it. The library that sends telemetry, the SDK that phones home, the base image that runs a background agent: these are real flows across real trust boundaries, and a DFD that omits them threat-models a system that does not exist. A rigorous DFD treats external code and services as first-class elements with their own boundaries.
Making those hidden flows visible is where tooling helps. Software Composition Analysis inventories every open source component and its transitive dependencies, revealing the third-party code — and the flows it introduces — that belong on your diagram but rarely make it there. Dynamic testing observes the actual traffic a running system produces, exposing egress the design docs never mentioned. And Griffin AI reasons across those flows and boundaries to highlight where sensitive data crosses into untrusted territory. Compare approaches on our comparison page, and see the principles behind the practice in the concepts library.
A data flow diagram is the map that makes threat modeling possible. Keep it simple, keep the trust boundaries front and center, keep it honest about the third-party flows you did not write — and it will surface threats you would otherwise never think to look for.
Create a free account to reveal the third-party data flows in your system, or read the documentation.
Frequently Asked Questions
What are the four elements of a data flow diagram?
External entities (users or systems outside your control), processes (code that transforms or routes data), data stores (where data rests, like databases and caches), and data flows (the arrows showing data moving between elements). Trust boundaries are then drawn around groups of these to mark where the trust level changes.
Why are trust boundaries the most important part of a DFD?
Because the overwhelming majority of threats occur where data crosses from one trust level to another — the internet-to-API edge, the app-to-database link, one tenant to another. A DFD makes every such crossing explicit so none is overlooked, which is why boundary crossings are exactly where you focus your threat analysis.
How detailed should a data flow diagram be?
Detailed enough to show the trust boundaries clearly, and no more. Start with a high-level diagram of the whole system and only drill into lower-level DFDs for the areas where risk justifies the extra detail. Excessive detail buries the boundaries you are trying to reason about.
How do data flow diagrams relate to STRIDE?
STRIDE is the threat checklist you apply to each element of the DFD: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The DFD gives you the structured map of elements and boundaries; STRIDE gives you the categories of threat to check against each one. They are designed to be used together.