AC-4 Information flow enforcement: evidence and tests

AC-4 information flow enforcement: what the control asks for

AC-4 requires the system to enforce approved authorizations for how information moves, both inside the system and between the systems it connects to, under information flow control policies that the organization defines. An assessor or a contract clause that names AC-4 is asking one question: can you show that data cannot travel along paths nobody approved? Answering it means producing the policy that defines permitted flows, the enforcement mechanisms that apply it, and records that show those mechanisms work. AC-4 governs where information goes, which is a different question from AC-3, which governs who may access it. A user can be fully authorized to read a database and still be blocked from sending its contents to an external address. The risk AC-4 addresses is information leaving a boundary through an unintended path, such as a misrouted API call, an outbound connection from a reporting server, a file share synchronized to a partner network, or a cross-domain transfer that bypasses the review it was meant to pass through. Assessors look for the controls that stop these paths, not just the controls that stop unauthorized logins.

Two things make AC-4 hard in practice. First, information flows are often undocumented: teams know their main application paths but rarely have a current list of every service-to-service, egress and partner connection, so the flow policy describes an architecture that no longer matches the running system. Second, many systems share network segments, gateways, message queues and logging pipelines, so a permitted flow in one system can carry information from another. Before scoping the control, confirm which flows the policy must cover, who owns the authorization for each, and where enforcement sits (firewall, proxy, web application firewall or data-layer filter). The SP 800-53B baselines select AC-4 for moderate and high impact systems, but only enhancement AC-4(4), which concerns flow control of encrypted information, is selected in the high baseline. That leaves 30 current enhancements, covering filters, domains and separation, that a team may choose to adopt through tailoring or a system-specific requirement. Ask your assessor or contracting officer which enhancements they expect you to address, and record the decision and its rationale in the system security plan so that the scope is defensible.

Which systems and flows fall under AC-4 scope

AC-4 scope follows the security categorization of the system and the flows that cross its boundaries. The cards below cover the decisions that change the work, from impact level and baseline selection to the boundary types where information moves between connected systems.

Moderate and high impact systems

AC-4 is selected in the moderate and high security control baselines in SP 800-53B. A system categorized low does not pick up AC-4 from the baseline alone. Confirm the FIPS 199 categorization of each system in the boundary, because a single high-impact component can change the control set for the whole authorization package.

Privacy-only scope does not trigger AC-4

AC-4 is not selected in the privacy baseline. A system that processes PII under the privacy baseline without a moderate or high security categorization does not inherit AC-4 from that baseline alone. Teams should still check whether PII flows are governed by other controls in their tailored set before deciding the scope is closed.

Encrypted flows under AC-4(4)

AC-4(4) addresses flow control of encrypted information and is selected only in the high baseline. Where encrypted traffic crosses a boundary, the organization must be able to inspect, restrict or block it according to its policy. Identify every encrypted path that leaves a high-impact system, including tunnels and TLS sessions, and document how the flow is handled.

Internet edges and zone-to-zone links

Internet-facing gateways and links between internal network zones are the most common places where AC-4 flow policies are written and tested. Inventory each edge and inter-zone link, record the permitted sources, destinations and protocols, and confirm that the policy set for each link is documented and reviewed.

Cloud VPC peering and shared services

Peering connections between cloud networks, shared service accounts and transit gateways move information between systems that may have different categorizations. Treat each peering link as a flow to be scoped, and confirm which system owns the policy that governs it, since the peer may be operated by a different team or provider.

Third-party integrations and overlays

Third-party APIs, data feeds and vendor connections are flows that leave the organization's control. Confirm with the authorizing official whether any overlay or agency-specific tailoring adds, removes or changes AC-4 or its enhancements before the control set is final, because tailoring decisions alter what must be assessed.

How AC-4 differs from AC-3 access enforcement

AC-3 decides who may access information, while AC-4 decides how information may move between components, networks and systems. The catalog draws this line explicitly: access control governs whether a user, process or device may reach a resource, and information flow enforcement governs the paths data takes once it is in or leaving a system. A team can pass every AC-3 check and still fail AC-4, for example when an authorized application server sends regulated data to an unapproved external endpoint. Assessors will look for flow control policies and a list of approved flow authorizations, not just an access control matrix.

The two controls overlap at the boundary, which is where most confusion starts. AC-3 (access enforcement) and AC-6 (least privilege) decide whether a principal can perform an action at all. AC-4 applies to the data path itself, including traffic between systems that have no user in the loop. AC-16 (security and privacy attributes) is the bridge: labels attached to information let flow rules act on the content, not only the sender. AC-17 (remote access) and AC-19 (mobile devices) also sit on both sides, since authenticating a remote session is an access decision while restricting what that session may send out is a flow decision. AC-21 (information sharing) is closer to AC-4 than to AC-3 because it asks whether a sharing partner's permissions match the restrictions on the data.

Do not count an identity check as flow control, and do not count a firewall rule as an access decision. A firewall that allows a host to reach a database port is enforcing a flow authorization; it says nothing about which user may query the records. Confirm which component in your environment owns each decision, document the flow policies separately from the access control policy, and check that CM-7 (least functionality) and CA-3 (information exchange) cover the connections that AC-4 names. Teams that record both controls as satisfied by the same identity system usually have an AC-4 gap.

How an assessor tests AC-4 information flow enforcement

This table maps each SP 800-53A assessment method for AC-4 (examine, interview and test) to the actions an assessor takes, the evidence that method requests and the findings that commonly come up. SP 800-53A lists one determination statement for AC-4, so every row below supports a single question: does the system enforce approved flow authorizations? Use it to prepare the evidence set before an assessor arrives.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine: flow control policy	Reads the organization-defined information flow control policies and checks that they state which flows are approved, which are prohibited and who approves changes.	Signed information flow control policy, revision history and the approval record.	Policy exists but names no approved flows, or was never reviewed after the architecture changed.
Examine: security and privacy architecture	Traces the documented data paths between components, zones, tenants and external systems and compares them with the stated flow rules.	Security architecture diagrams, data flow diagrams and privacy architecture documentation with version dates.	Diagrams omit integrations, backup paths or service-to-service traffic that the running system uses.
Examine: list of information flow authorizations	Compares each listed authorization with the policy and asks who approved it and whether it still serves a business need.	The list of approved flows, with source, destination, data type, owner and approval date.	Flows approved years ago that no longer match any system, or flows that appear in rules but not in the list.
Examine: system baseline configuration	Checks that the baseline configuration of firewalls, proxies, routers and gateways matches the approved flows.	Exported firewall and gateway rule sets, configuration baselines and change records for those devices.	Rule sets drift from the baseline after emergency changes that were never approved or documented.
Examine: system audit records	Samples logged flow decisions to confirm that blocked and allowed transfers are recorded and that the records cover the approved paths.	Sampled log entries for allowed and denied flows, with log source and retention settings.	Denied flows are not logged, or logs cover only one boundary device while traffic crosses several.
Interview: system and network administrators	Asks how rules are created, reviewed and removed and how they confirm a new flow matches the policy before it goes live.	Named administrators, change tickets for recent rule changes and the procedure used to review rules.	Administrators describe a rule-by-rule process that nobody has checked against the policy in a long time.
Interview: architecture personnel	Asks which information flows the architecture is meant to allow or block, and how cross-domain and external transfers are handled.	Architecture decision records and the names of personnel responsible for flow design.	Architects and administrators describe different intended flows, which shows the policy is not the operating standard.
Test: enforcement mechanisms	Attempts flows that the policy prohibits and confirms that the mechanism blocks them, then attempts an approved flow to confirm it passes.	Test plan, test results with timestamps, and captured device or log output for each attempted flow.	Rules allow any-to-any traffic between zones, or a prohibited flow succeeds through an unlisted protocol or port.

Implementing AC-4 step by step

This sequence turns the AC-4 requirement into a documented, enforced and periodically re-checked set of information flow rules, with each step producing an artifact an assessor can examine. The organization owns the policy and the authorizations, while the implementation work produces the rule sets, logs and test records that show the flows are actually controlled.

Inventory data flows and connected systems
Start by listing the systems inside the boundary, the connections between them, and the external systems that send or receive information. For each connection, record the source, destination, data types carried, protocol and business owner. The owner of the system or service is responsible for confirming each entry, and architects should check the list against current network diagrams. This step is done when the flow inventory matches the security architecture documentation and an administrator can explain every connection on it.
Define organization-approved flow control policies
The organization, through its security and privacy leadership, writes the information flow control policy. It states which categories of information may move between which zones, which flows require inspection, filtering or encryption, and which must never occur. Privacy architecture should be consulted where personal data crosses boundaries. The output is a signed policy document that names the approving authority, and it is done when every flow in the inventory can be classified against a stated rule.
Authorize each permitted flow
Convert the policy into a list of information flow authorizations. Each entry names the source, destination, information type, conditions such as encryption or inspection, and the approver. Flows without an authorization are treated as prohibited by default. The approver signs off each entry, and the list is complete when no connection in the inventory lacks either an authorization or a documented denial.
Map each authorized flow to an enforcement point
For each authorized flow, identify the mechanism that enforces it, such as a packet filter at a segment boundary, a web application firewall in front of an application, an intrusion detection sensor on a monitored link, or an application-level control. Record the enforcement point and the rule or policy object that implements the authorization. This mapping shows the assessor where each policy statement is enforced and reveals flows that have no enforcement point at all, which must be resolved before configuration.
Configure rules and logging at each enforcement point
Build the rule set on each enforcement point using the authorization list as the source. Open-source options such as OPNsense for stateful filtering, Coraza for inspecting HTTP traffic against OWASP Core Rule Set rules, and Suricata or Zeek for network visibility can each support this work, but the team should confirm the capabilities they need in each product's documentation before choosing. Enable logging of rule matches and connection records so that flow decisions can be reviewed later. The rule set and its configuration exports are the artifacts produced, and the step closes when every mapped flow has a rule and a log source.
Validate enforcement through testing
Test each enforcement point against both permitted and prohibited flows. Permitted flows should pass, and prohibited flows should be blocked or alerted with a log entry. Include a sample of attempts that try to bypass a boundary, such as routing through an intermediate system. The test results, with the test case, expected outcome, observed outcome and log reference, form the evidence that assessors use to examine the mechanism. Failed tests return to the rule configuration step.
Set a review cycle for flow authorizations
Define how often the flow inventory, policy and authorization list are reviewed, and what triggers an earlier review, such as a new connected system, a change in data classification or a significant architecture change. Reviewers compare logs and the inventory against the authorizations, record any drift and close it through change control. The signed review record, with dates and reviewer names, shows that flow control remains current. The organization sets the cadence, and it is done when the first review has been recorded against the approved list.

AC-4 evidence that passes and how to keep it current

An assessor testing AC-4 Information flow enforcement looks for a chain of documents that agree with each other: the policy states the rules, the architecture and authorization lists say which flows are approved, and the configuration, rule exports and logs show the system enforcing them. Each artifact below goes stale for a different reason, so each needs its own refresh trigger.

Information flow control policy

This is the organization-defined policy that sets which information may move, between which systems, and under what conditions. Assessors check that it names the classes of information and the boundaries it governs, and that an owner approved it. Review it on a schedule and also after any new interconnection, cloud region, or change in data classification, because a policy that predates the current architecture fails on its face. Confirm the review cadence with your assessment plan.

Security architecture and flow diagrams

Architecture documentation shows where enforcement points sit, such as firewalls, proxies, web application filters and cross-domain gateways, and which paths between systems pass through them. Assessors compare the diagrams against live network data. Update them whenever a new connection, segment or enforcement device is added, and record the diagram version in the change ticket that caused the update.

List of approved information flow authorizations

This list names each permitted source, destination, protocol and information type, with the owner who approved it and the reason. It is the document that rule exports must match, so every firewall or filter rule should trace back to an entry. Keep entries tied to change requests and remove them when a system is decommissioned, since stale entries suggest that approvals are not being enforced.

Baseline configuration of enforcement devices

Assessors want the configuration as it stood at a known point, so they can see what enforcement was in force during the assessment period. For open-source enforcement points such as OPNsense, Coraza or Suricata, store configuration in version control and tag each approved state. Any change should create a new baseline, and the difference between baselines should be explainable from a change record.

Rule exports and change reviews

Periodic exports of filter rules, aliases and web application filter rulesets are the evidence that the enforced rules match the approved list. Schedule a rule review, comparing the export against authorizations, and record who signed it off. Rule count and alias changes between reviews should be investigated, not accepted by default. Ask the assessor which export format and frequency they expect.

Flow logs and retained audit records

Logs showing allowed and blocked flows are the strongest evidence that enforcement operates in practice. Suricata's EVE output and Zeek's conn.log can record flows and protocol transactions, and OPNsense can log each rule match. Keep these logs for the period the assessment plan and authorizing official require, and test that old records can still be retrieved. Retention periods are a decision for your authorizing official, not a default to assume.

Test records showing blocked paths fail

A dated test that attempts a prohibited flow and records that it was blocked proves the control works, not just that a rule exists. Repeat these tests after firewall, proxy or filter changes, and keep the attempt, the expected result, the observed result and the log entry that confirms the block. Test records also give the assessor something to replay if they question a rule.

Open-source tools that produce AC-4 evidence

Coraza is an open-source web application firewall licensed under Apache-2.0. It is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it defends against attacks such as SQL injection, cross-site scripting and code injection. For AC-4, its value is evidence that requests carrying disallowed content are inspected and blocked or logged before they reach an application, which is a flow decision at the boundary of a web service.

Rule configuration: The rule set and its version, showing which content patterns the policy permits to flow to the application.
Integration point: Documentation of where Coraza sits in the path, such as with Caddy, HAProxy, Traefik or Nginx, so assessors can see that traffic cannot bypass it.
Audit log entries: Records of blocked and logged transactions that show enforcement occurred.
Exception handling: Documented tuning decisions and approvals for rules disabled or adjusted.
Testing results: Evidence from test requests showing the policy blocks defined disallowed flows.

Before relying on this layer, confirm with the vendor and your own testing exactly which Coraza features and integrations your deployment uses, and have your counsel review the Apache-2.0 license terms for your distribution model.

What meeting AC-4 costs in money and effort

This table breaks down the money and effort behind AC-4 information flow enforcement, row by row, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a written scope before requesting quotes, since no DeployOpen price list exists and no supplied figures set durations or fees. The main takeaway is that flow count, boundary count and log volume drive most of the effort.

Cost component	One-time or recurring, and who is paid	What drives it and how to reduce it
Tooling and licenses	Mostly one-time setup, plus recurring subscriptions if commercial. Open-source options such as OPNsense, Suricata and Zeek carry no license fee, but staff time and hosting are still paid.	Commercial flow control or gateway licenses scale with throughput or devices. Self-hosted open source removes license spend; confirm hardware and support needs in writing.
Policy and rule design	One-time for the initial flow control policy and rule set, recurring for revisions. Paid to the organization's architects and to any implementation partner for scoping work.	Cost rises with the number of authorized flows and boundaries. Reduce it by grouping flows into named aliases and reusing one policy template across enclaves.
Engineering and configuration	One-time for building filters, domains and separation in the target environment. Paid to internal engineers or a fixed-scope implementation partner.	Driven by number of boundaries, connected systems and whether high baseline AC-4(4) encrypted-flow inspection applies. Ask for a written fixed-scope quote listing each boundary.
Testing effort	One-time for initial verification, recurring after each change to rules. Paid to internal testers or a security testing provider.	Driven by the number of rules and change frequency. Reduce it by scripting test cases for denied and allowed flows and retesting only affected rules.
Log and evidence upkeep	Recurring. Paid to operations staff for log retention, review and storage, and for hosting log platforms.	Log volume is the main driver. Suricata EVE output and Zeek conn.log can be split into separate files, which helps focus review. Confirm retention periods against your own policy.
Change management	Recurring. Paid to network and security staff who approve and document each rule change.	Change frequency drives this cost. Batch approved changes and record the authorization for each flow change so the change history supports assessment.
External testing or review	Periodic, paid to an independent tester or assessor. Assessors issue findings; DeployOpen does not issue audit reports.	Driven by scope and the number of boundaries tested. Request the assessor's written scope and sampling approach before agreeing fees.
Auditor sampling	Recurring per assessment cycle, paid to the independent auditor or assessor.	Sample size depends on the assessor's method and the number of flows and logs in scope. Ask the assessor for the sample basis in writing before the engagement starts.

Who does what for AC-4: your team, a partner and the auditor

Your organization owns AC-4. That means defining the information flow control policies the system must enforce, approving which flows are authorized between the system and other systems, and accepting the residual risk when a flow is allowed. The assessor will ask for these decisions in writing, so they cannot be delegated to a vendor or left implicit in a firewall configuration.

Flow policies: Write the policies that state which information may move, between which zones, in which formats and under which conditions. Assessors check these against the architecture.
Authorization decisions: Keep a current list of information flow authorizations, with an owner and a review date for each.
Control ownership: Name the people who run the enforcement points and the log review, and make sure they can explain them in an interview.
Final evidence: Review, sign and retain the evidence package, including the system security and privacy plan entry for AC-4.
Outsourcing: You can buy help with rule sets, logging and test records, but accountability for the control and its results stays with you.

Before engaging anyone, confirm with your assessor which artifacts they expect for AC-4 and who in your organization signs off on each one.

AC-4 questions buyers ask before bringing in help

How much effort does AC-4 take compared with other access control families?

AC-4 usually takes less effort than account management or remote access, because it has one assessment determination statement in SP 800-53A Rev. 5 and is selected only in the moderate and high baselines of SP 800-53B. The effort comes from design, not paperwork: someone has to define the information flow control policies, map which systems and domains connect, and show that the enforcement points (firewalls, proxies, data guards, network segmentation) match those policies. Effort rises with the number of connected systems, the number of trust zones and how many flow rules exist. Ask any partner to size the work from a written list of system boundaries and flow paths.

Can a small team handle AC-4 in-house?

A small team can often handle the baseline requirement in-house if it has someone who understands the network architecture and can explain it on paper. The assessor will examine the information flow control policy, the security architecture documentation, the list of approved flow authorizations and the system audit records, then interview administrators and test the enforcement mechanisms. A small team typically struggles with keeping the flow authorization list current as systems change, and with producing logs that show enforcement decisions. An outside partner is most useful for building that evidence set and testing it before the assessor arrives.

What does AC-4 require from our own staff?

Your staff must own the policy and the decisions behind it. The organization defines the flow control policies, approves each flow authorization and keeps the architecture documents accurate. Network or security engineers must be able to walk an assessor through how traffic is permitted, blocked and logged between zones, and administrators must be able to demonstrate the mechanisms in use. Expect to name a control owner, a reviewer for flow changes and someone who can export firewall or sensor logs on request. A partner can prepare the configuration and evidence, but it cannot decide what your organization is allowed to move between systems.

How long does an AC-4 implementation take?

The timeline depends on scope: how many systems and connections are in the boundary, how much of the flow design already exists and how much evidence is missing. Your team should not rely on a generic duration. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, after the scope, deliverables and dependencies are documented. Ask any provider to break the timeline into discovery of flows, policy definition, technical configuration, logging and a dry-run assessment, and to state which steps depend on your staff's availability.

Do we need an auditor or implementation partner for AC-4?

Neither the standard nor the process requires an outside partner, but an independent assessor or authorizing official is part of the federal or contractual process that uses SP 800-53. Only an independent auditor, assessor or certification body issues assessment reports or certificates. DeployOpen prepares systems, controls and evidence for assessment and does not issue reports or certifications. Whether you need a partner depends on your team's capacity, the complexity of your flow architecture and the assessment your contract or regulator requires. Confirm the assessor's requirements before you start preparation.

Are open-source tools acceptable for AC-4 evidence?

Open-source tools can produce strong AC-4 evidence as long as the assessor accepts them within your documented architecture and your records show who configured them and how they are tested. OPNsense rules can show permitted and blocked flows with per-rule logging, Coraza can enforce web application traffic policy with OWASP Core Rule Set rules, and Suricata EVE output and Zeek conn.log can record flows and transactions across boundaries. Confirm with your assessor and with your own environment which tool outputs they will accept, how logs are retained and whether the product versions are supported. Tooling is evidence support, not a substitute for the flow policy.

What is the difference between AC-4 and AC-3 for our audit?

AC-3 governs who may access information, while AC-4 governs how information may move within the system and between connected systems, even by authorized users. Under AC-4 the organization defines flow control policies and enforces approved authorizations for each path. An auditor will test them separately, so your evidence for AC-4 should show flow rules, boundary devices and logs, not just user permissions. Confirm the boundary of each control in your system security plan so the two assessments do not overlap or leave gaps.

How DeployOpen scopes and prepares AC-4 evidence

DeployOpen works on AC-4 as an implementation partner. We prepare the flow control policies, enforcement points and evidence on self-hosted open-source platforms inside your own infrastructure, while your organization owns the control and an independent assessor reaches its own conclusions.

How we scope

Engagements are fixed-scope, with the systems, network boundaries and connected systems covered by AC-4 agreed in writing before work starts.
The written scope names the information flow control policies and authorizations that the implementation must enforce.
Scope records which enhancements are in play, such as AC-4(4) for high baseline systems, and which are out of scope.

How we build

We configure enforcement points such as packet filter rules, web application firewall rulesets and aliases for approved address groups.
We enable logging of rule matches and protocol records so each permitted or blocked flow can be traced to a policy decision.
We test enforcement against the agreed policy, covering allowed and denied flows, and record the results for the assessor.

How we hand over

Handover includes the documented flow control policy, the list of information flow authorizations and the security architecture diagrams.
Configuration baselines, rule exports and sample audit records are packaged so an assessor can examine them directly.
Your team receives runbooks for changing rules, reviewing logs and recording approvals, so the control keeps running after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
A retainer can cover rule reviews when connected systems change, keeping authorizations and enforcement aligned over time.
Assessor questions about AC-4 evidence can be answered with the same configurations and logs, with the final assessment conclusions remaining with the independent assessor.

AC-4 Information flow enforcement