AU-9: Protection of Audit Information

What this control requires

AU-09 requires organizations to protect audit information and logging tools from unauthorized access, modification, and deletion. That scope is broader than most teams initially assume, because “audit information” covers not just log files sitting on a SIEM but also audit records, log configuration settings, audit reports, and any personally identifiable information (PII) captured during the logging process.

In practice, the protection requirement extends to active detection. Organizations must alert designated personnel when unauthorized access, modification, or deletion of audit data is detected. If an attacker, a careless admin, or an automated process can alter or erase any of those artifacts without triggering an alert, the integrity of your entire audit trail is compromised.

The result is a control with near-universal reach. AU-09 appears in all three NIST SP 800-53 baselines (LOW, MODERATE, and HIGH), so every federal information system and any organization benchmarking against the framework must address it. The control pairs a preventive requirement (protect) with a detective one (alert), so access controls alone don’t satisfy it and you also need monitoring that tells you when those protections fail.

Why it matters

Audit logs are the forensic backbone of every security investigation, compliance assessment, and incident response effort. When those logs can’t be trusted, every downstream activity built on them becomes unreliable.

As a result, auditors treat log integrity as a prerequisite, not a control in isolation. If your organization can’t demonstrate that audit records are tamper-resistant, assessors will question the validity of evidence tied to other controls across the AU family and beyond.

Beyond the evidence chain, regulatory and contractual obligations raise the stakes further. FedRAMP authorizations, SOC 2 examinations, and Cybersecurity Maturity Model Certification (CMMC) assessments all expect organizations to show that audit data is protected from tampering, not just collected. Failing to address AU-09 undermines confidence in your broader compliance posture, not just one control.

From an operational standpoint, unprotected logs leave you blind at the worst possible moment. If an adversary gains access and covers their tracks by modifying or deleting log entries, your security team loses the ability to reconstruct what happened, when it happened, and what was affected.

What attackers exploit

• Direct log deletion to erase evidence of lateral movement or data exfiltration
• Log configuration tampering that silently disables logging on specific systems or reduces verbosity
• Privilege escalation to log management accounts that lack multi-factor authentication
• Modification of audit reports after generation to remove indicators of compromise before review
• Exploitation of shared storage where audit records are co-located with application data under the same access permissions

How to implement

For your organization

The most common failure mode is overly broad administrative privileges that bundle log management access as a side effect, not missing access controls on the log files themselves.

Start by isolating audit log storage from general-purpose administrative access. Dedicated log management infrastructure, whether a standalone SIEM instance, a hardened syslog server, or an immutable cloud storage bucket, should be accessible only to personnel with an explicit need.

Separation of duties matters here. The people generating audit events shouldn’t be the same people who can modify or delete audit records.

Implement write-once or append-only storage for critical logs wherever your infrastructure supports it. Cloud object storage with retention locks, WORM (write once, read many) configurations on network-attached storage, and blockchain-anchored log hashing all serve this purpose. The goal is to make retroactive modification technically infeasible, not just policy-prohibited.

Configure real-time alerting for any unauthorized access attempts against audit repositories. Alerting coverage should include failed authentication to log management consoles, unexpected privilege changes on log storage directories, and bulk deletion requests. Your alerting mechanism should reach the personnel or roles defined in your system security plan, and it should trigger independently of the systems being monitored so that a compromised host can’t suppress its own alerts.

Encrypt audit data in transit and at rest. TLS for log transport and AES-256 (or equivalent) for stored records protect against interception and unauthorized reads. Pair encryption with integrity verification using cryptographic hashing so you can detect log modifications even if access controls are bypassed.

Finally, review access control lists on audit infrastructure quarterly. People change roles, projects end, and service accounts accumulate permissions. A quarterly review catches drift before it becomes an audit finding.

For your vendors

Your vendors’ audit log protections directly affect your own risk exposure, especially when those vendors process, store, or transmit your data.

During procurement and ongoing assessments, request evidence that the vendor separates audit log management from general system administration. Ask specifically about who can delete logs, whether write-once storage is used, and what alerting is in place for tampering attempts. Vendors who can’t articulate their log protection strategy likely haven’t formalized one.

