What is a data flow diagram in threat modeling?

A data flow diagram in threat modeling is a drawing of how data moves through one system, made so a team can ask what could go wrong with it. The same three words name an older thing, the data flow diagram of classic software engineering, which models business processes and carries no security meaning. This guide is about the security one: much the same shapes put to a different job, plus one element type that does most of the work, the trust boundary. DFD is the abbreviation, and it means this one.

OWASP's Threat Modeling Cheat Sheet says data flow diagrams "are arguably the most common approach" to modelling a system for threat modeling, and describes what a good one gives you: "a clear view of trust boundaries, data flows, data stores, processes, and the external entities" that interact with the system. Five kinds of thing, and that is the whole notation.

Why a data flow diagram matters

The Threat Modeling Manifesto frames the practice as four questions: "What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?" OWASP's cheat sheet repeats them word for word. The diagram is the answer to the first question, and each of the other three needs something the one before it produced.

Without a diagram the second question has nothing to ask of, so a threat modeling session is a brainstorm, and a brainstorm finds what the loudest person in the room remembers. With one, the unit of work changes. Every threat is anchored to an element, every element gets the same questions, and at the end of the session you can say which parts of the system were looked at and which were not. That last part is the difference between a meeting and a method.

There is an external reason as well. CISA, the NSA, the FBI and fifteen international partners wrote in Shifting the Balance of Cybersecurity Risk (April 2023, revised 25 October 2023) that "secure by design products start with written threat models that describe what the creators are trying to protect and from whom", and that effective models cover the enterprise and development environments as well as the way the software is meant to be used by customers. That is guidance for software makers, not a rule anyone enforces, but it has changed what customers ask for, and it turns a diagram drawn in a room into an artefact other people read.

What earns a model is a change, not a date on a calendar. Four triggers cover most of it: a new system or a materially new service, a new external integration, a change to authentication or authorisation, and a new category of data. Our step-by-step guide to threat modeling sets out the method those triggers start; this page stays on the diagram.

The last reason is what happens afterwards. Number the elements and a threat can name the thing it targets, a control can name the threat it answers, and an assessor's question can be walked backwards from the evidence to the design decision that produced it. An unnumbered picture carries none of that, and gets redrawn from scratch every time somebody asks.

How to draw a data flow diagram, step by step

The notation is small enough to hold in your head, which is the point: anyone in the room can read the drawing, argue with it and correct it. Five element types, and each attracts a different set of questions later.

Ten steps take a blank page to a diagram that has been checked, questioned and decided on. The first eight produce the drawing; the last two are what the drawing was for.

1. Set the scope and the question

Scope is the step teams skip and then pay for. Model one system and its immediate neighbours: everything past the first hop is an external entity with an arrow pointing at it, which is what keeps a diagram from turning into a map of the company. Write the protection question down in one sentence before drawing anything, because every later argument about a control is really an argument about whether a particular loss matters.

2. Place the external entities

Start outside. An external entity is anything that interacts with the application from outside it, and the defining property is that you cannot change how it behaves: you decide only what you accept from it and what you send it. Each one is a place where your assumptions meet somebody else's decisions.

3. Draw the processes

A process is code that handles data: it reads something, decides something, writes something. One per responsibility you would defend separately, and the test is whether splitting the element would change an answer. Three copies of the same service behind a load balancer are one process: same code, same credentials, same level of trust. A gateway that authenticates and a service that acts on the authenticated request are two.

4. Add the data stores

A data store is anywhere data rests, and OWASP's definition is the one to draw by: data stores do not modify the data, they only store it. Databases are the obvious ones. The stores that get missed are the quiet ones: caches, message queues, object storage, log files, exports on a shared drive and backups. They hold the same data as the database, in much the same shape, and they are guarded less carefully.

5. Draw every flow with what it carries

Draw one arrow per direction, and label each one with three things: what data moves, over what protocol, and what authenticates it. The label to aim for reads "Order request, HTTPS, session cookie", with all three slots filled; an arrow labelled "API call" leaves every one of them open. The labels matter more than they look, because most threats are found by reading them: an arrow carrying personal data with nothing in the authentication slot has just written its own threat.

6. Mark the trust boundaries

