Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.1.3OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.1.3 — CUI flow control

3.1 Access Control · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Control the flow of CUI in accordance with approved authorizations.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

CUI moves only along paths you have approved — between systems, across network zones, out to partners — and other routes are blocked. This starts with knowing where CUI lives and where it is allowed to travel, then making the unapproved routes technically impossible rather than merely forbidden.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Network zones with deny-by-default paths between them are a primary mechanism for enforcing where CUI may travel: segmentation makes the approved flows the only flows the network permits, which is the enforcement half of this requirement.

What this does not claim: Flow authorization also runs through channels segmentation never inspects — email, cloud sharing, removable media, application-layer transfers within a permitted network path. And the requirement presumes documented approved authorizations to enforce; segmentation implements a flow decision but does not itself produce the approval record an assessor will ask for.

Practice-side activities
  • Place systems holding CUI in a defined zone with deny-by-default rules toward other zones
  • Derive firewall rules from the documented CUI flow paths rather than from accumulated exceptions
  • Review inter-zone rules on a cadence against the approved flow diagram
Evidence this produces
  • Zone architecture diagram aligned to the CUI flow diagram
  • Firewall rule exports for the CUI zone boundaries
  • Dated inter-zone rule reviews

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Contextual relationshipModerate confidence

Why: Governing which AI services may receive which classes of information is a flow-authorization decision for one specific and fast-growing destination: sanctioned tools become an approved flow path, and the practice's blocking and policy work constrains the unapproved ones.

What this does not claim: SP 800-171 has no AI-specific requirement, and this relationship holds only where an AI service would handle CUI — governance of uncontrolled data flowing to AI tools is good practice but outside the requirement. The bulk of 3.1.3 — internal network flow enforcement, email and media channels, the approved-authorization record — is untouched by AI governance.

Practice-side activities
  • Include AI services explicitly in the CUI flow authorization: which tools, if any, may receive controlled information
  • Block or intercept unsanctioned AI services from the network where CUI is handled
Evidence this produces
  • The AI acceptable-use rule naming sanctioned tools and prohibited data classes
  • Blocking or monitoring configuration for unsanctioned AI services

Where this holds: Meaningful only where staff who handle CUI can reach AI services from in-scope systems.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Draw the approved flow paths first: where CUI enters, where it is stored and processed, where it legitimately leaves. The diagram is the authorization the requirement speaks of.
  • Enforce the diagram with network zoning, share and mailbox permissions, and outbound restrictions — controlled unmanaged-cloud and personal-email egress is usually the largest unapproved path.
  • Revisit the flows when contracts or systems change; a flow diagram from two systems ago is a liability in an assessment.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A dated, approved CUI flow diagram or narrative naming the authorized paths
  • Firewall, sharing, and mail-rule configuration that enforces those paths
  • Records of blocked or flagged transfers where enforcement tooling exists

Suggested owners, derived from the mapped practices and artifacts: Network administrator · Engineering lead · IT leader or compliance lead · Contracts or compliance lead. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

WORKSHEET · REVIEW SEMIANNUALSystem Boundary Definition WorksheetQUESTIONNAIRE · REVIEW AT EVERY NEW CONTRACT AWARD OR MODIFICATIONCUI & FCI Applicability QuestionnaireWORKSHEET · REVIEW QUARTERLYAI Use-Case and Data-Handling Worksheet
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated