DKDavid Koran& Associates
Home The CMMC Guide Part III · Access Control AC.L2-3.1.3
The CMMC Guide · Access Control Family

AC.L2-3.1.3  Control the Flow of CUI

Control the flow of CUI in accordance with approved authorizations.

Family
Access ControlAC, 22 requirements
Point Value
1Lower weight, but not POA&M exempt
POA&M Eligible
YesOne-point requirement, may be deferred
Objectives
FivePer NIST SP 800-171A

1Overview

AC.L2-3.1.3 is the control that asks a deceptively large question: where is CUI allowed to go, and what stops it from going anywhere else. It moves the focus from people and permissions to the information itself and the paths it travels, which is why it sits at the center of the scoping and boundary work that shapes an entire CMMC program.

The requirement is worth one point rather than five, and unlike the first two controls in this family it may be placed on a plan of action. That lower weight understates its importance, because information flow control is where the assessment boundary is actually made real. A contractor who has defined where CUI may move, and enforced those paths, has drawn a boundary the assessor can see; a contractor who has not is claiming a boundary that the information itself does not respect. The control is less about a single setting than about whether the organization has decided, on purpose, which flows of CUI are approved and which are blocked.

The requirement · NIST SP 800-171 Rev 2, 3.1.3

Control the flow of CUI in accordance with approved authorizations.

Two phrases carry the weight. "Approved authorizations" means the organization has determined, in advance, which flows of CUI are permitted: from the engineering share to the machine that cuts the part, out to a specific prime through a specific encrypted channel, into the backup at a defined location. "Control the flow" means those approved paths are enforced and the unapproved ones, CUI to a personal email account, to a consumer file-sharing site, onto an unmanaged USB drive, out an uncontrolled internet path, are prevented. The control is satisfied when the approved flows are documented and the enforcement matches.

2The Assessment Objectives

NIST SP 800-171A decomposes 3.1.3 into five objectives: four that define, identify, and authorize the approved flows, and a fifth that enforces them. They fail together when an organization has never mapped where its CUI is allowed to travel.

[a]

Information flow control policies are defined. A written statement of the approved flows of CUI: where it may originate, where it may travel, where it may leave the boundary, and by what means.

MeetsA documented data-flow map: CUI moves from the engineering enclave to approved primes over encrypted email only, and never to personal accounts, consumer cloud, or uncontrolled USB.
FailsNo statement of where CUI is allowed to go, so every flow is implicitly permitted.
[b]

Methods and enforcement mechanisms for controlling the flow of CUI are defined. The specific means by which each approved flow will be controlled are written down, not just the intent: which firewall rule, which data-loss-prevention policy, which segmentation, which media control enforces which flow.

MeetsThe flow policy names its mechanisms: egress filtering at the boundary, mail DLP for outbound CUI, and USB write control on CUI hosts.
FailsA policy that says CUI "must be controlled" but never states by what method, leaving nothing to test.
[c]

Designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. The endpoints of every approved flow are named: which systems, people, and devices may send or receive CUI, inside the boundary and across connections to other systems.

MeetsThe flow map lists sources and destinations by name: the engineering enclave, the named prime's portal, the specific backup target, and nothing else.
FailsFlows described only in the abstract ("CUI goes to customers") with no identified systems, recipients, or devices.
[d]

Authorizations for controlling the flow of CUI are defined. For each identified source-to-destination flow, a decision on record that it is permitted, so enforcement has an approved baseline to match.

MeetsEach approved flow carries a recorded authorization; anything not on the list is unapproved by default.
FailsNo record of which flows were actually approved, so "approved authorizations" is a phrase with nothing behind it.
[e]

Approved authorizations for controlling the flow of CUI are enforced. The authorizations defined in [a] through [d] are enforced by technical or physical means, so CUI cannot take an unapproved path.

MeetsFirewall rules, mail data-loss-prevention, and blocked consumer-cloud domains stop CUI from leaving by unapproved routes, and USB write is controlled.
FailsA user can attach a controlled drawing to personal webmail or drop it in a consumer file-share, and nothing prevents it.

The pattern is the same one seen throughout this family: a documented flow policy that nothing enforces fails [e], and enforcement with no written definition fails [a] through [d], because the assessor cannot judge enforcement against an intent that was never recorded. Definition and enforcement are assessed against each other.

3Failure Patterns

The failures here are about uncontrolled exits: the paths by which CUI leaves the boundary without anyone having approved them.

The undefined flow

The foundational failure of objective [a]. The organization has never written down where CUI is allowed to move, which means there is no standard against which to enforce anything. Data-flow mapping is unglamorous work, tracing how a controlled drawing enters, where it is stored, which machines consume it, and how it reaches the customer, and it is skipped far more often than it is done. Without it, the remaining controls in this area have no anchor.

The open path to consumer cloud and webmail

A workstation inside the boundary that can reach personal Gmail, consumer Dropbox, or a free file-transfer site is an approved-looking device with an unapproved exit. Objective [e] requires those paths be closed for systems that handle CUI, and on most unmanaged networks they are wide open, because nobody ever had a reason to close them.

The uncontrolled USB port

Removable media is a flow path, and an open USB port is an unenforced one. A controlled file copied to a personal thumb drive has left the boundary entirely, outside any monitoring or encryption. This flow intersects with the media protection family, but it fails 3.1.3 first, as an approved authorization that was never enforced.

The flat internal network

