AU-12: Audit Record Generation

AU-12 requires you to ensure every in-scope system component can generate audit records for the event types you’ve defined in AU-2(a). Operationally, that means translating your AU-2 event list into concrete log sources, enabling logging everywhere those events can occur, and proving coverage through configuration evidence and repeatable validation. ¹

Key takeaways:

• AU-12 is an engineering requirement: logging must be technically enabled on each relevant component, not just written in policy. ¹
• Your control passes or fails on demonstrable coverage of AU-2(a) events across real components (apps, databases, OS, cloud control plane, IAM). ¹
• Evidence needs to tie together: AU-2(a) event list → component inventory → log configurations → sample audit records → ongoing health checks. ¹

AU-12: Audit Record Generation is where “we log things” becomes a testable control. Auditors and customer assessors will not accept intent; they will ask which components generate which audit records for which event types, and they will spot-check. Your job as CCO, GRC lead, or Compliance Officer is to force a clean handshake between governance (the AU-2(a) auditable event types you selected) and operations (the actual systems producing those records).

This page focuses on fast operationalization: how to map event types to system components, how to enable logging in a way that survives change, and what artifacts to retain so you can prove coverage without scrambling. You’ll also see where teams commonly fail AU-12 in practice: incomplete component coverage, logs enabled but not for the required events, and “we have a SIEM” as a substitute for demonstrating record generation at the source.

AU-12 is tightly coupled to AU-2 because AU-12’s scope is “the event types the system is capable of auditing as defined in AU-2(a).” If AU-2 is vague, AU-12 becomes untestable. If AU-2 is crisp, AU-12 becomes implementable. ¹

Regulatory text

Requirement (AU-12): “Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on system components.” ¹

Operator interpretation (what you must do)

1. Start with your AU-2(a) event types. AU-12 inherits its “what to log” from AU-2(a). If AU-2(a) says you audit authentication events, privilege changes, and admin actions, AU-12 requires the system to be able to generate records for those events. ¹
2. Ensure generation happens on the actual components where events occur. “System components” means the real places those events can happen: identity provider, endpoints/servers, applications, databases, network devices, cloud control plane, container orchestrator, and security tooling where applicable. ¹
3. Demonstrate capability, not aspiration. You need configuration and validation evidence showing the records are being generated for the defined event types, across the defined components. ¹

Plain-English interpretation of AU-12

AU-12 means: if you say you audit an event type, your systems must actually create audit records when that event happens, everywhere it can happen. A central SIEM does not satisfy AU-12 by itself; AU-12 is about the generation capability on the components (the sources).

A practical way to phrase the test:

• Pick an AU-2(a) event type (example: “privileged role assignment”).
• Identify every component where that event can occur (example: IAM/IdP, cloud IAM, Kubernetes RBAC).
• Show that each of those components is configured to produce an audit record when the event occurs.
• Produce a sample audit record and the config evidence that proves the capability is enabled.

Who AU-12 applies to

Entity scope

• Federal information systems and contractor systems handling federal data adopting NIST SP 800-53 controls (including as inherited or mapped requirements via federal contracts). ¹

Operational context (where AU-12 becomes real work)

AU-12 is most likely to be scrutinized when:

• You operate hybrid environments (SaaS plus on-prem; multi-cloud).
• You have distributed identity (multiple IdPs, local accounts, shared admin tooling).
• You rely on managed services where logging is optional or defaults are weak.
• You have regulated incident response expectations where audit trails must reconstruct actions.

What you actually need to do (step-by-step)

Step 1: Build the AU-12 control card (owner, scope, triggers)

Create a one-page “control card” your engineers can execute:

• Objective: Each in-scope component generates audit records for AU-2(a) event types it is capable of auditing. ¹
• Owner: Security Engineering or Platform Engineering, with GRC oversight.
• In-scope systems: Boundary definition (system name) and component inventory reference.
• Trigger events: New system onboarding, major version change, new logging pipeline, identity migration, cloud account/subscription creation.
• Exception rules: Document when a component cannot generate a specific event type and the compensating path (example: upstream identity logs cover it).

This control card is also where Daydream fits naturally: store the control card, map components to requirements, and attach the minimum evidence bundle so audits do not turn into a log scavenger hunt.

Step 2: Translate AU-2(a) event types into a logging coverage matrix

Create a table that ties governance to implementation:

Example AU-12 coverage matrix (template)

AU-2(a) event type	Components where it occurs	Log source / facility	Config setting	Validation method	Evidence location
Authentication (success/failure)	IdP, OS, app	IdP audit logs, OS security logs, app auth logs	“Audit sign-in events = on”	Generate test login, confirm record	GRC repository
Privilege/role changes	IAM, cloud IAM, Kubernetes	Admin audit logs	“Admin activity logging = on”	Create/modify role in test, confirm record	GRC repository
Configuration changes	cloud control plane, CI/CD	Cloud audit trail, pipeline logs	“Management events = on”	Change config in test, confirm record	GRC repository

Your matrix should reflect your environment. The audit move is simple: pick a row, then ask for proof.

Step 3: Identify “system components” concretely (inventory you can defend)

AU-12 collapses if “system components” is undefined. Build or reuse a component inventory that includes:

• Component name and function
• Environment (prod/non-prod as applicable)
• Owner team
• Where logs are generated from (native audit log, syslog, app logger)
• Where logs are sent (collector/SIEM)
• Whether the component is capable of auditing each AU-2(a) event type

If you already maintain an asset inventory for other controls, extend it with AU-12 fields rather than creating a parallel spreadsheet.

Step 4: Enable audit record generation at the source

For each component-event combination in your matrix:

• Turn on the right audit facility (native audit log vs debug logs vs access logs).
• Configure event selectors (example: management plane events, admin actions, auth failures).
• Harden against “silent off” (permissions, service accounts, storage quotas, rotation settings).
• Standardize timestamp and identity fields where possible to support correlation.

AU-12 focuses on record generation. Downstream handling (retention, review, protection) is typically addressed by other AU controls, but you still need to ensure generation produces usable records.

Step 5: Validate by generating test events and collecting sample records

For each major component class, run a validation procedure:

• Perform a representative action (failed login, role change, configuration update).
• Capture the resulting audit record (redact secrets if needed).
• Record the timestamp, actor identity, and target object in the evidence pack.
• Store the validation run output with the configuration snapshot.

This is where teams often fail: they show a SIEM screenshot, but cannot show that the source was configured to generate the required record type.

Step 6: Operationalize with recurring control health checks

Define a recurring check that answers:

• Are audit logs still enabled on each in-scope component?
• Did any new components appear without logging configured?
• Did any platform changes reduce event coverage (example: new auth path bypasses logging)?
• Are there ingestion failures that hide the fact that generation is broken?

Track findings to closure with owners and due dates. Keep the tickets and closure evidence.

Required evidence and artifacts to retain

Keep an “AU-12 minimum evidence bundle” that an auditor can follow end-to-end:

1. AU-2(a) auditable event types list (approved and current). ¹
2. System/component inventory showing in-scope components and owners.
3. AU-12 coverage matrix mapping event types to components and log sources.
4. Configuration evidence for each critical component class (screenshots/exports/config-as-code snippets).
5. Sample audit records for representative events per component class (with redaction notes).
6. Validation procedure/runbook and most recent execution results.
7. Change management hooks (how new components are onboarded into logging).
8. Control health check results and remediation tracking to closure.

Store these artifacts in a controlled repository with clear naming so you can respond quickly to audits and customer due diligence.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your AU-2(a) events, then show me where each is generated.” ¹
• “Which system components are in scope, and how do you know the inventory is complete?”
• “Pick one event type. Demonstrate the record is generated on the component, not just received by the SIEM.”
• “How do you prevent logging from being disabled or bypassed during changes?”
• “What happens when a third party or managed service hosts a component? Where do audit records come from?”

