AU-9(5): Dual Authorization

AU-9(5) requires you to enforce dual authorization (two distinct approvals) before anyone can move or delete audit information, so a single admin cannot tamper with logs to hide activity. Operationalize it by (1) defining what counts as “audit information,” (2) restricting log movement/deletion to controlled workflows, and (3) retaining approval evidence for each event. ¹

Key takeaways:

• Dual authorization must apply to log movement and/or deletion, not just viewing or exporting logs. ¹
• The control fails if one person can approve and execute, or if “break glass” actions lack compensating approvals and review.
• Evidence matters: you need immutable records of both approvals and the resulting log action, tied to a ticket/change record.

Audit logs are only useful if they are trustworthy. AU-9(5) is a targeted safeguard against a common failure mode: an administrator (or compromised admin account) alters, deletes, or relocates logs to erase traces of wrongdoing. The requirement is simple in text but easy to get wrong in implementation because “logs” live in multiple places (SIEM, cloud-native logging, EDR, application logs, database audit logs), and operational teams often keep broad admin permissions for troubleshooting.

For a CCO or GRC lead, the fastest path is to treat AU-9(5) as a workflow control, not a policy statement. You need to decide which log repositories are in scope, which actions count as “movement” or “deletion,” which systems can technically enforce two-person approval, and how you will prove it in an assessment. You also need an exceptions path for emergencies that does not become the default.

This page gives requirement-level implementation guidance you can hand to Security Operations, IAM, and platform owners, plus the evidence bundle auditors will ask for and the common hangups that cause findings.

Regulatory text

Requirement excerpt: “Enforce dual authorization for [one or more of: movement; deletion] of [audit information].” ¹

Operator meaning: Configure your systems and processes so that moving audit information (for example, transferring logs to a different bucket, index, tenancy, or storage account) and/or deleting audit information cannot be completed by a single individual acting alone. Two distinct authorized parties must approve (or one approves and another executes, depending on your design), and you must be able to prove it happened for each event. ¹

Plain-English interpretation

• What counts: “Audit information” includes the records you rely on for detection, investigation, and accountability. Treat both raw logs and centralized copies (SIEM indexes, archived WORM copies, cold storage exports) as in scope if they are part of your audit trail.
• What actions are controlled:
  • Deletion includes purge jobs, retention overrides, “delete index,” “delete bucket objects,” “truncate table,” and “wipe workspace.”
  • Movement includes changing the storage location, moving to a different account/project/subscription, migrating log backends, exporting to removable media, or changing where logs are routed so they are no longer retained in the controlled repository.
• What “dual authorization” means in practice: two separate identities with appropriate authority must be involved. If one person can self-approve (same individual or same credential used twice), you do not have dual authorization.

Who it applies to

AU-9(5) is most relevant where audit logs support security monitoring, incident response, compliance reporting, or investigations, and where administrators or third parties have the technical ability to alter logging repositories.

Typical applicability contexts:

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 as part of an ATO, contract clause, or inherited control set. ²
• Centralized logging and monitoring stacks (SIEM, log analytics platforms), especially those administered by SecOps or a managed security service provider (a third party).
• Cloud logging storage (object storage buckets, log archives) where IAM misconfiguration can allow delete actions.
• Platforms with high-privilege admin consoles (EDR, identity providers, ticketing and monitoring tools) where “delete audit events” exists as a UI function.

Practical scoping rule: if a log source is material to investigations or auditability, treat it as “audit information” for AU-9(5).

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

1) Define “audit information” and the in-scope repositories

Create a short inventory table owned by Security/GRC with system owners:

Log repository	Purpose	System owner	Admin roles	Movement actions	Deletion actions	Dual-auth method

Include at least: SIEM, cloud-native logging archive, EDR audit logs, identity provider audit logs, and any database/app audit logs used for investigations.

2) Choose which actions you enforce (movement, deletion, or both)

The control text allows selecting “movement,” “deletion,” or both. Most serious implementations cover both because moving logs out of controlled storage can be functionally equivalent to deletion. Document your selection and rationale in your control narrative. ¹

3) Implement technical enforcement where possible

Preferred patterns (strongest to weakest):

1. Native dual-control / approval workflows in the logging platform (if supported).
2. IAM + workflow gate: deny delete/move permissions by default; grant through time-bound elevation that requires an approver (for example, PAM with approval).
3. Change-management gate: infrastructure-as-code changes to routing/retention require code review by a second authorized reviewer, plus protected branches.

Minimum technical expectations you should push for:

• Remove standing permissions for delete and routing/retention changes from day-to-day admin roles.
• Require separate roles for “requester” and “approver,” and ensure the platform enforces separation of duties (no self-approval).
• Ensure service accounts cannot perform destructive actions without a second-party approval path; if a service account must delete as part of retention, treat that as a controlled, pre-approved automated job (see step 6).

4) Build a “two-person rule” runbook tied to tickets/changes

Write an operator runbook that answers:

• What triggers a log deletion or movement?
• Who can request it?
• Who can approve it (role/title, not a name)?
• Who executes it?
• Where approvals are recorded (ticketing system, PAM approval record, change record)?
• What post-action verification is required (confirm scope, confirm archive integrity, confirm alerts fired if applicable)?

This is where teams often fail: they have a policy but no usable steps for the on-call engineer at midnight.

5) Instrument detection for attempted or anomalous actions

AU-9(5) is about prevention, but auditors will still ask what happens if someone tries. Configure alerts for:

• Failed attempts to delete or change retention
• Direct API calls bypassing the normal workflow
• Permission changes that would allow single-person deletion
• Unexpected spikes in delete operations

Tie alerts to incident response procedures (even a lightweight “security review required” workflow).

6) Handle automated retention and lifecycle policies explicitly

Most environments delete logs automatically through retention settings. That can still meet AU-9(5) if you treat it as:

• Pre-authorized automation with dual authorization to change the retention rule and lifecycle configuration.
• A controlled change process where any adjustment to retention, lifecycle rules, bucket policies, SIEM index retention, or archive jobs requires dual authorization.

Document: “Automated deletion occurs via retention policy; dual authorization applies to creation/modification/override of that policy.”

7) Define exceptions (“break glass”) with compensating controls

You will eventually need emergency actions (cost runaway, legal request, corrupted indexes). Don’t pretend you won’t.

Minimum exception design:

• Emergency access requires approval from an alternate approver (on-call security manager) or a documented after-the-fact approval within your governance process.
• Every break-glass event triggers a required review, with documented justification and verification that the action scope matched the ticket.

8) Prove operation with recurring control health checks

Run a recurring check that:

• Validates no one has standing destructive permissions
• Samples recent log movement/deletion events and confirms dual-approval evidence exists
• Tracks findings to closure

This addresses a common risk factor: teams can’t show ownership, cadence, or evidence that the control actually operates. ¹

Required evidence and artifacts to retain

Auditors and customers will ask for both design proof and operating proof. Build an “evidence bundle” and standardize it.

Design artifacts

• Control narrative / control card: objective, scope, owners, in-scope systems, and which actions are covered (movement, deletion, or both).
• Role and permissions matrix for each in-scope log system (who can approve, who can execute).
• Runbook for log movement/deletion and retention-policy changes.
• Exception procedure for break-glass.

Operating artifacts ¹

• Ticket/change record showing:
  • Requestor identity
  • Approval 1 identity (with timestamp)
  • Approval 2 identity or executor identity (with timestamp), depending on your model
  • Justification and scope
• PAM approval logs (if used) and session recordings where available
• System audit trail showing the actual delete/move action (API event, admin console event, or platform audit log)
• Post-action verification checklist completion (for example, “archive copy intact,” “expected indexes present,” “monitoring restored”)

Storage tip: Keep evidence pointers (ticket IDs, audit event IDs, links) in a single register so you can answer an auditor in minutes, not days.

Common exam/audit questions and hangups

Expect these, and prepare answers in your control narrative:

1. “Show me that one person cannot delete logs.”
   Be ready to demonstrate permission boundaries and a live request/approval flow.

2. “Does this include cloud provider logs and SaaS audit logs?”
   Answer with your scoped inventory table and explain inclusions/exclusions.

3. “How do you handle automated retention deletes?”
   Show that changes to retention policies require dual authorization and are logged.