In practice, your security questionnaires should include targeted questions for AU-09 alignment. Ask whether the vendor enforces role-based access controls on log repositories, whether they use append-only or immutable storage for audit records, and how quickly they alert on unauthorized log access. Request the names and roles of personnel authorized to manage audit infrastructure, and ask whether those roles are subject to separation of duties constraints.

Require contractual commitments to log retention and integrity. Your vendor agreements should specify minimum retention periods aligned with your own AU-11 requirements and should prohibit the vendor from modifying or deleting logs related to your data without documented authorization. These commitments give you recourse if a vendor’s log handling undermines your compliance posture.

Validate vendor controls through independent evidence, not just attestations. SOC 2 Type II reports, ISO 27001 certificates, and FedRAMP authorization packages all address log protection to varying degrees. Review the relevant sections rather than accepting the report’s existence as sufficient evidence.

Red flags include vendors who cannot provide screenshots of access controls on log systems, who lack documented alerting procedures, or who store audit records on the same infrastructure as application data without logical separation.

Incorporate log integrity checks into your continuous monitoring program. Periodic reassessment of vendor audit controls ensures that protections don’t degrade after initial onboarding, particularly after vendor infrastructure changes, mergers, or platform migrations.

Evidence examples

Cross-framework mapping

Coverage is partial across all three mappings because AU-09’s combined preventive and detective requirements (protect plus alert) go beyond what any single mapped control fully addresses. ISO 27001:2022’s 5.33 focuses on record retention and protection but doesn’t mandate real-time alerting for tampering.

Its 8.15 addresses logging practices broadly but doesn’t prescribe specific access controls on the logs themselves. NIST SP 800-171’s 03.03.08 aligns closely on protection but scopes to controlled unclassified information (CUI) environments rather than the full federal information system scope of 800-53.

Related controls

• AC-03 — Access Enforcement: Provides the access control mechanisms that AU-09 relies on to restrict who can read, modify, or delete audit records.
• AC-06 — Least Privilege: Ensures that only personnel with a documented need can access audit logging tools and repositories.
• AU-06 — Audit Record Review, Analysis, and Reporting: Depends on AU-09’s integrity protections to ensure that the records being reviewed haven’t been tampered with.
• AU-11 — Audit Record Retention: Defines how long audit records must be kept, which AU-09 protects from premature deletion throughout that retention period.
• AU-14 — Session Audit: Generates detailed session-level audit data that AU-09 must protect alongside standard audit records.
• AU-15 — Alternate Audit Logging Capability: Provides backup logging paths that remain protected even if primary audit infrastructure is compromised.
• MP-02 — Media Access: Controls physical and logical access to media where audit records may be stored.
• MP-04 — Media Storage: Governs secure storage conditions for media containing audit information.
• PE-02 — Physical Access Authorizations: Manages who is authorized to physically access areas housing audit logging infrastructure.
• PE-03 — Physical Access Control: Enforces physical access restrictions on facilities containing audit data storage.

Frequently asked questions

What is NIST SP 800-53 AU-09?

AU-09 is the NIST SP 800-53 control that pairs a preventive mandate (lock down audit records, log settings, and logging tools) with a detective one (alert designated personnel when someone tries to tamper with them). Because it appears in all three baselines, any system assessed against the framework must address both halves, making AU-09 one of the foundational controls in the Audit and Accountability family.

What happens if AU-09 is not implemented?

Without AU-09 protections, audit logs become vulnerable to tampering, which undermines the trustworthiness of your entire audit trail. Assessors may issue findings that cascade beyond AU-09 because unprotected logs call into question the evidence supporting other controls. In regulated environments, this gap can delay or block authorization decisions such as FedRAMP authorizations to operate.

How do you audit AU-09?

Auditors verify AU-09 by examining access control lists on log repositories, testing whether write-once or immutable storage is enforced, and confirming that alerting mechanisms trigger on unauthorized access attempts. They also review the system security plan to validate that designated personnel are defined and that alert routing is documented and tested.

How do you protect audit logs from tampering?

The most effective approach combines write-once storage (WORM or cloud object locks) with strict separation of duties so that no single role can both generate and delete audit records. Layer cryptographic hashing on top to detect unauthorized modifications, and route integrity alerts through a channel that operates independently of the monitored systems. Periodic access reviews close the loop by catching privilege drift before it becomes exploitable.