AU-2: Event Logging

The au-2: event logging requirement (NIST SP 800-53 AU-2) requires you to identify and document the types of events each system is capable of logging to support audit and investigation, then operationalize that decision through configuration standards, ownership, and recurring evidence. Your fastest path is an “event catalog” per system, mapped to log sources and reviewed on change. ¹

Key takeaways:

• AU-2 is a scoping and specification control: define what events you can log and which you will require, per system and context. ²
• Auditors will look for a documented event type inventory, traceability to technical log sources, and proof it stays current through change management. ¹
• Treat AU-2 as the front door to your entire audit logging program: if the event list is vague, downstream logging, alerting, and retention controls fail in practice.

AU-2 is easy to misunderstand because it does not say “turn on logs.” It says: identify the types of events the system is capable of logging in support of the audit function. That language forces a concrete outcome: an operator should be able to answer, for any in-scope system, “What events can this system produce, and which ones are required for security and compliance outcomes?”

For a CCO, Compliance Officer, or GRC lead, AU-2 becomes operational once you translate it into three artifacts that stay in sync: (1) an event logging catalog (required event types by system and data sensitivity), (2) a log source-to-event mapping (where each event is actually generated), and (3) a maintenance mechanism (review triggers tied to system changes, onboarding new log sources, and periodic control checks).

This page focuses on rapid execution. You’ll get a practical interpretation, applicability boundaries, step-by-step implementation guidance, evidence to retain, common audit failure modes, and a phased execution plan. All guidance aligns to NIST SP 800-53 Rev. 5 AU-2 as provided. ³

Regulatory text

AU-2: Event Logging requires you to:
“Identify the types of events that the system is capable of logging in support of the audit function: {{ insert: param, au-02_odp.01 }};” ²

What the operator must do

You must produce and maintain a documented list of event types that each system can log, written at a level that is testable. “Testable” means a technical reviewer can confirm, from system settings or configuration, that the events are supported and can be emitted to your logging pipeline. Your list also needs to be scoped to “support of the audit function,” meaning it should enable investigation, accountability, and reconstruction of activity when something goes wrong. ¹

Plain-English interpretation (what AU-2 is really asking)

AU-2 expects you to answer three questions per system:

1. What events can this system generate? (capability)
2. Which of those events do we require and why? (policy decision)
3. Where do those events go, and who verifies they keep flowing? (operationalization)

If you only have “we log authentication events” as a statement, you will struggle in assessment. If you can say “this system logs successful and failed sign-ins, privilege changes, configuration changes, and data access to regulated repositories,” and you can point to the system settings and log samples, you are operating AU-2 like an assessor expects. ¹

Who it applies to (entity and operational context)

AU-2 is relevant for:

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data, where NIST SP 800-53 is contractually flowed down or used as the control baseline. ¹

Operationally, AU-2 applies anywhere you have:

• Systems that process or store sensitive data (regulated, mission-critical, or high-impact internal data).
• Systems that provide identity, access, network, endpoint, application, database, or cloud control planes.
• Third-party hosted platforms where your organization is responsible for security logging requirements, even if the third party operates the infrastructure.

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

Step 1: Set the control boundary and ownership

• Define the system scope for AU-2 (which systems are in scope, and what “system” means in your environment: application, platform, enclave, or major service).
• Assign a control owner (accountable for the AU-2 event catalog) and technical owners per system (responsible for log source configuration).
• Define the review trigger: minimum triggers are major system changes, onboarding a new log source, and material changes to authentication/authorization flows.

Practical tip: if AU-2 has no named owner, it becomes a shared responsibility gap. Make one person accountable for the catalog quality and freshness.

Step 2: Build an “Event Types Catalog” template that auditors can test

Create a table (one per system) with fields like:

Field	What to capture	What an auditor will test
System name + boundary	What’s included/excluded	Scope matches SSP/asset inventory
Log sources	Native logs, agents, cloud services	Sources exist and are enabled
Event type	Plain label + short definition	Definitions are specific
Event identifiers	IDs, categories, or mappings	Can be found in log output
Minimum fields	user, timestamp, src/dst, action	Log entries contain fields
Required vs optional	“Must log” vs “nice to have”	Required events are configured
Routing destination	SIEM, log lake, ticketing	Events are forwarded
Owner + review date	Who checks, when updated	Evidence of maintenance

Your catalog does not need every possible event. It needs the types of events the system is capable of logging that matter for audit outcomes, and it must be kept current. ²

Step 3: Identify event types by starting from common audit questions (then validate capability)

For each system, decide event types that support accountability and investigations, such as:

• Identity events: sign-in success/failure, MFA enrollment, session creation, token issuance.
• Access events: data access to sensitive repositories, permission grants, role changes.
• Administrative actions: configuration changes, policy changes, creation/deletion of resources.
• Security signals: malware detections, EDR alerts, firewall denies, integrity failures.
• Application events: authentication decisions, authorization failures, high-risk business actions.
• Data protection events: encryption key operations, DLP actions, export/download actions.

Then validate the system’s actual capability: what can it log natively, what requires an agent, and what requires application instrumentation.

Step 4: Map each event type to the technical log source and configuration setting

For each event type in the catalog, record:

• Where it is generated (service/module/component)
• How it is enabled (setting, policy, agent config)
• Where it is forwarded (collector/SIEM)
• What the expected output looks like (sample event)

