A Data Flow Diagram (DFD) is a map of how data moves through a system — not the code, not the infrastructure, but the actual path information travels from the moment it enters until it's stored, processed, or leaves again. It's the single most important artifact in structured threat modeling, because you can't systematically ask "what could go wrong" about a system you haven't first mapped.
Quick definition: A DFD is a diagram made of four element types — processes, data stores, external entities, and data flows — plus trust boundaries marking where data crosses from one zone of trust into another.
The four elements
- External entity — something outside your system that sends or receives data: a user, a third-party API, another service you don't control. Usually drawn as a rectangle.
- Process — something that transforms data: an API endpoint, a background job, an authentication check. Usually drawn as a circle or rounded rectangle.
- Data store — anywhere data comes to rest: a database table, a cache, a file on disk, a log. Usually drawn as an open-ended rectangle.
- Data flow — the arrow connecting the above, representing data actually moving from one element to another (a request, a query, a write).
On top of those four, a trust boundary is drawn wherever data crosses into a zone with different trust assumptions — the line between the public internet and your API, or between an unauthenticated request and an authenticated session.
A minimal example
Take a simple login flow: a User (external entity) submits credentials to a Login API (process), which checks them against a Users table (data store) and returns a session token. Drawn as a DFD, that's two external-entity/process arrows, one process/data-store arrow, and one trust boundary — the point where the request crosses from the public internet into your backend.
That sounds almost too simple to be useful, but it's exactly the point: a DFD doesn't need to be complicated to be effective, and forcing yourself to draw even a trivial flow out explicitly surfaces assumptions ("wait, is that connection actually authenticated?") that stay invisible when the flow only exists in your head.
Want to try this yourself? Grab our free Data Flow Diagram template — a worked example already laid out in draw.io, no signup required.
Why DFDs matter for threat modeling
A DFD is what makes a framework like STRIDE systematic rather than ad hoc. Instead of brainstorming threats in the abstract, you walk every single element of the diagram — every process, every data store, every flow crossing a trust boundary — and check it against each STRIDE category. The diagram is the checklist; STRIDE is what you check each item against.
This is also why DFDs scale down well: a two-person startup's DFD might have five elements and take fifteen minutes to draw and threat-model. A DFD isn't a heavyweight architecture-review artifact reserved for large systems — it's useful precisely because it's cheap to produce and immediately actionable.
For a full step-by-step walkthrough of building one — including how to handle nested trust boundaries and multi-service systems — see How to Build a Data Flow Diagram (DFD) for Threat Modeling.