AU-12: Audit Record Generation

What this control requires

AU-12 requires your organization to generate audit records for every security-relevant event your systems are capable of logging. It mandates three things: your systems must have the technical capability to produce audit logs, authorized personnel must be able to select which event types get logged on specific components, and the resulting audit records must capture the content fields defined in NIST SP 800-53 control AU-3.

In practice, this requirement means you can’t treat logging as a passive default. You need deliberate configuration decisions about which events to capture, on which systems, and with what level of detail. AU-12 works in concert with AU-2 (which defines loggable event types) and AU-3 (which defines required record content), forming the operational backbone of your audit and accountability program.

Without AU-12 in place, your security operations team has no reliable trail to investigate incidents, validate compliance, or detect unauthorized access. The control applies across all three baselines, making it a foundational requirement for any system operating under NIST SP 800-53. You can find AU-12 within the Audit and Accountability family alongside related controls that govern event logging, record content, and log storage.

Why it matters

Organizations that fail to generate comprehensive audit records lose the ability to detect threats in progress and reconstruct incidents after the fact. When logging gaps exist, attackers operate undetected for months, exfiltrating data while security teams remain blind to lateral movement, privilege escalation, and unauthorized data access.

The consequences extend beyond security operations. Incomplete audit records undermine compliance posture, complicate forensic investigations, and erode trust with regulators, auditors, and business partners. For federal agencies and their contractors, AU-12 gaps can result in findings of material weakness during Federal Information Security Modernization Act (FISMA) assessments.

Office of Personnel Management breach (2014-2015)

The U.S. Office of Personnel Management (OPM) breach remains one of the most consequential examples of what happens when audit record generation fails at scale. Attackers exfiltrated 21.5 million background investigation records, 5.6 million fingerprints, and 4.2 million personnel files over a period that stretched back to approximately 2012.

Neither intrusion was discovered by OPM’s own monitoring. The first was identified in March 2014 through an external notification, and the second was discovered in April 2015 by Cylance software and CyTech Services during a product demonstration.

The House Oversight Committee found that both discoveries were made by outside parties, not OPM’s internal security operations. OPM had deployed ArcSight as its SIEM platform, but auditable events weren’t being forwarded to it. The FY 2014 audit revealed that 11 of 47 major systems lacked valid security authorization.

Inspector General reports from 2007 through 2014 had repeatedly flagged logging as a material weakness. The IG’s FY 2015 FISMA report stated that “gaps in OPM’s audit logging capability likely limited OPM’s ability to answer important forensic and threat assessment questions related to the incident discovered in 2014. This limited capability also undermined OPM’s ability to timely detect the data breaches.” Seven years of documented logging deficiencies preceded one of the largest government data breaches in U.S. history.

What attackers exploit

• Unmonitored system components where audit record generation is disabled or misconfigured, allowing lateral movement without triggering alerts
• Inconsistent event selection across environments, creating blind spots in authentication, privilege escalation, and data access logging
• Centralized logging failures where individual systems generate records but never forward them to a security information and event management (SIEM) platform or log aggregator
• Overly broad role assignments that allow unauthorized personnel to modify which events get logged, effectively suppressing detection
• Legacy systems and shadow IT operating outside the organization’s audit logging policy, providing unmonitored entry points

Audit record generation gaps are particularly dangerous in public sector environments where attackers specifically target systems with weak monitoring to maintain persistent access.

How to implement

For your organization

The primary challenge with AU-12 isn’t understanding the requirement. It’s ensuring consistent implementation across every system component in your environment, including those managed by different teams with different tooling preferences.

The foundation for this work is a complete inventory of all system components that must generate audit records. Map each component against the auditable event types defined in your AU-2 implementation, and verify that the technical capability to generate records exists and is enabled on every one.

Specifically, each component needs to generate records that include the content fields required by AU-3: what happened, when it happened, where it happened, the source of the event, the outcome, and the identity associated with it. Don’t rely on default logging configurations. Defaults rarely capture the full scope of events your security operations team needs for detection and investigation.

Where this frequently breaks down is in unauthorized changes to logging configuration. Establish a role-based authorization process for selecting event types, and document who has the authority to modify logging on each component. Implement change management controls to prevent unauthorized modifications, which maps directly to AU-12’s requirement that “personnel or roles” control event type selection.

