| Field | Value |
|---|---|
| Control ID | AC-04 |
| Control Name | Information Flow Enforcement |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | Access Control |
| Baselines | MODERATE HIGH |
| Relevance | System (First Party and Third Party) |
| Risk Severity | High |
What this control requires
AC-04 requires organizations to enforce approved policies governing where information can travel within and between connected systems. Most security teams focus on access control, deciding who can reach a resource, but overlook the equally critical question of whether data itself should be allowed to cross a boundary once access is granted.
In practice, this control demands that you define and enforce policies at network boundaries and internal segmentation points. These policies regulate traffic based on packet headers, message content, data structures, and metadata attributes. Boundary protection devices, including firewalls, proxies, and data loss prevention systems, must enforce rule sets that block unauthorized flows at every network boundary.
In practice, this means enforcement applies in both directions. You need to account for inbound threats like external traffic that falsely claims an internal origin and outbound risks like export-controlled data transmitted in the clear.
Beyond packet-level traffic, the requirement extends to control plane communications such as routing protocols and DNS queries. Organizations must also address information transfers between connected systems, verifying write permissions before accepting data from another security domain and employing mechanisms like hardware-enforced one-way data flows where the sensitivity level demands it.
Why it matters
The absence of information flow enforcement creates a condition where a single compromised endpoint can reach every system on the network. When attackers gain initial access, the first thing they test is how far they can move laterally without triggering a control. Networks that lack segmentation and flow restrictions answer that question generously.
Bangladesh Bank SWIFT heist
On the night of February 4-5, 2016, attackers submitted 35 fraudulent SWIFT payment instructions from Bangladesh Bank’s terminal to the Federal Reserve Bank of New York, attempting to transfer approximately $951 million. Five transfers totaling $101 million succeeded before a spelling error (“fandation” instead of “foundation”) and a sanctions list match caused Deutsche Bank to flag further transactions. Of the $101 million stolen, $81 million went to the Philippines and $20 million to Sri Lanka, with only approximately $15 million ultimately recovered.
The result was a clean path through the organization. The attackers, attributed to North Korea’s APT38/Lazarus Group (Department of Justice indictment 2021), entered the network through spear phishing and moved laterally from the general employee network to SWIFT terminal infrastructure.
Specifically, the attackers deployed custom malware (evtdiag.exe, documented by BAE Systems) that submitted fraudulent requests, deleted outgoing message records, and intercepted incoming SWIFT confirmation printouts.
The root cause was the complete absence of AC-04 information flow enforcement. Bangladesh Bank had no firewall separating its general network from the SWIFT terminal systems. The network used secondhand switches incapable of virtual local area network segmentation.
The exposure worsened in October 2015, when the bank connected its SWIFT system to its commercial banking payment platform, expanding the blast radius further. This incident became the canonical case study cited by SWIFT’s Customer Security Programme for mandatory network isolation.
What attackers exploit
- Flat network architectures that allow unrestricted lateral movement from any compromised host to high-value targets
- Missing or misconfigured boundary protection devices that fail to enforce flow rules between security domains
- Unregulated control plane traffic where DNS tunneling or routing manipulation exfiltrates data through channels that bypass content inspection
- Overly permissive inter-system connections that transfer data without verifying write permissions or validating information flow authorizations
- Absent egress filtering that allows sensitive data to leave the network without content-aware inspection
How to implement
The most common failure mode with AC-04 is treating it as a one-time firewall deployment rather than an ongoing program of flow policy definition, enforcement, monitoring, and revision.
For your organization
Start by mapping your information flow architecture. Document every path that data takes within your systems and between connected systems, including control plane traffic like DNS and routing protocols. This mapping becomes the foundation of your information flow control policies.
Specifically, define approved information flow authorizations for each boundary. Each authorization should specify the source, destination, data type, protocol, and conditions under which the flow is permitted. Document these authorizations formally and tie them to your security architecture.
With authorizations documented, deploy boundary protection devices at every segmentation point. Firewalls, proxies, and content filters should enforce your flow rules using packet header inspection, message filtering, or both. Where sensitivity demands it, consider hardware-enforced one-way data diodes for flows that must never reverse direction.
In practice, segmentation must extend beyond boundary devices. Implement network segmentation that isolates high-value assets and critical systems from general-purpose networks. Microsegmentation adds granular flow control within segments, restricting lateral movement even after an attacker gains a foothold.
In practice, the same discipline must extend to egress. Block outbound traffic that doesn’t match approved flow authorizations, and implement web filtering to restrict requests that bypass your internal proxy.
But enforcement without monitoring leaves gaps undetected. Establish audit processes that log flow enforcement decisions, review denied flows for patterns suggesting misconfiguration or attempted exploitation, and update your flow policies whenever you add new systems, connections, or data types.
Common mistakes:
- Deploying firewalls but leaving default-allow rules in place
- Segmenting the network without accounting for control plane traffic
- Defining flow authorizations once and never reviewing them after infrastructure changes
- Treating information transfer controls as synonymous with access control, missing the distinction between who accesses data and where data travels
For your vendors
When assessing a vendor’s AC-04 compliance, focus your security questionnaire on whether they can demonstrate actual enforcement rather than just policy documentation. The distinction matters because most vendors can produce a policy document, but far fewer can show the technical artifacts proving enforcement is active.
Specifically, ask for a copy of their information flow control policy and any associated network architecture diagrams that show segmentation boundaries. Request evidence of specific flow authorizations, including source, destination, data type, and enforcement mechanism for each approved path. A vendor that can only provide a high-level network diagram without documented flow rules likely hasn’t implemented meaningful AC-04 controls.
Beyond policy documents, request firewall rule sets or boundary device configurations for the segments that process your data. You don’t need every rule across the enterprise, but you should see the rules governing the trust boundaries around your data. Look for default-deny postures and explicit allow rules tied to documented authorizations.
But documented controls without monitoring leave gaps undetected. Ask how the vendor audits information flow enforcement and request samples of audit logs showing both approved and denied flows at boundary points. Vendors should be able to demonstrate a regular review cadence for their flow policies.
Red flags to watch for:
- Network diagrams that show a flat architecture with no internal segmentation
- Inability to identify where your data resides and which flow boundaries protect it
- Firewall configurations with broad allow-any rules or legacy rules that no one can explain
- No documented process for reviewing and updating flow authorizations after changes
- Self-attestation without supporting technical artifacts
To verify beyond self-attestation, request recent penetration test results that specifically tested network segmentation effectiveness. An independent assessor’s findings on lateral movement controls provide far stronger assurance than a completed questionnaire alone.
Evidence examples
The following artifacts demonstrate AC-04 compliance during an assessment, covering both policy-level and technical evidence aligned with the Access Control family.
| Evidence Type | Example Artifact |
|---|---|
| Policy documentation | Information flow control policy defining approved flow authorizations, boundary enforcement requirements, and review cadence |
| Architecture documentation | Security and privacy architecture diagrams showing all segmentation boundaries, trust zones, and flow enforcement points |
| System design and configuration | Firewall rule sets, proxy configurations, and data loss prevention policies enforcing approved information flow authorizations |
| Baseline and authorization records | System baseline configuration with a current list of all approved information flow authorizations specifying source, destination, and conditions |
| Procedures | Documented procedures for requesting, reviewing, and revoking information flow authorizations |
| Audit records | System audit logs showing enforcement decisions at boundary protection devices, including both permitted and denied flows |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.14 Information transfer | Partial |
| ISO 27001:2022 | 8.22 Segregation of networks | Partial |
| ISO 27001:2022 | 8.23 Web filtering | Partial |
| NIST SP 800-171 Rev 3 | 03.01.03 Information Flow Enforcement | Partial |
Related controls
| Control | Relationship |
|---|---|
| AC-03 Access Enforcement | Governs who can access information, complementing AC-04’s control over where information flows |
| AC-06 Least Privilege | Restricts user and process permissions to the minimum needed, reducing the scope of potential unauthorized flows |
| AC-16 Security and Privacy Attributes | Defines the metadata labels and tags that flow enforcement mechanisms use to make filtering decisions |
| AC-17 Remote Access | Controls the channels through which external users connect, creating boundaries where flow enforcement rules apply |
| AC-19 Access Control for Mobile Devices | Extends flow enforcement considerations to mobile endpoints that may bypass traditional network boundaries |
| AC-21 Information Sharing | Establishes the organizational agreements and conditions under which information flows between entities are authorized |
| AU-10 Non-repudiation | Provides assurance that information flow transactions can be traced to their origin, supporting enforcement accountability |
| CA-03 Information Exchange | Defines the formal agreements governing information flows between systems owned by different organizations |
| CA-09 Internal System Connections | Documents and authorizes connections between internal system components where flow enforcement applies |
| CM-07 Least Functionality | Reduces the attack surface by disabling unnecessary services and protocols that could create unauthorized data flow paths |
Frequently asked questions
What is NIST SP 800-53 AC-04
AC-04 requires organizations to enforce approved information flow authorizations that control where data can travel within a system and between connected systems. Unlike access enforcement (AC-03), which determines who can reach a resource, AC-04 governs the movement of information itself through boundary protection devices using rule sets, packet filtering, and message-filtering mechanisms. Organizations must document each approved flow path, deploy enforcement at every segmentation boundary, and extend these controls to cover control plane traffic like DNS and routing protocols.
What happens if AC-04 is not implemented
Without AC-04, a single compromised endpoint can reach every system on the network because no boundary protection devices enforce restrictions on where data travels. Attackers exploit this gap to move laterally from low-value entry points to high-value targets, as demonstrated in the Bangladesh Bank heist where the absence of a firewall between the general network and SWIFT terminals enabled a $101 million theft. Organizations also face compliance failures in NIST SP 800-53 moderate and high baselines, where AC-04 is a required control with assessors specifically evaluating whether approved information flow authorizations are enforced.
How do you audit AC-04
Auditing AC-04 starts with verifying that the organization maintains a current list of approved information flow authorizations and that boundary protection devices enforce those authorizations at every documented segmentation point. Assessors review firewall rule sets, proxy configurations, data loss prevention policies, and system audit records to confirm they match documented flow authorizations and that denied flows are logged. Penetration testing targeting network segmentation controls provides the strongest technical validation that enforcement operates as intended.
What is the difference between AC-3 and AC-4
AC-3 (Access Enforcement) controls who can access a system or resource based on identity, role, and permissions. AC-4 (Information Flow Enforcement) controls where information itself can travel, regardless of who initiated the request, by enforcing rules at boundary protection devices based on data attributes, packet headers, and content inspection. A user might have legitimate access to two systems under AC-3, but AC-4 could still block a data transfer between those systems if no approved information flow authorization exists for that path.