3.1.3Control where CUI is allowed to travel in Rev. 3
No significant change: 03.01.03 Information Flow Enforcement.
Status as of 2026-09-08
Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.
Side by side
Rev. 2 · in force 3.1.3 Control CUI Flow
Assessment objectives · 800-171A
- [a] information flow control policies are defined
- [b] methods and enforcement mechanisms for controlling the flow of CUI are defined
- [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified
- [d] authorizations for controlling the flow of CUI are defined
- [e] approved authorizations for controlling the flow of CUI are enforced
Rev. 3 · not adopted 03.01.03 Information Flow Enforcement
Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.
Determination statements · 800-171A Rev. 3
- 03.01.03[01] approved authorizations are enforced for controlling the flow of CUI within the system.
- 03.01.03[02] approved authorizations are enforced for controlling the flow of CUI between connected systems.
Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.
Word by word
The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.
removed in Rev. 3 added in Rev. 3
Rev. 2 3.1.3 → Rev. 3 03.01.03 Information Flow Enforcement
4 words kept, 6 removed, 12 added. Rev. 3 statement labels omitted for the comparison.
What NIST says changed
- New security requirement title
- Aligned with SP 800-53, Rev 5
- Rephrased for clarity; outcome remains unchanged
- Discussion updated to include additional guidance on the relationship between 03.01.03 and 03.12.05
NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “No significant change”. At adoption, Bedrock files this under “Carries as-is”.
NIST's Rev. 3 discussion for 03.01.03
Information flow control regulates where CUI can transit within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include keeping CUI from being transmitted in the clear to the internet, blocking external communications traffic that claims to be sourced from within the organization, restricting requests to the internet that are not from the internal web proxy server, and limiting CUI transfers between organizations based on data structures and content. Transferring CUI between organizations may require an agreement that specifies how the information flow is enforced (see <a href="#/cprt/framework/version/SP_800_171_3_0_0/home?element=03.12.05">03.12.05</a>). Transferring CUI between systems that represent different security domains with different security policies introduces the risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes prohibiting CUI transfers between interconnected systems (i.e., allowing information access only), employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security attributes and security labels. Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of CUI between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., encrypted tunnels, routers, gateways, and firewalls) that use rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement.
What this means for you now
Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.1.3 as written in Rev. 2.
Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.
Where this page's facts come from
- Rev. 2 text and objectives
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
- Mapping and change class
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
- Rev. 3 03.01.03
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]