Introduction
Audit logs are a primary target during and after security incidents. Attackers, ransomware operators, and malicious insiders routinely attempt to delete or alter logs to cover their tracks. This is not a hypothetical risk — it's a documented attack pattern across real-world breaches.
CISA joint advisories confirm that Play, Hive, and Ghost ransomware actors all actively delete logs to hide intrusion activity. Nation-state actors go further — disabling administrative accounts and clearing Windows Event Logs from critical servers before exfiltrating data.
NIST SP 800-53 AU-9 addresses this threat directly. Where AU-2 and AU-12 govern what gets logged, AU-9 governs how logs are protected once they exist. This guide breaks down exactly what AU-9 requires, how its six enhancements work, and how to implement it across federal, healthcare, financial, and AI system environments.
TL;DR
- AU-9 requires protecting audit logs and tools from unauthorized access, modification, and deletion by any user, including privileged administrators
- Six optional enhancements add hardware write-once storage, cryptographic protection, and dual authorization
- Separate log storage from audited systems so a compromised host cannot alter or destroy its own records
- Federal, healthcare, and financial organizations treat AU-9 as non-negotiable, with enhancements increasingly required for high-impact and AI systems
What Is NIST SP 800-53 AU-9?
NIST SP 800-53 Revision 5 defines AU-9 (Protection of Audit Information) clearly: organizations must protect audit information and audit tools from unauthorized access, modification, and deletion. AU-9 is distinct from its neighboring controls. AU-2 and AU-12 govern what events to log and how to generate records. AU-9 governs what happens to those records afterward.
A log that can be modified or deleted by the same accounts or systems it monitors provides no reliable accountability. An attacker with admin credentials—or a malicious insider—can erase evidence of their actions. AU-9 closes this gap by requiring that log protection be treated as a security objective in its own right.
AU-9 sits within the broader Audit and Accountability (AU) control family. It works in coordination with:
- AU-11 (Audit Record Retention) — governs how long logs must be kept
- AU-10 (Non-Repudiation) — ensures individuals cannot deny actions they took
- AU-3 (Content of Audit Records) — defines what information each record must contain
AU-9 is the link that makes the rest of this chain enforceable — without it, even well-designed logging can be silently undermined.
What Does AU-9 Require?
AU-9 operates through a defined set of protection requirements that apply from the moment a log record is written through the end of its retention period. Each requirement addresses a different failure mode in audit log security.
Who Is Protected and When Coverage Applies
AU-9 coverage begins at the point of log creation and applies to both the audit records themselves and the tools used to manage, analyze, and access them. "Audit tools" include log management software, SIEM agents, and any system used to read or modify audit data—not just raw log files.
One common point of confusion: AU-9 does not specify what events to log—AU-2 and AU-12 govern that. AU-9's scope is entirely about protecting whatever audit records already exist. That means AU-9 must be implemented at the storage and access layer, independently of how logging is configured.
Core Protection Requirements
AU-9's base control requires two primary mechanisms:
- Restricting read and write access to audit logs so only authorized roles can view them
- Restricting access to audit tools so logging configuration itself cannot be altered by unauthorized parties
"Unauthorized" explicitly includes privileged system accounts. An administrator with root access to an application server should not automatically have write access to that server's audit logs.
The operational principle is privilege separation: log storage must be managed independently from the systems being audited. If the same account that operates the audited system also owns the log destination, a single credential compromise defeats both system security and its audit trail.
Access Control and Monitoring Requirements
AU-9 requires organizations to document who has access to audit information and audit tools, and to monitor that access. Any access to audit records should itself be logged—sometimes called "auditing the auditor." This creates a second-order audit requirement that organizations frequently overlook:
- Access to log storage must itself be logged, not just access to the systems being audited
- Chain of custody depends on this second layer — without it, you cannot prove logs remained untouched between creation and review
Output: Trusted, Legally Defensible Evidence
AU-9 produces log records that hold up as an accurate, unaltered account of system events—through incidents, insider compromises, and regulatory investigations alike. Forensic work and compliance audits both depend on that integrity. If logs could have been modified, their evidentiary value collapses.
The practical result: when an auditor or regulator asks what happened, when, and by whom, AU-9-compliant logs provide a defensible answer rather than a qualified one.
AU-9 Control Enhancements Explained
AU-9 includes six numbered enhancements (AU-9(1) through AU-9(6)) that organizations can implement beyond the base control. These are not always optional—high-impact systems, federal contractors, and many regulated industries specify which enhancements are required. Organizations select enhancements based on their system impact level (Low/Moderate/High per FIPS 199) and regulatory requirements.
Table: AU-9 Baseline Requirements by Impact Level
| Control/Enhancement | Low | Moderate | High |
|---|---|---|---|
| AU-9 (Base Control) | Required | Required | Required |
| AU-9(2) Separate Physical Systems | Not Required | Not Required | Required |
| AU-9(3) Cryptographic Protection | Not Required | Not Required | Required |
| AU-9(4) Access by Subset of Privileged Users | Not Required | Required | Required |
Source: NIST SP 800-53B
AU-9(1) – Hardware Write-Once Media
This enhancement requires storing audit logs on hardware-enforced write-once, read-many (WORM) media. Once written, the storage medium physically prevents modification or overwrite.
Two common implementation paths exist:
- Hardware WORM: Optical disks or purpose-built tape media with physical write-lock mechanisms — no software override possible
- Cloud-based WORM: Services such as S3 Object Lock or Azure Immutable Blob Storage apply software-enforced retention policies; NIST SP 800-209 recognizes these as valid protection mechanisms
Organizations using cloud-based WORM should verify it meets their authorization body's interpretation of AU-9(1) and document it as a compensating control.
AU-9(2) – Store on Separate Physical Systems
This enhancement requires that audit records be backed up to a physically or logically separate system from the one being audited.
Without this separation, a ransomware attack or full system compromise gives the attacker the ability to destroy audit evidence alongside the production data. The standard implementation is log forwarding to a dedicated SIEM or centralized log server configured so the audited system has no write-back access.
AU-9(3) – Cryptographic Protection
Requires using cryptographic mechanisms (digital signatures or HMAC-based chaining) to detect unauthorized changes to audit records.
Each log entry or batch is signed or hashed with a key the audited system cannot access. Any subsequent modification changes the hash, making tampering detectable even when altered records remain in place.
Federal agencies must use FIPS-approved algorithms:
- FIPS 180-4 specifies SHA-224, SHA-256, SHA-384, and SHA-512
- NIST SP 800-131A confirms SHA-2 and SHA-3 as acceptable
Combined with AU-9(1), cryptographic protection adds a detection layer on top of write-prevention — a defense-in-depth approach recommended for high-impact systems.
AU-9(4) and AU-9(5) – Access Restrictions and Dual Authorization
AU-9(4) requires that only a designated subset of privileged users can access audit logs, not all administrators.
AU-9(5) adds dual authorization—changes to audit logging configuration or access to raw log data requires approval from two independent individuals.
These enhancements directly address the insider threat model and are commonly required for high-impact federal systems.
AU-9(6) – Read-Only Access
Requires that audit information be accessible to certain roles (such as security analysts or auditors) only in a read-only capacity, with no ability to delete or modify records.
This is distinct from AU-9(4)'s access restriction—AU-9(6) allows broader visibility while still enforcing immutability at the access layer.
Implementing AU-9 Compliant Immutable Audit Logs
Storage Architecture — WORM, Object Lock, and Append-Only Models
Three primary storage architectures satisfy AU-9 immutability requirements:
- Hardware WORM — tape or optical media for long-term archival
- Cloud object storage with object lock/retention policies — for operational logs (AWS S3 Object Lock, Azure Immutable Blob Storage, Google Cloud retention policies)
- Append-only database or log structures — prevent record modification at the data layer
Choose based on retention period, access latency needs, and cloud vs. on-premises environment. Cloud object lock offers the best balance of accessibility and immutability for operational logs with 12-18 month retention periods.
Cryptographic Integrity Verification
Implementation pattern for AU-9(3): log entries are hashed at write time using an approved algorithm (FIPS-approved SHA-256 or stronger for federal systems). Hashes are stored separately from logs in a location the logging system cannot modify.
For higher assurance, log records can be chained—each entry's hash incorporates the hash of the previous entry, so altering any record breaks the entire chain. This pattern is similar to blockchain-style integrity but does not require a distributed ledger.
NIST SP 800-92 emphasizes that organizations should use time synchronization technologies such as NTP servers to keep log sources' clocks consistent with each other for reliable event correlation.
Infrastructure Separation — The Single Most Critical Requirement
Of all AU-9 implementation requirements, infrastructure separation consistently delivers the highest risk reduction. Log destinations must operate in a separate security boundary from audited systems:
- Separate network zone
- Separate credentials
- Separate administrative accounts
The audited application should be able to write new log entries (append) but never read, modify, or delete existing ones.
Common misconfiguration to avoid: log management accounts sharing credential stores with application accounts.
Access Controls and Role Separation
The practical access model:
- Log writers (application/system accounts) — append-only access
- Log readers (security analysts, auditors) — read-only access
- Log administrators (who manage retention, rotation, archival) — operate under dual authorization and cannot modify log content
These roles should never overlap on a single account. Access to audit logs must itself be logged and reviewed.
AU-9 for AI Systems and Modern Workloads
These general AU-9 controls hold for traditional systems, but AI workloads introduce a distinct set of challenges. AI models, agents, and automated pipelines generate high-velocity, heterogeneous log data across inference calls, tool invocations, prompt/response pairs, and policy decisions.
Protecting this data under AU-9 requires that the AI governance layer itself maintain immutable, append-only records that neither the AI application nor its operators can retroactively modify.
Platforms like Trussed AI address this by generating governance evidence as a built-in byproduct of the AI control plane, rather than requiring separate log protection to be retrofitted onto AI infrastructure. Each governed interaction is logged with:
- Policy evaluation results and enforcement decisions
- Model version and timestamp at inference time
- Data lineage from prompt through output to downstream action
Where AU-9 Applies
Federal and FedRAMP Environments
AU-9 is a mandatory baseline control for all federal information systems under FISMA. All three impact levels (Low, Moderate, High) require the base AU-9 control—with enhancements required at Moderate and High.
OMB Memorandum M-21-31 establishes strict requirements: "To ensure data integrity, logging facilities and log information must be protected by cryptographic methods from tampering and unauthorized access." Agencies must also ensure "that current log files are promptly backed up to an authorized source, such as a centralized log server or write-once media."
Retention minimums: 12 months active storage and 18 months cold storage for most log categories.
FedRAMP cloud service providers must implement AU-9 and selected enhancements based on their baseline.
Healthcare, Financial, and Other Regulated Industries
AU-9's immutability requirements directly satisfy audit controls in:
- HIPAA 45 CFR 164.312(b) — "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information"
- HIPAA 45 CFR 164.312(c)(1) — "Protect electronic protected health information from improper alteration or destruction"
- SOX IT control requirements for financial system logs — PCAOB AS 1105 requires testing accuracy and completeness of information produced by the company
- PCI DSS v4.0.1 — Requirement 10.3.2 requires audit log files be protected from modifications, and 10.3.3 requires prompt backup to secure, central, internal log servers or media that is difficult to modify
Regulators are beginning to extend AU-9 principles to AI system logs. Healthcare and financial organizations deploying AI should plan for this now, not after their next audit.
Cloud, Containerized, and AI-Native Environments
AU-9 applies regardless of deployment model — cloud-native, containerized, or on-premises. Two considerations come up most often in practice:
- Cloud environments: The shared responsibility model means organizations must verify their own cloud log storage satisfies AU-9 requirements. The cloud provider's native logs don't count.
- Ephemeral environments: Containers and serverless functions require log forwarding to a persistent, protected destination before the compute resource terminates.
Conclusion
The central operational principle AU-9 encodes: the protection of audit information is a security objective independent of, and as important as, the security of the systems being audited. A log that can be deleted is not a log—it is a liability that creates false confidence in accountability.
Organizations that implement AU-9 with appropriate enhancements are building the evidentiary foundation that makes incident response, forensic investigations, and regulatory audits possible. Those enhancements include:
- Infrastructure separation — audit storage isolated from the systems it monitors
- Cryptographic integrity — tamper detection that survives even privileged access attempts
- Strict access controls — read-only paths for auditors, no delete permissions for operators
Each layer addresses a distinct failure mode. Together, they move audit logs from administrative artifacts to defensible evidence.
That evidentiary standard doesn't change when the system generating logs is an AI. For teams deploying AI in regulated industries, AU-9 applies equally to AI-generated audit trails — and most platforms aren't built to satisfy it. Platforms where governance is a core design principle, not a post-deployment retrofit, are the ones that hold up under scrutiny. When governance evidence is captured as a byproduct of every AI interaction rather than reconstructed after the fact, organizations gain continuous assurance that meets both the letter and spirit of AU-9.
Frequently Asked Questions
What is the difference between AU-9 and AU-12 in NIST SP 800-53?
AU-12 governs audit record generation—what events are logged and how records are created. AU-9 governs protection of those records after they exist, covering access restrictions, immutability, and protection from tampering or deletion.
What does AU-9(1) require and how is it implemented in cloud environments?
AU-9(1) requires hardware write-once storage for audit records. Modern cloud object storage services with object lock or immutable retention policies can satisfy this requirement. Organizations should confirm that their specific authorization body accepts this approach and document the rationale in their system security plan.
How long must audit logs be retained under NIST SP 800-53?
Retention falls under AU-11, not AU-9. Federal guidance commonly cites 12 months active storage plus 18 months cold storage for Moderate and High impact systems, though exact requirements vary by regulation and agency.
Does AU-9 protect against insider threats from system administrators?
Yes, AU-9 protects audit logs even from privileged users. The control requires that admin access to audited systems does not automatically confer access to those systems' audit logs. Enhancements AU-9(4) and AU-9(5) further restrict and require dual authorization for any access to audit information.
What are the most common AU-9 implementation failures organizations make?
The most common failures: co-locating logs on the same system being audited, granting application admin accounts write access to log storage, and failing to log access to the audit logs themselves. Each of these failures leaves audit evidence exposed to the exact threats AU-9 exists to prevent.
Does AU-9 apply to AI systems and AI-generated logs?
AU-9 applies to any system within an organization's authorization boundary — including AI inference platforms, agentic workflows, and governance tools. Audit evidence covering model decisions, prompt/response pairs, and policy enforcement actions carries the same AU-9 protection requirements as logs from traditional IT systems.
