AC-4(25): Data Sanitization

AC-4(25): data sanitization requirement means you must sanitize information whenever it moves between different security domains so the receiving domain only gets what it’s allowed to have, and nothing that could create unacceptable risk. Operationalize it by defining domain boundaries, specifying sanitization rules per transfer path, enforcing them with a technical control, and retaining repeatable evidence. ¹

Key takeaways:

• You need an explicit inventory of “security domains” and the transfer paths between them, not a generic data-handling policy.
• Sanitization must be enforceable (technical or tightly controlled manual) and mapped to clear “minimize [risk]” objectives and standards.
• Auditors look for consistent evidence: rules, configurations, logs, test results, and exceptions tied to approvals.

AC-4(25) is a control enhancement under NIST SP 800-53 Rev. 5 that comes into play any time data crosses a boundary between security domains. “Security domains” can be separate networks (classified/unclassified), cloud tenants, enclaves, environments (prod/dev), partner connections, or segmented zones with different authorization and trust assumptions. The requirement is simple to read and easy to fail in practice because teams often treat it as a general “sanitize storage media” activity rather than a “sanitize data-in-motion between domains” activity.

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to convert AC-4(25) into an enforceable set of transfer rules: what crosses which boundary, what must be removed or transformed, what standard governs the method, and how you prove the control works. You also need to decide what “minimize [objective]” means in your environment (for example, minimizing unauthorized disclosure, malicious content transfer, or metadata leakage) and document that decision so your assessor doesn’t have to guess. ¹

What AC-4(25) requires (plain English)

AC-4(25): data sanitization requirement expects you to sanitize information during transfers between different security domains to reduce a defined risk objective, using a defined sanitization standard/method that your organization specifies. In operational terms, you must:

1. identify the domain boundary, 2) define what “sanitized” means for that boundary, 3) enforce it on the transfer mechanism, and 4) keep evidence that sanitization happened consistently. ¹

This is not the same as end-of-life media destruction. This is about content control and transformation at the boundary.

Regulatory text

“When transferring information between different security domains, sanitize data to minimize {{ insert: param, ac-04.25_odp.01 }} in accordance with {{ insert: param, ac-04.25_odp.02 }}.” ¹

What the operator must do with the bracketed parameters

The OSCAL text includes organization-defined parameters. You must fill them in and make them auditable:

• ac-04.25_odp.01 (the “minimize …” objective): Define the specific risk(s) you are minimizing for cross-domain transfers. Examples you can defensibly choose include unauthorized disclosure, introduction of malicious code, hidden data/metadata leakage, or integrity loss. Pick what matches your authorization boundary and threat model, then keep it consistent across procedures.

• ac-04.25_odp.02 (the “in accordance with …” reference): Name the standard, procedure, or technical specification that governs sanitization for these transfers (for example, an internal Cross-Domain Transfer Standard, a secure file transfer gateway rule set, content disarm and reconstruction profiles, or approved data transformation schemas). Your assessor needs to see a stable reference they can test against. ¹

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 is flowed down through contracts, ATO requirements, or program security requirements. ¹

Operational contexts where it triggers

AC-4(25) is relevant whenever you have differing trust zones, including:

• Classified/unclassified or high/medium/low impact enclaves
• Regulated vs non-regulated environments (for example, FedRAMP boundary vs corporate IT)
• Prod-to-dev data movement (masking/redaction is often part of “sanitization” here)
• File exchanges with third parties via SFTP/managed file transfer, portals, or APIs
• Data replication across tenants, accounts, or regions with different security controls

If you cannot describe your domains and boundary controls, you cannot credibly claim compliance.

How to implement it (step-by-step)

Use this sequence to get from policy text to an operating control.

Step 1: Define security domains and trust boundaries

Create (or update) a domain register:

• Domain name and purpose (e.g., “Corporate IT”, “Fed enclave”, “Partner DMZ”)
• Data types handled (CUI, PII, export-controlled, proprietary)
• Boundary mechanisms (firewalls, proxies, API gateways, cross-domain solution, file gateway)
• Domain owner and boundary control owner (often network/security engineering)

Artifact: “Security Domain & Boundary Inventory” mapped to systems and data flows.

Step 2: Inventory cross-domain transfer paths

Enumerate each transfer path and its mechanism:

• Source domain → destination domain
• Transfer method (API, SFTP, email gateway, message bus, removable media, admin jump host)
• Directionality (one-way vs bidirectional)
• Human involvement (automated, operator-assisted, manual approval)
• Volume/criticality (qualitative is fine; focus on highest risk paths first)

Artifact: “Cross-Domain Transfer Register” (table form works best).

Step 3: Define the sanitization objective and sanitization standard (fill in the parameters)

For each transfer path, specify:

• Objective minimized: choose and document the risk to minimize for that path (the ODP objective). ¹
• Sanitization approach: what you remove/transform and why.
• Standard/procedure: the reference document or configuration baseline that defines “done.” ¹

A practical rule format assessors can test:

Transfer path	Allowed content	Sanitization rules	Tool/control	Standard/reference	Exceptions
Prod → Dev	Only synthetic or masked datasets	Remove direct identifiers; tokenize keys; drop free-text fields	Data pipeline job + DLP checks	Cross-Domain Transfer Standard vX	Approved by data owner

Step 4: Implement enforcement at the boundary

Pick enforcement that matches the transfer type:

• Files: secure file gateway with AV scanning, file type allowlisting/denylisting, macro stripping, metadata scrubbing, PDF “flattening,” or content disarm and reconstruction profiles.
• APIs/data streams: schema enforcement, field-level filtering, tokenization/masking, reject unknown fields, transform to approved canonical formats.
• Email: attachment controls, sandboxing, DLP rules, conversion to safe formats.
• Manual transfers: controlled staging area + two-person review + checksum validation + logging. Treat manual as an exception path and keep tight approvals.

What auditors will probe: whether the enforcement is consistent and cannot be bypassed without detection.

Step 5: Add logging, alerting, and exception handling

Minimum operational components:

• Log each transfer event (who/what/when/source/destination/object identifiers)
• Log sanitization outcomes (allowed, transformed, rejected) with reason codes
• Alert on policy violations (blocked prohibited file types, failed scans, schema violations)
• Manage exceptions with time-bound approvals and compensating controls

Artifacts: log samples, alert rules, exception tickets, and approvals.

Step 6: Validate with testing and recurring review

Testing must show the sanitization rules actually work:

• Test files with embedded metadata, macros, and disallowed formats
• Test API payloads with disallowed fields and overshared objects
• Confirm rejects are logged and visible to operations
• Retest after tool updates and boundary rule changes

Artifacts: test plan, test results, remediation records, change approvals.

Required evidence and artifacts to retain

Keep evidence that is easy to produce during an assessment and ties directly to the requirement text:

1. ODP decisions: documented “minimize [X]” objective and “in accordance with [Y]” reference, approved by the control owner. ¹
2. Domain and transfer inventories: domain register and transfer register with owners.
3. Sanitization rule definitions: configuration baselines, rule sets, schemas, or transformation specs.
4. Implementation proof: screenshots/exported configs, infrastructure-as-code repos, gateway policies.
5. Operational logs: samples showing transfers and sanitization outcomes across representative periods.
6. Exception workflow: tickets, risk acceptances, expirations, and compensating controls.
7. Testing evidence: test cases demonstrating rejection/transformation of prohibited content.

Daydream tip: many teams lose time because evidence lives across network tooling, data engineering, and ticketing systems. Daydream can help you map AC-4(25) to a named owner, a single implementation procedure, and a recurring evidence checklist so you can produce the same package every audit cycle without reinvention. ¹

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your artifacts:

• “What are your security domains, and who owns them?”
• “Show me the specific transfers that cross domains.”
• “Where is ‘sanitize’ defined for this boundary?”
• “How do you prevent bypass (alternate routes, direct internet transfers, shadow IT file shares)?”
• “Show a blocked transfer and the alert/ticket it generated.”
• “How do you handle urgent exceptions, and how do they expire?”

Hangup pattern: teams provide a data classification policy and a media sanitization policy, but cannot show boundary-specific enforcement.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating this as disk wiping.
   Fix: scope AC-4(25) to cross-domain transfers and document the boundary controls.

2. Mistake: one global statement like “we sanitize data” with no rule granularity.
   Fix: define sanitization rules per transfer path, even if you reuse standard profiles.

3. Mistake: relying on manual review with no logging.
   Fix: if manual is unavoidable, require structured checklists, tamper-evident logging, and approvals.

4. Mistake: no ownership across network and data teams.
   Fix: assign a single control owner with delegated technical owners per boundary; keep a RACI.

5. Mistake: no evidence that sanitization actually occurred.
   Fix: retain rule configs and logs; run periodic test transfers and keep results.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program to a specific penalty narrative. Your risk argument should stay practical: cross-domain transfers are a common path for data spills, malware propagation, and unauthorized data mixing. AC-4(25) reduces that risk by forcing deliberate, testable boundary transformations and by making exceptions visible and time-bound. ¹

Practical 30/60/90-day execution plan

Use phases (not date promises) to move fast without guessing effort.

First 30 days (Immediate)

• Name the AC-4(25) control owner and technical owners per boundary.
• Draft the domain register and transfer register focused on the highest-risk domains.
• Fill in the two parameters: the “minimize [objective]” statement and the “in accordance with [standard]” reference, even if the standard starts as an internal v0.1. ¹
• Select priority enforcement points (file gateway, API gateway, data pipeline controls).

By 60 days (Near-term)

• Implement sanitization rules for priority transfer paths and document configurations.
• Stand up logging and alerting for allowed/transformed/rejected transfers.
• Create an exception workflow with explicit expiry and approvals.
• Run a first round of adversarial test cases (bad file types, embedded macros, overshared API fields) and fix gaps.

By 90 days (Operationalize)

• Expand coverage to remaining transfer paths and reduce unmanaged pathways.
• Add recurring review: rule review on change, periodic evidence pulls, and re-testing after major updates.
• Package audit-ready evidence: inventories, rules, logs, tests, and exceptions in a consistent folder structure.
• If you’re scaling across many systems, configure Daydream to track owner assignments, procedures, and recurring evidence tasks so the control stays stable during org and tooling changes. ¹

Frequently Asked Questions

Does AC-4(25) require a specific sanitization tool?

No. It requires that you sanitize data crossing domains and do so in accordance with a defined standard or method that you specify and can evidence. ¹

What counts as a “different security domain” in a cloud environment?

Separate tenants/accounts, enclaves, or network segments with different trust assumptions or authorizations can be different domains. Document your domain definitions and the boundary mechanisms so the scope is clear during assessment.

Is masking PII for prod-to-dev transfers considered “sanitization” here?

It can be, if your defined objective is to minimize unauthorized disclosure and your standard requires masking/tokenization before the transfer. Your evidence must show the transformation is enforced, not optional. ¹

How do we handle manual transfers when automation isn’t possible?

Treat manual transfer as a controlled process with approvals, a checklist of sanitization steps, and strong logging of what moved and what checks were performed. Manual-only with no durable evidence is a common audit failure.

What evidence is strongest for auditors?

A transfer register tied to boundary rule configurations plus logs showing real transfers being transformed or blocked. Add test results that demonstrate your controls catch prohibited content.

How should third-party connections be handled under AC-4(25)?

Treat a third party connection as a domain boundary. Define allowed content, sanitize at the boundary (API gateway, file gateway, or DLP), and manage exceptions with approvals and expiry just like internal domain crossings.

Footnotes

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