NIST SP 800-53 AU Audit and Accountability: Key Controls, Enhancements and How to Evidence Them

Most audit and accountability findings are not about missing logs, they are about logs nobody chose deliberately, nobody reviews and nobody can prove are complete. This guide works through the Audit and Accountability (AU) family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for under SP 800-53A. It is written for control owners, system security plan authors, SOC and logging engineers and assessors. For the catalogue as a whole, see the NIST SP 800-53 Guide; for log pipeline design and retention tiers, see the Log Management and Retention Guide. This page stays at the level of the controls and their evidence.

Key takeaways

• AU-2 is a decision record, not a switch. It asks you to list what the system can log, choose a subset, coordinate with others who need the data and write down why that subset is enough for after-the-fact investigation. The rationale in AU-2d is the line most often missing.
• Ten controls apply at Low. AU-1 to AU-6, AU-8, AU-9, AU-11 and AU-12 are in all three baselines. Moderate adds AU-7 and five enhancements; High adds AU-10 non-repudiation and storage on separate systems.
• Logging failure is its own control. AU-5 requires an alert within a time you define when logging stops, and at High AU-5(1) and AU-5(2) add capacity warnings and real-time alerts. A silent log source is a finding.
• Protect logs from the people they record. AU-9 requires protection from unauthorised access, modification and deletion, and AU-9(4) limits management of logging to a subset of privileged users. Administrators who can delete their own audit trail fail it.
• Service identities belong in AU-3. AU-3f covers the identity of individuals, subjects and objects or entities, so workload, service account and API client identities must be recorded, not only human user names.

The AU family at a glance

The table lists every current AU base control with its baseline allocation, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High). AU-15 is withdrawn and omitted.

Release 5.2.0 (27 August 2025) added SA-15(13) Logging Syntax in the SA family, which lists AU-2 and AU-3 as related controls and asks developers to log defined event types in a defined secure logging format. If you buy or build software for an AU-heavy system, tailor SA-15(13) in alongside AU-3. For baseline selection, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

AU-2, AU-3 and AU-12: choosing and generating events

These three controls work as a chain. AU-2 decides what to log, AU-3 decides what each record contains, and AU-12 makes the components actually produce it.

• AU-2 Event Logging: (a) identify the event types the system can log; (b) coordinate with other organisational entities that need audit information; (c) specify the subset to log and the frequency or situation for each; (d) give a rationale that the subset is adequate for after-the-fact investigation; (e) review the selection at a frequency you define. A practical AU-2c list covers authentication success and failure, privilege use and elevation, account and group changes, policy and configuration changes, security tool state changes, access to sensitive data, token and key issuance, and changes to logging itself.
• AU-3 Content of Audit Records: each record must establish what type of event occurred, when, where, the source, the outcome, and the identity of any individuals, subjects or objects and entities involved. AU-3(1) at Moderate and High adds additional information you define, such as session ID, source IP, user agent, the client or application ID of a service caller, and the request ID that ties a record to an upstream trace.
• AU-12 Audit Record Generation: provide generation capability on the components you list, allow named roles to choose which events each component logs, and generate records for the AU-2c events with AU-3 content. AU-12(1) at High compiles records into a system-wide trail time-correlated to a tolerance you set, and AU-12(3) lets named roles change logging within a time threshold, which matters during an incident.

For non-human identities, the weak point is AU-3f. Cloud and SaaS audit logs often show the role or service principal, not the workload or person behind it. Record the mapping from service identity to owner and workload so an investigator can resolve "who" from the log. See the Cloud Logging and Audit Trail Guide and the Secure Logging Vocabulary and Application Security Events Guide.

AU-4, AU-5 and AU-11: capacity, failure and retention

The settings column is our recommendation, not NIST text, except the M-21-31 figures, which come from the memo's Appendix C. M-21-31 also defines event logging maturity tiers EL0 (not effective) to EL3 (advanced) that federal agencies use to scope this work. Retention without capacity planning is the usual cause of silent gaps: when storage fills, collectors drop or overwrite records and AU-5 never fires because nobody defined "failure" to include dropped events.

