How to Construct a Data Flow Diagram for CMMC Scoping

Constructing a Data Flow Diagram (DFD) is a useful way to determine an organization’s scope with respect to how Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) is processed, stored, or transmitted through a system.  A DFD maps out the flow of information for any process or system, focusing on what the system does rather than how it does it.

A DFD for FCI and CUI, along with a system boundary diagram, is usually included in the organization’s System Security Plan.

Here is a step-by-step guide to constructing a clear and accurate Data Flow Diagram.

1. The Basic DFD Symbols

Using the drawing symbols typically found in constructing a DFD isn’t critical, but most software drawing applications will provide or default to these symbols.

There are four standard symbols used in DFDs. There are also two main notation styles (Gane & Sarson and Yourdon/DeMarco), but the concepts are identical.

External Entity (Source/Sink): A square or rectangle. This represents where data comes from (source) or goes to (destination) outside the system (for example, customers, managers, external data sources).
Process: A circle or rounded rectangle. This represents a task or function that transforms data (for example, “Edit File”, “Verify Login”).
Data Store: An open-ended rectangle or two parallel lines. This represents data at rest (for example, Databases, Filing Cabinets).
Data Flow: An arrow. This represents data in motion moving between the other three components.

2. Step-by-Step DFD Construction

Step 0: Choose the DFD Construction Method

The standard approaches for constructing a DFD are:

Top-down—start with the highest level of abstraction (the “big picture”) of the system and break it down into details. 
Bottom-up—lay out the most detailed level of the system and build up from that level to greater abstraction.
Meet-in-the-middle—start at both the highest and lowest levels of the system simultaneously. Break the highest levels into more details and abstract the lowest level to less detail until the top-down and bottom-up approach meet in the middle.

Most DFDs are constructed top-down, since people find thinking about the highest-level system and then breaking it down into details to be easiest. However, there is no “right” answer—proceed in the way that feels most natural.

The following steps present constructing a DFD using a top-down method.

Step 1: Determine the Scope (Level 0 / Context Diagram)

The Context Diagram represents the entire system as a single process. It shows the system’s boundaries and how it interacts with the outside world.

Draw one single process bubble in the center and label it with the system name (for example, “Contract Management System”).
Identify all External Entities that interact with the system (for example, Invoicing, Financial Reporting, Proposal Development). Place them around the central process.
Draw data flows (arrows) between the entities and the main process.
Ask: What data does the Customer send? (Contract documents, Statement of Work).
Ask: What data does the System send back? (Invoices, Progress reports).

Step 2: Expand the Context Diagram into a Level 1 Diagram

Now, break that single “System” bubble into its major sub-processes. This provides a more detailed view of the major functions.

Identify major functions: If your system is “Contract Management System,” major processes might be: “1.0 Proposal Development”, “2.0 Contract Execution, and “3.0 Invoicing and Reporting”.
Add Data Stores: This is usually the first level where databases or files appear. (for example, “Proposal Documents”, “Contract Documents”).
Connect the flows: Ensure the inputs and outputs from your Context Diagram (Step 1) match the inputs and outputs here. This is called “balancing” the diagram.

Step 3: Review and Refine (Level 2 and beyond)

If a specific process in Level 1 is still too complex (for example, “Invoicing and Reporting” involves “work completion validation”, “invoice generation”, and “contract deliverable tracking”), continue to break down each level until each bubble in the diagram represents a simple, atomic task or object.

For CMMC, the goal is to refine the data flow diagram until you can determine all of the objects, such as Virtual Desktop Infrastructure (VDI) nodes, physical servers or computers, network routers, firewalls, databases, etc., where FCI or CUI is processed, stored, or transmitted.

3. DFD Validation 

To ensure the diagram is logically sound, validate the diagram against these rules:

No “Black Holes”: A process cannot have only inputs. It must produce an output.
No “Miracles”: A process cannot have only outputs. It must have an input to process.
Data Store Restrictions:
Data cannot move directly from one Data Store to another store, the data must go through a process.
Data cannot move directly from an Entity (external system object) to a Data Store, the data must be processed first. (Processing can just be formatting; for CMMC, this could be labeling with data handling restriction markings)
Entity Restrictions: External Entities cannot send data directly to each other. (If they do, then this activity is outside the scope of your system and should not be shown in your diagram).

4. Summary Table of Allowable DFD Connections

Use this quick reference to check if a connection line is valid: