A data flow diagram shows where information enters a software system, how it moves, where it is stored, and which people, services, or vendors can access it. This guide provides a repeatable workflow for creating a software data flow diagram, marking trust boundaries, recording data classifications, and reviewing changes before they become documentation or security gaps.
Overview
A data flow diagram (DFD) is a focused software architecture diagram for understanding information movement. It is different from a deployment diagram, which emphasizes infrastructure locations, and from a sequence diagram, which emphasizes the order of interactions in a specific scenario. A DFD answers questions such as: What data does the application receive? Which component processes it? Where is it persisted? Which queue, API, analytics service, or third party receives a copy?
The most useful diagrams are neither exhaustive maps of every function nor vague boxes labeled “backend.” They show meaningful data exchanges at a level that product, engineering, operations, privacy, and security stakeholders can review together. A single system may need several diagrams: a context view for external relationships, a container or service view for internal movement, and a detailed view for sensitive workflows such as authentication, payments, file uploads, or customer exports.
Before drawing, define the scope in one sentence. For example: “This diagram covers customer profile data from account creation through storage, support access, and analytics export.” Record the system name, owner, date, environment, and assumptions beside the diagram. Clear scope prevents a data flow diagram tool from producing a visually precise but practically ambiguous result.
What to track
1. Actors and entry points
Start with people and systems outside the boundary of the application. Include end users, administrators, support staff, mobile clients, browser clients, partner systems, identity providers, payment processors, messaging platforms, analytics services, and scheduled jobs. Label the entry point rather than only the actor: “mobile app submits access token and profile update” is more useful than “user connects.”
2. Processes and services
Group code by responsibility and data-handling behavior. Typical processes include an API gateway, authentication service, order service, file processor, notification worker, reporting job, or administrative console. You do not need every endpoint on the overview diagram. Add detail when a service changes classification, authorization, retention, or ownership.
3. Stores, queues, and caches
Track durable databases, object storage, search indexes, backups, logs, caches, message queues, dead-letter queues, and temporary files. A store should have an owner and a purpose. Record whether it is a system of record, a derived copy, a transient buffer, or an operational artifact. This step often reveals undocumented replicas and data retained in places that were not considered part of the application.
4. Data classifications and movement
Use labels that your team can apply consistently, such as public, internal, confidential, personal, sensitive personal, financial, authentication-related, or regulated. Avoid treating a classification label as a complete security decision; pair it with access requirements, retention expectations, and handling notes. Label each arrow with the data type and operation: “customer email and account ID,” “upload file,” “token validation request,” or “aggregated usage event.” Use directional arrows and distinguish synchronous requests from asynchronous messages when that difference affects failure handling or review.
5. Trust boundaries and third parties
A trust boundary marks a meaningful change in administrative control, network exposure, identity context, or security assumptions. Common boundaries include the public internet, a browser or mobile device, a production account, a separate cloud account, a corporate network, a vendor platform, and an internal service zone. Do not imply that every component inside one boundary is automatically trusted. Record the authentication method, authorization decision, encryption expectation, and owner at important crossings.
| Element | What to show | Review question |
|---|---|---|
| External actor | Person, client, partner, or vendor | Who initiates or receives the exchange? |
| Process | Service, job, worker, or gateway | What transforms, validates, or authorizes the data? |
| Data store | Database, object store, cache, log, or backup | Why is this copy retained, and who owns it? |
| Data flow | Direction, payload, protocol, and timing | Is the transfer necessary and understood? |
| Trust boundary | Change in control, exposure, or identity | What assumption changes at this crossing? |
For a database-focused view, pair the DFD with an ERD or database schema diagram. For a request-level view, link to a sequence diagram for an API request. These complementary diagrams answer different questions without forcing one crowded picture to do everything.
Cadence and checkpoints
Treat the diagram as an operational record, not a one-time project deliverable. Establish a review cadence that matches the system’s rate of change. A monthly review can work for an actively evolving product; a quarterly review may be sufficient for a stable service. The schedule matters less than assigning an owner and defining what evidence triggers an update.
At each checkpoint, compare the diagram with current sources of truth:
- API routes, service repositories, infrastructure configuration, and deployment manifests.
- Database inventories, queue definitions, object-storage locations, backup settings, and log pipelines.
- Identity and access lists, service accounts, secrets references, and vendor integrations.
- Incident reports, architecture decision records, threat models, and privacy or data inventory records.
- Recent pull requests or change tickets that introduced a new field, integration, store, export, or processing job.
Keep a small change log next to the diagram. Record the date, changed flow, affected classification, owner, and follow-up action. For diagrams managed as code, store the source beside the documentation and review diagram changes with the related code change. A visual editor can work just as well when it preserves version history and provides a stable export. See the guide to Mermaid diagrams in Markdown for one docs-as-code approach, or compare diagram formats in Mermaid, PlantUML, D2, and Graphviz.
How to interpret changes
Not every visual change has the same architectural significance. A new internal call may alter performance or ownership, while a new external transfer can change privacy, security, and operational review requirements. During review, classify changes by what they affect:
- New data: A field, file type, identifier, or event appears that was not previously documented.
- New destination: Data reaches a new database, queue, log, analytics platform, or third party.
- New privilege: A service, employee role, vendor, or support workflow gains access.
- New boundary: Data crosses from a client to the public API, between environments, or into another organization’s control.
- New lifetime: A temporary value becomes durable, replicated, backed up, or retained in logs.
- Changed ownership: Responsibility moves to another team, account, service, or provider.
Use these changes to drive questions, not automatic conclusions. Ask whether the transfer is necessary, whether the receiving component has a documented owner, whether access is narrower than the data set, and whether deletion or correction workflows reach every relevant copy. For threat modeling, inspect each trust-boundary crossing for spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation concerns. The diagram helps locate questions; it does not replace testing, configuration review, or an organization’s formal security process.
A practical review template is: flow, data, source, destination, owner, classification, access, retention, boundary, control, evidence, follow-up. If any field is unknown, mark it explicitly instead of filling the gap with an assumption.
When to revisit
Revisit the software data flow diagram on the planned monthly or quarterly checkpoint and immediately after events that can change the system’s information map. These include adding an integration, adopting a new identity provider, introducing a queue or cache, changing database or cloud architecture, launching a new export, modifying logging, migrating environments, acquiring a service, or responding to an incident. Also update it when a privacy review, threat model, audit preparation activity, or major API redesign exposes an undocumented flow.
Use this final checklist before marking a review complete:
- Confirm the scope, date, environment, and diagram owner.
- Trace each important data type from entry point to processing, storage, copies, and deletion or expiry path.
- Check every external dependency and third-party transfer for ownership and purpose.
- Mark all trust boundaries and annotate the control or assumption at each crossing.
- Look for stores that have no owner, flows with unclear direction, and access broader than the stated purpose.
- Compare the diagram with repositories, infrastructure configuration, data inventories, and recent changes.
- Record open questions and assign follow-up owners rather than hiding uncertainty.
- Link the diagram from the relevant architecture or developer documentation so future changes start from the current view.
Keep the overview readable, link to deeper service, database, Kubernetes, or request diagrams where needed, and make the next review date visible. A maintained data flow diagram becomes a practical decision record: it helps teams see where information moves today and identify what must be reconsidered when the system changes.
For related architecture views, see the guides to C4, cloud, and microservices diagrams and Kubernetes architecture diagrams.