This mapping is where AU-2 stops being paperwork. It becomes a build checklist for engineering and operations.

Step 5: Operationalize maintenance through change management

Add two control checks to your change process:

1. Pre-change: does this change affect event logging capability (new component, new auth flow, new third party service)?
2. Post-change validation: do required event types still appear in the centralized logging destination?

Keep it lightweight. A simple checkbox plus evidence attachment (sample logs or query screenshot) is often enough.

Step 6: Establish recurring evidence production

Run a recurring control activity: for each in-scope system, perform a log presence check for required events and document results. This supports assessment readiness and catches broken forwarding, disabled audit settings, or dropped events.

Step 7: Use a GRC workflow to prevent “catalog drift”

Most AU-2 failures come from drift: systems change faster than catalogs. A practical approach is to maintain AU-2 in a control system (or Daydream) with:

• A control owner and system owners
• A standard procedure
• A recurring evidence schedule
• A record of updates tied to tickets/changes

This aligns with the recommended control practice: “Map AU-2 to control owner, implementation procedure, and recurring evidence artifacts.” ²

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Core artifacts

• Event Types Catalog per system (approved versioned document or GRC record)
• Log source inventory (systems/services producing logs, owners, destinations)
• Configuration standards (baseline settings for audit logging per platform)

Operational evidence (assessment-friendly)

• Change tickets showing AU-2 review occurred for relevant changes
• Sample log exports or SIEM queries demonstrating required event types are present
• Periodic review records (sign-off, date, issues found, remediation tickets)
• Exception register for gaps (event type not supported, compensating control, timeline)

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers:

1. “Show me the list of event types for System X.”
   Hangup: you have generic statements without system-specific capability.

2. “How do you know these events are actually being logged today?”
   Hangup: you documented events but never validated forwarding and visibility.

3. “What triggers updates to the event list?”
   Hangup: no linkage to change management, so the list is stale.

4. “Who owns AU-2, and who fixes gaps?”
   Hangup: unclear accountability across security, IT, and application teams.

5. “How do you handle third-party platforms?”
   Hangup: relying on a third party without defining what logs you need and how you receive them.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating AU-2 as “turn on logging”	AU-2 is about identifying event types and capability	Start with an event catalog and mapping
One global event list for all systems	Capability and risk vary by system	Maintain per-system (or per-system-class) catalogs
No testability	Auditors can’t verify	Add event IDs/categories and sample outputs
Ignoring SaaS/admin plane logs	High-risk actions happen there	Include control plane/admin actions explicitly
No maintenance trigger	Catalog drifts	Tie updates to change management and onboarding

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-2, so this page does not cite enforcement actions.

From a risk standpoint, AU-2 gaps typically surface as:

• Inability to reconstruct incidents (missed events, incomplete coverage)
• Delayed detection because critical actions are not recorded or forwarded
• Audit findings for control design (no defined event types) or operating effectiveness (no evidence logs exist)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and create the catalog)

• Name the AU-2 control owner and define system scope.
• Publish the Event Types Catalog template.
• Pilot the catalog on a small set of high-impact systems (identity, cloud control plane, one critical application).
• Stand up evidence capture: where screenshots/queries/log samples will be stored, with naming conventions.

Days 31–60 (scale coverage and make it testable)

• Expand catalog coverage across remaining in-scope systems.
• Add event-to-source mappings and “how enabled” steps for each required event type.
• Start recurring log presence checks for the pilot systems and open remediation tickets for gaps.
• Add AU-2 checks to change management intake and closure criteria.

Days 61–90 (operationalize and prepare for assessment)

• Complete coverage for all in-scope systems, including third-party platforms where you depend on provider logs.
• Build an exception process for systems that cannot produce required event types, with compensating controls and timelines.
• Run an internal audit-style walkthrough: pick two systems and trace from catalog → configuration → SIEM evidence.
• Move AU-2 tracking into Daydream (or your GRC tool) so ownership, procedures, and recurring evidence are enforced through workflow. ¹

Frequently Asked Questions

Does AU-2 require that I collect or retain logs?

AU-2 focuses on identifying the types of events the system is capable of logging for audit purposes. Retention and protection are covered by other audit/logging controls; AU-2 is the starting point that defines what should exist. ²

Can I have one standard event list for all systems?

You can use a baseline list, but AU-2 expects you to identify event types the specific system can log. A common pattern is a baseline plus per-system overrides with documented rationale.

What counts as “the system” for AU-2 in a cloud environment?

Define the boundary in a way that matches how you operate and assess risk, such as “application + its cloud control plane components” or “the SaaS tenant and its admin interfaces.” Then document event types for that boundary consistently.

How do I handle third-party SaaS where I can’t control logging internals?

Document what the SaaS can produce (admin logs, access logs, API audit logs), how you obtain them (export, API, SIEM integration), and where the gaps are. If required events are not available, record an exception and a compensating measure.

What evidence is most persuasive to an auditor for AU-2?

A system-specific event catalog plus a traceable mapping to log sources, followed by a SIEM query or exported log sample showing the required event types are actually present.

How do I keep AU-2 from becoming a stale spreadsheet?

Tie catalog updates to change management triggers and require post-change validation evidence. A GRC workflow (including Daydream) helps by assigning owners, scheduling evidence, and tracking exceptions to closure. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON