03.01.03 Information flow enforcement: what it requires

03.01.03 information flow enforcement: what CUI flow controls must do

Your contract requires NIST SP 800-171, and the assessor will want proof that CUI cannot move where it should not. Requirement 03.01.03 asks you to enforce approved authorizations that control how CUI flows within your system and between the systems you connect to it. The question it answers is not who may open a file. It is where the data is allowed to go once someone or something has it. That distinction matters because 03.01.02 covers access enforcement, which governs who and what may reach CUI, while 03.01.03 governs the paths CUI takes after access is granted. A user with legitimate rights to a CUI repository can still cause a violation if that repository syncs to an unapproved cloud folder or an external partner's network.

Flows are hard to control because most of them are not designed in the network diagram. They appear through shared drives, email attachments, API integrations, collaboration tools, print and scan services, and backup jobs that copy whole datasets to locations nobody reviewed. An assessor will typically start with your security architecture documentation and the information flow control policy, then interview the people who run the architecture, and then test whether the mechanisms in place actually block or log the flows you say are prohibited. Expect to show the rules, the boundary devices or policy engines that enforce them, and a sample of flows traced end to end. Confirm with your assessor which artifacts they expect, because the depth of testing varies with how your environment is built.

Requirement 03.12.05 on information exchange is the companion you should plan alongside this one. It concerns the agreements and terms under which CUI is exchanged with other systems and organizations, and the approved flows you define under 03.01.03 should match those agreements. A practical starting point is to inventory every connection and transfer path for CUI, record the authorization for each, and then confirm that a technical control enforces it. Ask your implementation partner and your assessor to agree on how that inventory will be kept current as integrations change.

Which CUI flows fall under 03.01.03 information flow enforcement

Before any firewall rule or data flow policy is written, the organization has to decide which paths CUI can take. Each decision below changes which systems, agreements and evidence fall inside the 03.01.03 assessment, so the boundary should be settled and documented in the system security plan first.

Internal segments that hold CUI

Start by mapping which internal networks, VLANs, hosts and application tiers store, process or transmit CUI. Each segment that holds CUI needs approved flow rules on both sides, so a flat network with one CUI database forces every host in it into scope. Segment by data sensitivity, then confirm with a data flow diagram that matches the actual routing. Ask who owns each segment and who approves changes to its rules.

Boundaries to connected systems and external parties

Every link to a partner network, a customer portal, a managed service or a government system is a flow that must be authorized and enforced. Document the direction, protocol, ports and data types allowed on each link, and confirm that traffic outside those rules is denied. Assessors commonly ask how an external connection was approved and how a rule change is reviewed.

Cloud and SaaS connections

Cloud accounts, SaaS applications and backup services can receive CUI through sync, API or log export paths that never cross the traditional perimeter. Inventory each one, record whether it stores or merely routes CUI, and confirm the provider's responsibilities in writing. Check that exports to log analytics or ticketing tools do not copy CUI into systems outside the boundary without authorization.

Data exchange agreements tied to 03.12.05

Where CUI is exchanged with another system or organization, the flow needs a written agreement that sets the terms for handling it. The Rev. 3 discussion of 03.01.03 refers to 03.12.05 (Information exchange), so the agreement and the enforced flow rule should match. Confirm that each agreement names the data, the parties and the permitted paths, and that the firewall or gateway configuration reflects those same terms.

Shared services on CUI paths

Identity providers, DNS, patching servers and centralized logging often sit on or near CUI paths without handling CUI themselves. Decide whether each shared service is in scope, and document how its traffic is limited to the functions it needs. A logging pipeline that carries CUI-bearing records, for example, must be treated as part of the flow it observes. Confirm this decision with the assessor before the boundary diagram is finalized.

The CUI-handling enclave boundary

An enclave places CUI systems behind a defined boundary with a narrow set of approved entry and exit points. Choosing an enclave shrinks the number of systems in scope, but the boundary must be enforced at every crossing and the enclave's rules must be justified in the system security plan. Ask the implementation partner to show how each permitted crossing is logged and reviewed, since the enclave is only as strong as its least controlled path.

How an assessor tests 03.01.03 information flow enforcement

This table maps how SP 800-171A Rev. 3 tests 03.01.03 against its two determination statements, showing the examine, interview and test objects an assessor uses, the evidence to prepare, and the findings that commonly come up. Read each row as a question the assessor will ask and the artifact that answers it.

Assessment element	What the assessor looks at	Evidence to have ready	Common findings
Determination statement 1: approved flow authorizations	Whether the organization has defined which CUI flows inside the system and between connected systems are approved, and enforces those authorizations	Information flow control policy, documented flow authorizations by data path, approved boundary and interconnection list	Flows exist in practice that no one has approved, or the policy names no owner for each path
Determination statement 2: enforcement mechanisms	Whether the defined authorizations are enforced by mechanisms such as segmentation, firewall rules, proxies and data-flow restrictions	Security architecture diagrams, firewall rule exports, VLAN and segment definitions, proxy or gateway configuration	Rules that allow broader traffic than the documented flows, or rules with no business justification
Examine: policy and procedures	Whether access control and information flow policies and procedures exist, are current and match the system	Signed policy, procedure for changing flow rules, review dates and version history	Procedures describe a process the team does not follow, or were last reviewed long ago
Examine: architecture and configuration	Whether design documents and system configuration settings show the enforcement points that the policy describes	Security architecture and design documentation, configuration exports, network data-flow diagrams for CUI	Undocumented paths such as legacy interfaces, file shares or backup links that carry CUI outside the diagram
Interview: administrators and architects	Whether system administrators and security architecture staff can explain how flows are approved, enforced and changed	Named roles with flow-rule responsibilities, change tickets, escalation contacts	Rules without owners, or staff who cannot explain why a rule exists
Interview: information security personnel	Whether security staff monitor flows, review exceptions and respond when a flow falls outside authorization	Review records for flow rules, exception register, alert handling records	Exceptions granted verbally and never recorded or closed
Test: enforcement mechanisms	Whether the mechanisms actually block or permit traffic as the policy states, using sample flows	Test plan and results showing permitted and denied flows, logs of blocked attempts, rule-match logging	Rules that pass traffic the policy prohibits, or logging that is off for the boundary rules
Connected systems and external flows	Whether flows to other systems, cloud services and external partners are authorized and enforced at the boundary	Interconnection agreements, boundary device rule sets, list of connected systems carrying CUI	Partner or cloud connections added during a project and never added to the boundary review

Implementing information flow enforcement in order

This sequence turns the 03.01.03 requirement into a documented, tested set of flow rules that an assessor can trace from the CUI inventory to the enforcement points and the recorded results.

Map where CUI actually flows
Start from the CUI inventory and draw every path CUI takes through the system: user workstations, application tiers, databases, backups, file transfers, email gateways, APIs, and links to external or connected systems. Include flows that run through administrative and monitoring tools. The owner is the system owner with input from engineering and operations staff who know the real traffic. The step is complete when each flow has a source, a destination, a data type, and a protocol recorded in a flow diagram that matches the system security plan.
Define and approve each permitted flow
For each mapped flow, record whether it is permitted, under what conditions, and who authorized it. Approvals usually sit with the system owner and the security function, and connections to other organizations should be covered by written agreements that 03.12 also addresses. Mark every flow not on the list as denied by default. The output is an approved flow register with a named approver and date for each entry, plus a rule that anything missing from the register is blocked.
Set the organization-defined parameters
Requirement 03.01.03 is tied to organization-defined parameters that the contract or the federal agency may specify. Ask the contracting officer or agency for any values before implementation, and where none are given, the organization must assign them and document the rationale. Confirm the parameter list in the current Rev. 3 catalog and the applicable DoD or agency deviation, since the requirements that apply to a contract can change. The output is a parameter table with each value, its source (agency or organization), and the approver.
Enforce approved flows at the boundaries
Translate the approved register into enforcement at the boundary: stateful packet filter rules that pass only the permitted source, destination, port and protocol combinations, with aliases for grouped addresses and rule-match logging enabled where the design calls for it. Confirm the chosen platform's capabilities against its own documentation before relying on them. The output is a rule set exported from the firewall configuration and reviewed against the register, with every rule traceable to an approved flow.
Enforce flows inside the system
Flows also cross internal boundaries: between network segments, between application tiers, and between a CUI enclave and general corporate systems. Apply segmentation, application-layer rules such as web application firewall policies where web traffic carries CUI, and restrictions on where data may be written or copied. Assign each internal control to the flow it supports. The output is an internal enforcement map showing which mechanism enforces which flow, with configuration settings captured as evidence.
Document the security architecture
Write the security architecture and design documentation that explains the flow model, the enforcement points, the approved register, and the parameter values. Link each enforcement point to the requirement it supports and to the related requirements in 03.01.01, 03.01.02, 03.12.05 and the others named in the requirement's discussion. Keep the document under configuration control so changes trigger an update. The output is a versioned architecture document that an assessor can read without help from the engineers who built the system.
Test enforcement and monitor the flows
Test each enforcement point against the register: attempt permitted and denied flows, confirm the outcome, and record the results with dates and tester names. Turn on logging for denied and anomalous flows and review samples to confirm the logs show what the rules are meant to show. Network metadata tools such as flow loggers and intrusion detection systems can produce this evidence, but confirm their output with the vendor documentation first. The output is a signed test record for each flow and a monitoring summary, which become the evidence an assessor examines and tests.
Retest after every change
Any change to the network, applications, cloud configuration or connected systems can open a new path, so the register, rules and architecture document are updated in the same change record. Schedule a retest of the affected flows and keep the results with the change ticket. The output is a change history showing that flow enforcement was reviewed each time the system changed, which supports the assessment and any Plan of Action and Milestones entries.

Which open-source tools produce information flow evidence

Information flow enforcement is proven with records that show which traffic was allowed, blocked and observed at each boundary. The four tools below sit at different points in that path: a web application firewall, a packet filter, a network intrusion detection engine and a network metadata sensor. Each one produces different evidence, and none of them decides on its own what CUI may flow where.

Coraza web application firewall

Coraza is an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP requests and responses at the edge of a CUI web application, so its audit logs show which requests were blocked or allowed by which rule. Integrations exist for Caddy, HAProxy, Traefik and Nginx. Confirm which proxy you run, that the rule set is version controlled, and that audit logs leave the host for retention. Check whether your Apache-2.0 use creates obligations you have not reviewed.

OPNsense firewall rules

OPNsense is a BSD-2-Clause stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses for each CUI enclave. Enabling per-rule logging produces records of each rule match that can be reviewed in the live log view. Confirm that the rule set is deny by default between enclaves, that aliases match your documented boundary, and that logs are exported to a store you control, since the live view is not a retention record.

Suricata EVE JSON records

Suricata is a GPL-2.0-only intrusion detection engine. Its EVE output writes JSON records for rule alerts, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, plus dropped packets and engine statistics. Output can be split into separate files for log management tools, which helps assessors trace a flow to a rule. The GPL-2.0-only license matters if you modify and distribute the engine, so have counsel confirm your use. Confirm which protocols and rule sets are enabled, because unlisted traffic produces no record.

Zeek connection and protocol logs

Zeek is a BSD-3-Clause network security monitor. By default it writes conn.log, which records who talked to whom, for how long, how much and over which protocol for TCP and UDP traffic, along with protocol logs such as dns.log and http.log. Its weird.log captures anomalous events. A unique connection identifier links these logs together, so an assessor can follow one flow across records. Confirm that sensors see every boundary crossing you claim to control, and that the logs are retained for the period your plan states.

What evidence passes an assessment and how to keep it current

An assessor testing 03.01.03 Information flow enforcement wants to see that the organization decided where CUI may travel, that the system enforces those decisions, and that the records still match the system as it runs today. The core evidence set is the approved flow authorizations, the rule sets that implement them, boundary configurations, flow logs that show enforcement happening, current architecture diagrams, and exchange agreements for CUI that leaves the system. The examine method covers the information flow control policy and procedures and the security architecture documentation, the interview method covers system administrators and security architecture staff, and the test method covers the mechanisms that carry out the policy. Each rule set should name an owner, state the business reason for each allowed path, and carry a change history linking every rule to an approved change request. Confirm the exact assessment objects against the 800-171A Rev. 3 assessment procedure before you build the evidence binder, since the wording of the examine, interview and test objects is what the assessor will check against.

Between assessments, the risk is drift. Firewall and boundary devices change through emergency rules, vendor updates and forgotten test paths, so the evidence must be produced on a schedule rather than reconstructed for the audit. Set a recurring review of each boundary rule set against its authorization record, export the running configuration and store the export with a date, and retain flow logs long enough to show that enforcement operated over the period an assessor will ask about. For open-source boundary tooling, the OPNsense rule log, Suricata EVE output and Zeek conn.log can all be exported to a log store on a fixed schedule. Confirm with your assessor and your system security plan how long logs and configuration exports must be kept. Stale architecture diagrams are one of the most common failures: a diagram that shows a segment or connection that no longer exists, or omits a link added during a project, undermines every other piece of evidence, so tie diagram updates to the change process and review them at each rule review.

What meeting 03.01.03 costs in money and effort

This table breaks down the cost components of meeting 03.01.03 Information flow enforcement, showing who is paid for each, whether it is one-time or recurring, what drives it up, and how to keep it down. No prices are given because none were supplied, so use the table to structure quotes and internal budgets. The main takeaway is that the largest recurring costs come from evidence upkeep and log review, not from the initial rule set.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Flow mapping and architecture work	One-time, revisited on architecture change	Number of CUI flows, connected external systems, age and documentation of the existing network design	Map flows from existing diagrams and logs first, limit the CUI boundary to the smallest enclave, and reuse the security architecture documentation assessors will examine
Firewall and inspection tooling or licenses	Recurring if commercial, one-time setup if self-hosted	Commercial license tiers, throughput, number of segments, inspection features bought per boundary	Use open-source enforcement and inspection tools where they meet the design, and confirm each platform's capabilities against your own requirements before committing
Engineering time for rule design and testing	One-time build, then recurring change effort	Number of allowed flows, deny-by-default rule complexity, testing depth, and the number of change requests	Use address aliases or named groups for repeated sources, test each rule change in a staging segment, and keep a short written rationale for every allowed flow
Evidence upkeep and log review	Recurring	Log volume from boundary devices, retention period, number of people reviewing alerts, and how often flow rules change	Route boundary and flow logs to a central store with retention set by policy, filter routine events, and schedule reviews that produce signed records
External testing or review	Recurring at each assessment cycle or after major change	Scope of the boundary tested, depth of the test, and whether the organization or an outside party performs the work	Fix scope in writing before work starts, retest only changed rules, and check whether internal evidence already answers the question
Auditor or assessor sampling	Recurring at each assessment	Number of flow rules and interfaces the assessor selects, how well the evidence is organized, and questions raised by interviews	Keep a current rule inventory with owners and rationale, and prepare a sample of change tickets and log extracts before the assessment starts

Who owns, who prepares and who assesses information flow controls

The organization owns requirement 03.01.03. It decides which CUI may flow where, between which components and connected systems, and under what conditions. Those decisions belong in written information flow control policy and procedures, which an assessor will examine. The organization also sets any organization-defined parameter values that the requirement leaves open, and it approves exceptions, because an exception to an approved flow is a risk acceptance decision that someone with authority must make and record.

Flow authorizations: Define the approved flows of CUI, such as which enclave may send data to which external service and over which protocols.
Parameter values: Assign the values for any organization-defined parameters that apply to the flow policy, and record the rationale.
Exception approval: Decide, in writing, whether an unapproved flow is accepted, remediated or blocked, and who signs off.
Ownership of evidence: Keep the policy, the approvals and the review records current, since these are what the assessor examines first.
Ongoing review: Re-check flows after changes to architecture, connected systems or contract terms.

Before engaging anyone, confirm internally which person or role signs the flow policy and whether your federal contract or agreement assigns any ODP values that you must adopt.

Common gaps that fail 03.01.03 and how to close them

Assessors testing 03.01.03 usually find the same few gaps: flows that were never mapped, rules nobody can justify, diagrams that drift from the real network, and logs no one reads. Each card names one gap and a closing action the organization can complete and show as evidence before an assessment begins.

Unmapped flows outside the network

CUI often leaves the enclave through email, file sync clients, shared drives, backup jobs and API integrations that nobody drew on the architecture diagram. Because 03.01.03 covers flows between connected systems, an unmapped channel is an unapproved flow even when the firewall is configured correctly. Close the gap by inventorying every outbound path for CUI, including backup replication and sync agents, and recording an approved authorization or a removal decision for each one. Ask the team which systems send data to others on a schedule, since those flows are the ones most often missed.

Rules without owners or justification

Firewall and boundary rules accumulate over time, often as temporary exceptions that outlive the project that needed them. An assessor testing 03.01.03 will ask why a given rule allows a given flow and who approved it, and a rule with no answer is hard to defend. Give every rule or alias group a named business owner, a stated purpose tied to a CUI flow, and a review date. Remove rules whose owner cannot be identified. Keep the rule set and its justification records together so the assessor can trace each permitted flow back to an authorization.

Diagrams that drift from the network

Data flow and network diagrams are often drawn at design time and then left alone while the deployed environment changes. The assessor compares the documented flow model with the configuration on the boundary devices and the security architecture documentation, so any mismatch undermines the whole control. Reconcile diagrams against exported firewall rules, VLAN definitions and cloud network configuration, then record the date and the person who verified them. Treat a diagram that cannot be regenerated from configuration as unverified until someone checks it.

Flow logs that no one reviews

Many systems produce firewall, IDS and network metadata logs, yet nobody looks for flows that violate the approved authorizations. Under 03.01.03 the organization must enforce flow rules, and an assessor will ask how a blocked or unexpected flow is noticed and handled. Feed firewall rule-match logs and Zeek connection records into a central store, define a recurring review, and create alerts for traffic to destinations outside the approved list. Keep a record of each review and the follow-up on any violation, because the review record is what shows enforcement in operation.

Organization-defined parameters left unset

Rev. 3 requires the organization to assign values to organization-defined parameters where a federal agency has not specified them, and an unset parameter leaves the requirement incomplete. For 03.01.03 this typically covers which flows are approved, which boundaries are monitored and how often rules are reviewed. Confirm with the contracting agency which values it has set, then assign and document values for every remaining parameter in the system security plan. Ask the assessor to confirm during planning that the values you chose are defensible for your environment.

Undocumented external system connections

Connections to cloud services, managed providers, partner networks and vendor remote support tools are the flows most likely to exist without a written agreement or documented purpose. The requirement expects connections to external systems to be controlled, and the assessor will look for the agreement, the approved data types and the enforcement point. Build a register of every external connection with the owner, the CUI categories that may cross it, the controlling rule and the agreement reference. Remove connections that cannot be documented, and review the register when a vendor or integration changes.

How long, costly and hard is 03.01.03 information flow enforcement?

What makes 03.01.03 information flow enforcement expensive or time-consuming?

The effort depends mostly on how many paths CUI can take through the system and how many of those paths already have documented, enforced rules. A small environment with one enclave, one boundary and few external connections needs far less work than a mixed estate where CUI moves between file shares, email, collaboration tools, cloud services and subcontractor links. The main cost drivers are the number of connected systems, the state of the existing network design, how many flow rules must be written from scratch, and how much logging must be configured to show the rules work. Requirement 03.01.03 is short, but an assessor will expect the organization to show a documented authorization for each flow and a mechanism that enforces it, so the work grows with the architecture. Ask any partner to base its quote on a written list of flow paths and connected systems.

Can an in-house team implement information flow enforcement without outside help?

Yes, many organizations do this with internal staff, provided they have people who understand network segmentation, firewall policy and the system security plan. The work requires someone who can map CUI data flows, someone who can write and test boundary rules, and someone who can produce evidence in the form an assessor expects. Teams without recent architecture experience often find the flow mapping takes longer than the rule changes. An implementation partner can prepare the configuration, documentation and evidence, and can help with testing, but the organization still owns its controls and decides what flows are authorized. Only an independent assessor can issue an assessment result, so outside help does not replace that step.

What does the organization need to provide during an information flow enforcement project?

The project needs three things from the organization: access to architecture material, named owners for each change, and access to logs. Architecture access means current network diagrams, data flow diagrams, firewall and router configurations, and the system security plan, so the team can see where CUI actually travels. Change owners are people who can approve a new flow rule or block an existing one, usually from IT operations, application owners and the security function. Log access means the ability to review firewall, proxy and sensor records after changes, so the organization can confirm that enforced rules match the documented authorizations. Agree on these inputs in the written scope before work starts, along with who will sign off on each deliverable.

How does 03.01.03 differ from 03.01.02 access enforcement?

Requirement 03.01.02 governs who may access CUI and system resources, while 03.01.03 governs where CUI may flow once it is inside the system or moving between connected systems. A user may be fully authorized to open a CUI file and still violate 03.01.03 if that file is sent to an unapproved external service or copied to a system outside the boundary. For that reason the two requirements need separate evidence: access control lists, role assignments and authentication records for 03.01.02, and documented flow authorizations, boundary rules and enforcement configurations for 03.01.03. Teams sometimes merge these into one project, which can hide gaps in either area.

How does 03.01.03 relate to 03.12.05 information exchange?

Requirement 03.12.05 covers agreements for exchanging CUI with other systems, and the Rev. 3 discussion of 03.01.03 refers to it. In practice, when CUI is sent to another system, the organization needs both an approved information exchange agreement under 03.12.05 and an enforced flow authorization under 03.01.03 that permits the transfer. The agreement describes the terms of the exchange, while the flow rule technically limits it to the approved paths. An assessor may test the two together, so the documentation should link each connected system to its agreement and to the rule that enforces it. Confirm the exact interpretation with your assessor, since the mapping is shown in the standard's discussion rather than in a separate control.

Can an implementation partner make the assessor's decision on 03.01.03?

No. An implementation partner can prepare the flow documentation, configure boundary and segmentation controls, collect logs and organize evidence for the examine, interview and test activities that the assessment procedure describes. Only the independent assessor decides whether the requirement is met, and only the organization's contracting federal agency or the applicable assessment body can accept the result. A partner's role is to make the evidence clear and reproducible, so the assessor can verify the controls without long delays. Ask a prospective partner to state in writing which deliverables it produces, which evidence it will hand over and which decisions remain with the organization and the assessor.

Which open-source tools produce evidence for information flow enforcement?

Several self-hosted tools can generate evidence that supports the rules and monitoring behind 03.01.03. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match for review. Coraza, a web application firewall compatible with ModSecurity SecLang rulesets, can enforce rules on web traffic and integrates with Caddy, HAProxy, Traefik and Nginx. Suricata writes EVE JSON records for alerts, flows and protocol transactions, which can be split into separate files for log management. Zeek writes conn.log, which records who talked to whom and over which protocol, along with dns.log, http.log and weird.log, linked by a unique connection identifier. Confirm with your assessor which records they will accept as evidence, and test that each rule produces the log entries you plan to show.

How DeployOpen scopes and prepares 03.01.03 evidence

DeployOpen works on 03.01.03 Information flow enforcement as a scoped implementation and evidence project inside your own environment. We map where CUI may flow, configure the enforcement points that keep it there, and document the result so an independent assessor can test it.

How we scope

Written scope lists every boundary, segment and connected system that CUI may cross for 03.01.03.
Scope names the flow authorizations, owners and approval records that the assessment will examine.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Configure stateful firewall rules with aliases and per-rule logging to enforce approved flows between zones.
Deploy web application filtering and network sensors such as Suricata and Zeek to record traffic crossing boundaries.
Document the flow policy and map each configured rule back to a specific authorization in the security architecture.

How we hand over

Deliver flow diagrams, rule inventories and configuration exports that show the enforcement is in place.
Provide log samples and retention settings that show how flow decisions are recorded and reviewed.
Walk your assessors and system administrators through the evidence so interview questions can be answered consistently.

How we support

Ongoing support is available as a retainer for rule reviews, upgrades and changes to connected systems.
Retainers can cover periodic re-testing of boundary rules after new integrations or architecture changes.
Confirm with your assessor which evidence formats and retention periods they expect before the handover is agreed.