Boundaries go on last, once there is something to draw them around. A trust boundary is used, in OWASP's words, "to represent the change of trust levels as the data flows through the application", and boundaries "show any location where the level of trust changes". Microsoft's tutorial draws them as red dotted lines "to show where different entities are in control", which is the practical test: if the two sides of the line have the same owner, the same credentials and the same exposure, there is no boundary there.

Three questions settle it, and in practice the boundaries you draw fall in four places.

Two of the four have somebody else on the far side. With the boundaries on, the drawing has been built in five passes, one kind of thing at a time.

7. Number every element

Give every element a code and keep it: EE for external entities, C for components or processes, DS for data stores, DF for data flows, TB for trust boundaries. A numbered element can be named by a threat, a control, a test, a ticket and an audit finding, and all five will be talking about the same thing a year later.

8. Check it against the real system

Now go and look. Read the code, the configuration, the infrastructure definition, and correct the drawing where it is wrong. Most diagrams drawn from memory are wrong somewhere, and the wrong places are interesting: a flow nobody expected, or a credential shared between components meant to be separate.

9. Ask the six STRIDE questions, element by element

STRIDE is Microsoft's taxonomy of six threat categories, and the letters are the mnemonic: spoofing (using someone else's authentication information), tampering (malicious modification of data, at rest or in transit), repudiation (a user denies an action and nothing can prove otherwise), information disclosure (exposure to people not meant to have access), denial of service (denying service to valid users) and elevation of privilege (an unprivileged user gains privileged access). Ask all six of every process. For the other element types some questions have nothing to bite on, and the STRIDE walkthrough on our blog sets out which letters attach to which element type. Work the flows that cross a boundary first.

10. Decide every threat, and record the decision

Every threat leaves the session in one of three states: the design changes so the threat has nowhere to land, a control is added and written as something an engineer builds, or the risk is accepted by a named person with a date against it. Analysis with no decision is the habit the Threat Modeling Manifesto names as the anti-pattern "Admiration for the Problem".

How much detail is enough

Two diagrams of the same system can both be right at different depths, and teams talk about depth in levels: a context diagram that fixes the scope, a level 1 diagram that opens the system up into the parts holding or moving data, and a level 2 diagram that opens up one of those parts when a question needs it.

A worked example: a customer portal with an API and a database

An online retailer lets customers sign in to a portal and look at their past orders. The browser calls an API gateway, the gateway calls an order service, and the order service reads an orders database that holds line items, delivery addresses and the last four digits of the card used. A new release is about to add order cancellation, which is a change to what the service can do on a customer's behalf, so the team threat models the design before it is built.

Step 1, scope and question. One system and its immediate neighbours: the portal's read and cancel paths, and the customer at the other end of them. The protection question is written in a sentence: no customer should ever see, or change, another customer's order.

Steps 2 to 4, the elements. One external entity, EE1, the customer browser, which is a device the retailer does not control and cannot inspect. Two processes: C1, the API gateway, which ends the connection and authenticates the session, and C2, the order service, which builds and runs the query. One data store, DS1, the orders database. The team argued about whether the gateway deserved its own element and decided it did, because C1 holds the session and C2 does not: a compromise of one is not a compromise of the other.

Steps 5 and 6, flows and boundaries. Five flows and two boundaries, drawn in that order.

DF1 and DF5 are drawn separately because they carry different data and fail differently: a session cookie and an order identifier going in, delivery addresses and the last four digits of a card coming back out into a browser. DF3 carries two movements on one arrow, the order query and the cancellation update, because the release puts the write on the same path to the same database account; if the update ever moves to its own credential, it becomes its own flow. DF2 is the other judgement call. The request from C1 to C2 and its reply travel the same authenticated channel inside one boundary, so the team drew one flow with an arrowhead at each end and wrote down why: if the reply ever starts carrying data the request does not, it gets its own number.

TB1 is the internet edge: everything inside it is under the retailer's control, and EE1 is not. TB2 is the line between the application tier and the data tier, and it exists because the database account C2 holds can read and change every order in the system, while C2 itself is only ever meant to act for one customer at a time. Four crossings fall out of those two lines: DF1 and DF5 across TB1, DF3 and DF4 across TB2. Those four are where the session gets shown, where the query gets trusted and where the personal data comes back, and they are where the walk starts.

Steps 7 and 8, numbers and the check. Every element got a code. The check against the running system found one disagreement worth having: a second engineer had drawn C1 reading DS1 directly for a status widget on the account page. Reading the code settled it. The widget calls C2 like everything else, and the drawing above is what runs.

Step 9, the walk. Six questions of each element, and the flows that cross a boundary first.

Five threats came out of it, T1 to T5, and two of them are worth following here. T2 is the one that paid for the session. C2 looked orders up by the identifier in the request, and nothing in the query said which account owned them, so changing a digit in the request would have returned somebody else's order. T4 arrived with the cancellation feature and would not have existed a release earlier: a customer says they never cancelled the order, and nothing records which account asked.

C1 is the one process the walk finished empty, and the drawing explains why: it authenticates and forwards, it stores nothing, and the two questions it would have failed are asked of DF1, which reaches it, and of C2, which trusts what it sends. Four of the five flows came back empty as well. An element with nothing against it is a result, not a gap, and each one was recorded as such so the next person does not assume it was skipped.

Step 10, the decisions. T2 changed the design instead of adding a control: C2 now builds every query and every update from the account identifier C1 authenticated, and the identifier in the request only narrows a set that is already restricted to that account. The rule is written as CTL-02 and a test goes with it. T1 became CTL-01, which binds the session to the account and re-authenticates before an address change or a cancellation. T3 became CTL-03, a rate limit at C1 per account and per source address, written as a build requirement with a number in it. T4 became CTL-04: C2 writes an event for every order change, carrying the account, the time and the request identifier, into a store C2's own account cannot rewrite. That store is not on the diagram above, because it does not exist yet. It arrives on the next pass as a second data store with a flow into it, and the coverage figure drops the day it is drawn, because a new element turns up carrying six unanswered questions.

T5 was accepted. Encrypting the address columns meant a migration the release could not carry, so it became RISK-207 on the register, owned by the engineering lead, with an expiry at the end of March 2027 and two compensating steps recorded against it: DS1 accepts connections only from C2, and reads on it are logged. Accepting a risk this way is a decision with a name and a date on it, which is a different thing from not having noticed.

What the numbers did afterwards. CTL-01 to CTL-04 left the review as build requirements written against the elements they protect, so each one can be tested without reading the whole design: the tester checks CTL-04 by cancelling an order and reading the event back. When a nightly export job is added inside C2 two releases later, the level 1 diagram does not change, because the job sits inside an element already drawn. A level 2 diagram of C2 answers what the export sends and where it goes, and the new flow out of the retailer's network gets its own crossing and its own questions. An assessor asking later how the portal keeps one customer out of another customer's orders gets CTL-02, the threat that produced it, the element it sits on and the test that proves it.

Common mistakes

Eight failure modes account for most of the data flow diagrams that produce nothing. They share one root: the drawing gets treated as the deliverable instead of as the thing the questions are asked of.

1. Drawing the deployment instead of the data. A network diagram answers where the software runs, which is a real question and a different one. The fix is to translate it: a box becomes an element only if it holds or handles data, and the copies collapse into one.
2. No trust boundaries, so every element on the page looks equally exposed. The fix is to draw the boundaries before the walk starts, and to start the walk on the flows that cross them.
3. Unlabelled arrows. An arrow with no label is an unasked question, because the question is in the label. The fix is three slots on every flow: what moves, over what protocol, authenticated how.
4. One diagram for the whole estate. It takes a month, it is wrong by the time it is finished, and nobody opens it. The fix is OWASP's: one high-level diagram for scope, plus focused ones for the sub-systems that need them.
5. Chasing a perfect picture. The Threat Modeling Manifesto names this anti-pattern "Perfect Representation". A diagram that is good enough to argue with beats a diagram that is still being drawn.
6. Forgetting the quiet stores. Caches, queues, log files, exports and backups hold the same data as the database and are guarded less. The fix is to ask where else this data exists before the boundaries go on.
7. Analysing without deciding, which the same manifesto calls "Admiration for the Problem". The fix is a rule that no threat leaves the session without one of three decisions and a name against it.
8. A diagram that goes stale because nobody owns it. The fix is to re-open the model on the four triggers above, not on a calendar.

The first mistake is worth showing, because the translation out of it is mechanical. The portal has a perfectly good infrastructure drawing: an internet gateway, a load balancer called alb-01 in a public subnet, three application servers called app-01 to app-03 in another, and db-primary and db-replica in a third. It is accurate, it is useful for other work, and almost none of it survives the translation.

