AC.L2-3.1.3 Control CUI flow: requirements and evidence

What AC.L2-3.1.3 control CUI flow requires in plain terms

AC.L2-3.1.3 requires you to control the flow of CUI within your system and between connected systems, and to do so in line with approved authorizations. In plain terms, you must decide where CUI is allowed to go, write those decisions down, and enforce them with technical mechanisms. The requirement is the Level 2 counterpart of NIST SP 800-171 Rev. 2 requirement 3.1.3, and it sits in the Access Control family. When an assessor asks where CUI can go, the answer must be a documented list of permitted sources, destinations and paths, not a general statement that staff know the rules.

The risk of uncontrolled flow is that CUI reaches a place the contract never contemplated: a personal cloud storage account, a subcontractor's mail relay, an unmonitored test network, or a public website. This is hard to control for practical reasons. Connections accumulate over time and are often undocumented, cloud and SaaS integrations create paths that nobody drew on the network diagram, and routine changes such as a new sync tool, a firewall exception or a vendor API can open a new flow without anyone reviewing its effect on CUI. The CMMC Assessment Guide points to firewalls, internal network zones and proxy servers as typical flow controls, and it expects any CUI allowed across the internet to be encrypted. Confirm your current flow authorizations against the actual rules in your environment before an assessment, because the paper record and the enforced configuration often differ.

AC.L2-3.1.3 is worth 1 point under 32 CFR 170.24. Because it is not on the exclusion list in 32 CFR 170.21, it may be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110 (0.8), with closeout due within 180 days. Treat that as a short window, not a plan to defer the work: a flow control gap usually signals broader problems with the system boundary. Confirm current Department of War timing and any changes to the POA&M rules before relying on them, since the CMMC program has been subject to recent suspensions and reviews.

Which systems, connections and teams fall under CUI flow control

Scoping decides how much of the environment AC.L2-3.1.3 reaches. Each decision below sets which paths CUI can travel, which boundary devices must enforce the approved flows, and which parties must be inside the evidence.

CUI-bearing systems and data stores

Start by listing every system that stores, processes or transmits CUI, including file shares, email, collaboration tools, backups and ticketing systems where CUI is pasted. Each one becomes a source or destination that needs a documented flow authorization. Ask the team to trace real data, not only the intended architecture, because CUI often reaches systems nobody listed. Effort grows with every undocumented store found during this inventory.

Internal network zones and segmentation

Decide which network zones hold CUI and which do not, then define the flows allowed between them. A flat network forces the assessor to accept that CUI can reach any host, which usually makes the flow policy hard to defend. Splitting zones reduces the number of flows to authorize but adds firewall rules, routing changes and testing. Confirm each zone boundary with the network diagram in the system security plan.

Boundary devices and firewalls

Identify every firewall, router access list, and proxy that sits between CUI zones and anything else. These devices are the typical enforcement mechanisms assessors examine for this requirement, so each one needs its rule set, change history and logs in scope. Devices outside the boundary still matter if they can pass CUI. Ask whether the rules are deny by default and who approves each change.

Proxies, web gateways and content paths

Map how web, email and file transfer traffic leaves the CUI environment through proxies or gateways. Each path can permit or block specific content types and destinations, so the flow policy must state which paths are allowed. Confirm whether the proxy inspects encrypted traffic, since assessors expect CUI that crosses the internet to be encrypted. Missing a proxy in scope leaves an unmonitored exit for CUI.

Cloud and SaaS paths

Cloud platforms, hosted email and SaaS applications that store or relay CUI create flows that run outside your own boundary devices. Determine which provider controls enforce each flow, and whether those controls are documented and available as evidence. Shared tenants, sync clients and API integrations often move CUI in ways that are not obvious from the console. Confirm the provider's responsibility matrix before you assume a flow is covered.

External connections and third-party providers

List every external system, partner network and third-party service provider that exchanges data with the CUI environment, including managed service providers with administrative access. Each connection needs a documented authorization, a defined direction and a method of enforcement. Service providers that can view or move CUI may need to be assessed as part of your scope, so ask each one how it protects the data it touches. Changing a provider later can reopen the flow analysis.

How an assessor tests CUI flow control

This table maps the five SP 800-171A assessment objectives for AC.L2-3.1.3 to the test method, the evidence an assessor will ask for, and the findings that most often stall a review. Read each row as a question the assessor will put to your system: what is the rule, where is it enforced, and can you show it working. The main takeaway is that a documented policy alone does not meet the requirement; the assessor needs the authorization list and enforcement records that match it.

Assessment objective	How the assessor tests it	Evidence requested	Common finding
Information flow control policies defined	Reads the policy and procedures and checks they describe how CUI may move within and out of the system	Final, approved flow control policy and procedures with owner and review date	Policy exists only as a draft or does not mention CUI specifically
Methods and enforcement mechanisms identified	Confirms each mechanism named in the policy exists and is configured as described	Firewall rule sets, proxy configuration, network zone diagram, WAF or content inspection settings	Mechanisms listed in the policy are not present in the baseline configuration
Designated CUI sources and destinations identified	Traces where CUI originates and where it is allowed to go, then checks the boundary between them	Data flow diagram, system inventory, list of CUI repositories and approved external endpoints	Undocumented paths such as personal file sync, email forwarding or ad hoc integrations
Flow authorizations defined	Compares the authorized flows against the list of what the system actually permits	Approved flow authorization list with approver and date, mapped to specific rules	Authorizations are general statements that cannot be matched to a firewall or proxy rule
Approved authorizations enforced	Selects sample flows and tests whether the mechanisms block unapproved traffic and permit approved traffic	Rule set exports, deny logs, audit records showing blocked and allowed flows, test results	Rules exist but logs are missing, or rules were changed without a recorded impact review

Implementing CUI flow control step by step

This sequence turns the requirement to control CUI flow into a documented policy, approved authorizations, enforced network boundaries and log evidence that an assessor can test. Each step produces an artifact that the next step depends on.

Inventory CUI and its sources and destinations
Start by listing every system, repository, mailbox, share and service that stores, processes or transmits CUI, then record where that data originates and where it is allowed to go. The owner of the CUI environment, with input from system administrators and data owners, completes the inventory. It is done when each CUI data set has a named source, a named set of destinations and a system owner, and when the list matches the boundary described in the system security plan. Anything outside that list is a candidate for exclusion or review.
Write the information flow control policy
Draft a written policy that defines which CUI flows are permitted, which are prohibited, and which methods (for example, encrypted transfer, approved file share or managed email gateway) apply to each. Security and compliance leads write it, and the accountable executive approves it. The policy is complete when it names the enforcement mechanisms in use and states how CUI crossing the internet must be encrypted, and when it is version-controlled and tied to the system security plan.
Record approved flow authorizations
Translate the policy into a list of specific flow authorizations: source, destination, protocol, port, data type and the business reason. Each entry needs an approver and a review date. Assessors typically ask for this list first, so it should be the single reference that firewall rules, proxy policies and zone definitions trace back to. The step closes when every permitted flow has a record and any flow without a record is documented as denied.
Design network zones and boundary enforcement
Separate CUI systems into defined internal network zones and place boundary devices where traffic enters or leaves each zone. The architect maps zones to the inventory, decides where firewalls, proxies and any web application filtering sit, and documents a default-deny posture between zones. The output is a current network diagram and zone table that show every boundary crossing, so that each authorized flow has a defined path through an enforcement point.
Configure firewalls and proxies to enforce flows
Implement the approved flows as explicit rules on firewalls and proxies, and deny everything else. Engineers group addresses into aliases, restrict each rule by source, destination, port and protocol, and enable logging on rule matches. For web-facing CUI paths, a web application firewall can inspect requests. Open-source options such as OPNsense for stateful filtering, Coraza for web application inspection and Suricata for network detection can support this, but the team should confirm each capability in its own environment before relying on it. The step closes when a test from an unauthorized source is blocked and an authorized flow succeeds, with both results recorded.
Verify enforcement with network and audit logs
Confirm the controls work by reviewing evidence over a representative period. Firewall rule logs show allowed and blocked traffic against each authorization. Network metadata tools such as Zeek can record connection details, protocol logs and anomalies, and Suricata's EVE output can record alerts and flows that log management tools ingest. Compliance staff compare observed flows to the authorization list and open a ticket for any flow that has no approval. The step is complete when every observed CUI flow maps to an authorization and each exception is tracked to closure.
Gate future changes by their effect on CUI flow
Add a change control check that requires anyone proposing a network, application or integration change to assess its effect on CUI flow before implementation. The reviewer confirms whether the change creates a new source, destination, protocol or zone crossing, and updates the authorization list, policy and diagrams before the change goes live. The output is a signed change record for each affected change, which gives assessors evidence that flow control is maintained over time, not only at the point of initial configuration.

Evidence that proves CUI flow is enforced

An assessor testing AC.L2-3.1.3 needs to see both the rules that define where CUI may go and proof that those rules operate. The cards below cover the documents that state the policy, the records that show enforcement, and the change and audit trail that keeps both accurate between assessments.

Information flow control policy and procedures

This is the written policy that defines how CUI may move inside the system and between connected systems, along with the procedures staff follow to apply it. Assessors start here because the other evidence must match it. Check that the policy names the CUI categories covered, the approved sources and destinations, and the owner who approves exceptions. Confirm that the version in use is approved and dated, since a draft does not satisfy the objective.

Approved flow authorizations list

The authorization list records each permitted path for CUI, including the designated source, destination, protocol and the business reason. Assessors compare it against firewall rules and network diagrams to find any path that exists without approval. Review the list at a defined cadence and remove paths that are no longer used. An entry with no named approver is a gap an assessor will raise.

Network diagrams with security zones

Current diagrams show the internal network zones, the boundary between CUI and non-CUI segments, and every point where traffic crosses into an external network. Each zone should be labeled with the systems it contains. Assessors use these diagrams to trace a CUI path from end to end. Confirm that the diagram matches the live environment, because a diagram that predates a cloud service or VPN change is weak evidence.

Firewall and proxy rule exports

Exports of firewall and proxy rule sets show what the enforcement points actually permit and deny. Compare each rule against an approved authorization and confirm that a default deny rule sits at the end of each boundary. Rule exports taken at the time of assessment, with the date and device name visible, carry more weight than screenshots. Look for overly broad rules, such as any-to-any entries, that undermine the authorization list.

Baseline configuration and change records

The baseline configuration documents the approved state of firewalls, proxies and network devices. Change records show that each modification to flow rules was reviewed for its effect on CUI flow before it was implemented, as the DoW CMMC FAQ advises. Each record should name the requester, the impact analysis, the approver and the implementation date. Changes made without a record are the most common reason this requirement fails in practice.

Audit records showing enforcement

Logs from firewalls, proxies and intrusion detection tools show that blocked and allowed flows actually occurred as the policy intends. Retain logs for the period the organization defines, protect them from modification, and be ready to show a sample of denied CUI-bound attempts. Open-source sensors such as Suricata and Zeek can produce flow and protocol records that connect a network event to a specific session. Confirm with your assessor which log sources they expect for your boundary.

Self-hosted tools that produce flow control evidence

Packet filtering is usually the first enforcement point an assessor asks about. OPNsense, licensed under BSD-2-Clause, is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Used well, its rules implement the network zones and flow authorizations the organization has documented, so that CUI-bearing segments can reach only the destinations the authorization list names. The evidence is the rule set itself, the aliases that group addresses into zones, and the rule match logs that show the rules are being applied.

Rule export: A dated export of the ruleset, showing deny-by-default placement and the rules that permit each documented CUI flow.
Aliases as zone definitions: Address and port aliases that map to the zones in the system security plan, so the rules read against the same boundary the assessor reviewed.
Rule match logging: Confirm whether logging is enabled for each relevant rule and where those logs are retained, since the live log view alone is rarely enough for an assessment.
Change history: Configuration backups and change records that show how a rule was added, reviewed and approved before the flow changed.
Scope limits: Firewalls do not inspect application content, so pair this evidence with the web and visibility tools below.

