Audit Record Generation

To meet the audit record generation requirement (NIST SP 800-53 Rev. 5 AU-12), you must (1) enable audit logging for every event type your system can technically audit, (2) assign specific roles who can choose which events are logged, and (3) consistently generate audit records for the selected events across the FedRAMP authorization boundary. ¹

Key takeaways:

• You need a documented, role-controlled “what we log and why” decision, not just “logging is on.” ¹
• Auditors will test whether logs are actually generated for in-scope systems, not whether a policy exists. ¹
• Evidence must tie configuration, access control, and operating results together (screenshots/exports, change records, and sample log output). ¹

Audit record generation sounds basic until an assessor asks you to prove three things at once: the platform can generate audit records, the right people can decide what gets logged, and the system actually produces logs for those selected events—reliably, across the whole authorization boundary. AU-12 is where many teams get tripped up because they treat logging as a tooling feature rather than a controlled requirement with governance, configuration, and evidence.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to operationalize AU-12 as a short set of decisions and controls: define event categories, map them to each boundary component, restrict who can change logging selection, and produce “show me” evidence that logs are being generated for the chosen events. This page gives you requirement-level guidance you can hand to engineering and security operations, plus the artifacts you should collect for FedRAMP assessment and continuous monitoring expectations. Helpful references include NIST SP 800-53 Rev. 5 and FedRAMP’s published templates for documenting the implementation approach in SSP-style narratives and control evidence packages. ^{1 2}

Regulatory text

Requirement (AU-12): “Provide audit record generation capability for the event types the system is capable of auditing; allow organization-defined personnel or roles to select the event types that are to be logged; and generate audit records for the selected events.” ¹

What the operator must do

AU-12 has three operator-checkable parts:

1. Capability exists: Each in-scope system component (cloud service, platform service, host, identity system, network/security control plane, key apps) must be able to generate audit records for the event types it can audit. ¹

2. Selection is controlled: You must define which roles (not “any admin”) can decide which event types are logged. This is governance plus access control: documented authority and technically enforced permissions. ¹

3. Generation happens for selected events: It’s not enough that a setting exists. Audit records must be produced for selected events in practice, and you must be able to show sample outputs and configurations. ¹

Plain-English interpretation (what AU-12 really means)

If your system can produce logs for an activity, you must be able to turn those logs on, decide (through approved roles) which activities you will log, and then actually generate the logs you said you would. AU-12 is the “logging is real” control: it bridges policy intent, configuration, and operational output. ¹

A practical way to phrase the requirement for engineering:
“Every boundary component must have logging enabled for the approved event set, and only designated roles can change that event set.” ¹

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) operating a cloud service offering inside a FedRAMP authorization boundary. ¹
• Federal Agencies responsible for implementing/maintaining the authorized baseline for the system they operate or sponsor. ¹

Operational context where AU-12 shows up:

• FedRAMP authorization (3PAO testing) and ongoing continuous monitoring evidence expectations, typically documented using FedRAMP templates and SSP-style narratives. ²
• Any environment where you have multiple log sources (IdP, cloud control plane, workload OS, containers, apps, databases, WAF, EDR) and need consistent selection and governance.

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

Use this as an execution checklist you can assign across Security Engineering, Platform, and App owners.

Step 1: Define the authorization boundary log source inventory

Create a boundary log source register with:

• Component name and owner
• Function (IdP, hypervisor, DB, API gateway, etc.)
• Native audit log capability (what it can generate)
• Where logs are sent (SIEM/log platform)
• Current state (enabled/disabled; gaps)

Output artifact: “Audit Logging Source Inventory” (table).
Why it matters: AU-12 starts with “event types the system is capable of auditing.” You cannot defend coverage without an inventory. ¹

Step 2: Build your “event types to log” standard (organization-defined)

Define your audit event categories in a way that maps to real systems. Common categories you can standardize without overfitting:

• Authentication events (success/failure, MFA changes)
• Authorization and privilege changes (role grants, policy changes)
• Administrative actions (config changes, user lifecycle)
• Data access actions for sensitive stores (read/export/delete where feasible)
• Security control events (WAF blocks, EDR detections)
• System lifecycle events (service start/stop, scaling, backup/restore)

Decision point: For each category, specify:

• Must-log vs. conditional-log
• Minimum fields required in the audit record (who, what, when, where, outcome)
• System mapping (which components generate this category)

Output artifact: “Audit Event Selection Matrix.”

Step 3: Assign and enforce the roles allowed to select/modify logging

AU-12 requires “organization-defined personnel or roles” who can select event types to be logged. ¹

Do both:

• Governance: Write a short RACI for log selection changes (requestor, approver, implementer, reviewer).
• Technical enforcement: Restrict permissions in the cloud provider, SIEM, and logging agents so only those roles can:
  • Enable/disable audit log sources
  • Change what event types are collected (filters, selectors)
  • Change destinations or disable forwarding
  • Modify retention/immutability settings if those changes affect record generation

Output artifacts: IAM role definitions, access reviews, and a “Logging Change Control SOP.”

Step 4: Configure audit record generation per component (and prove it)

For each boundary component:

• Turn on the native audit log feature(s)
• Configure event selectors to match your matrix
• Configure forwarding to your central log store
• Validate that audit records are being generated by producing a small test (for example: a known admin change, a test login failure, a policy update) and capturing the resulting log entry

Evidence tip: Auditors like seeing the configuration + a sample log entry that corresponds to a specific test action, tied together by time and actor.

Step 5: Add change control and drift monitoring

Logging failures are usually caused by drift: a new account, a new service, a changed policy, an agent upgrade, or a cost-saving change that drops audit volume.

Minimum operational controls:

• Ticketed change requests for any logging selector/coverage change
• Monitoring for ingestion failures (no logs from a source)
• Alert on disabling audit logging where technically possible
• Periodic re-validation that sources still emit events in line with the event selection matrix

This also supports the practical expectation to keep review evidence and follow-up tickets showing that logged events are actively monitored and resolved. ¹

Step 6: Document it in FedRAMP-style narratives and packages

FedRAMP reviewers will expect you to document “what is implemented where” using their templates and SSP-style control descriptions. ²

Practical documentation approach:

• One narrative describing the logging architecture and role-based control over event selection
• One appendix/table mapping each component to event categories and evidence locations

If you manage this in Daydream, treat AU-12 as a control page backed by a living system inventory, evidence attachments, and recurring tasks for log source verification. Daydream becomes the place you show assessors the crosswalk from requirement → configuration → evidence without rebuilding the package each cycle.

Required evidence and artifacts to retain

Keep evidence that proves all three AU-12 elements: capability, controlled selection, and actual generation.

Evidence type	What “good” looks like	Owner
Audit event selection matrix	Event categories, rationale, mapping to components, last approval date	GRC + Security Engineering
Log source inventory	Complete list of boundary components and audit log capabilities	Platform/Cloud Ops
Configuration proof	Screenshots/exports of audit logging enabled and selectors/filters	System owners
IAM/RBAC proof	Role definitions + who has access to change logging	IAM/Security
Change records	Tickets/PRs for logging changes; approvals captured	Engineering/ITSM
Sample audit records	Example log entries for representative events from key sources	SecOps
Review evidence	Tickets showing investigation/escalation tied to logged events	SecOps
This aligns with recommended practices to document systems/events/settings and keep review evidence with follow-up and escalation records. 1

Common exam/audit questions and hangups

Expect these lines of questioning in assessor testing:

1. “Who can change what gets logged?”
   They want named roles, not job titles, plus proof in IAM settings. ¹

2. “Show me audit records generated for these selected events.”
   Bring sample records from multiple sources, especially identity, admin actions, and key applications. ¹

3. “How do you know every boundary component is covered?”
   Your inventory must match the SSP boundary description and architecture diagrams.

4. “What happens when a new service is added?”
   You need a process hook: onboarding requires logging setup and inclusion in the event selection matrix.

5. “Prove it’s not just configured; prove it’s operating.”
   Provide test evidence (time-bound) and monitoring/alerting evidence for log ingestion failures.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “SIEM connected” as AU-12 compliance.
   Fix: AU-12 is about generating audit records for selected events. Keep per-system proofs and samples. ¹

2. Mistake: No controlled role for event selection changes.
   Fix: Define and enforce a logging-admin role with explicit permissions; remove ad hoc admin access. ¹

3. Mistake: Filters drop high-value events to reduce noise.
   Fix: Keep “must-log” events non-negotiable, and document any conditional logging decision with rationale and approval.

4. Mistake: Missing application-layer audit records.
   Fix: For custom apps, define what the app must log (authz decisions, admin actions, sensitive data operations) and verify output.

5. Mistake: Evidence is scattered and rebuilt for every assessment.
   Fix: Centralize evidence and map it to AU-12 sub-points (capability, selection authority, generation). A GRC system like Daydream helps keep this packaged and current.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement actions.

Operational risk still matters: if audit record generation is incomplete or not reviewed, suspicious activity and control failures can go undetected, and you may lack operating evidence during FedRAMP authorization reviews, assessor testing, and continuous monitoring submissions. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Produce the boundary log source inventory and identify coverage gaps.
• Draft the audit event selection matrix and get formal approval from the defined authority.
• Define the roles allowed to change logging selection; remove broad permissions where feasible.
• Start collecting configuration exports/screenshots for high-risk systems (identity, cloud control plane, admin consoles).

By 60 days (implement and prove)

• Enable/configure audit record generation for all prioritized sources and align selectors to the matrix.
• Set up central forwarding and basic ingestion health monitoring.
• Run and record verification tests that generate representative audit records; store the sample outputs as evidence.
• Implement ticketed change control for logging configuration changes.

By 90 days (operate and make it audit-ready)

• Expand coverage to remaining sources and address edge cases (managed services, third-party hosted components inside boundary).
• Perform an internal control test: pick a sample of event types and trace from action → generated log record → stored centrally.
• Package evidence in a FedRAMP-friendly format using published templates and SSP-style narratives. ²
• Stand up a recurring review cadence for logging coverage and ingestion failures, with tickets and outcomes captured. ¹

Frequently Asked Questions

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

AU-12 requires the capability to generate audit records for event types the system can audit, and that designated roles select which event types are logged. You should define and approve a selected set, then prove generation for that set. ¹

Who should be allowed to select or change audit event types?

Assign a small set of organization-defined roles with explicit permission to change logging selectors and enable/disable sources. Then enforce it technically in IAM and document it in your procedures. ¹

What evidence is most convincing to a FedRAMP assessor for AU-12?

Pair configuration evidence (logging enabled, selectors set) with sample audit records generated from known test actions, plus the role/permission proof showing who can change settings. Keep it mapped back to each boundary component. ¹

Does AU-12 require a SIEM?

AU-12 focuses on generating audit records for selected events and controlling who can select those events. Centralization is a practical way to show consistent generation and retention, but the control language itself is about capability, selection, and generation. ¹

How do we handle third-party or managed services in the authorization boundary?

Treat them as boundary components: document what audit records the service can generate, how you select event types, and how logs are exported or accessed. If you cannot generate or access required records, document the gap and remediation plan. ¹

Our engineers change logging filters during incidents. How do we stay compliant?

Allow emergency changes through a defined break-glass process with after-the-fact approval and ticketed documentation. Keep the change record and restore the approved baseline selectors as part of incident closure. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates