AU-12: Audit Record Generation

To meet the au-12: audit record generation requirement, you must ensure each in-scope system can actually generate audit records for every auditable event type you defined under AU-2a, across the defined system components and time periods. Operationalize this by mapping events to log sources, configuring logging, validating output, and retaining repeatable evidence that auditors can test. ¹

Key takeaways:

• AU-12 is a capability requirement: if the system can audit an event type, it must generate an audit record for it. ¹
• Your AU-2 event list drives scope; AU-12 proves the logging pipeline produces records for that list on the defined components. ¹
• Evidence must show configuration + test results + ongoing operation, not just a logging policy.

AU-12 is where audit logging stops being a policy statement and becomes a testable system behavior. Auditors and assessors will not accept “we send logs to a SIEM” unless you can show that the specific event types you said you audit (under AU-2a) are generating audit records on the specific system components and environments you claimed were covered.

Practically, AU-12 is about closing three gaps that commonly fail assessments: (1) event types listed on paper but not enabled in systems, (2) logs generated but missing required context because collection is partial (wrong components, wrong accounts, wrong network segments), and (3) logs generated but not reliably retrievable because pipelines drop, overwrite, or misroute records.

If you’re a Compliance Officer, CCO, or GRC lead, your job is to turn AU-12 into an owned control with a measurable procedure: define scope, configure sources, validate output against AU-2a, and retain artifacts that prove the capability exists and stays on. ²

Regulatory text

Text (excerpt): “Provide audit record generation capability for the event types the system is capable of auditing as defined in [AU-2a] on {{ insert: param, au-12_odp.01 }};” ¹

What the operator must do:

• Use your AU-2a outcome as the logging contract. AU-12 inherits the list of “event types the system is capable of auditing” that you defined under AU-2a. Your first operational dependency is confirming AU-2a is complete and scoped correctly. ¹
• Make audit record generation real on the defined scope. The “on {{ … }}” parameter is an organizationally defined parameter in NIST’s catalog representation. In practice, treat it as: “on the system components, environments, and/or time periods you define.” Your implementation must match that definition consistently (for example, production workloads, privileged access paths, and security-relevant components). ¹

Plain-English interpretation

AU-12 requires that your systems produce logs (audit records) for the auditable event types you’ve identified, wherever you said the control applies. If your policy says you audit privileged logins, admin actions, and access to sensitive data, then your identity provider, endpoints, servers, applications, and cloud control planes need configurations that actually emit those records.

This is not a “SIEM installed” control. It is a verifiable capability control: can an assessor trigger an event (for example, a privileged role change) and then see the expected audit record generated by the right system, with enough detail to support investigation and accountability?

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are imposed contractually or via an assessment boundary. ²

Operational context

• Any system inside the authorization or assessment boundary where AU-family controls are required: core business apps, cloud infrastructure, identity platforms, network security tooling, endpoint management, databases, and managed services that materially affect confidentiality, integrity, or availability.
• Third parties matter here: if a third party operates part of your system (managed hosting, SaaS, SOC service), you still need evidence that audit records are generated for in-scope events. You may satisfy this through third-party logs, exports, APIs, or contractual attestations, but you must be able to demonstrate the capability in your boundary.

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

1) Confirm the AU-2a event list and boundary

• Pull the approved AU-2a event types list (the “what we audit” list).
• Confirm the system boundary and “where it applies” definition for AU-12 (the organizational parameter referenced in the control text). Document the exact environments and components included (for example: production only; all identity services; all administrative consoles). ¹

Deliverable: AU-12 scope statement that points to AU-2a and names covered components/environments.

2) Build an event-to-log-source mapping table

Create a table that maps each AU-2a event type to:

• System of record (where the event occurs)
• Log source (what generates the record)
• Collection method (agent, API, syslog, cloud-native export)
• Expected fields (actor, action, target, timestamp, outcome, correlation IDs where available)
• Retention destination (central log platform, immutable store, ticketing correlation)

Deliverable: “AU-12 Audit Record Generation Matrix” (this becomes your control operating procedure backbone).

3) Configure audit generation at the source (not just collection)

For each log source, verify:

• Audit logging is enabled (many products default to partial logging).
• The configuration captures the event types from AU-2a.
• Time synchronization is consistent enough to correlate events across sources (tie this to your org’s time management practices; keep it practical and testable).

Operator tip: You want evidence of source configuration because collectors and SIEMs cannot recover events that were never generated.

4) Validate by testing real events and observing audit records

For each major event category (authn/authz, admin activity, data access, configuration changes, security alerts), run a controlled test:

• Trigger the event in the system (for example, create a user, elevate privileges, change a firewall rule).
• Verify the audit record is generated in the native log stream.
• Verify it arrives in the centralized destination if you rely on one for investigations.

Deliverable: Test scripts + screenshots/exports showing the record, including timestamps and identifying fields.

5) Define operational monitoring for logging breakage

AU-12 fails quietly when pipelines break or configs drift. Put in place:

• Alerts for “log source silent” conditions on critical sources.
• Change control checks: logging settings included in baseline configuration and reviewed during releases.
• Periodic spot checks: sample events and confirm records exist.

Deliverable: Monitoring rules, alert examples, and a runbook for “audit record generation failure.”

