AU-9: Protection of Audit Information

AU-9 requires you to protect audit logs and the audit logging infrastructure from unauthorized access, modification, or deletion by hardening access, segregating duties, making logs tamper-resistant, and proving those protections operate continuously. Operationalize AU-9 by locking down who can administer logging, writing logs to protected storage, monitoring for log tampering, and retaining evidence of controls and reviews.

Key takeaways:

• Treat logs and logging tools as high-value assets; protect both the data and the mechanisms that generate/transport/store it.
• Build tamper resistance (write-once patterns, immutability, separation of duties) plus detective controls (alerts on gaps/tamper).
• Auditors will ask “Who can change logging or delete logs, and how do you know it didn’t happen?” Prepare evidence to answer fast.

AU-9: Protection of Audit Information is one of those controls that looks simple in policy but fails in operations. Many teams focus on “we have logs” (AU-2/AU-12 thinking) and miss the AU-9 question: “Are the logs and the logging pipeline themselves protected against the people and processes most likely to tamper with them?” That includes administrators, incident responders working under pressure, third parties with privileged access, and automated jobs with overly broad permissions.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to convert AU-9 into a small number of non-negotiable technical requirements you can test: strict access control for log systems, separation between system admins and log admins, protected/immutable log storage, and monitoring that detects deletion attempts or logging outages. Then you wrap it with artifacts: an ownership model, a runbook, evidence bundles, and recurring control health checks.

This page gives requirement-level guidance you can put in front of engineering and audit. It stays close to the NIST control intent and translates it into concrete build-and-prove steps using standard security operations patterns. ¹

Regulatory text

Requirement (AU-9): “Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and” ²

What an operator must do with this text

AU-9 is not asking you to “turn on logging.” It assumes logs exist and focuses on protecting:

1. Audit information (the logs, audit trails, and related metadata), and
2. Audit logging tools (agents, collectors, SIEM, log forwarders, storage targets, and the configurations that control what gets logged)

To meet AU-9 in an audit, you need to show three things:

• Prevent: unauthorized parties cannot access, edit, or delete logs or disable logging without going through controlled pathways.
• Detect: you can detect attempted or successful tampering and logging outages.
• Prove: you can produce artifacts that demonstrate the protections are designed and operating.

(Primary requirement source: NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5 DOI)

Plain-English interpretation (what AU-9 really means)

If someone compromises a workload, steals admin credentials, or a third party makes an error, they should not be able to clean up evidence by editing or deleting logs, or by turning logging off without leaving traces you can detect. You must protect the log pipeline with the same seriousness as production data because logs are often the only record of what happened.

Who it applies to

AU-9 applies wherever you rely on audit logs for security monitoring, incident response, investigations, compliance reporting, or customer trust.

Entity scope (common):

• Federal information systems and contractors handling federal data ²

Operational scope (practical):

• Central logging/SIEM platforms
• Cloud-native logging services and storage buckets
• Endpoint and server logging agents
• Identity provider logs, privileged access logs
• Network/security tool logs (firewalls, WAF, EDR, IDS)
• Any third party-managed environment where the third party has admin access to logging components

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

Step 1: Define ownership and the “system of record” for logs

Deliverable: a control card/runbook that states:

• Owner (Security Operations or Platform Security)
• In-scope systems (what must send logs)
• System of record (SIEM/log archive)
• Change authority (who can alter log settings)
• Exceptions process

This is where many teams fail: nobody “owns” the logging pipeline end-to-end, so protections drift. A simple one-page control card fixes that and is directly auditable.

Practical tip: put the control card in the same repository as other control runbooks and link it in your GRC system (Daydream works well here because it keeps the requirement, owner, steps, and evidence expectations together without burying it in a policy PDF).

Step 2: Lock down access to audit logs and logging tools

Implement least privilege for both:

• Read access to logs (often broader: analysts, IR, some engineers)
• Administrative access to logging tools (must be narrow: a small group, time-bound where possible)

Minimum access control requirements you should enforce:

• Centralized identity (SSO) for the SIEM/log platform admin console
• Role-based access control (RBAC) with separate roles for:
  • log viewer/search
  • content author (queries, dashboards)
  • ingestion/config admin
  • retention/storage admin
• MFA for privileged roles
• Ticket/change record required for enabling/disabling major log sources or changing retention

Common audit focus: “Show me who can delete logs or change retention.” Have a clean role map ready.

Step 3: Make logs tamper-resistant (design for write-protection)

You need at least one reliable pattern that prevents silent log alteration:

Accepted engineering patterns (choose one or combine):

• Append-only storage: logs stored in a way that prevents edits, only appends.
• Immutability controls: storage features that block deletion/modification for a defined retention period.
• Separate account/project: send logs to a security-owned account/subscription so a compromised app account cannot erase evidence.
• Dual control on destructive actions: two-person approval for retention reductions or deletion workflows.

Decision point you must document: where your “authoritative copy” of logs lives and what prevents modification/deletion there.

Step 4: Protect the pipeline (agents, forwarders, collectors, and configs)

Attackers often avoid editing the log archive and instead disable logging at the source.

Control requirements to implement:

• Configuration management for logging agents/forwarders (versioned config, restricted write access)
• Baseline hardening for collectors and SIEM components (patching, restricted admin access)
• Network restrictions so only approved sources can send logs to collectors
• Secrets protection for any tokens/keys used by log shippers

Operational requirement: log configuration changes must be traceable to an identity and a change record.

Step 5: Monitor for tampering, deletion, and logging gaps

AU-9 expects more than prevention. You need detection and response hooks.

Build alerts and reviews for:

• Attempts to delete logs or reduce retention
• Logging agent stopped/uninstalled
• Sudden drop in event volume from a critical source
• Changes to SIEM ingestion rules/parsers that could “hide” events
• Privileged activity in the logging platform itself

Hangup to avoid: “We’d notice in an incident.” Auditors want routine detection, not incident-only discovery.

Step 6: Formalize retention and legal hold alignment (without overreaching)

AU-9’s text is about protection from unauthorized deletion/modification. Retention is usually addressed in adjacent controls, but in practice, your retention settings are part of the protection story because they determine how easily logs can disappear.

Do this in a tight, auditable way:

• Document required retention by log class (security logs, admin logs, application logs)
• Restrict who can change retention
• Monitor retention policy changes

If Legal requires holds, document the handoff: who requests, who implements, where proof is stored.

Step 7: Prove it runs (control health checks and remediation)

Convert AU-9 from “set-and-forget” to a control with recurring checks:

• Quarterly access review for SIEM/log archive privileged roles
• Monthly check that critical sources are still reporting
• Review alerts for tamper attempts and track to closure

Use a simple issue log with owners and due dates; close items with evidence.

Required evidence and artifacts to retain

Keep an “AU-9 evidence bundle” that a new auditor can understand quickly:

Control design artifacts (static, update on change)

• AU-9 control card/runbook (objective, scope, owner, triggers, steps, exceptions)
• Logging architecture diagram (sources → transport → SIEM/archive)
• Role matrix for logging platform (who has viewer vs admin vs storage admin)
• Change management procedure for logging configuration and retention

Operating evidence (time-bound, sampled)

• Export of privileged role membership and access review sign-off
• Samples of change tickets/approvals for logging configuration changes
• Screenshots/exports showing immutability/append-only configuration (where applicable)
• Alert records for tamper/gap detections and incident/ticket closures
• Health check outputs (source coverage checks, ingestion volume checks)

Evidence hygiene rule: store evidence in a controlled repository with clear naming and retention. If evidence is scattered across Slack, email, and consoles, you will lose time and credibility in an exam.

Common exam/audit questions and hangups (with what to show)

What auditors ask	What they mean	What you show
“Who can delete audit logs?”	Prove least privilege and separation of duties	RBAC role list, storage permissions, access review record
“Can an admin of system X alter its logs?”	Can attackers cover tracks at the source	Architecture showing off-host log shipping + restricted config
“How do you detect log tampering?”	Detective controls exist and are used	Alert rules + sample alerts + ticket closures
“How do you prevent disabling logging?”	Controls on config changes	Config management approach + change tickets
“Where are logs stored and protected?”	Identify the authoritative copy	SIEM/archive location + immutability/access controls evidence

Frequent implementation mistakes (and how to avoid them)

1. Same admins run prod and logging.
   Fix: put the log archive in a security-owned account/project and restrict admin roles.

2. Logs are protected, but logging configs are not.
   Fix: treat agent configs, ingestion rules, and retention policies as controlled configuration items with change control.

3. No monitoring for “silent failure.”
   Fix: implement gap detection (source heartbeat checks, volume anomaly alerts) and track it like any other security alert.

4. Overbroad read access exposes sensitive logs.
   Fix: separate “can search everything” from “can search subset” and apply need-to-know for high-sensitivity log sources.

5. Evidence is an afterthought.
   Fix: define a minimum evidence bundle per cycle and store it consistently. Daydream-style control cards and evidence checklists reduce variance across teams.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source set, so this page does not cite specific actions. Practically, AU-9 failures increase breach impact and investigation cost: if logs can be altered or erased, you lose the ability to reconstruct events, prove containment, or support legal/regulatory response. In customer diligence, weak log protections often show up as “insufficient detective controls” or “inadequate separation of duties,” which can block deals in regulated sectors.

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish the AU-9 control card: owner, in-scope systems, logging system of record, and exception process.
• Inventory log sources and identify “crown jewel” sources (IdP, cloud control plane, EDR, SIEM admin audit logs).
• Pull current privileged access lists for logging tools and storage; remove obvious overprivilege.
• Define your minimum AU-9 evidence bundle and where it will live.

Days 31–60 (harden and add tamper resistance)

• Implement RBAC cleanup and SSO/MFA enforcement for logging platforms.
• Move authoritative logs to protected storage patterns (security-owned account/project; immutability/append-only where supported).
• Add change control requirements for logging configs and retention changes.
• Implement gap detection for critical sources (alert when a source stops logging).

Days 61–90 (operationalize and prove)

• Run the first formal access review and store approvals as evidence.
• Run a control health check: sample log sources, validate retention, validate permissions, test a “tamper attempt” alert path.
• Create a remediation backlog for any missing sources or weak permissions and track items to validated closure.
• Add AU-9 testing steps to internal audit, SOC procedures, or your continuous control monitoring program.

Frequently Asked Questions

Do I need immutable storage to satisfy AU-9?

AU-9 requires protection against unauthorized modification and deletion; immutability is a strong way to meet that intent. If you don’t use immutability, document the alternative controls (access restrictions, separation of duties, monitoring) and be ready to prove they prevent and detect tampering.

Are read-only users a problem for AU-9?

Read access is not inherently a violation, but uncontrolled access can expose sensitive audit data. Define roles, restrict broad searches, and prove that only authorized users can access sensitive logs.

How do we handle third parties that administer parts of our environment?

Treat the third party’s admin access as in-scope for AU-9. Require contractual and technical controls: named accounts, least privilege, MFA, logged admin actions, and assurance that logs are exported to a customer-controlled system of record.

What evidence is fastest to produce during an audit?

Start with a role/permission export for the SIEM and log storage, the latest access review sign-off, and screenshots/exports showing retention and deletion protections. Add one or two closed tickets that show your alert-to-remediation workflow for logging gaps or tamper attempts.

If engineering can’t ship logs off-host for a legacy system, what’s the minimum acceptable approach?

Document the exception, restrict local log access, and add compensating controls such as frequent log forwarding batches, host integrity monitoring, and strict admin access logging. Time-box the exception with a migration plan and track it like a risk acceptance.

How does Daydream fit AU-9 without turning this into a tool project?

Use Daydream to keep the AU-9 control card, evidence checklist, review cadence, and remediation items in one place so you can prove ownership and ongoing operation without rebuilding a spreadsheet workflow every audit cycle.

Footnotes

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

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