When every device on the shop network can reach every other device, CUI flows freely between systems that should be separated, and the boundary exists only on paper. Objective [b] is where internal segmentation earns its place: separating the CUI environment from general office and guest traffic is how the approved internal flows get enforced, and its absence is how a scoping claim quietly collapses.

The common root
3.1.3 fails when CUI can go somewhere no one approved. The control asks the organization to decide where the information may travel and then to close every other door, which is the same work that makes an assessment boundary real.

4Ownership

This control sits at the meeting point of the people who know where CUI actually goes and the people who can enforce where it is allowed to go. The mapping cannot be done by IT alone, because the real flows follow the work, and the enforcement cannot be done by the business, because it lives in firewalls and policy.

RoleResponsibility for this control
Process and engineering ownersDescribe the real journey of CUI through the operation, from receipt of a controlled drawing to delivery of the part, because the approved-flow definition has to match how the work is actually done.
IT and network leadEnforces the approved flows and closes the unapproved ones: firewall egress rules, network segmentation, mail and endpoint controls, and removable-media policy. Owns the enforcement evidence.
Security or compliance leadOwns the information-flow policy itself and the data-flow map, and keeps them aligned with the system security plan and the defined boundary.
Program leadEnsures the flow map is revisited when the environment changes, since a new machine, a new customer channel, or a new cloud service can open a flow the map does not yet cover.
Executive sponsorAccountable for the boundary the flows define, and for the business consequences of closing convenient but unapproved paths.
See also: The flow map built here is the same artifact that drives assessment scope; reducing where CUI is allowed to travel is the highest-leverage cost decision in a program, discussed in Executive Series, Part 4.

5Tooling

Information flow control is enforced by network and endpoint tooling, most of it already present in a business-grade environment. The design decision, which flows are approved, precedes the tooling and governs how it is configured.

ObjectivesToolingWhat it provides
[a]Data-flow diagram, information-flow policy, the SSP boundary descriptionThe written approved-flow definition. This is a documentation and design artifact; the diagram of how CUI moves is the reference every enforcement control is measured against.
[e], network boundaryFirewall egress rules, VLAN segmentation, managed switchesEgress filtering blocks CUI systems from reaching unapproved destinations, and segmentation separates the CUI environment from office and guest networks so internal flows follow the approved paths.
[e], cloud and mailMicrosoft Purview data-loss-prevention, Conditional Access, domain and category web filteringDLP policies detect and block CUI leaving by mail or to unsanctioned cloud, category filtering closes consumer file-sharing and personal webmail, and Conditional Access confines cloud CUI to managed devices.
[e], removable mediaGroup Policy or Intune removable-storage controls, BitLocker To GoUSB write control and enforced encryption govern the removable-media flow path, closing the uncontrolled exit or bringing it inside policy.

The caveat for this control is about sequence rather than licensing. Every tool above enforces a decision that has to be made first, and buying data-loss-prevention before mapping the flows produces policies that block the wrong things and miss the real exits. The assessor tests objective [e] by attempting an unapproved flow, sending a marked file to a personal account or a consumer share, and watching whether the control stops it, so the enforcement has to match a flow map that reflects how CUI actually moves.

6Evidence

The satisfied version of 3.1.3 shows the approved flows on paper and the enforcement that holds them, and demonstrates that an unapproved flow is actually prevented.

EvidenceWhat it demonstrates
Information-flow policy and data-flow diagramObjective [a]. The written approved flows of CUI through the environment, maintained and dated, consistent with the SSP boundary.
Firewall and egress rule setObjective [b]. The rules that permit approved destinations and deny the rest, showing CUI systems cannot reach unapproved external paths.
Network segmentation designObjective [b]. The separation of the CUI environment from office, guest, and shop-floor networks that enforces the approved internal flows.
Data-loss-prevention and web-filter configurationObjective [b]. The mail and cloud controls that block CUI from leaving by unapproved means, with the policies that define them.
Removable-media control configurationObjective [b]. The USB and removable-storage policy governing that flow path.

The evidence must describe the environment as it runs, because the assessor will attempt an unapproved flow and observe the result, and it must show the flows have been reviewed as the environment changed, since a data-flow map that predates the last new machine or cloud service is already incomplete. This control is also foundational: the flow map produced here defines the boundary that nearly every other requirement operates within, so the work done for 3.1.3 pays into scoping, boundary protection, and the media and communications families alike.

The flow map is walked, not diagrammed from memory

Mapping where CUI actually travels means following it through the operation: the email it arrives in, the share it lands on, the machines that consume it, the channels it leaves by, the drawer and the drive it also sits in that no one mentioned. That tracing is onsite work, and it is where readiness for this control begins, because the map has to reflect the real paths before the enforcement can close the rest.

Start CMMC Readiness or call 802-335-2662

7Sources

  1. NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.3. csrc.nist.gov
  2. NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.3[a] through 3.1.3[e]. csrc.nist.gov
  3. 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov
← Previous in Access Control
AC.L2-3.1.2 · Limit Transactions and Functions
Next in Access Control →
AC.L2-3.1.4 · Separate the Duties of Individuals
About the Author
David W. Koran is a CyberAB Registered Practitioner Advanced and the author of The CMMC Decision, now in its second edition. He works onsite with defense contractors and their counsel, from the first leadership briefing through the pre-assessment review. Reach him at 802-335-2662 or dkoran@davidkoran.com.
Entry AC.L2-3.1.3 · Edition 2026.1 · Last reviewed July 12, 2026