In practice, the above steps mean nothing if records never reach a central platform. Deploy a log management or SIEM solution to aggregate records from all components, then test the pipeline end to end. Common mistakes include configuring local logging without forwarding, using inconsistent time sources across components, and failing to account for log volume growth in your compliance checklist.

The result is a set of evidence artifacts that demonstrate your implementation: logging policies, system configuration screenshots, sample audit records, role assignments for event selection, and periodic validation reports.

For your vendors

Evaluating AU-12 compliance in your vendor ecosystem requires a different approach than internal implementation. You can’t configure their systems directly, so your focus shifts to verification and evidence collection.

Include these questions in your vendor security assessments:

• Do your systems generate audit records for all event types defined in your security plan?
• Can authorized personnel select which event types are logged on specific system components?
• Do your audit records include timestamps, event type, user identity, source, outcome, and affected objects?
• How do you validate that audit record generation is functioning correctly across all system components?
• What is your process for detecting and responding to audit logging failures?

Request specific evidence: audit logging policies, sample audit records with all required fields populated, SIEM or log management architecture diagrams, and documentation of role-based access controls for logging configuration. Configuration screenshots showing enabled audit policies on representative system components are more valuable than high-level policy documents alone.

Watch for red flags: vendors who can’t produce sample audit records on request, organizations that rely exclusively on default logging without documented customization, environments where logging configuration changes aren’t tracked through change management, and vendors who lack a centralized log aggregation platform.

Verify the vendor’s approach against NIST SP 800-53 third-party risk requirements to ensure their audit record generation covers the event types relevant to the services they provide to your organization.

Evidence examples

Cross-framework mapping

Related controls

• AU-02 — Event Logging: Defines the auditable event types that AU-12 uses to determine what records to generate
• AU-03 — Content of Audit Records: Specifies the required fields that AU-12 generated records must include
• AU-04 — Audit Log Storage Capacity: Ensures sufficient storage exists for the volume of records AU-12 produces
• AU-05 — Response to Audit Logging Process Failures: Defines what happens when AU-12’s record generation capability fails or degrades
• AU-06 — Audit Record Review, Analysis, and Reporting: Consumes the records AU-12 generates for threat detection and compliance reporting
• AU-07 — Audit Record Reduction and Report Generation: Processes and filters the raw audit records AU-12 creates
• AU-14 — Session Audit: Extends AU-12 by capturing detailed session-level activity beyond individual event records
• AC-06 — Least Privilege: Restricts who can modify the logging configurations that AU-12 depends on
• AC-17 — Remote Access: Remote sessions require audit record generation to maintain visibility across access channels
• CM-05 — Access Restrictions for Change: Protects logging configurations from unauthorized modification that could undermine AU-12

Frequently asked questions

What is NIST SP 800-53 AU-12?

AU-12 is the NIST SP 800-53 control that requires information systems to generate audit records for security-relevant events. It mandates that systems provide the technical capability to create logs, that authorized personnel can select which event types are captured on specific components, and that all generated records include the content defined in AU-3. The control applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal systems and organizations adopting the NIST framework.

What happens if AU-12 is not implemented?

Failure to implement AU-12 leaves your organization without a reliable record of security-relevant activity across system components. Incident response teams can’t reconstruct attack timelines, compliance auditors flag material weaknesses in FISMA assessments, and threat detection capabilities degrade because SIEM platforms have no events to analyze. The OPM breach demonstrated that logging gaps can allow attackers to operate undetected for years, exfiltrating millions of records while the organization’s own monitoring tools remain blind.

How do you audit AU-12?

Auditing AU-12 requires verifying three assessment objectives: that system components provide audit record generation capability for defined event types, that authorized personnel can select event types for specific components, and that generated records contain AU-3 content fields. Collect evidence including audit logging policies, system configuration exports showing enabled events, sample records with required fields, SIEM integration documentation, and role assignments for logging configuration authority. Test the pipeline by triggering known events and confirming they appear in your centralized platform with correct content and timestamps.

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

AU-2 defines which event types an organization considers auditable and establishes the policy for what should be logged. AU-12 requires the systems themselves to generate the actual audit records for those event types. Think of AU-2 as the “what to log” decision and AU-12 as the “make it happen” implementation. AU-2 identifies that failed authentication attempts should be auditable; AU-12 ensures your authentication systems actually produce records when those failures occur, with the content fields AU-3 requires.