Data Flow Diagram (DFD) Creation for Security Reviews

Threat modelling DFDs use a small, consistent set of element types, generally drawn from the notation popularised alongside STRIDE. Getting the element types right matters because, as covered in the STRIDE methodology, which threat categories even apply to an element depends on its type.

• •External entity (rectangle) — anything outside the system's control that interacts with it: a user, an external service, a third-party API. You model its interactions with your system but not its internals.
• •Process (circle or rounded rectangle) — anything that transforms or acts on data: an application server, a microservice, a Lambda function, a background worker.
• •Data store (parallel lines or open-ended rectangle) — anywhere data is persisted: a database, a cache, a message queue, a file store, a log store.
• •Data flow (labelled arrow) — the movement of data between the above elements, labelled with what data is moving, not just that a connection exists.
• •Trust boundary (dashed line) — a line marking a change in trust level or privilege, such as the boundary between the public internet and an internal network, or between two services with different privilege levels.

It's tempting to treat trust boundaries as a cosmetic addition to a DFD, but they're arguably the single most important element for threat modelling purposes: threats concentrate at trust boundary crossings, because that's precisely where an assumption held on one side may not hold on the other. A data flow that never crosses a trust boundary is lower priority than one that does, all else equal.

Common trust boundaries worth drawing explicitly include the perimeter between the public internet and your infrastructure, the boundary between an unauthenticated and authenticated zone of an application, boundaries between services owned by different teams (who may have different security postures), the boundary between your infrastructure and a third-party SaaS integration, and — increasingly relevant in containerised environments — the boundary between a container and its host.

Start at a high level and decompose only as far as the review actually needs. A Level 0 diagram (sometimes called a context diagram) shows the system as a single process with its external entities and the data flows between them — useful for scoping and for non-technical stakeholders. A Level 1 diagram decomposes that single process into its major internal components (application server, database, cache, auth service) and is usually the level at which STRIDE-per-element analysis is actually run. Going deeper than Level 1 is rarely necessary for a threat model and tends to produce diagrams too large to review effectively in one sitting — deeper decomposition is better scoped to a specific high-risk component identified at Level 1.

• •Identify every external entity that interacts with the system, including internal teams' services if they're operated with different trust levels.
• •Identify every process and data store within scope, at a consistent level of granularity (avoid mixing 'the whole backend' with 'this one Redis cache' in the same diagram).
• •Draw every data flow between elements, and label each with what data actually moves — 'credentials,' not just 'request.'
• •Overlay trust boundaries wherever privilege, ownership, or network trust changes.
• •Validate the diagram against the real system — a design doc or an engineer's mental model is a starting point, not a source of truth; confirm against actual configuration, network rules, or code where diagrams and reality tend to diverge.

The most common failure is drawing the intended architecture rather than the deployed one — a diagram based on a design document from a year ago, when the system has since grown a caching layer, a new third-party integration, or a debug endpoint nobody removed. Threat modelling against a stale diagram gives false confidence, since it validates a system that no longer exists.

A second common mistake is omitting trust boundaries entirely, or drawing only the obvious internet-facing one while missing internal boundaries between services with genuinely different privilege levels — this is what causes lateral-movement-style threats to be missed, since nothing on the diagram flags the crossing as interesting. A third is inconsistent granularity, where one branch of the diagram is decomposed down to individual functions while another branch is left as a single unlabelled box — this tends to happen when different people contribute different sections, and it produces uneven threat coverage across the system.

A DFD produced once during an initial design review has a short shelf life in any system under active development. Treating the DFD as a living artifact — updated as part of significant architecture changes, not regenerated from scratch during the next annual review — keeps the threat model it feeds meaningfully accurate. Some teams tie DFD updates to architecture decision records (ADRs) or design review sign-off, so a diagram update becomes a natural byproduct of the existing change process rather than a separate maintenance burden nobody owns.

Once the DFD is built and validated, it becomes the direct input to STRIDE-per-element or STRIDE-per-interaction analysis, and it's the artifact PASTA's Stage III (Application Decomposition) produces as well. The time invested in getting the diagram accurate pays off across every subsequent stage of the review — and unlike the specific threats identified in a single session, a well-maintained DFD is reusable across every future threat modelling exercise the system goes through.