CMMC Level 2 Practice 3.1.3: Control the flow of CUI in accordance with approved authorizations

CMMC Level 2 Practice 3.1.3 requires you to control where Controlled Unclassified Information (CUI) can go, how it can move, and who can move it, based on documented, approved authorizations. Operationalize it by defining allowed CUI “paths” (systems, users, destinations), enforcing them with technical controls, and retaining evidence that blocks, approvals, and exceptions work in practice. ¹

Key takeaways:

• Build an “authorized CUI flow” model (people + systems + destinations) and treat everything else as denied-by-default.
• Enforce the model with access control, network boundary controls, and data handling rules tied to CUI labeling.
• Keep an audit-ready evidence bundle: diagrams, policies, tickets, logs, and recurring control checks mapped to authorized flows. ²

“Control the flow of CUI” sounds abstract until you translate it into operator terms: CUI must only move through routes you have explicitly approved, and you must be able to prove those routes are the ones actually used. Practice 3.1.3 is mapped to NIST SP 800-171 Rev. 2 control 3.1.3, so assessors will expect NIST-style rigor: defined boundaries, documented authorizations, and enforcement that matches what’s written. ¹

For most contractors, failure modes are predictable: CUI in shared SaaS with weak sharing controls, engineers emailing files to personal accounts “just to print,” suppliers receiving CUI without a defined authorization, or “temporary” file transfer services becoming the default. This requirement is how you prevent those patterns from turning into an assessment finding or, worse, a reportable incident.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to stand up a workable control quickly. It focuses on decisions, implementation steps, and the evidence you will be asked to produce for CMMC Level 2. ²

Regulatory text

Provided excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.3 (Control the flow of CUI in accordance with approved authorizations).” ¹

Operator meaning: you must define which flows are authorized for CUI and then make the environment enforce those authorizations. “Flow” includes:

• System-to-system movement (e.g., CUI enclave to approved supplier portal).
• User-driven movement (download, copy, print, email, sync).
• Network movement (across segments, to the internet, to remote access).
• Third-party movement (to subcontractors, consultants, cloud services). ¹

Approved authorization is not a verbal “yes.” Treat it as documented permission tied to a role, a system boundary, and an allowed destination (and ideally a business purpose).

Plain-English interpretation (what the assessor will look for)

A CMMC assessor will pressure-test three things:

1. You know where CUI is and where it is allowed to go. If you cannot point to a boundary, a list of approved repositories, and approved transfer methods, you will struggle.

2. You enforce allowed flows with technical controls. Policy-only answers do not survive interviews with system administrators.

3. You have traceable evidence of operation. You can show a blocked transfer, an approved exception, and routine checks that catch drift. ²

Who it applies to

Entities: defense contractors and other federal contractors that handle CUI in support of DoD work and require CMMC Level 2 alignment. ³

Operational context: any environment where CUI is created, processed, stored, or transmitted. That includes:

• CUI enclaves and the surrounding corporate network if pathways exist.
• Cloud collaboration and ticketing tools if they contain CUI.
• File transfer, email, removable media, printing, and remote access workflows.
• Third parties that receive CUI from you (subs, labs, consultants). ¹

What you actually need to do (step-by-step)

Step 1: Define the “authorized CUI flow” model (your control card)

Create a one-page control card your operators can run:

• Objective: Only authorized flows of CUI occur.
• Owner: typically Security + IT, with Compliance accountable for evidence readiness.
• Trigger events: onboarding new system, new third party, new program, new CUI type, network change, M&A, tool rollout.
• Enforcement points: identity, endpoints, network boundaries, repositories, transfer tools.
• Exceptions: who can approve, how long, compensating controls, logging requirements. ²

Step 2: Inventory CUI locations and classify flow types

Produce a simple inventory that answers:

• Where is CUI stored now (repositories, shared drives, SaaS, endpoints)?
• How does CUI move today (email, Teams/Slack, SFTP, portals, USB)?
• Who sends it and to whom (internal roles, external organizations)? Then categorize flows:
• Internal allowed flows (within enclave or approved systems).
• External allowed flows (to specific third parties and destinations).
• Prohibited flows (personal email, consumer file sharing, unmanaged devices). ¹

Step 3: Turn “approved authorization” into a concrete approval mechanism

Pick an approval object you can show:

• A system authorization: “CUI may be stored in System X; sharing restricted to Group Y.”
• A third-party authorization: “Third party Z may receive CUI via Method M for Program P.”
• A user/role authorization: “Role R may export CUI using Approved Tool A.” Operationalize with:
• Standard request form (ticket) and required fields (purpose, data type, destination, retention).
• Named approvers (data owner + security).
• Time-bounded approvals for exceptions with review dates you enforce. ²

Step 4: Enforce with technical controls (map to common control points)

You do not need exotic tooling. You need consistent enforcement.

Identity and access

• Restrict CUI repositories to least privilege groups.
• Separate admin accounts; prevent “everyone can share externally.”
• Require MFA where CUI is accessed remotely. ¹

Endpoints

• Block writing CUI to removable media unless explicitly approved.
• Control local printing and local downloads on managed devices.
• Ensure unmanaged/personal devices cannot access CUI repositories. ¹

Network and boundary

• Segment the CUI environment; restrict egress.
• Allow outbound connections only to approved destinations used for CUI transfers.
• Monitor for anomalous transfers from CUI repositories. ¹

Transfer methods

• Standardize approved transfer channels (secure portal, SFTP, approved email encryption).
• Disable consumer file-sharing and ad-hoc transfer services for CUI.
• Configure SaaS sharing: default internal-only, domain allowlists, external sharing by exception. ¹

Step 5: Validate flows with testing you can repeat

Run a repeatable “flow test”:

• Attempt a prohibited flow (e.g., external share link, personal email forward, USB copy).
• Capture proof that it is blocked or requires explicit approval.
• Confirm allowed flows work and are logged. Record results in a control health check log and track remediation to closure. ²

Step 6: Build the minimum evidence bundle (audit-ready)

Keep evidence in one place, indexed to 3.1.3.

Core artifacts

• CUI boundary diagram / data flow diagram with authorized paths.
• CUI handling policy and procedures describing approved transfer methods.
• Access control matrix for CUI repositories (groups, roles, permissions).
• Third-party authorization records (contracts/flow-down references plus approval tickets). ¹

Operational evidence

• Samples of approved flow requests and approvals (tickets).
• Configuration screenshots/exports: sharing restrictions, egress rules, removable media policies.
• Logs showing blocked/allowed transfers (or alerts), and how they are reviewed.
• Control health check reports and remediation tracker with closure evidence. ²

Common exam/audit questions and hangups (what to prep for)

Assessors often ask questions in “show me” form:

• “Show me where CUI is stored and how you prevent it from leaving the enclave.” Have the diagram and egress controls ready.
• “How do you approve sharing CUI with a subcontractor?” Show the request workflow, approvers, and a real completed example.
• “What stops a user from emailing CUI externally?” Be ready with a technical answer (configured controls) plus logs or tests.
• “How do you detect and correct drift?” Produce control health checks and remediation closure. ²

Hangup to avoid: mixing “we have a policy” with “it is enforced.” For 3.1.3, the enforcement story matters.

Frequent implementation mistakes (and how to avoid them)

1. Defining authorizations in prose only. Fix: convert approvals into tickets, allowlists, and group-based access that you can export.

2. Over-scoping “flow control” to DLP only. DLP can help, but identity, repository permissions, and network egress controls usually carry the control.

3. Ignoring third parties. Fix: treat any external recipient as a governed flow. Maintain an approved recipient list tied to programs and transfer methods.

4. No evidence of negative testing. Fix: run and record attempted prohibited transfers. Assessors respond well to demonstrations that controls prevent common mistakes. ²

Enforcement context and risk implications

This control reduces the likelihood that CUI ends up in unauthorized systems or with unauthorized recipients. The risk is not theoretical: uncontrolled sharing and ad-hoc transfers are common roots of CUI spillage incidents, which can trigger contractual, reporting, and customer trust impacts. CMMC sits within the DoD program context described in federal regulation and program guidance, so assessment failure can affect eligibility for certain DoD work. ^{3 2}

Practical 30/60/90-day execution plan

No numeric timelines are required by the requirement text, but operators often need a staged plan. Use phases that match change-management reality.

First 30 days (stabilize and define)

• Assign an owner and publish a 3.1.3 control card (objective, triggers, exceptions).
• Draft the authorized CUI flow diagram and a list of approved repositories and transfer methods.
• Freeze new CUI tools and new external sharing paths until the approval process is live.
• Stand up an approval workflow (ticket form + approver list + required fields). ²

By 60 days (enforce and collect evidence)

• Implement or tighten sharing restrictions in your primary CUI repositories.
• Put egress controls in place for the CUI boundary (deny-by-default where feasible).
• Roll out endpoint restrictions for removable media and unmanaged devices that can touch CUI.
• Start a recurring control health check and remediation tracker. ¹

By 90 days (prove operation and handle exceptions cleanly)

• Run and document negative tests for prohibited flows; remediate failures.
• Review third-party recipients of CUI and formalize authorizations for each.
• Create an audit-ready evidence folder with an index mapped to 3.1.3.
• Schedule a tabletop review with IT/Security/Compliance to walk through “how CUI moves” and update diagrams after changes. ²

Tooling note (keep it practical)

Most teams don’t fail 3.1.3 because they lack tools. They fail because authorizations are scattered across emails, teams approve exceptions informally, and nobody can show an assessor a single “source of truth” for allowed flows.

If you use Daydream, treat it as the system that holds the control card, the required evidence bundle checklist, and the recurring health check workflow with remediation-to-closure tracking. That is the fastest path to making 3.1.3 repeatable across programs and owners. ²

Frequently Asked Questions

What counts as “approved authorizations” for CUI flow?

A documented approval that identifies the allowed source, destination, method, and approving authority. In practice, approvals should be traceable (for example, tickets, signed requests, or an access control change record) and enforceable in system configuration. ¹

Does 3.1.3 require a DLP tool?

No specific technology is mandated in the requirement text. You can meet 3.1.3 with a combination of repository permissions, sharing restrictions, network egress controls, and controlled transfer methods, as long as they implement approved authorizations. ¹

How do we handle sending CUI to a subcontractor?

Treat it as an external authorized flow: validate the subcontractor relationship, define the approved transfer method, document the approval, and restrict transfers to that method. Keep evidence of the authorization and proof that ad-hoc methods are blocked or controlled. ²

If CUI is in Microsoft 365/Google Workspace, what does “control the flow” mean?

It means controlling sharing and export paths: limit who can access CUI sites, restrict external sharing, require approved domains/allowlists where feasible, and log sharing events. Your evidence should include configuration outputs and sample approval records for exceptions. ¹

Are screenshots acceptable evidence for assessors?

Yes, screenshots and configuration exports are commonly used, but pair them with time-bound operational evidence like logs, tickets, and health check records. A screenshot shows a setting; operational artifacts show sustained control. ²

What’s the fastest way to fail this control during an assessment?

Letting CUI exist in multiple tools without a defined boundary and then relying on policy statements to explain “authorized use.” If you cannot enumerate authorized flows and show enforcement, the assessor has little to validate. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170