4. “What about admins of the SIEM itself?”
   Show separation: SIEM platform admins do not also approve destructive actions, or approvals are enforced via PAM/change control.

5. “What about third parties?”
   If a third party administers your logging stack, require the same dual-authorization workflow contractually and collect their evidence (or run the workflow in your own PAM/ticketing).

Frequent implementation mistakes (and how to avoid them)

• Mistake: Dual approval exists only in policy.
  Fix: make it technically impossible or procedurally blocked via PAM approval and restricted permissions.

• Mistake: Self-approval loopholes.
  Fix: enforce “no self-approve” in the approval tool, and audit for the same person appearing twice across ticket + PAM + platform.

• Mistake: Only deletion is covered; movement is ignored.
  Fix: treat export/migration/routing changes as “movement” and gate those changes through the same dual-authorization control. ¹

• Mistake: Retention changes are unmanaged.
  Fix: make retention settings infrastructure-as-code with mandatory peer review and protected branches.

• Mistake: Break-glass becomes the normal path.
  Fix: track break-glass frequency and require management review and corrective action when patterns emerge.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-9(5), so treat this as a framework-driven control expectation rather than a case-law-driven requirement.

Operationally, the risk AU-9(5) addresses is straightforward: if someone can move or delete audit logs alone, you can lose forensic integrity, weaken incident response, and create auditability gaps that become reportable control failures in regulated environments. For contractor environments, that risk often shows up as an ATO weakness, a contract noncompliance issue, or a customer due diligence blocker tied to log integrity expectations under NIST-based programs. ²

A practical 30/60/90-day execution plan

First 30 days: Scope and lock down the obvious

• Identify the authoritative audit repositories (SIEM, cloud log archive, identity/EDR audit sources).
• Pull current permissions and find who can delete, purge, or change retention/routing.
• Remove standing delete/move permissions where low risk; require tickets for any remaining.
• Publish a one-page runbook and an approvals matrix.

Day 31–60: Enforce dual authorization via tooling

• Implement PAM approvals for destructive actions (delete/move/retention override) in each in-scope system.
• Add protected branch controls and mandatory peer review for infrastructure-as-code that affects log routing/retention.
• Configure alerts for deletion attempts and retention/routing changes.
• Create the evidence bundle template and start collecting it for every event.

Day 61–90: Prove sustained operation

• Run a control health check and sample recent events to verify two-party approval evidence exists end-to-end.
• Fix any bypass paths (direct API keys, legacy admin accounts, shared accounts).
• Formalize third-party admin expectations and require evidence if a third party touches log repositories.
• Operationalize reporting: a simple monthly metric like “log-destructive actions with complete dual-approval evidence / total actions” (no percentages required) and a remediation tracker.

Where Daydream fits (practical, not theoretical)

If you struggle with consistency, Daydream can act as the system of record for the AU-9(5) control card, the minimum evidence bundle definition, and recurring control health checks with remediation tracking. That closes the most common gap: operators can’t quickly show ownership, cadence, and proof across disparate tools. ¹

Frequently Asked Questions

Does AU-9(5) require dual authorization for viewing or exporting logs?

The text is specific to movement and/or deletion of audit information. Treat “export” as movement if it relocates logs outside controlled storage or changes custody. ¹

Can a ticket approval plus an engineer executing the action count as dual authorization?

Yes, if the approval is from a separate authorized person and you can prove both the approval and the execution occurred, with separation of duties and no self-approval path.

How do we handle automated log deletion via retention policies?

Keep automated retention, but require dual authorization for creating, changing, disabling, or overriding the retention and lifecycle configurations. Retain change records and platform audit logs for those configuration changes.

What if the logging platform does not support dual approval natively?

Enforce it with IAM restrictions plus PAM or change-management gating: deny destructive actions by default, then require time-bound privileged elevation with a second-party approver.

Are break-glass deletions allowed under AU-9(5)?

They can be, but you need a defined exception workflow with compensating controls: restricted emergency access, documented justification, and required management/security review with evidence after the fact.

What evidence is “enough” for an auditor?

For sampled events, show the request record, two distinct approvals (or approval plus separate executor), and the system audit trail proving the move/delete occurred as approved, all tied together by IDs and timestamps.

Footnotes

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

2. NIST SP 800-53 Rev. 5