AC-4(20): Approved Solutions

AC-4(20): Approved Solutions requires you to use an approved, organization-authorized solution to control how information moves across security domains (for example, from a higher-trust enclave to a lower-trust network). To operationalize it, define your domain boundaries, select and authorize the specific cross-domain controls, and keep evidence that only those approved paths and tools can move data. ¹

Key takeaways:

• “Approved solutions” means specific, pre-authorized technical mechanisms for cross-domain information flows, not informal process controls. ²
• You need a documented boundary, a controlled set of allowed flows, and enforcement that blocks everything else by default. ¹
• Audit readiness depends on evidence: approvals, configurations, monitoring, and change records for cross-domain paths. ²

AC-4(20): approved solutions requirement is a targeted enhancement under NIST SP 800-53’s Information Flow Enforcement control family. It exists for one reason: moving data between security domains is where “small” exceptions turn into major incidents. If your environment has multiple trust zones, multiple classifications, separate enclaves for regulated data, or segmented networks for third parties and production systems, you already have “security domains” in practice, even if you don’t call them that.

For a CCO or GRC lead, the operational win is clarity: this requirement is less about writing a policy and more about forcing cross-domain movement through named, authorized technical controls that you can explain to an assessor. The fastest path to implementation is to (1) define what “domains” are for your system, (2) define which information types are allowed to cross, (3) select the approved technical patterns that permit that movement, and (4) prove it with repeatable evidence.

This page gives requirement-level guidance you can hand to control owners and then assess against. It emphasizes what auditors ask for: clear scope, explicit approvals, enforceable configurations, and change control. ¹

Regulatory text

NIST AC-4(20) excerpt: “Employ {{ insert: param, ac-04.20_odp.01 }} to control the flow of {{ insert: param, ac-04.20_odp.02 }} across security domains.” ²

Operator interpretation of the text (what you must do)

• You must “employ” a real solution, not just a documented procedure. In practice, this means a technical enforcement point (or set of enforcement points) that mediates cross-domain traffic and data transfer. ¹
• The solution must be “approved.” Your organization needs an explicit authorization step (designated approver, decision record, and conditions of use) that declares which mechanisms are permitted for cross-domain transfers. ¹
• You must control “flow” across “security domains.” Define the domains, define what can cross, and enforce it so data does not “route around” the approved path. ²

Because the control uses organization-defined parameters (the placeholders in the excerpt), your implementation must fill in those parameters with your chosen approved solution(s) and the information types or flows they govern. ²

Plain-English requirement (what AC-4(20) expects)

If data needs to move between two zones with different trust levels, you must force that transfer through a designated, security-reviewed mechanism that your organization has explicitly approved. Your control posture should make the “approved path” the only path.

A practical way to read AC-4(20) is: no ad hoc cross-domain sharing. If a team can move data by emailing it to themselves, copying to unmanaged media, standing up an unreviewed tunnel, or enabling a one-off firewall rule, you have not met the intent.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 controls. ¹

Operational context (when you should trigger this control)

AC-4(20) becomes concrete when you have any of the following:

• Segmented environments (prod vs. dev, regulated vs. non-regulated, high-trust vs. low-trust)
• Separate enclaves for third-party access
• Boundary-controlled networks (on-prem to cloud, restricted SaaS to internal)
• Data movement via file transfer, APIs, message buses, integration platforms, or administrative tools that cross segmentation boundaries

If you have only one domain, the control tends to be “not applicable” in practice, but most modern enterprises have multiple domains once you include cloud accounts/projects/subscriptions, VPC/VNETs, and third-party connectivity.

What you actually need to do (step-by-step)

Step 1: Define your security domains and document the boundary

Create a short, assessor-readable “domain map”:

• Domain name (e.g., “Restricted PII enclave,” “Corporate IT,” “Third-party support zone”)
• Boundary components (firewalls, gateways, private connectivity, identity boundaries)
• Trust assumptions and sensitivity (high-level, no need to over-classify)

Deliverable: Security domain inventory + boundary diagram (system-specific).

Step 2: Inventory cross-domain flows and classify them by risk

Build an “approved flows register” that lists:

• Source domain → destination domain
• Information type (e.g., logs, PII extracts, build artifacts, tickets/attachments)
• Protocol/path (API, SFTP, message queue, HTTPS upload)
• Business owner and technical owner
• Required security checks (malware scanning, content filtering, DLP, sanitization, allowlist)

Keep this tight. Your goal is to shrink the set of flows you must defend and evidence.

Step 3: Define “approved solutions” and set approval criteria

Write a standard that answers:

• What tools/patterns count as an approved cross-domain solution in your environment?
• Who can approve a solution (security architect, ISSO, CISO delegate)?
• What minimum controls the solution must enforce (examples below)
• What logging and alerting is mandatory
• What change control is required for rule updates

Common approved-solution patterns (examples; pick those that match your architecture):

• Managed file transfer gateway with malware scanning and allowlists
• API gateway with strong auth, schema validation, and allowlisted routes
• Message broker with topic-level ACLs and content constraints
• Segmentation gateway with explicit, reviewed firewall policies plus application-layer controls

Key design choice: Decide whether you allow multiple approved solutions or a single standard mechanism. Multiple mechanisms are often inevitable, but they expand audit scope.

Step 4: Implement technical enforcement (default deny across domains)

The expected control posture is:

• Cross-domain connections are blocked unless explicitly allowed.
• Allowed flows are routed through the approved solution(s).
• Bypass paths are prevented (network routes, security groups, VPN split tunneling, unmanaged endpoints).

Concrete actions for control owners:

• Configure gateways, firewall rules, or service control policies to restrict cross-domain traffic to the approved endpoints.
• Enforce strong authentication and authorization for initiating transfers.
• Apply content controls appropriate to the flow (filtering, scanning, transformation, or validation).
• Turn on logging at the enforcement point and forward logs to your monitoring stack.

Step 5: Operationalize approvals and change management

Make approvals real:

• Require a ticket for any new cross-domain flow and any rule change.
• Document the approver, decision, and conditions (scope, expiry, compensating controls).
• Periodically revalidate flows: confirm they are still needed and still meet criteria.

This is where most programs fail: they implement a gateway but treat rule changes as “ops work” with no compliance trail. AC-4(20) expects the trail.

Step 6: Monitor and test

Your monitoring should answer:

• Who transferred what, from where to where, and was it allowed?
• What was blocked, and why?
• Are there repeated attempts to bypass the approved solution?

Your testing should include:

• A negative test: attempt a cross-domain transfer outside the approved solution and confirm it fails.
• A positive test: confirm approved transfers succeed and are logged.

Step 7: Map ownership and recurring evidence (assessment readiness)

Assign a control owner (usually network/security engineering) and a GRC owner (to maintain the register, approvals, and evidence calendar). A lightweight way to keep it stable is to track AC-4(20) in your control library with an implementation procedure and a list of recurring artifacts. ²

If you use Daydream for GRC execution, treat AC-4(20) as a requirements page that links directly to: the approved flows register, the approvals workflow, and recurring evidence tasks. That turns this control from a one-time project into a managed obligation.

Required evidence and artifacts to retain

Assessors usually want “show me” artifacts. Keep these in a single AC-4(20) evidence folder with consistent naming.

Minimum evidence set (practical)

• Approved solutions standard: what solutions are approved, approval criteria, and approvers.
• Security domain map: diagram + domain definitions.
• Approved flows register: the authoritative list of allowed cross-domain flows.
• Approval records: tickets/records for each flow and each material rule change.
• Configuration evidence: exports/screenshots of gateway policies, firewall rules, API gateway routes, allowlists.
• Logging evidence: sample logs showing allowed and blocked attempts; proof logs are retained and reviewable.
• Test results: negative/positive tests demonstrating enforcement.
• Periodic review record: evidence that flows and solutions are revalidated.

Common exam/audit questions and hangups

1. “What are your security domains?” If your answer is fuzzy, the rest collapses.
2. “Show me the approved solution.” Be ready to point to the exact enforcement point and its config.
3. “How do you prevent bypass?” Auditors look for alternate paths: direct VPN, open security group rules, unmanaged endpoints, shadow integrations.
4. “Who approved this flow and when?” Missing approvals are a common finding because teams treat cross-domain rules as routine changes.
5. “How do you know it’s working?” You need logs, alerts, and at least one control test that proves default deny outside the approved path.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-4(20)	How to avoid it
Calling a policy “the approved solution”	The requirement expects a solution that controls flow	Tie the requirement to specific gateways, services, and configurations. 1
No explicit domain definitions	You cannot prove “across security domains”	Publish a domain list and boundary diagram, then scope flows to it.
Allowing multiple “exceptions” paths	Real transfers happen outside the control	Enforce default deny and restrict cross-domain routing to the approved endpoints.
No approvals trail for rule changes	“Approved” becomes unverifiable	Require tickets with approver and rationale for each new flow or change.
Logging exists but isn’t reviewable	You cannot demonstrate control operation	Centralize logs, retain samples, and document review/alert procedures.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement context as general compliance and risk exposure rather than case-driven. ²

Risk-wise, cross-domain data movement is a common path for:

• Data leakage from restricted zones into general-purpose environments
• Malware introduction from lower-trust networks into higher-trust enclaves
• Untracked replication of regulated datasets, which complicates incident response and legal holds

For regulated environments, AC-4(20) gaps often show up during assessments as “boundary protection” or “information flow” failures: undocumented paths, unapproved tools, or missing evidence of approvals and monitoring.

Practical 30/60/90-day execution plan

You asked for speed. Use this as an execution checklist rather than a theoretical roadmap.

First 30 days: Stabilize scope and stop the bleed

• Name the security domains in scope and publish a simple boundary diagram.
• Stand up the approved flows register and capture current known flows.
• Identify any obvious bypass paths (unmanaged file sharing, direct routing) and put short-term blocks or compensating controls in place.
• Draft the “approved solutions” standard with interim approvals.

By 60 days: Implement enforceable approved solutions

• Select the approved solution patterns you will permit (one primary path per flow type where possible).
• Implement default deny between domains with explicit allow rules only through approved endpoints.
• Turn on logging and ensure you can retrieve events for allowed and blocked traffic.
• Put approvals and change control into your ticketing workflow.

By 90 days: Prove operation and make it repeatable

• Run and document negative/positive enforcement tests.
• Perform a first periodic review of the flows register: remove stale flows, tighten rules.
• Package evidence so an auditor can follow it: domains → flows → approvals → configs → logs → tests.
• Create recurring tasks in your GRC system (Daydream or equivalent) to collect config snapshots, sample logs, and review attestations on a defined cadence.

Frequently Asked Questions

What counts as a “security domain” for AC-4(20)?

A security domain is any environment boundary where trust level, access rules, or data sensitivity differs. If crossing that boundary changes who can access data or how it’s protected, treat it as a domain and manage the flow.

Do we need a specialized cross-domain solution product?

AC-4(20) requires an approved solution that controls cross-domain flows, but it does not name a specific product. Many organizations meet intent with well-governed gateways and strict segmentation, as long as the solution is explicitly approved and enforced. ¹

How do we show “approved” in a way auditors accept?

Keep a documented standard that lists approved solutions and the approval authority, plus tickets/records showing each cross-domain flow was reviewed and authorized. Tie each approval to a configuration baseline and change history.

We have lots of integrations. How do we keep the approved flows register from becoming a mess?

Start with the highest-risk domain crossings and require registration for new flows through intake. Then rationalize existing flows by deprecating duplicates and standardizing on a small set of approved patterns.

Is logging mandatory for AC-4(20)?

The excerpt focuses on employing approved solutions to control flow, but in practice you need logs to prove the solution is operating and to investigate misuse. Without logs, you will struggle to demonstrate ongoing control effectiveness during assessment. ¹

What evidence is most likely to be missing during an audit?

Approval records and change control for cross-domain rule updates are common gaps, followed by incomplete domain definitions. Fix this by making approvals part of the normal engineering workflow and collecting evidence on a recurring schedule.

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON