NIST SP 800-53 Audit Logging AU Controls: Requirements and How Coralogix Helps You Comply

An audit logging pipeline built to federal standards does two jobs at once: it produces the evidence an assessor asks for during authorization, and it hands your on-call engineer a complete trail when an incident hits at two a.m. For National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, the Audit and Accountability (AU) control family defines exactly what that pipeline must capture, retain, protect, and surface for review.

This guide covers what each AU control from AU-1 through AU-12 requires of your systems, how to implement those requirements across Kubernetes and multi-cloud environments, and where Coralogix’s architecture maps to specific controls.

What Is NIST SP 800-53 Audit Logging?

The AU control family governs NIST SP 800-53 audit logging: 56 controls and enhancements across 15 base controls covering event selection, record content, storage capacity, failure response, review, time stamps, protection, and retention. Recent updates adjusted cross-references without substantively revising the AU requirements themselves, so teams that last mapped controls under Revision 4 need to account for the shifted structure, most notably around which controls carry which enhancements. Three baselines, Low, Moderate, and High, determine control applicability, with enhancements stacking as impact level rises. AU-7 and AU-9 start at the Moderate baseline, and AU-10 applies at High only. Everything else, from policy through record generation, applies at every baseline.

How Audit Logging Supports NIST SP 800-53 Compliance and Incident Response

Audit records give incident responders the sequence of events and give assessors the evidence needed for authorization. They also help teams find attackers before an outside party notifies you. Each of these outcomes traces to specific AU controls, and each fails quietly when teams treat logging as an afterthought.

Supporting Incident Investigation and Non-Repudiation

AU-3 requires each record to capture record content: the event description, time stamps, source and destination addresses, user or process identifiers, and success or failure indications. Records missing user identifiers can’t answer the question every post-incident review asks: which account or process performed the action? Non-repudiation under AU-10 raises the bar further by making your log archive evidence that can attribute a specific action to a specific individual.

Meeting FedRAMP, FISMA, and CMMC Mandates

The Federal Information Security Modernization Act (FISMA) requires federal systems to implement SP 800-53 controls at a baseline matched to impact level, and the Federal Risk and Authorization Management Program (FedRAMP) makes those controls a FedRAMP authorization condition for cloud service providers and adds its own parameters on top. The Cybersecurity Maturity Model Certification (CMMC) reaches defense contractors through NIST SP 800-171, whose requirements derive from the Moderate baseline; the current CMMC Level 2 model includes four audit practices covering log creation and retention, user traceability, event review, and audit failure alerting. If you sell into any of these markets, the AU family is contractual.

Reducing Dwell Time for Undetected Threats

Global median attacker dwell time reached 14 days in the most recent reporting period, and cyber espionage incidents ran much longer than the global median. Organizations detecting intrusions internally found them faster than those notified by an external party. A working audit review process helps teams detect intrusions internally before an external party notifies them.

The NIST SP 800-53 AU Control Family Explained

AU-1 through AU-12 govern system implementation. Baseline applicability comes from SP 800-53B, and parenthetical enhancements such as AU-6(1) stack on the base control at higher baselines. Each entry below states what the base control requires, the baseline it applies at, and how Revision 5 changed the requirement where relevant.

AU-1: Audit and Accountability Policy and Procedures

AU-1 requires an AU-1 policy covering purpose, scope, roles, responsibilities, and compliance with applicable laws, at all three baselines. Revision 5 lets you set policy at the organization, mission, or system level. This is the written artifact your System Security Plan (SSP) points to, so your pipelines need to implement the written policy.

AU-2: Event Logging

AU-2 defines which event types the system must log, such as login attempts and privilege escalation, along with a documented rationale for each selection. The control also requires reviewing and updating those selections at a defined frequency, a duty Revision 5 folded into the base control. Event selection is a policy decision, which is why assessors evaluate it separately from the generation capability in AU-12.

AU-3: Content of Audit Records

AU-3 specifies record content: event description, time stamps, source and destination addresses, user or process identifiers, success or fail indications, and filenames involved. Moderate and High baselines add AU-3(1), which requires organization-defined additional detail. Structured logging is a compliance requirement because AU-3 requires time stamps and identifiers.

AU-4: Audit Log Storage Capacity

AU-4 requires audit log storage capacity that meets organization-defined requirements, because insufficient capacity risks losing logging capability outright. AU-4(1) requires teams to transfer logs at a defined frequency to a system or medium other than the one doing the logging. Your pipeline needs documented capacity thresholds and defined overflow behavior before it starts dropping records.

AU-5: Response to Audit Logging Process Failures

AU-5 requires a defined response when audit logging fails, whether from exceeded capacity or transport problems. The response includes alerting designated personnel. FedRAMP Moderate assigns the failure action as “overwrite oldest record,” and FedRAMP High adds AU-5(1), a warning when storage reaches a defined percentage of capacity. Meeting it means monitoring the logging pipeline itself: events-per-second rates and drop counters.

AU-6: Audit Record Review, Analysis, and Reporting

AU-6 requires reviewing and analyzing audit records for inappropriate or unusual activity at an organization-defined frequency, with findings reported to designated personnel. Moderate and High add AU-6 enhancements: AU-6(1), automated integration of review and reporting processes, and AU-6(3), correlation of records across repositories for organization-wide awareness. Centralized log management systems support these two enhancements in the SSP.

AU-7: Audit Record Reduction and Report Generation

AU-7, at Moderate and High, requires reduction and report generation that supports on-demand review without altering the original records. Analysts filter, sort, and search working views while the originals stay intact. AU-7(1) adds automatic sort and search capability on organization-defined fields.

AU-8: Time Stamps

AU-8 requires time stamps from internal system clocks, recorded in Coordinated Universal Time (UTC) or a fixed local offset from it, at organization-defined granularity. Clock drift between Kubernetes nodes and third-party integrations breaks cross-service correlation during investigations. Revision 5 moved time source synchronization requirements to SC-45, but your team still owns the operational problem.

AU-9: Protection of Audit Information

AU-9, starting at Moderate, protects audit information from unauthorized access, modification, and deletion, and Revision 5 added an alert requirement when tampering occurs. High adds AU-9(2) separation, storing records on a physically separate system from the audited system, and AU-9(4), restricting audit management to a defined subset of privileged users. AU-9(3) covers cryptographic integrity protection of both audit information and audit tools.

AU-10: Non-Repudiation

AU-10 applies at the High baseline only. The control protects against an individual falsely denying an action, which requires identity binding in audit records strong enough to withstand dispute. Revision 5 moved the digital signatures enhancement into SI-7, so the integrity mechanisms now live in the system integrity family.

AU-11: Audit Record Retention

AU-11 requires retaining audit records for an organization-defined period that supports after-the-fact investigations and regulatory requirements. AU-11(1) requires organization-defined measures so long-term records remain retrievable, such as converting records to newer formats or keeping the equipment and documentation needed to read them. Logs archived in a format you can no longer query fail the enhancement even if the bytes still exist.

AU-12: Audit Record Generation

AU-12 is the technical capability control: the system must generate records for the AU-2 event types on all components, let authorized personnel select which events each component logs, and produce records with AU-3 content. Revision 5 absorbed the former enhancements for compiling records from multiple sources and selecting events by component. Assessors check this control component by component, and teams that document AU-2 policy without demonstrating per-component generation typically fail here.

How to Implement NIST SP 800-53 Audit Logging Requirements

Implementation should start with policy and event selection, then move to the pipeline that collects records and supports review. Each step produces an artifact an assessor will ask for. Skipping ahead to tooling before the policy exists is a common way teams end up re-doing the work.

Defining an Organization-Wide Logging and Retention Policy

Your AU-1 policy should specify roles, event categories, retention periods, and failure responses before any collector configuration happens. For federal work, the four-tier event logging (EL) maturity model starts with basic categories and consistent time stamps at EL1, then advances toward container security tied to a security information and event management (SIEM) system with automation and user behavior analytics at EL3. Writing the policy against those tiers gives you a defensible structure even outside federal contracts, since the model centers on investigation and remediation needs.

Identifying Which Events and Systems to Log

Systems can generate audit records at various levels, including packet-level activity as information traverses the network, which makes over-collection as real a risk as under-collection. Kubernetes gives you the granularity to tune this: the audit system defines four log levels (None, Metadata, Request, RequestResponse). A policy that logs secret access, role-based access control (RBAC) changes, pod mutations, and authentication anomalies while dropping noisy read-only requests can materially reduce audit volume compared to logging everything. For example, a Kubernetes policy can capture RequestResponse for secret reads and RBAC updates, then assign None to high-volume health checks. Your team should document the rationale for each selection, because AU-2 requires the why as well as the event list.

Centralizing Log Collection Across Hybrid and Cloud Systems

AU-6(3) requires correlating records across repositories, which in practice pushes teams toward one queryable destination. Centralized delivery of cloud audit logs to a single repository supports AU-6(3). For managed Kubernetes clusters, keep the collector layer backend-agnostic where possible, so a backend change does not require reworking every service.

Automating Audit Record Review and Alerting

AU-6(1) calls for automated mechanisms that fold review, analysis, and reporting into your investigation and response processes. Detection logic should reflect the inappropriate or unusual activity your SSP defines, with thresholds set to cut false positives. Privileged account activity and other high-value sources belong in near-real-time review. Administrators and security teams still need weekly manual review even with a SIEM correlating and alerting.

Common Challenges in Meeting NIST SP 800-53 AU Controls

AU compliance can fail on retention economics. Cross-system correlation and pipeline health create the same risk, and none of these problems shows up in a policy review. The SSP can read perfectly while the pipeline underneath drops records or prices the team out of its own retention commitment. Each problem pairs with specific controls, and those controls guide the fixes.

Balancing Retention Costs Against AU-4 and AU-11

Cost pressure can push teams toward retention cuts that break AU-11 outright. Espionage campaigns whose dwell times can run 393 days make the exposure concrete: a team deleting logs at six months can’t investigate the class of attacker most likely to target a regulated environment. Retention architecture should make long-term storage economically normal, so engineers do not have to defend it every quarter.

Correlating Audit Records Across Distributed Systems

Organizations often store audit logs on many hosts throughout an organization, and that conceptual problem still applies to cloud-native estates. Correlation identifiers help engineers avoid reconstructing request paths by hand. That many-source reality can compound the problem, since cloud-native tooling can silo data inside its own provider. AU-6(3) requires analyzing and correlating audit records across different repositories to gain organization-wide situational awareness.

Catching Audit Logging Process Failures Before They Spread

AU-5 implementation should assume telemetry transport and pipeline failures can create audit gaps unless the log management infrastructure is monitored directly. Security administrators should manage, secure, and monitor log infrastructure as a control surface. A gap in the audit trail makes AU-11’s after-the-fact investigation impossible for that window, no matter how good the retention policy reads on paper. Meeting the control means instrumenting the pipeline itself, tracking events per second, delays, and drop counts independently of the log payloads it carries.

How Coralogix Simplifies NIST SP 800-53 Audit Logging Compliance

Coralogix, a cross-stack observability platform, writes archived telemetry to your own Amazon Simple Storage Service (S3) bucket in open Parquet format with no platform storage fee and no retention limits, and you query that archive directly through DataPrime with no rehydration step. Customer-owned storage does double compliance duty: your bucket is a physically separate repository under AU-9(2), governed by access policies you manage under AU-9(4), while unlimited retention with direct query can help meet both AU-11 and the AU-11(1) retrievability enhancement.

The TCO Optimizer, which helps teams manage total cost of ownership, routes log and trace data to the Frequent Search, Monitoring, Compliance, and Blocked pipelines based on policies you define for each data stream, and Coralogix applies archive retention labels (Default, Short, Intermediate, Long) as tags. Coralogix capabilities can support these AU controls:

Coralogix Capability	AU Controls Supported
Infinite retention in customer-owned S3 (Parquet)	AU-11, AU-11(1)
TCO Optimizer policy-based routing with retention tags	AU-4, AU-11
Archive query via DataPrime, no rehydration	AU-6, AU-11(1)
Flow Alerts sequential alert chaining	AU-6, AU-6(1)
Cloud SIEM in-stream detections	AU-6(1), AU-6(3)
Customer-owned bucket separation and access control	AU-9(2), AU-9(4)

On the review side, Cloud SIEM runs out-of-the-box detections in-stream as data arrives, and Flow Alerts chain alerts across logs, metrics, traces, and security data into one correlated incident, which can support AU-6(1) automated integration and AU-6(3) cross-repository correlation. For federal buyers, Coralogix U.S. GovOps is currently in Agency Authorization In Process at the Moderate baseline, with the Department of Education’s Federal Student Aid as sponsoring agency; Coralogix has not yet received full authorization, so agencies requiring an authorized provider can track status on the FedRAMP marketplace listing. Independent assessments and certifications already in place include System and Organization Controls (SOC) 2 Type II and International Organization for Standardization (ISO) 27001, 27701, 27017, 27018, and 42001.

Building an Audit-Ready Logging Program

An audit-ready program follows a fixed sequence: an AU-1 policy naming events and retention periods, AU-2 selections with documented rationale, AU-12 generation verified per component, centralized correlation for AU-6, and health monitoring on the pipeline itself for AU-5. The same architecture that satisfies assessors also shortens incident investigation, so the compliance work and the reliability work converge on a single pipeline aligned to the AU control family. Retention economics is usually the first failure point, and storage you own in an open format removes the incentive to delete the records AU-11 says you’ll need. If that cost tradeoff is what’s holding your AU-11 policy back, Coralogix’s infinite retention in your own S3 bucket keeps records queryable without a rehydration fee working against you. Start a free 14-day trial to see how your retention period holds up against a live audit workload.

Frequently Asked Questions About NIST SP 800-53 Audit Logging

How often should audit logs be reviewed under NIST 800-53?

The base AU-6 control leaves review frequency as an organization-defined parameter, but the FedRAMP Moderate and High baselines both assign “at least weekly.” Higher-risk sources such as privileged account activity and remote access logs warrant daily or near-real-time review, while lower-risk sources can justify longer intervals.

Does NIST SP 800-53 apply to cloud-native applications?

Yes. FISMA makes it mandatory for federal systems, and FedRAMP makes it a condition of authorization for cloud service providers, regardless of architecture. NIST SP 800-190 addresses container security, and the kube-apiserver’s audit logging capability directly supports AU-2 and AU-12 in cluster environments.

What is the difference between AU-2 and AU-12?

AU-2 and AU-12 split the requirement in two: AU-2 is the organizational decision about which event types to log and why, and AU-12 is the system’s demonstrated capability to generate those records with AU-3 content on every component. A documented event selection policy without per-component generation evidence won’t pass an AU-12 assessment.

How long must audit records be retained for FedRAMP compliance?

Under FedRAMP’s Revision 5 baselines, AU-11 carries no FedRAMP-assigned retention period; you define and document your own period in the SSP. The legacy Revision 4 parameters were at least 90 days online at Moderate and one year at High, and M-21-31 directs agencies toward 12 months of active storage plus 18 months cold; that structure is a defensible target with your Authorizing Official’s concurrence. Coralogix’s infinite retention keeps records queryable in your own bucket, so your retention period becomes a policy setting.