AU-9(5): Dual Authorization

To meet the au-9(5): dual authorization requirement, you must configure and operate your environment so that two distinct authorized individuals (or equivalent independent approvals) are required before specific audit-related actions can occur. In practice, this means enforcing two-person approval for sensitive changes to audit logging configurations, audit records, or audit tools, and retaining evidence that the approvals were required and occurred.

Key takeaways:

• Define exactly which audit-related actions require dual authorization, then encode it in technical controls and workflow gates.
• Enforce separation of duties so the person requesting a sensitive audit action cannot be the sole approver.
• Keep durable evidence: approval records, change tickets, configuration snapshots, and reviewer identity.

AU-9(5) is a requirement under NIST SP 800-53 Rev. 5 focused on protecting the integrity and trustworthiness of your audit capability. Audit logs and the systems that generate, store, and analyze them are high-value targets. If a single administrator can disable logging, change what gets logged, delete records, or alter forwarding rules without a second set of eyes, your detection and investigation capability can fail silently.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing AU-9(5) is to treat it as a “two-person rule” for a defined set of audit control-plane actions. Your job is to (1) scope the actions, (2) ensure the technology enforces dual approval rather than relying on “policy only,” (3) assign clear owners and backups, and (4) build an evidence package that an assessor can test without guesswork.

This page gives requirement-level implementation guidance you can put into a control procedure, map to system workflows, and produce repeatable evidence for audits and assessments against NIST SP 800-53 Rev. 5. ¹

Requirement summary (plain English)

AU-9(5) requires dual authorization for certain actions affecting audit records or audit functionality. The control text is intentionally parameterized, so you must define the “what” (which action) and the “where” (which audit component or record set), then enforce two independent approvals before the action executes. ²

Think of AU-9(5) as protection against a single point of failure or abuse in audit administration. It aims to prevent one person from unilaterally:

• reducing visibility (disabling or narrowing logging),
• destroying evidence (deleting or truncating logs),
• manipulating audit tooling (changing collectors, forwarders, correlation rules),
• altering retention/immutability settings.

Regulatory text

“Enforce dual authorization for [assignment/organization-defined action] of [assignment/organization-defined audit-related object].” ²

Operator interpretation: what you must do

You must do three things, and auditors will look for all three:

1. Define the scope: document which audit-related actions (and which systems/data stores) require dual authorization.
2. Enforce it: implement workflow and technical controls so two independent approvals are required before execution.
3. Prove it: retain evidence showing the gating works and is used in day-to-day operations (not just in a policy).

Who it applies to

Entity scope

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

Operational scope (where AU-9(5) shows up)

AU-9(5) is most relevant anywhere you have an “audit control plane,” including:

• SIEM platforms and log analytics tools
• Central log collectors/forwarders/agents
• Cloud audit services and organization trails
• WORM/immutable log archives
• Privileged access tooling that can modify logging configurations
• Backup/restore workflows that can overwrite or purge log repositories

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

Step 1: Choose the “dual authorization” pattern you will enforce

Pick a pattern that your tooling can reliably implement and your assessors can test:

Pattern	What it looks like	Works well when	Evidence is easiest when
Two-person approval workflow	Requestor submits a change; two distinct approvers must approve before merge/apply	You manage audit config through tickets/IaC	Your ITSM and repo keep immutable approval logs
Two-person cryptographic control	Two separate keys/approvals required to decrypt/alter protected logs	You use immutable stores/HSM-backed operations	The key ceremony and HSM logs are captured
Dual-role gating	Action requires two roles; one person cannot hold both roles	You can enforce SoD in IAM	IAM role assignments and access reviews are strong

Document the chosen approach per system boundary and be consistent.

Step 2: Define the exact AU-9(5) scope statement (the parameters)

Because the control is parameterized, write a short scoping statement that fills in:

• Action(s): e.g., “disable audit logging,” “modify audit policy,” “delete audit records,” “change log forwarding destination,” “change retention/immutability settings,” “restore log archive from backup.”
• Object(s): e.g., “central log repository,” “SIEM correlation rules,” “cloud organization audit trail,” “audit agent configuration,” “audit record store.”

Deliverable: a one-page “AU-9(5) scope matrix” listing systems, in-scope actions, and enforcement mechanism.

Step 3: Map ownership and separation of duties (SoD)

Define roles, not names:

• Requestor role: the team that needs the change (often SecOps, Platform, CloudOps).
• Approver role A: security control owner (often Security Engineering or SOC lead).
• Approver role B: independent second approver (often GRC-designated approver, SRE manager, or system owner outside the requestor chain).

Rules to encode:

• A requestor cannot approve their own change.
• Approver A and B cannot be the same identity.
• Emergency access (“break glass”) requires compensating review with documented after-the-fact dual sign-off.

Step 4: Implement technical enforcement (don’t rely on policy text)

Common implementation options that assess well:

• ITSM-integrated change control: configure the change template for “audit systems” to require two approvals and block implementation until approvals are recorded.
• IaC / GitOps gating: require two reviewers/approvals before merging changes that touch audit logging repositories, plus branch protection and signed commits if available.
• Cloud policy guardrails: apply organization policies that prevent disabling audit trails except through an approved pipeline account, and then require dual approval for pipeline execution.
• Immutable logging configurations: use write-once storage and restrict delete actions behind dual approval workflows.

A fast test: attempt the in-scope action with only one approver and confirm the system blocks it. Capture that as evidence.

Step 5: Write the control procedure (what people do each time)

Your procedure should read like an operator runbook:

1. Open a change request using the “Audit Systems / AU-9(5)” template.
2. Document business justification, scope, rollback, and testing plan.
3. Obtain approvals from Approver A and Approver B (named roles).
4. Execute change through the approved mechanism (pipeline, change window, scripted runbook).
5. Attach implementation proof (logs, config diff, pipeline run ID).
6. Close change with post-change validation that audit collection is still functioning.

Step 6: Establish recurring oversight

AU-9(5) fails quietly when exceptions accumulate. Add oversight checks:

• Review a sample of audit-related changes to confirm dual approvals exist and match role requirements.
• Review privileged access assignments to ensure no one can both request and approve (or hold both approval roles).
• Track and retire emergency exceptions.

Daydream tip (where it fits naturally): Use Daydream to map AU-9(5) to a control owner, implementation procedure, and recurring evidence artifacts, then run a lightweight evidence cadence so approvals and tickets are collected continuously instead of during audit scramble. ²

Required evidence and artifacts to retain

Assessors typically want proof of design and proof of operation.

Design evidence (static)

• AU-9(5) scope matrix (systems, actions, objects, enforcement method)
• Role and responsibility definitions for requestor and dual approvers
• Documented procedure/runbook for audit-related changes
• Configuration screenshots/exports showing approval rules (ITSM workflow, repo branch protection, pipeline gates, IAM constraints)

Operating evidence (recurring)

• Change tickets showing dual approvals for in-scope actions
• Pull requests showing two distinct approvals before merge for audit config repos
• Pipeline execution logs tied to approved changes
• System logs showing the action occurred after approvals (or that it was blocked without them)
• Exception records for emergencies, with retroactive dual review and closure notes

Retention: align to your broader audit/log retention and change management retention rules; keep it long enough to cover the assessment lookback window used by your auditors.

Common exam/audit questions and hangups

1. “What exactly is covered by AU-9(5) in your environment?”
   Hangup: vague scope. Fix: provide the scope matrix and point to the tagged change template/repo path.

2. “Show me an example where dual authorization prevented an action.”
   Hangup: no negative test. Fix: keep one captured test where a single approver attempt was blocked.

3. “How do you prevent the same person from being both approvers?”
   Hangup: approvals exist but are not independent. Fix: enforce in the workflow tool and show SoD in IAM.

4. “What happens in an incident when you must change logging fast?”
   Hangup: emergency bypass without governance. Fix: define break-glass with after-the-fact dual approval and compensating monitoring.

5. “How do you know dual authorization is consistently used?”
   Hangup: control drift. Fix: periodic sampling and metrics from ITSM/repo reports.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only dual authorization.
  Avoidance: implement hard gates in ITSM, Git, or pipeline controls so the action cannot occur without approvals.

• Mistake: Scoping too broadly and creating operational paralysis.
  Avoidance: start with the highest-risk audit actions (disable logging, delete logs, retention/immutability changes). Expand scope after you prove the workflow works.

• Mistake: “Two approvals” from the same team and same admin group.
  Avoidance: define independence. Put Approver B outside the requestor chain, or require Security + System Owner.

• Mistake: Backdoor paths bypass the workflow.
  Avoidance: remove direct console permissions that can change audit settings. Force changes through the controlled pipeline account.

• Mistake: No evidence package.
  Avoidance: predefine evidence artifacts and store them in a single audit-ready location. Daydream can track the control, owner, and recurring evidence so you do not rebuild it each audit cycle.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-9(5), so this page does not cite enforcement actions. Practically, the risk is assessment failure and loss of trust in incident investigations: if an attacker or insider can change audit controls alone, you may be unable to prove what happened, when it happened, or who did it. That becomes a material operational risk even without a specific cited penalty schedule.

Practical execution plan (30/60/90-day)

Because this requirement is parameterized and tool-dependent, treat the plan as phased outcomes, not fixed-duration commitments.

First 30 days (Immediate)

• Identify in-scope systems that generate/store/route audit logs.
• Draft the AU-9(5) scope matrix with the initial set of high-risk actions.
• Assign control owner and approver roles; document SoD rules.
• Pick your enforcement mechanism per system (ITSM workflow, GitOps, IAM gating).

By 60 days (Near-term)

• Implement the technical gates in your chosen systems.
• Run a negative test (attempt a restricted action with one approver) and save evidence.
• Train operators: how to submit requests, how approvals work, what “emergency” means.

By 90 days (Stabilize and audit-ready)

• Collect multiple real change samples showing dual approvals and successful execution.
• Implement periodic sampling/oversight and a lightweight exception log.
• Centralize evidence storage and map artifacts to the AU-9(5) control record (Daydream fits well for this mapping and evidence cadence). ²

Frequently Asked Questions

What actions should I pick for AU-9(5) if the control text is parameterized?

Start with actions that can reduce visibility or destroy evidence: disabling logging, changing audit policy scope, deleting audit records, and changing retention/immutability settings. Document your choices in a scope matrix and tie each to a technical enforcement method. ²

Does “dual authorization” have to be two human approvals?

The control requires dual authorization, which you can meet through two independent approvals in a workflow or an equivalent mechanism that requires two distinct authorized actors. What matters is independence and enforceability, plus evidence that the system blocks single-party execution. ²

Can the same person approve twice using two accounts?

That fails separation of duties and will not assess well. Enforce identity uniqueness and role constraints so one person cannot satisfy both approvals, and review IAM assignments to prevent role stacking.

How do we handle emergency changes during an outage or active incident?

Define a break-glass path with tight access control, time limits, and mandatory after-the-fact dual review tied to the incident record. Keep the exception evidence with the same rigor as standard approvals.

What evidence do auditors ask for most often?

They ask for real examples: change tickets or pull requests showing two distinct approvals, plus proof the change actually executed and audit collection still worked after the change. Keep one negative-test artifact showing the gate blocks single-approver attempts.

How do I operationalize this across cloud and on-prem tools without creating chaos?

Standardize on one approval workflow (ITSM or GitOps) and force changes through it by removing direct permissions where feasible. Where you cannot, add detective controls and an exception register, then prioritize closing the bypass paths.

Footnotes

1. NIST SP 800-53 Rev. 5

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