Data Flow Diagrams 101

This guide explains what data flow diagrams (DFDs) are, when government teams must produce them, and how to create one that satisfies both technical and privacy review requirements. It covers the four elements of a DFD, the three levels of detail, government-specific labeling requirements, and how DFDs support Authority to Operate (ATO) packages.

Engineers, architects, and technical leads at government agencies who need to document how data moves through a system will find it most useful — especially systems that handle personally identifiable information (PII), protected health information (PHI), or other sensitive data.

TL;DR

A data flow diagram shows where data comes from, where it goes, how it’s transformed, and where it’s stored. For government systems handling PII or PHI, it is a required artifact — not optional documentation. Build it early. Label every sensitive flow. Keep it current.

Draw a Level 0 context diagram first. Expand to Level 1 before your first security review.

Every arrow that carries PII, PHI, or CUI must be labeled with the data classification.

Every data store needs an encryption indicator and a retention label.

A privacy officer should be able to trace any piece of PII through the diagram from collection to disposal without asking you a single question.

Data Flow Diagram Fundamentals

A data flow diagram is a visual map of how information moves through a system. It shows the inputs and outputs of a system, the processes that transform data, the places where data is stored, and the external actors who send or receive data.

A DFD is not the same as an architecture diagram. An architecture diagram shows how components connect — servers, services, load balancers, network boundaries. A DFD shows what data flows between those components and what happens to the data along the way. Both are useful, and they answer different questions: an architecture diagram answers “What is this system made of?” while a DFD answers “If a piece of PII enters this system, where does it go, who can see it, how is it stored, and where does it end up?”

In a security review or privacy audit, auditors will reach for the DFD. If it does not exist, or if it is incomplete, the review stalls.

When Government Teams Need a DFD

You need a DFD any time your system collects, stores, transmits, or processes sensitive data. In government contexts, this means any system that touches:

Personally identifiable information (PII): Names, addresses, Social Security numbers, dates of birth, financial records, or any combination of data that could identify a specific person.
Protected health information (PHI): Any health data governed by HIPAA, including diagnoses, treatment records, and insurance information.
Controlled Unclassified Information (CUI): Sensitive federal data that is not classified but still requires controlled handling under the National Archives CUI program.
For Official Use Only (FOUO): A legacy marking that overlaps significantly with CUI. Many agencies are transitioning away from FOUO toward CUI, but you will still see it in older systems and contracts.
Payment card data (PCI): Credit and debit card numbers and related cardholder data.

Even if your system only touches PII briefly — for example, a form that collects a name and routes it to another service — you still need a DFD. That brief touch is precisely what security reviewers want to see documented.

If you are pursuing an Authority to Operate (ATO) for a federal system, a DFD is almost always required as part of the System Security Plan (SSP). FedRAMP authorization packages require a network and data flow diagram at a minimum.

The Four DFD Elements

External entities

External entities are people, organizations, or systems that exist outside the boundary of your system but interact with it. They are the source or destination of data that flows into or out of your system.

External entities are important because they define your system’s boundary. Everything inside the boundary is your responsibility. Everything outside it is not — but you are still responsible for documenting the data that crosses the boundary in both directions.

Examples of external entities in a government benefits system: A citizen submitting an application. A federal agency receiving a nightly data export. A payment processor receiving transaction data. An identity provider (like Login.gov) that authenticates users before they reach your application. On diagrams, external entities are drawn as rectangles at the edges of the diagram.

Processes

A process is any function or activity that receives data, transforms or routes it, and produces output data. Processes are the “work” inside your system.

Name processes with active verb phrases that describe what they do. “Validate eligibility” is a good process name. “System” is not. Each process gets a unique number (P1, P2, P3) so you can reference specific processes in written documentation without redrawing the diagram.

Examples of processes: “Receive and validate application form.” “Check eligibility against federal income database.” “Generate monthly statistical report.” “Encrypt and route uploaded documents.” On diagrams, processes are drawn as circles or rounded rectangles. A process that has no inputs or no outputs is a broken process — data has to come from somewhere and go somewhere.

Data stores

A data store is any place where data is held at rest. This includes databases, file storage, message queues, caches, archives, and even physical filing systems.

Data flows into data stores (writes) and out of data stores (reads). A data store with no inflows or outflows is a dead store — it should either be removed from the diagram or investigated.

For government systems, every data store needs three additional pieces of information beyond its name: what data it holds, how long it retains that data, and how the data is encrypted. Missing these details is a common ATO finding.

Examples: An agency PostgreSQL database holding approved applications. An S3 bucket holding uploaded supporting documents. A Redis cache holding session tokens. On diagrams, data stores are drawn as open-ended rectangles (two parallel horizontal lines).

Data flows

A data flow is the movement of data from one element to another. On a DFD, it is drawn as a labeled arrow. The label is the most important part.

The label must describe what kind of data is moving, not just that something is moving. “Application form data (PII — Name, DOB, SSN)” is a correct label. “Data” is not a label — it is a placeholder that tells the reviewer nothing.

For government systems, every arrow that carries sensitive data must also carry that data’s classification label. Every arrow must have a label. An unlabeled arrow on a government DFD is an automatic finding in a security review.

Figure 1 (placeholder) — A data flow diagram for a government benefits application. Show: a citizen external entity submitting a form, a web application process (P1) receiving it, a validation process (P2) checking eligibility, an agency database storing the approved application, a federal reporting data store receiving a subset of data (no PII), and a document storage system for uploaded files. Label every arrow with the data type flowing across it and mark PII-carrying flows with a red PII badge. Show encryption indicators on data-at-rest stores (EAR: AES-256) and transit encryption labels on arrows (TLS 1.3). Show retention labels on each data store.

DFD levels

DFDs come in three levels of detail. You choose the level based on who the audience is and what question you are trying to answer. You do not always need all three levels. Every system needs at least a Level 0. Most systems in a government context need a Level 1.

Level 0 — Context diagram

A Level 0 DFD, called a context diagram, shows the entire system as a single process box surrounded by all external entities. Arrows show what data flows in and out of the system boundary. Nothing inside the system is shown at this level.

Use a Level 0 diagram when you need to show stakeholders, executives, or program managers the scope of a system at a glance. It takes ten to twenty minutes to draw, and it answers the question: “What does this system touch?” Most ATO packages start here, and a context diagram is the right thing to show leadership in a kickoff meeting.

A good context diagram test: If someone sees this diagram and cannot tell whether an external system or actor is in scope or out of scope for this ATO, the diagram is wrong.

Level 1 — Main processes

A Level 1 DFD explodes the single system box into its major sub-processes. You show each main function of the system as a labeled process, connect them to each other and to data stores with labeled flows, and show all external entity connections.

Level 1 is the primary working diagram. Security reviewers use it during ATO reviews. Your own team uses it to understand how the system is supposed to work. This is the diagram that typically appears in a System Security Plan.

It should be detailed enough that a reviewer can trace any PII from the moment it enters the system to the moment it is stored, forwarded, or deleted — without needing to ask you clarifying questions. If a reviewer cannot do that from the Level 1 diagram alone, it is too abstract.

Level 2 — Detailed processes

A Level 2 DFD breaks one specific Level 1 process into its internal sub-steps. Not every process needs a Level 2 diagram. Use Level 2 when a specific process handles sensitive data in complex ways that reviewers need to understand in detail.

For example: An “Eligibility Validation” process that calls three external APIs, applies income and residency rules, logs each decision to an audit table, and handles appeals separately would benefit from a Level 2. A simple “Store record in database” step does not need one.

Level 2 diagrams are most valuable for processes that are the subject of specific compliance controls — for example, the process that handles SSN storage or the process that transmits data to a federal partner system.

Government-specific requirements

Label every PII and PHI flow

Every arrow that carries PII or PHI must be labeled with the data classification. Do not just label an arrow “data.” Security reviewers need to know what kind of data is present. “Name, DOB, SSN (PII)” is acceptable. “User data” is not.

Use the labels your agency has standardized. If your agency does not have a standard, adopt the federal CUI registry categories from the National Archives: CUI Registry category list.

Data residency

Mark on the diagram whether data is leaving the jurisdiction of your agency, state, or federal system. Data that moves to a cloud provider in a foreign country, or to a vendor system hosted outside your authority boundary, requires documentation and in many cases a legal agreement.