Hangups that stall audits:

• Teams cannot define “system components” beyond “our environment.”
• Logging is enabled, but not for the required event selectors.
• Evidence is scattered across tools with no traceable mapping to AU-2(a).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating AU-12 as a SIEM project.
   Fix: Prove source generation first, then ingestion. Keep config evidence at the component level.

2. Mistake: AU-2(a) is vague, so AU-12 is untestable.
   Fix: Force AU-2(a) into a list of event types you can map to real log sources. AU-12 explicitly depends on AU-2(a). ¹

3. Mistake: Only covering “core infrastructure,” ignoring SaaS control planes.
   Fix: Include IdP, cloud control plane, CI/CD, and admin consoles as components if they can execute auditable actions.

4. Mistake: Logging works in production but not in break-glass or admin paths.
   Fix: Add break-glass, emergency access, and privileged admin tooling to the coverage matrix.

5. Mistake: No ownership model.
   Fix: Assign a named control owner and component owners. Tie onboarding to change management.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for AU-12, so this page does not cite specific actions or penalties.

Operationally, AU-12 failures tend to show up as:

• Investigation failure: you cannot reconstruct who did what and when.
• Control testing failure: auditors cannot verify events are generated across the system boundary.
• Customer trust issue: enterprise customers expect demonstrable audit logging coverage during security reviews.

Treat AU-12 as a reliability control for your security facts, not a paperwork exercise.

Practical 30/60/90-day execution plan

No fixed timelines are required by AU-12 in the provided text, so treat the plan below as an execution pattern you can adapt. ¹

First 30 days (stabilize scope and ownership)

• Name the AU-12 control owner and approve the control card.
• Finalize AU-2(a) event types in an auditable list, with system boundary alignment. ¹
• Build the first version of the component inventory and identify logging owners by platform.
• Draft the AU-12 coverage matrix for the most critical components (IdP, cloud control plane, core apps).

Days 31–60 (implement and validate coverage)

• Enable audit record generation for the highest-risk event types across priority components.
• Create validation runbooks per component class (IdP, cloud, OS, app, database).
• Collect representative sample audit records and configuration evidence.
• Document exceptions where components cannot generate a required event type; define compensating sources where appropriate.

Days 61–90 (operationalize and make it durable)

• Add AU-12 checks to onboarding and change management: new component equals new log source validation.
• Stand up recurring control health checks and a remediation workflow.
• Build an “audit-ready” evidence bundle structure in your GRC system (Daydream or equivalent) so each assessment pulls from a consistent folder and mapping.
• Run a tabletop audit: pick random AU-2(a) events and demonstrate generation on the mapped components.

Frequently Asked Questions

Do we have to log every possible event the system can produce?

AU-12 ties to the event types you defined in AU-2(a), and requires generation capability for those event types on system components. If you expand AU-2(a), AU-12 scope expands with it. ¹

Does forwarding logs to a SIEM satisfy AU-12?

Forwarding helps, but AU-12 is about audit record generation on the components. Keep evidence that the source systems are configured to generate the required audit records. ¹

What counts as a “system component” for AU-12?

Treat any technology that can perform AU-2(a) event types as a component: identity services, cloud control planes, applications, databases, hosts, network/security devices, and admin tooling. Document your component inventory so the boundary is defensible.

How do we handle managed services and third parties?

If a managed service performs actions in your system boundary, capture its native audit logs (or admin activity logs) as the audit record generation source. Document how you access those logs and how you validate event coverage.

What evidence do auditors usually accept for AU-12?

A mapping from AU-2(a) events to components, plus configuration exports/screenshots and sample audit records produced by real test actions. Keep the evidence packaged so a reviewer can trace each requirement to proof. ¹

How do we keep AU-12 from drifting after changes?

Wire AU-12 into change management and onboarding: new components and new admin paths require logging configuration and a validation test. Run recurring health checks that confirm logging remains enabled across the inventory.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON