AC-4(10): Enable and Disable Security or Privacy Policy Filters

AC-4(10) requires you to give privileged administrators a controlled, auditable way to turn security or privacy policy filters on and off, but only under defined conditions. To operationalize it, document which filters are in scope, restrict who can change them, enforce approved conditions (for example, break-glass), and retain logs and tickets that prove each enable/disable event was authorized and reviewed. ¹

Key takeaways:

• Define the exact “filters” and the approved conditions to disable them, then make those conditions enforceable in tooling and process. ¹
• Treat filter changes as high-risk configuration changes: least privilege, approvals, logging, and post-change validation. ²
• Evidence is the control: change records, access lists, configurations, and logs must tie each event to an authorized admin and approved condition. ¹

The ac-4(10): enable and disable security or privacy policy filters requirement shows up in real operations as a tension between availability and control. Security and privacy filters (for example, network firewalls, web proxies, email DLP rules, API gateways, or data egress controls) sometimes need to be disabled for troubleshooting, incident response containment steps, maintenance windows, performance testing, or controlled data handling exceptions. AC-4(10) does not ban disabling. It requires that disabling is possible only through a privileged administrative capability and only under conditions you define and can defend. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate the enhancement into a narrow, testable control statement: “Only named privileged administrators can enable/disable defined policy filters, only via approved mechanisms, only under approved conditions, with complete audit trails and review.” Then you build the operational rails: roles, approvals, technical enforcement where feasible, and evidence packaging for assessors.

This page gives requirement-level implementation guidance you can hand to IAM, network/security engineering, and IT change management without rewriting it into theory.

Regulatory text

Control enhancement text (excerpt): “Provide the capability for privileged administrators to enable and disable [assignment: security or privacy policy filters] under the following conditions: [assignment: organization-defined conditions].” ¹

What the operator must do: you must (1) identify which security or privacy policy filters are in scope, (2) ensure privileged administrators have a defined capability to enable/disable those filters, and (3) constrain that capability to organization-defined conditions. Your “conditions” must be documented and implemented as enforceable process controls, technical controls, or both, and you must be able to prove it happened as designed. ¹

Plain-English interpretation (what AC-4(10) is really asking)

AC-4(10) expects controlled “circuit breakers” for policy enforcement points. You are allowed to disable a filter, but only:

• By the right people (privileged administrators you designate),
• Through the right path (approved mechanisms, not ad-hoc console changes with no record), and
• For the right reasons (conditions you define ahead of time and can show were met). ¹

In practice, assessors will test two things: (1) “Can someone disable a filter outside the rules?” and (2) “Can you prove every disable/enable event was authorized, time-bounded if applicable, logged, and reviewed?” ²

Who it applies to (entity and operational context)

This requirement is most relevant if you operate:

• Federal information systems or systems assessed against NIST SP 800-53. ²
• Contractor systems handling federal data, including environments where network segmentation, boundary protection, or data egress controls are used to enforce handling rules. ¹

Operationally, it applies wherever you have policy enforcement points that can be toggled:

• Network firewalls and segmentation rules
• Secure web gateways / proxies
• Email security and DLP rules
• Endpoint DLP controls (where centrally enforced)
• API gateway policy filters (authz, schema validation, rate limits tied to data protection)
• Cloud security controls that act as “filters” (for example, egress controls, service control policies that block specific actions, WAF rulesets)

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

Step 1: Define “filters” in scope (make it assessable)

Create a register that lists each filter/enforcement point that qualifies for AC-4(10) in your environment. For each entry, capture:

• System/service name and owner
• Where the filter runs (device, SaaS console, cloud policy layer)
• What policy it enforces (security or privacy objective)
• How it can be enabled/disabled (UI, API, config deployment)
• Logging source for changes (SIEM feed, native audit log) ²

Practical tip: if you cannot explain what a “filter” is in your environment in one sentence, your scope is too vague to test.

Step 2: Define the “conditions” under which enable/disable is permitted

Write organization-defined conditions that are narrow enough to defend. Common condition categories you can define (choose what fits your risk model):

• Approved change window tied to a change record
• Incident response activity tied to an incident ticket
• Break-glass emergency with retrospective approval
• Vendor-supported maintenance event with documented need
• Short-term troubleshooting with compensating controls (for example, temporary routing through an alternate inspection point)

Your conditions should specify:

• Required approvals (role-based, not named individuals)
• Required compensating controls when disabling (for example, alternate monitoring)
• Maximum duration or explicit re-enable trigger (use whatever your organization can enforce consistently)
• Required validations after re-enable (for example, confirm policy enforcement resumes) ¹

Step 3: Restrict the capability to privileged administrators (and prove it)

Implement least privilege so only designated roles can change filter state. Minimum expectations:

• Role-based access control in each control plane (firewall manager, cloud console, DLP console)
• Separate roles for “view” vs “change”
• MFA for privileged actions (where supported)
• Named groups mapped to HR-backed identity lifecycle (joiner/mover/leaver controls)

Evidence should show current membership and approvals for membership changes. ²

Step 4: Put the change path under control (avoid “silent disables”)

Decide the approved mechanism for changing filter state:

• Central configuration management (preferred)
• Change management workflow with scripted execution
• Break-glass path that triggers heightened logging and paging

Block or discourage out-of-band changes:

• Remove direct device access where possible
• Require changes via management plane with audit trail
• Alert on “disable” keywords or state changes in audit logs ²

Step 5: Log every enable/disable event and tie it to authorization

You need end-to-end traceability:

• Who performed the action (identity)
• What changed (object, rule, policy, filter state)
• When it changed (timestamp)
• Where it changed (system/device)
• Why it changed (ticket/change/incident reference)

If your tools do not natively capture “why,” require it in the ticket and enforce correlation by process (for example, change record must include the exact object name). ²

Step 6: Validate and review (prove the filter came back)

Build a lightweight review loop:

• Post-change verification checklist (filter enabled, policy deployed, health checks green)
• Periodic review of disable events (exceptions report) by security governance or the control owner
• Follow-up on any disable without a valid condition, documented as an incident or nonconformance ²

Step 7: Package the control for assessment

Map AC-4(10) to:

• Control owner
• Implementation procedure
• Recurring evidence artifacts and frequency expectations

This is where Daydream helps in practice: keep the control narrative, scope register, and evidence requests in one place, so engineering teams produce the same artifacts each cycle instead of rebuilding them for every assessment. ¹

Required evidence and artifacts to retain

Keep evidence that answers: “What are the filters, who can change them, under what conditions, and did it happen that way?”

Minimum evidence set:

• Filter scope register (system list with owners and control points)
• Policy / standard defining the organization-approved conditions for enable/disable
• Access control evidence: privileged admin role definitions and current group membership exports/screenshots
• Procedures / runbooks: normal change and break-glass steps
• Change/incident tickets for a sample of enable/disable events (include approvals and justification)
• Audit logs showing the enable/disable action (native logs and/or SIEM entries)
• Post-change validation records (checklist, monitoring screenshots, or automated test output)
• Exception report + management review notes for periodic governance review ²

Common exam/audit questions and hangups

Expect questions like:

• “What filters are in scope, and how did you decide?” ¹
• “Show me who can disable them today.” ²
• “Show me a disable event and prove it met the defined conditions.” ¹
• “How do you detect and respond to an unauthorized disable?” ²
• “How do you ensure re-enable happens and policy enforcement resumes?” ²

Hangups that slow teams down:

• Filters exist across multiple consoles with inconsistent role models.
• Logs exist but are not correlated to tickets, so “why” is missing.
• Break-glass exists but has no retrospective approval or review record.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AC-4(10)	Fix
“Conditions” are vague (“as needed”)	Not defensible or testable against the enhancement’s required conditions. 1	Write explicit condition categories and required artifacts (ticket types, approvers, compensating controls).
Too many admins can toggle filters	Expands the blast radius of disabling controls. 2	Reduce to role-based groups, require approvals for membership, and review membership routinely.
Disables happen via local console/CLI with no ticket	Breaks traceability and creates “silent bypass.” 2	Force changes through managed planes; alert on out-of-band changes; require ticket IDs in change workflow.
No proof of re-enable and validation	Auditors will treat “disabled temporarily” as “disabled without control.” 2	Add post-change checklist and capture evidence; alert if disable exceeds your defined condition.
Evidence is scattered	Control exists but cannot be demonstrated. 1	Centralize the control narrative and evidence list (Daydream or an equivalent GRC system).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, AC-4(10) is assessed as a control design and operating effectiveness issue: if staff can disable security/privacy filters without defined conditions and auditability, you have an uncontrolled policy-bypass path. That increases the likelihood that data flows in ways your organization did not authorize, and it complicates incident investigations because you cannot prove what protections were active at a given time. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and rules)

• Identify the systems where disabling a filter would materially change data flow or policy enforcement; build the first version of the filter scope register. ²
• Draft the “conditions to enable/disable” standard and get Security, Privacy (if applicable), and Change Management sign-off. ¹
• Inventory who currently has rights to disable each filter and remove obvious excess access (quick wins). ²

Next 60 days (implement the rails)

• Implement role-based groups and align them across consoles (or document compensating controls where a platform is limited). ²
• Standardize the approved change path: define ticket fields, required approvals, and required validation steps. ²
• Ensure audit logs are collected centrally and you can query for enable/disable events by filter type. ²

By 90 days (prove operational effectiveness)

• Run a tabletop: execute a planned disable and a break-glass disable, then confirm logs, tickets, approvals, and validation artifacts are complete. ¹
• Produce an exception report of disable events for a review period and hold the first governance review meeting; document outcomes and corrective actions. ²
• Package the control: owner, procedure, scope register, and “evidence kit” in Daydream so the next audit request is a pull, not a scramble. ¹

Frequently Asked Questions

What counts as a “security or privacy policy filter” for AC-4(10)?

Treat it as any technical enforcement point that blocks, allows, inspects, or transforms traffic or data to enforce security or privacy rules. If disabling it changes what data can flow or be exposed, include it in scope. ¹

Do we need a technical control to enforce the “conditions,” or is a process enough?

The requirement says you must define conditions and provide the capability for privileged admins to enable/disable under those conditions. If your tools cannot technically enforce the condition, make the condition enforceable through approvals, ticketing, logging, and review, and be ready to show evidence. ¹

How do we handle break-glass disables during an incident?

Define break-glass as an allowed condition, limit who can invoke it, and require heightened logging and retrospective approval. Keep the incident ticket, the audit log event, and the post-incident review notes linked. ²

Is “disabling a single rule” the same as “disabling the filter”?

It can be, if the rule change materially removes the policy enforcement outcome. Scope both full disable actions and “effective disables” (for example, allow-any rules, bypass groups, inspection exclusions) where they function as turning the filter off. ²

What evidence does an assessor usually ask for first?

They usually start with the list of in-scope filters, the defined conditions, and one or more disable/enable samples that show approvals, logs, and validation. Have that packaged as a repeatable evidence kit. ¹

Our SaaS control plane has limited audit logs. What do we do?

Document the limitation, turn on the strongest available native auditing, and add compensating controls such as ticket-required changes, admin activity monitoring, and periodic configuration snapshots. Keep the documentation and snapshots as part of your evidence set. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5