Add a note on any data store or flow where physical data location matters. For example: “Stored in AWS GovCloud us-gov-west-1” or “Replicated to vendor SaaS — data residency: US only per contract section 7.2.” If you do not know where a vendor stores data, that is a gap that must be resolved before ATO.

Encryption indicators

Every data store must be marked with its encryption status. Use consistent notation on the diagram.

At rest: is the data encrypted when stored, and with what standard? FedRAMP systems require a minimum of AES-256 for data at rest. Mark each store with EAR: AES-256 or EAR: None (a red flag) as appropriate.

In transit: is data encrypted in transit? Mark each data flow with the transport security standard. TLS 1.3 is the current best practice. TLS 1.0 or TLS 1.1 is a finding. Unencrypted flows are a critical finding.

If your diagramming tool does not have space for inline labels, create a data flow table that accompanies the diagram and lists each numbered flow with its encryption status.

Data retention labels

Every data store needs a retention label that answers three questions: How long is this data kept? Under what legal authority or records schedule? What happens to it when the retention period ends?

Examples of acceptable retention labels:

“Retained 7 years per [Agency Records Schedule RS-003]. Archived to tape, then destroyed.”
“Purged 90 days after case closure. Purge runs nightly via automated job.”
“Retained indefinitely under active legal hold — [case number].”

Missing retention labels are one of the most common ATO findings. Add them early in the documentation process rather than retrofitting them after a review.

Data authority

For every major data element in your system, document who the authoritative source is. If you receive a citizen’s address from a federal identity system, that federal system is the authority for address data — your copy is a downstream replica. If there is ever a conflict between your record and the authority’s record, the authority wins.

Documenting data authority matters for audit trails and for data correction requests under privacy law. When a citizen disputes a record, you need to know whether you own it or whether you need to route the dispute upstream.

How DFDs support ATO packages

An Authority to Operate is a formal approval from an authorizing official that a federal system may operate. Most federal systems require an ATO before going live, and many state systems have equivalent processes (often called security accreditation or certification and accreditation).

Security reviewers reading an ATO package use the DFD to answer five questions:

Scope: What is the system boundary? What components are in scope for this ATO and what is explicitly out of scope?
Data sensitivity: Does the system touch PII, PHI, or CUI? If so, does it have the controls required for that data type?
External connections: What third-party systems does this system connect to? Are those systems approved? Do they have their own ATO or FedRAMP authorization?
Encryption: Is data encrypted everywhere it should be? Are there unencrypted flows or stores?
Retention: Is data kept only as long as required, and no longer?

If the DFD is missing, incomplete, or contradicts the written System Security Plan, reviewers will issue findings that delay the ATO. A clear, accurate, and current DFD often saves weeks of back-and-forth with the authorizing official’s office.

NIST SP 800-18 (Guide for Developing Security Plans for Federal Information Systems) and the FedRAMP SSP template both require data flow diagrams as a named deliverable. The FedRAMP templates are available at FedRAMP documents and templates.

Labeling sensitive data flows

Use consistent, agency-approved labels for every sensitive data classification. The table below shows the most common labels used in federal and state government systems.

Label	Full name	What it means	Governing authority
PII	Personally Identifiable Information	Data that can identify a specific individual	OMB M-07-16, Privacy Act
PHI	Protected Health Information	Health data governed by HIPAA	HIPAA Privacy Rule (45 CFR Part 164)
CUI	Controlled Unclassified Information	Sensitive federal data with handling requirements	32 CFR Part 2002, NARA CUI Registry
FOUO	For Official Use Only	Legacy federal label; largely replaced by CUI	DoDI 5200.48 (DoD); legacy at civilian agencies
SBU	Sensitive but Unclassified	Common at state level; similar to CUI	Varies by state policy
PCI	Payment Card Industry data	Credit/debit card numbers and related cardholder data	PCI DSS (industry standard)

Add the label directly on the data flow arrow in the diagram. If your diagramming tool supports color, use red for PII/PHI flows and orange for CUI flows. Color alone is never sufficient — always include the text label, because diagrams are often printed in black and white and reviewed by people with color vision differences.

A Mermaid DFD example

The example below models a simple government benefits application. Mermaid does not have a native DFD notation, but a flowchart captures the same structure and can be stored in version control alongside your code. For formal ATO packages, use a dedicated diagramming tool such as Lucidchart, draw.io, or Microsoft Visio that supports proper DFD notation (Gane-Sarson or Yourdon-DeMarco).

flowchart TD
    Citizen([Citizen]) -->|"Application: Name, DOB, SSN — PII"| WebApp["P1: Receive and\nRoute Application"]
    Citizen -->|"Supporting documents — PII"| WebApp

    WebApp -->|"Applicant data — PII"| Validation["P2: Eligibility\nValidation"]
    WebApp -->|"Encrypted documents — PII"| DocStore[("Document Storage\nEAR: AES-256\nRetention: 7 years")]

    Validation -->|"Approved application — PII"| AgencyDB[("Agency Database\nEAR: AES-256\nRetention: 7 years")]
    Validation -->|"Denial notification — no PII"| Citizen

    AgencyDB -->|"Aggregate statistics — NO PII"| FedStore[("Federal Reporting Store\nEAR: AES-256\nOut of agency boundary")]

    style Citizen fill:#e8f5e9,stroke:#388e3c,color:#000
    style AgencyDB fill:#fff3e0,stroke:#f57c00,color:#000
    style DocStore fill:#fff3e0,stroke:#f57c00,color:#000
    style FedStore fill:#e3f2fd,stroke:#1976d2,color:#000

Reading the diagram

Green nodes are external entities (outside your system boundary).
Orange nodes are data stores inside your system’s ATO boundary.
Blue nodes are external data stores outside your boundary.
Rounded rectangles are processes inside your system.
Every arrow label identifies what type of data is in motion.
“NO PII” on the federal reporting flow documents explicitly that the data crossing the boundary has been de-identified. This is a critical marker for auditors.

The privacy review test

Before finalizing a DFD, apply the privacy review test. Hand the diagram to someone who has not worked on the system — ideally a privacy officer or a colleague from a different team — and ask them to answer these five questions using the diagram alone:

Where does a citizen’s Social Security number enter the system?
Where is it stored?
Who or what process can read it?
When is it deleted or archived?
Does it leave the agency’s control at any point? If so, where does it go?

If they cannot answer all five questions from the diagram alone, the diagram is incomplete. Add the missing elements before submitting to a security or privacy review.

This test surfaces the most common DFD failures: unlabeled flows, data stores without retention labels, and external system connections that are treated as undocumented black boxes.

A passing diagram is one where a reasonable privacy officer could sign off on data handling practices without asking the engineering team a single question about the system.

Common DFD Mistakes

Missing external integrations

Teams often draw the boundaries of their own application clearly but omit third-party services that receive data — analytics vendors, identity providers, payment processors, federal databases. Every system your application sends data to must appear on the DFD, even if the data transfer is a nightly batch job or a webhook.

Unlabeled data at rest

Drawing a database box with only a name is incomplete. What data does it hold? How is it encrypted? How long is it retained? What security classification applies? Reviewers will flag an unlabeled data store every time.

Vendor syncs treated as black boxes

“We sync to Vendor X every night” is not a DFD element. Show what data is synced, how it is transmitted (protocol and encryption), who at Vendor X receives it, where Vendor X stores it, and under what data handling agreement.

Stale diagrams

A DFD that reflects the system as it was eighteen months ago is worse than no DFD. It gives reviewers false confidence in a system that has changed. Assign an owner. Review it after every significant system change and at least annually.

Happy-path-only coverage

What happens to PII when a transaction fails midway? Where does the partial record land? What process cleans it up? Error paths often have the worst data handling hygiene and are exactly what an attacker would target.

Unversioned DFDs

A diagram that lives only in someone’s email or on a shared drive with no version history cannot be used to show that controls were in place at a specific point in time. Store DFDs in version control or a document management system with a clear revision history.

Next steps

After completing your data flow diagram, these resources will help you with the next stages of engineering health reporting:

Architecture Diagrams 101 — How to document the infrastructure your system runs on and how to connect it with the DFD.
System Inventory — How to maintain a living inventory of every system, service, and integration in your agency’s environment.
Privacy Impact Assessment basics — How to use your DFD as the primary input to a formal PIA, and what questions a PIA requires you to answer.