AU-6 and AU-7: review, correlation and reporting

AU-6 requires review and analysis of audit records at a frequency you define for indications of inappropriate or unusual activity you define, reporting findings to named roles, and adjusting review when risk changes based on law enforcement, intelligence or other credible information.

• AU-6(1) Automated Process Integration (M, H): integrate review, analysis and reporting using automated mechanisms. A SIEM or data lake with scheduled detection rules is the usual implementation. See the SIEM Guide.
• AU-6(3) Correlate Audit Record Repositories (M, H): analyse and correlate records across repositories for organisation-wide awareness. Identity provider, cloud control plane, endpoint and network logs must be joinable on identity and time.
• AU-6(5) and AU-6(6) (H): integrate audit analysis with vulnerability scanning, performance or system monitoring information, and correlate it with physical access monitoring.
• AU-7 and AU-7(1) (M, H): provide on-demand reduction and reporting that does not alter original content or time order, and allow search and sort on fields you list. Name the fields: user, service identity, source address, event type, outcome, resource.

The AU-6a parameters are where vague plans fail. "Logs are reviewed regularly" is not a frequency. Write the detection use cases, how often each runs, and who triages. The joint ASD's ACSC, CISA, FBI, NSA and partner publication Best practices for event logging and threat detection (22 August 2024) sets four key factors that line up with AU-1, AU-6, AU-9 and SI-4: an enterprise-approved logging policy, centralised log collection and correlation, secure storage and event log integrity, and a detection strategy for relevant threats. See the Detection Engineering Guide.

AU-8, AU-9 and AU-10: time, integrity and non-repudiation

• AU-8 Time Stamps: use internal system clocks and record time stamps at a granularity you define, in UTC, with a fixed offset from UTC, or including the local offset. Time synchronisation itself sits in SC-45, which is outside the baselines but worth tailoring in. See the NTP Security Guide.
• AU-9 Protection of Audit Information: protect audit information and logging tools from unauthorised access, modification and deletion, and alert named roles on detection of such access. AU-9(4) at Moderate and High restricts management of logging functions to a defined subset of privileged users. At High, AU-9(2) stores records at a frequency you set on a physically different system or component, and AU-9(3) uses cryptographic mechanisms to protect the integrity of audit information and tools.
• AU-10 Non-repudiation (H): provide irrefutable evidence that an individual, or a process acting for one, performed actions you define. Digital signatures on approvals, signed commits and signed release artefacts are typical implementations.

In practice AU-9 means separating the people who administer a system from the people who administer its logs. Forward records off the host as they are written, write them to storage with object lock or immutability, and send an alert when a logging policy, sink or retention setting changes.

Tailoring candidates: AU-13, AU-14 and AU-16

• AU-13 Monitoring for Information Disclosure: monitor open-source information and sites you define for evidence of unauthorised disclosure, then notify and act. Leaked credential and secrets monitoring fits here, which makes it relevant to API keys and tokens posted to public repositories or paste sites.
• AU-14 Session Audit: capability to record, view, hear or log user session content in circumstances you define, developed with legal counsel. Privileged session recording in a PAM platform is the common implementation.
• AU-16 Cross-organizational Audit Logging: methods for coordinating audit information with external organisations when it crosses organisational boundaries. Relevant where a managed service or cloud provider holds logs you need, and AU-16(1) preserves identity across that boundary.

How to evidence AU controls

The SP 800-53A methods for AU are examine (policy, procedures, the list of auditable events, audit records, configuration, storage settings), interview (administrators, those responsible for review) and test (the mechanisms that generate, protect and review records). The table turns that into evidence an assessor can accept in one pass.

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the AU family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system with partial logging.

1. Write the parameters. Fill AU-2c, AU-2e, AU-5a, AU-6a, AU-8b and AU-11 in the system security plan. Every later step tests against them.
2. Inventory sources. List every component and log source, including identity providers, cloud control planes, SaaS admin logs, secrets managers and CI/CD systems. Mark which produce AU-3 identity fields for service callers.
3. Centralise and normalise. Forward to a central store in a common schema, with UTC time stamps. Onboard sources in waves; the SIEM Log Source Onboarding Checklist helps.
4. Add silence detection before detection content. An AU-5 alert for each source going quiet protects everything built later.
5. Lock down the store. Separate log administration from system administration (AU-9(4)) and turn on immutability for the retention period. Test by attempting deletion with a system administrator account.
6. Write review use cases. Start with privilege changes, logging changes, failed and anomalous authentication and token issuance, then expand.
7. Collect evidence continuously. Schedule exports of source health, alert tests and retention settings. See the Audit Evidence and Continuous Controls Monitoring Guide.

Roll out changes to audit policy in a test ring first: verbose logging can exhaust storage or affect performance. Roll back by reverting the audit policy, never by stopping the forwarder.

Decision guidance

• Low versus Moderate: Low already requires event selection, content, failure alerting, review, time stamps, protection and retention. Moderate adds automated review, cross-repository correlation, report generation and restricted logging administration, which in practice means a central platform.
• Inherit or implement: a cloud provider can supply AU-12 generation and AU-9 storage protection for its control plane, but AU-2 selection, AU-6 review and AU-11 retention settings remain yours. Record the split in the plan.
• Small organisations: one managed logging service with immutable storage and a short list of high-value use cases meets the Low and most of the Moderate intent. Depth of AU-2 matters more than the number of sources.

Detection and measurement

• Share of in-scope components forwarding to the central store, against the source inventory.
• Mean time from a source going silent to an AU-5 alert, measured with scheduled tests.
• Share of service and workload actions whose records resolve to an owned identity.
• Number of people able to change logging configuration or delete records, against the AU-9(4) list.
• Oldest record successfully retrieved in the last restore test, against the AU-11 period.

Framework mapping

Mappings are "intersects with", not equivalence, and are our reading of the texts. Check them against NIST's published informative references before using them in an audit. For method, see the Control Mapping Guide and the CIS Control 8 Audit Log Management Guide.

Common failure patterns

• Logging everything, selecting nothing: default verbose collection with no AU-2 rationale, so storage fills and the events that matter are not identified.
• No silence detection: a forwarder breaks after an upgrade and nobody notices until an investigation needs the missing weeks.
• Shared identities in records: automation runs as one service account for many workloads, so AU-3f cannot answer who acted.
• Administrators own their audit trail: the same group administers the system and its log sink, so AU-9 and AU-9(4) fail.
• Retention on paper only: the plan states a period, but cold storage has never been restored.
• Clock drift: components disagree by minutes, so correlation under AU-6(3) and AU-12(1) produces a misleading timeline.

Practitioner checklist

• Write the AU-2 event list per component with a rationale and a review date.
• Confirm AU-3 fields, including the calling identity for service and API actions.
• Alert on every source going silent and test the alert on a schedule.
• Define AU-6 review frequency, use cases and triage owners in the plan.
• Use UTC or explicit offsets and synchronise clocks to an authoritative source.
• Separate log administration from system administration and make log storage immutable.
• Set AU-11 retention from legal and investigation needs and test a restore from the oldest date.
• Tailor in AU-13 for leaked credential monitoring and AU-14 for privileged session recording where risk warrants.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: Revises Security and Privacy Control Catalog to Improve Software Update and Patch Releases
• NIST: SP 800-92 Rev. 1 (Initial Public Draft), Cybersecurity Log Management Planning Guide
• OMB: M-21-31, Improving the Federal Government's Investigative and Remediation Capabilities
• ASD's ACSC and partners: Best practices for event logging and threat detection
• NIST: SP 800-171 Rev. 3
• CIS: Controls Assessment Specification, Control 8 Audit Log Management

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · NIST SP 800-53 IA Identification and Authentication · Log Management and Retention Guide · SIEM Guide