AC-4: Information Flow Enforcement


FieldValue
Control IDAC-04
Control NameInformation Flow Enforcement
FrameworkNIST SP 800-53 Revision 5
Control FamilyAccess Control
BaselinesMODERATE HIGH
RelevanceSystem (First Party and Third Party)
Risk SeverityHigh

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 TypeExample Artifact
Policy documentationInformation flow control policy defining approved flow authorizations, boundary enforcement requirements, and review cadence
Architecture documentationSecurity and privacy architecture diagrams showing all segmentation boundaries, trust zones, and flow enforcement points
System design and configurationFirewall rule sets, proxy configurations, and data loss prevention policies enforcing approved information flow authorizations
Baseline and authorization recordsSystem baseline configuration with a current list of all approved information flow authorizations specifying source, destination, and conditions
ProceduresDocumented procedures for requesting, reviewing, and revoking information flow authorizations
Audit recordsSystem audit logs showing enforcement decisions at boundary protection devices, including both permitted and denied flows

Cross-framework mapping

FrameworkControl(s)Coverage
ISO 27001:20225.14 Information transferPartial
ISO 27001:20228.22 Segregation of networksPartial
ISO 27001:20228.23 Web filteringPartial
NIST SP 800-171 Rev 303.01.03 Information Flow EnforcementPartial
ControlRelationship
AC-03 Access EnforcementGoverns who can access information, complementing AC-04’s control over where information flows
AC-06 Least PrivilegeRestricts user and process permissions to the minimum needed, reducing the scope of potential unauthorized flows
AC-16 Security and Privacy AttributesDefines the metadata labels and tags that flow enforcement mechanisms use to make filtering decisions
AC-17 Remote AccessControls the channels through which external users connect, creating boundaries where flow enforcement rules apply
AC-19 Access Control for Mobile DevicesExtends flow enforcement considerations to mobile endpoints that may bypass traditional network boundaries
AC-21 Information SharingEstablishes the organizational agreements and conditions under which information flows between entities are authorized
AU-10 Non-repudiationProvides assurance that information flow transactions can be traced to their origin, supporting enforcement accountability
CA-03 Information ExchangeDefines the formal agreements governing information flows between systems owned by different organizations
CA-09 Internal System ConnectionsDocuments and authorizes connections between internal system components where flow enforcement applies
CM-07 Least FunctionalityReduces 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.

Experience superior visibility and a simpler approach to cyber risk management