6) Assign ownership and recurring evidence

Make AU-12 an owned control:

• Control owner (usually Security Engineering, IAM, Platform, or SOC).
• Backup owner.
• Frequency of checks (drift detection, alert review, sample testing).
• Evidence package cadence aligned to your assessment cycle.

Deliverable: Control narrative that ties owner, procedure, and artifacts together (this is where Daydream fits naturally: one place to map AU-12 to an owner, a procedure, and recurring evidence expectations so audits stop becoming scavenger hunts). ¹

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

1. Design / scope

• AU-2a auditable event list reference
• AU-12 scope statement (“on [components/environments]”)
• Event-to-log-source mapping matrix

2. Implementation

• Configuration snapshots or exports from key systems showing audit logging enabled
• Logging baseline standards (configuration requirements by platform)

3. Validation

• Test cases (what event was triggered, by whom, when)
• Output proof (native log entries and, if applicable, centralized platform entries)
• Exceptions list with compensating controls and remediation dates (avoid open-ended exceptions)

4. Operations

• Monitoring/alert configuration for missing logs
• Incident/runbook for logging failure
• Change tickets showing logging settings preserved during changes

Common exam/audit questions and hangups

Assessors tend to probe these areas:

• “Show me AU-2a, then prove you generate records for those events.” If AU-2a is missing or vague, AU-12 becomes untestable and you’ll lose time rebuilding scope. ¹
• “Which components are in scope for AU-12?” If your scope is “all systems” but you can’t produce logs for a major platform, expect a finding.
• “Can you demonstrate it works now?” Screenshots from last year’s implementation project do not prove current capability. Bring current tests or recent samples.
• “What happens if logs stop?” No alerting or no runbook often translates to “control not operating.”

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Avoid it by doing this
Listing event types in AU-2 but not mapping to sources	No one knows where the record should come from	Maintain the event-to-source matrix and keep it version-controlled
Relying on SIEM ingestion as proof	Ingestion does not prove generation	Keep source config evidence and a “trigger event → record exists” test
Partial coverage (prod only, but admin plane is excluded unintentionally)	Attack paths often run through admin/control planes	Explicitly include identity and cloud control plane logging in scope definition
Logging enabled but missing actor/target context	Records exist but don’t support accountability	Define minimum fields per event category and test for them
No operational monitoring	Logging breaks silently	Implement “source silent” alerting and document response steps

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AU-12 primarily as an assessment and incident-readiness risk driver rather than a cited enforcement trend in this write-up.

From a risk standpoint, AU-12 gaps typically show up as:

• Inability to reconstruct security incidents (missing events, missing context).
• Failure to detect unauthorized changes (no records for admin/config actions).
• Audit findings that cascade into related controls (AU-2 scoping, AU-6 review/analysis, IR evidence, and broader system integrity concerns).

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and prove minimum capability)

• Confirm AU-2a event list exists and is approved for the system boundary. ¹
• Draft the AU-12 scope statement (components/environments covered).
• Build the first version of the event-to-source matrix for critical platforms (identity, endpoints, cloud control plane, core apps).
• Run a small set of trigger tests and store outputs as your baseline evidence pack.

Next 60 days (close coverage gaps and make it repeatable)

• Expand the matrix to remaining in-scope systems.
• Standardize logging configuration baselines by platform (what must be enabled, where logs go).
• Implement monitoring for silent sources and document the runbook.
• Convert tests into a repeatable validation procedure tied to change management (new system onboarding and major releases).

By 90 days (operate like an assessor will test you)

• Conduct an internal control test: pick several AU-2a event types across different platforms and demonstrate record generation end-to-end.
• Formalize exceptions with owners and closure criteria.
• Package evidence in an audit-ready format: control narrative + matrix + config proof + test outputs + operational monitoring proof.

Frequently Asked Questions

Does AU-12 require a SIEM?

AU-12 requires audit record generation for defined event types, not a specific tooling choice. A SIEM can help centralize and retain records, but you still need proof that each source system generates the underlying records. ¹

How do AU-2a and AU-12 relate in an audit?

AU-2a defines which event types you audit, and AU-12 requires the system to generate records for those event types on the defined scope. Auditors commonly review AU-2a first, then test AU-12 by triggering or sampling those events. ¹

What counts as “the system is capable of auditing”?

Treat this as the event types your platforms can reasonably emit based on built-in logging and available telemetry. If a system can produce those records but you didn’t enable them, assessors will usually view that as an AU-12 gap. ¹

We use a third-party SaaS. How do we meet AU-12?

Get evidence that the SaaS generates audit records for your required event types and that you can access them (admin console exports, APIs, or scheduled deliveries). Document the mapping in your event-to-source matrix and retain sample exports as evidence.

What evidence is strongest for AU-12?

The strongest package combines source configuration proof plus a trigger test showing the exact audit record produced for an AU-2a event type. Add monitoring evidence that you detect logging failures to show the capability stays operational.

How do we keep AU-12 from drifting after go-live?

Tie logging settings to configuration baselines and change management, then monitor for silent sources. Run periodic spot checks that trigger a small set of events and confirm records appear where expected.

Footnotes

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

2. NIST SP 800-53 Rev. 5