Confirm in your own environment that the rule logging, configuration backup and change history features meet your retention and review requirements before you rely on them as evidence.

What meeting CUI flow control costs in money and effort

This table breaks down who is paid for each part of meeting AC.L2-3.1.3 and whether the cost is one-time or recurring. Use it to build a quote request that separates hardware, open-source tooling, engineering, documentation, log handling and assessor fees. The main takeaway is that the named open-source tools carry no license spend, so most of the cost sits in design, documentation and ongoing review.

Cost component	Who is paid	One-time or recurring	What drives it, and what to request in a quote
Firewall and boundary hardware or cloud network services	Hardware vendor, cloud provider or reseller	Hardware is one-time with refresh; cloud network services recur	Number of network zones, throughput and high availability. Request itemized hardware, licensing and cloud service lines with renewal terms.
Open-source tooling (OPNsense, Coraza, Suricata, Zeek)	No license fee for the named tools; staff time and support are paid	Mostly recurring staff effort for tuning, patching and upgrades	Number of rule sets, log sources and sensors. Ask whether the quote covers installation, hardening, upgrades and support windows.
Engineering time to design zones and deny-by-default rules	Implementation partner or internal engineers	One-time for initial design, recurring for changes	Number of systems that handle CUI, count of external connections and existing network complexity. Request a written scope listing zones, rules and test cases.
Policy and flow authorization documentation	Internal compliance or security staff, or a consultant	One-time for baseline, recurring for each review	Number of approved CUI flows and data owners involved. Ask who approves authorizations and how often the list is reviewed.
Log storage and review	Internal security operations or a managed provider; storage vendor or cloud provider	Recurring	Retention period, log volume from firewalls, proxies and sensors, and review frequency. Request storage sizing and the review procedure in writing.
Change impact analysis for network and rule changes	Internal change board or the engineer making the change	Recurring with every change	Frequency of network changes and cloud migrations. Ask how the quote handles pre-change analysis of CUI flow impact.
Assessor fees	Certified third-party assessor (C3PAO) for certification, or internal or consultant staff for self-assessment	Periodic, tied to assessment cycle	Scope size and the assessment type in effect when you assess. Confirm current assessment requirements with the sponsoring program before budgeting.
Testing and evidence collection	Internal staff or a testing provider	Recurring at each assessment	Number of test cases for deny-by-default, encryption of CUI crossing the internet and enforcement. Request the test plan and evidence list.

Who owns CUI flow control and what to outsource

Your organization owns CUI flow control in full. Only your leadership and security staff can decide where CUI may go, which external destinations are approved, and who signs off on each flow authorization. Those decisions must be written down, approved and kept current, because the assessor will test whether the enforcement matches what you said you authorized. A partner can draft the material, but the content and the approval record must come from inside your organization.

Flow control policy: Define which types of CUI may move between which zones, systems and external parties, and state the conditions, such as encryption in transit.
Flow authorization register: Maintain the list of approved sources, destinations and paths, with an owner and approval date for each entry.
Change review: Assess the effect of each planned network, firewall or cloud change on CUI flow before it is implemented, as the DoW CMMC FAQ advises.
System security plan alignment: Make sure the flows you authorize match the boundary and data flow descriptions in your system security plan.
Ongoing monitoring: Review rule hits and flow logs on a schedule and act on exceptions.

Before engaging anyone, confirm that your staff can name the owner of each authorization and explain why it exists.

Where CUI flow control usually falls short

Most AC.L2-3.1.3 findings come from paths nobody mapped, rules nobody reviewed, and changes nobody checked against CUI flow. The cards below pair each common gap with a closure step an assessor can verify in the configuration and the records.

Unmapped cloud and SaaS paths

CUI often leaves the enclosure through a sync client, an API integration or a collaboration tool that was enabled for convenience and never added to the flow map. Assessors compare the authorized flow list against the system baseline and audit records, so an undocumented path is a finding even if it is encrypted. Close the gap by inventorying every outbound destination, including SaaS tenants and browser-based services, and recording each one as an authorized or prohibited flow with a named owner.

Any-to-any firewall rules

A rule that passes all sources to all destinations on all ports makes the network zones decorative, because nothing enforces the approved authorizations between them. Review the rule base for broad source or destination aliases and for rules placed above more specific denies. Close the gap by writing deny-by-default between the CUI zone and every other zone, then permitting only the source, destination, port and protocol combinations on the authorization list. Ask the reader to confirm each rule maps to a documented flow.

No written flow authorization list

Assessors look for a list of information flow authorizations that names the designated sources and destinations of CUI and the conditions under which each flow is approved. Without that list, the firewall rules have nothing to be tested against, and the enforcement mechanisms cannot show they match an approval. Close the gap by producing a single flow authorization register tied to the system security plan, with an approver, a date and a review trigger for each entry.

Proxies that do not log

A proxy that forwards CUI-bearing web traffic without recording requests, destinations and decisions leaves the enforcement point unverifiable, since the assessor cannot see what was allowed or blocked. Confirm that proxy and web application firewall logs capture the source, destination, action and rule identifier, and that they reach a log store the organization reviews. Close the gap by enabling per-rule logging, forwarding logs centrally and testing one blocked and one permitted flow as evidence.

CUI sent over the internet unencrypted

The Assessment Guide expects that any CUI allowed to cross the internet is encrypted, so plaintext email attachments, unencrypted file transfers and HTTP endpoints carrying CUI are direct gaps. Network sensors can show whether flows on the internet edge use encrypted protocols, but they do not prove the content was protected at the application layer. Close the gap by blocking unencrypted protocols at the boundary, requiring encrypted transport for each approved external flow, and confirming the cryptographic modules meet the FIPS-validated requirement of the related encryption controls.

Changes made without a CUI flow impact check

The DoW CMMC FAQ advises assessing how a planned change affects CUI flow before implementing it, and assessors ask for that record alongside change tickets. A new SaaS connector, a firewall rule added during an outage or a migrated server can open a path that no one reviewed. Close the gap by adding a CUI flow impact question to the change request template, requiring an approver from the CUI owner group, and comparing network logs after each change against the authorization list.

Common questions about AC.L2-3.1.3 cost, effort and assessment

How much effort does AC.L2-3.1.3 take to implement in-house?

The effort depends mostly on how many CUI data paths already run through defined boundaries, and no single figure applies to every environment. The work falls into four parts: writing the flow control policy and list of authorizations, mapping where CUI enters, leaves and moves, configuring enforcement with firewall rules, network zones and proxies, and collecting evidence that those rules work. The main costs are staff time and any licensing for the products you choose. Most of the spending is one-time build work. The recurring cost is reviewing authorizations and assessing each planned change for its effect on CUI flow, which the DoW CMMC FAQ advises. Start with an inventory of systems and data paths, because its size sets the size of the job.

Do we need an outside partner to meet AC.L2-3.1.3?

No rule requires an outside partner for this requirement, but many organizations bring one in for design and configuration work. The organization owns its controls and its flow authorizations. An implementation partner such as DeployOpen can plan, configure and document the enforcement layer inside your own environment, prepare the evidence and test the rules under a written scope. Only an independent assessor can judge whether the requirement is met. For Level 2 certification, that assessor is a C3PAO authorized or accredited by The Cyber AB. Outside help makes the most sense when your team lacks firewall, network or documentation capacity, or when the contract timeline is tight. Approvals should stay with your organization, so a partner should not sign off authorizations without your written approval.

Can AC.L2-3.1.3 go on a POA&M, and what score is required?

Yes. AC.L2-3.1.3 is worth 1 point and is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it can go on a plan of action and milestones for Conditional Level 2 status when the total score is at least 88 of 110 (0.8). The closeout deadline is 180 days. Three points matter. A POA&M item still needs a documented plan, an owner and milestones, so it does not replace a missing control design. Conditional status depends on the overall score, so weigh this item against every other open item. Confirm with your contracting officer and assessor how the item will be treated in your contract, because program status and contract clauses can change. Check the current rule text in the eCFR before you rely on this.

What does the internal team need to provide for this control?

The internal team carries most of the knowledge the assessor will test, so four roles should be named early:

A network engineer who knows the boundary, network zones, firewall rules and proxy configuration.
A data owner or compliance lead who can name the CUI sources, destinations and the flows that are approved.
A change manager who runs the impact check on any planned change that touches CUI paths.
A system administrator who can export configurations, baselines and audit records in a form that shows enforcement.

The organization must also approve the policy and the authorization list itself. Staff availability is often the constraint, so book reviews and sign-offs at the start of the work.

How long does preparing AC.L2-3.1.3 evidence usually take?

No reliable duration applies across environments, and this page does not give one. The main drivers are the number of CUI data paths, the number of network zones and external connections, whether firewalls and proxies are already in place and documented, and how mature your change control already is. A clear boundary with written flow authorizations usually needs less building than a flat network with undocumented connections. Ask any provider for a written schedule tied to a defined scope, and ask which dependencies it assumes, such as change windows and staff availability. Timing also depends on the program schedule. The Department of War suspended CMMC Phase II on 13 July 2026 and started a 60-day review, so confirm the current requirements with your contracting office.

What will an assessor ask for to test AC.L2-3.1.3?

The assessor works from the NIST SP 800-171A objectives and will typically ask for:

Information flow control policies and procedures.
The list of approved flow authorizations, including the designated sources and destinations of CUI.
The system baseline configuration for firewalls, network zones and proxies.
Audit records that show the enforcement mechanisms operating and being reviewed.
A live test showing that the mechanisms allow and block flows as authorized.

The assessor also expects any CUI allowed to cross the internet to be encrypted. Evidence must be in final form, not drafts, and each applicable objective must be satisfied for the requirement to be MET.

Which open-source tools help enforce and evidence CUI flow controls?

Several open-source tools can enforce or record flows, but none satisfies the requirement alone. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, with aliases for address groups and an option to log each rule match. Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx. Zeek writes conn.log entries showing who talked to whom, for how long and over which protocol. Suricata's EVE output writes JSON records of alerts and protocol transactions that can go to a log management tool. Confirm each tool's fit with your architecture and test it yourself, and document the policy the tools enforce. OPNsense rules documentation is a good place to start.

How DeployOpen prepares CUI flow control for assessment

DeployOpen starts by building a flow map for the client's own environment, because AC.L2-3.1.3 can only be tested against flows the organization has defined and authorized. The work covers where CUI is created, stored, processed and transmitted, which systems and external parties are designated sources and destinations, and which flows are approved. The client owns those decisions and signs off on them. DeployOpen then turns the approved map into zones and enforcement points inside the client's cloud accounts, data center or air-gapped network, such as firewall rules that default to deny, proxy paths for web traffic, and encryption for any CUI that crosses the internet. Every change to a zone or rule is checked against the flow map before it goes live, in line with the DoW's guidance to assess the effect of a planned change on CUI flow.

Configuration logging is where many flow control programs lose evidence. DeployOpen sets up firewall logging in OPNsense so each rule match is recorded, with aliases that name the approved address groups so the rule set reads the same way the flow map does. Suricata's EVE output and Zeek's conn.log and protocol logs can be configured to show who talked to whom, over which protocol, and for how long, linked by a connection identifier. The client should confirm that log retention, time synchronization and access to these logs meet its own audit logging requirements, since those sit in the AU family. Coraza, where a web application firewall is in scope, is configured against the rulesets the client selects, and the client should confirm which rulesets it has approved.

Assessors need evidence in final form, not drafts, so DeployOpen prepares a packet that matches the assessment objectives of NIST SP 800-171A: the flow control policy, the list of approved flow authorizations, the baseline configuration of the zones and rules, sample enforcement records, and a short test record showing that a blocked flow was actually blocked. DeployOpen prepares this packet and the systems behind it. It does not issue assessment results. Only the organization's own official and, where applicable, an authorized C3PAO issue determinations. Engagements are fixed-scope, with the flow map, deliverables and timelines agreed in writing and a quote that follows from that written scope before work starts.

AC.L2-3.1.3 Control CUI flow