AU-2(2): Selection of Audit Events by Component

AU-2(2) requires you to select and document audit event types at the component level (for example, identity system, database, firewall, application) so each part of the system logs the right security-relevant activity for its role. Operationalize it by building a component-to-event logging matrix, configuring each component accordingly, and retaining evidence that settings match the documented selection. ¹

Key takeaways:

• You need a defensible, documented rationale for what each component logs, not a single generic “enable logging” statement.
• Evidence is configuration-level: show what events are turned on per component and how you review/maintain those choices.
• Treat cloud and third-party-managed components as in-scope; contract and verify logging responsibilities.

The fastest way to fail AU-2(2) in an assessment is to treat audit logging as one global switch. Assessors expect you to show that different components generate different audit trails based on what they do and the risks they create. A domain controller, an IAM service, a database, a container orchestrator, and a WAF should not all log the same things, at the same fidelity, or with the same triggers.

The operational problem AU-2(2) solves is simple: if you do not decide audit events per component, your logs become either too thin to support investigations or so noisy that security monitoring cannot detect real issues. AU-2(2) pushes you into a design discipline: identify the components that matter, decide what each must log, configure them to log it, and keep that decision current as systems change. ¹

This page translates AU-2(2): selection of audit events by component requirement into an implementable checklist, evidence set, and execution plan a Compliance Officer, CCO, or GRC lead can run with.

Regulatory text

Control excerpt: “NIST SP 800-53 control AU-2.2.” ²

Operator interpretation: AU-2(2) is the enhancement that drives granularity: you don’t just define “auditable events” for the system; you define them for each system component and ensure configurations match. In practice, that means:

• You maintain an inventory of auditable components (not just “apps”).
• You specify event categories per component (authn/authz, admin actions, configuration changes, data access, security detections, etc.).
• You implement component-specific logging settings and keep evidence of those settings.
• You update selections when components, threats, or mission/business processes change. ¹

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

AU-2(2) requires deliberate choices: for each component, decide which events it must log so you can detect misuse, support investigations, and satisfy oversight. If you cannot explain why a component logs what it logs (and why it does not log other things), you are exposed.

A workable mental model is: components generate “audit signals” that must be sufficient for reconstruction. You are building a case file in advance.

Who it applies to

Entity context

• Federal information systems and organizations implementing NIST SP 800-53 controls. ¹
• Contractors and service providers handling federal data where NIST SP 800-53 is flowed down through contracts, ATO packages, or customer requirements. ¹

Operational context

• Hybrid environments (on-prem + cloud).
• Systems with shared responsibility boundaries (SaaS, PaaS, managed services).
• High-change environments (CI/CD, containers, serverless) where components can appear and disappear quickly.

If you run a multi-tenant platform, treat tenant-boundary components (identity, authorization, key management, admin consoles) as the first-class AU-2(2) focus because they define “who did what.”

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

Step 1: Define “component” for your environment

Write down your component taxonomy so you don’t argue during the audit. Typical component groups:

• Identity and access (IdP, MFA, PAM, directory services)
• Compute (VMs, containers, serverless runtime)
• Network/security (firewalls, WAF, VPN, DNS, load balancers)
• Data layer (databases, object storage, data warehouses)
• Application layer (APIs, web apps, background workers)
• Management plane (cloud control plane, orchestration, CI/CD, config management)
• Endpoint and admin tooling (jump boxes, bastions, EDR consoles)

Deliverable: Component scope statement aligned to your system boundary. ¹

Step 2: Build a component-to-audit-event selection matrix

Create a matrix with rows = components and columns = required event types. Keep it short enough to operate but specific enough to configure. A practical set of columns:

• Authentication events (success/failure, MFA challenges, token issuance)
• Authorization/privilege events (role changes, policy changes, access denials)
• Administrative actions (create/modify/delete accounts, service principals, keys)
• Configuration changes (security group rules, firewall policies, logging settings)
• Data access (read/write/delete of sensitive datasets; export actions)
• Security detections (WAF blocks, EDR alerts, IDS findings)
• System integrity events (agent health, time sync issues, log pipeline failures)

Add two mandatory fields per row:

1. Rationale (why these events matter for that component)
2. Log destination (SIEM, central log store, ticketing, or both)

Deliverable: AU-2(2) audit event selection matrix with owner and review cadence defined. ¹

Step 3: Map each selection to an implementation method

For each component row, record:

• Configuration location (console path, policy name, agent config file, SaaS admin setting)
• Enablement mechanism (IaC module, GPO, MDM, cloud policy, API call, vendor setting)
• Change control trigger (what forces re-validation)

This is where teams usually break: they have a policy but no “how.” Your assessor will ask for the “how.”

Deliverable: Component logging procedures (runbooks) tied to the matrix. ¹

Step 4: Implement and validate logging per component

Execute enablement and then validate end-to-end:

• Generate a test event (failed login, role change, firewall rule update).
• Confirm the event appears in the central destination with required fields (timestamp, actor, target, action, result).
• Confirm time synchronization and source identification are consistent enough to correlate.

Deliverable: Validation records (test scripts, screenshots, sample log entries, SIEM queries). ¹

Step 5: Operationalize maintenance (drift control + change events)

AU-2(2) fails over time if drift goes unmanaged. Put three mechanisms in place:

• Change-driven review: new component added, major version upgrade, new integration, new sensitive dataset.
• Monitoring-driven review: log pipeline health alerts, missing logs, sudden drop in event volume.
• Periodic review: refresh the matrix and confirm configurations still match documented selections.

Deliverable: Review workflow with tickets, approvals, and documented outcomes. ¹

Step 6: Handle third-party-managed and cloud components explicitly

For SaaS/PaaS and managed services:

• Document what the provider logs vs what you can log.
• Turn on the provider’s audit logs (admin actions, access logs) where available.
• Contract for access to audit logs and retention aligned to your program needs.
• Validate ingestion into your log platform.

Deliverable: Shared responsibility logging addendum per critical third party. ¹

Practical note: Daydream is useful here because the control often breaks at the seams between GRC documentation, cloud configuration, and third-party commitments. A requirement page mapped to an owner, procedure, and recurring evidence artifacts reduces “policy-only” drift and keeps audit readiness continuous.

Required evidence and artifacts to retain

Keep evidence that proves selection, implementation, and ongoing control:

1. AU-2(2) audit event selection matrix (approved, versioned)
2. System component inventory within the authorization boundary
3. Logging configuration evidence per component, such as:
   • Policy exports or screenshots (cloud audit log settings, IAM audit settings)
   • Agent configs (EDR/OS audit settings)
   • Database auditing settings
4. Central logging ingestion proof
   • SIEM/log platform queries showing events from each component
   • Log source onboarding records
5. Validation/test artifacts
   • Test cases and results demonstrating key events appear end-to-end
6. Change and review records
   • Tickets/CRs showing updates to event selection or configuration
   • Exceptions with compensating controls and expiration dates ¹

Common exam/audit questions and hangups

Expect these questions in a NIST-based assessment:

• “Show me how you decide which events each component audits.” (Matrix + rationale)
• “Pick three critical components and prove they’re configured as documented.” (Config exports + live queries)
• “How do you ensure new components inherit required audit settings?” (Onboarding checklist + IaC standards)
• “What happens when logging breaks?” (Alerting, incident workflow, backlog handling)
• “Where are SaaS admin actions logged, and who reviews them?” (Provider audit logs + ingestion + review record)

Hangup: assessors often reject “we log everything.” They want selected events that match the component’s risk and function, plus proof you can operate that selection. ¹

Frequent implementation mistakes (and how to avoid them)

1. Single generic policy, no component mapping

• Fix: publish the matrix and link every row to a config method and owner.

2. Ignoring the management plane

• Fix: treat cloud control plane logs, CI/CD admin actions, and secrets manager events as first-tier sources.

3. No evidence of validation

• Fix: maintain a repeatable test pack: “generate event, find it in SIEM, record query.”

4. SaaS audit logs left off by default

• Fix: add a third-party onboarding step: “enable provider audit logs + confirm export.”

5. Drift after changes

• Fix: require logging controls in IaC modules and enforce them via code review and policy-as-code where possible. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-2(2). Operational risk still matters: weak or inconsistent component logging increases incident response time, complicates root cause analysis, and can make it hard to demonstrate control operation during customer audits and federal assessments. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Assign a control owner and component owners (IAM, cloud, network, app, data).
• Define your component taxonomy and system boundary for audit logging.
• Draft the audit event selection matrix for the highest-risk components first (identity, management plane, data stores).
• Identify log destinations and confirm you have access to required logs (including third-party platforms). ¹

Days 31–60 (implement and prove)

• Configure logging per the matrix for in-scope components.
• Onboard each component as a distinct log source in the central platform.
• Run validation tests and save artifacts (queries, screenshots, sample events).
• Write short runbooks for each component family: “how to enable, how to test, how to monitor.” ¹

Days 61–90 (operationalize and harden)

• Add change-control triggers: new components, major upgrades, new sensitive datasets.
• Implement drift checks (scheduled config reviews or automated policy checks).
• Formalize exceptions, expiration, and compensating controls.
• Run a tabletop: simulate an incident and confirm logs support reconstruction across multiple components. ¹

Frequently Asked Questions

What counts as a “component” for AU-2(2)?

Any distinct part of the system that can generate audit records or must be monitored independently, including cloud control planes, IAM, databases, CI/CD, and security tools. Define your taxonomy and apply it consistently across the authorization boundary. ¹

Do we have to log the same events on every server and application?

No. AU-2(2) expects event selection by component, so event types should match what that component does and the risks it introduces. Your matrix and rationale are how you show the selection is intentional. ¹

How do we handle SaaS products where we can’t configure deep logging?

Enable whatever audit logging the provider offers (admin actions, access logs) and document the shared responsibility boundary. If logs are limited, document compensating monitoring and contract for the audit data you need where possible. ¹

What evidence is strongest for auditors?

A versioned component-to-event matrix plus configuration exports or screenshots that show those events are enabled, backed by SIEM queries that demonstrate real events arriving. Pair that with review tickets that show ongoing upkeep. ¹

How often do we need to review the component event selections?

Tie review to change: new components, major config changes, new data flows, or new threat findings should trigger an update. Add a periodic review as a backstop and retain the review record. ¹

Where does Daydream fit in operationalizing AU-2(2)?

Use Daydream to keep AU-2(2) tied to an accountable owner, a documented procedure, and a recurring evidence list, so your matrix, configs, and validations stay aligned as systems and third parties change. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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