Seven boxes and four frames become four elements, and two things appear that the infrastructure drawing had no way to show: the customer at the other end of the connection, and the line where trust changes.

A data flow diagram compared with its neighbours

Two questions separate them: how much of the system each drawing covers, and whether it is drawn to explain the system or to find what could go wrong.

Everything in the right-hand half is a way of finding what could go wrong. The rest clears up in one line each.

Microsoft makes a point in its own tutorial that stops the comparison turning into an argument: thinking about assets, thinking about attackers and thinking about software design are all workable entry points into threat modeling. Microsoft teaches the software-design entry and says why plainly, that many software engineers understand their software better than they understand the concept of assets. Pick the entry your team can start from.

Standards and references

OWASP Cheat Sheet Series, Threat Modeling Cheat Sheet (read September 2026). The current OWASP guidance: the four questions, the "arguably the most common approach" line, the advice to keep one high-level diagram plus focused ones, and the tooling list. The page carries no publication date.

OWASP, Threat Modeling Process (read September 2026). The older OWASP page, which OWASP itself marks historical. Its element definitions are still the clearest short ones in print, including the privilege boundary as the change of trust levels as data flows through an application.

Microsoft Threat Modeling Tool documentation (articles dated 17 August 2017, getting started updated 10 December 2025, threats updated 4 March 2026) and the Microsoft Learn module Create a threat model using data-flow diagram elements (27 March 2025, updated 3 April 2025). The module teaches the five element types one unit each, and of the pages read for this guide it is the clearest short teaching of the notation. The threats article carries the STRIDE definitions quoted above, and the tool it documents generates threats per interaction from them.

The Threat Modeling Manifesto (2020). Written by fifteen practitioners including Adam Shostack. It holds the four questions, a set of values and principles, and the two anti-patterns named in this guide.

Adam Shostack, Threat Modeling: Designing for Security, Wiley (February 2014). Book-length coverage of the practice, from one of the manifesto's authors. A second edition, Threat Modeling: Designing for Security in an AI World, is announced for 2 February 2027.

NIST SP 800-154, Guide to Data-Centric System Threat Modeling (initial public draft, March 2016). The published alternative entry point, starting from the data to be protected instead of the system drawing. It has been an initial public draft for a decade, with a NIST note in January 2025 stating an intention to finalise it, so cite it as a draft.

CISA, NSA, FBI and fifteen international partners, Shifting the Balance of Cybersecurity Risk (April 2023, revised 25 October 2023). Guidance for software manufacturers, and the source of the position that secure by design products start with written threat models.

How Alvor helps

With Alvor, the diagram is the record rather than a picture of one. You model the system on a canvas where components, datastores, data flows, external entities and trust boundaries are all first-class elements. Each one is numbered, C1 for a component or DS1 for a datastore, and each can link to the asset it represents in your inventory, so the element on the drawing and the asset in the register are the same thing rather than two descriptions of it.

Threats hang off those elements. A threat is anchored to the element it targets and carries a STRIDE category, a severity and a status, and it can reference a MITRE ATT&CK technique by ID, sit on a Cyber Kill Chain phase or cite an OWASP or CAPEC source. Mapping a threat to a control assigns that control to the project and flags it as threat-driven. Those are the same controls the Compliance module cross-maps across frameworks such as ISO 27001, SOC 2 and NIST CSF, so a mitigation decided at the whiteboard becomes evidence for every framework that control satisfies. A threat you cannot mitigate is accepted as a risk with an owner and a rationale on the register, which is where an entry like the worked example's RISK-207 lives.

Coverage recounts as the diagram changes, so an element added in a redesign shows up as unanalysed, not quietly unasked, and the question "which parts of this have we looked at" keeps a current answer. For the drawing itself, the AI Design Studio draws the architecture as editable shapes from a written description or a photograph of a whiteboard, which needs a vision-capable model, and the AI Threat Modeling Studio reads the diagram, registers elements and proposes threats from your library, with each batch pausing on an approval card showing the exact payload for a person to approve or reject.

Every module runs in every deployment: a dedicated single-tenant instance in the region you choose, the same containerised platform on your own servers, or fully air-gapped with a self-hosted model such as vLLM or Ollama inside the boundary. Threat Modeling in Alvor covers the canvas, the STRIDE walk and the coverage figures in more detail.