AU-2(3): Reviews and Updates

AU-2(3): Reviews and Updates requires you to periodically review your audit event selection and related logging configuration, then update it when your mission, risk, system design, or threats change. Operationally, you need a scheduled review cadence, clear ownership, change triggers, and evidence that each review produced decisions and resulting configuration or documentation updates. (NIST SP 800-53 Rev. 5)

Key takeaways:

• Treat AU-2(3) as a living “what we log and why” review, not a one-time logging setup. (NIST SP 800-53 Rev. 5)
• Define review triggers (system changes, incidents, new data types, new third parties) and document the outcome every time. (NIST SP 800-53 Rev. 5)
• Evidence matters: retain review minutes, updated event lists, logging config change records, and approvals tied to each update. (NIST SP 800-53 Rev. 5)

AU-2 in NIST SP 800-53 sits in the Audit and Accountability (AU) family. The (3) enhancement, “Reviews and Updates,” is where most teams get tripped up during assessments because they can show that logging exists, but cannot show that logging choices are actively governed. Assessors typically want proof that you revisit audit event selection as the system evolves, and that you can explain why you log certain events, where they are collected, and how updates are controlled.

For a CCO, GRC lead, or compliance officer, the operational goal is straightforward: establish a repeatable mechanism to review audit event requirements, record decisions, and push updates into actual system configurations and procedures. This page gives you requirement-level implementation guidance you can assign to control owners, build into change management, and evidence quickly for audits.

Where teams struggle is not tooling. The failure mode is “set it and forget it” logging, unclear ownership between security and engineering, and missing artifacts that connect reviews to concrete changes. AU-2(3) is your forcing function to close that gap. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (framework excerpt): “NIST SP 800-53 control AU-2.3.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do: implement a governed process to review audit event selection and update it as needed. In practice, that means:

• You maintain an explicit list of auditable events (your “audit event catalog” for the system).
• You periodically reassess whether the list is still correct given changes in risk, architecture, data, third parties, and threat activity.
• You convert review outcomes into controlled updates: logging pipeline configuration, alerting rules, onboarding of new log sources, or documented rationale for “no change.”
• You retain evidence showing reviews occurred, who approved decisions, and what changed. (NIST SP 800-53 Rev. 5)

Plain-English interpretation (what AU-2(3) is really testing)

AU-2(3) tests whether your audit logging program is managed, not merely present. If the system adds a new authentication path, integrates a new third party identity provider, moves workloads, or starts handling a new category of sensitive data, your audit event selection should adapt. Your process must also catch gaps where you log the wrong things (too little for investigations, too much for privacy, or too noisy to monitor).

Who it applies to

Entity types:

• Federal information systems
• Contractor systems handling federal data (for example, systems supporting federal contracts where NIST 800-53 is in scope) (NIST SP 800-53 Rev. 5)

Operational context (where AU-2(3) shows up):

• Central logging / SIEM programs
• Cloud-native audit logging (cloud control plane logs, application logs, identity logs)
• Incident response and forensics readiness
• Change management and release engineering
• Third party integrations that affect authentication, authorization, data flows, or administrative access

Ownership usually spans security engineering (logging pipeline), platform/IT (log sources), application teams (app-level events), and GRC (governance, cadence, evidence).

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

Step 1: Name a control owner and define review scope

1. Assign a primary owner (role, not person) responsible for AU-2(3) execution and evidence packaging.
2. Define the scope boundary: which systems, environments, and log sources are in-scope for the review (production only vs. also staging; control plane vs. application).
3. Document interfaces: which teams must attend reviews and who can approve changes (security, engineering, product, privacy). (NIST SP 800-53 Rev. 5)

Practical tip: If you can’t name the approver for adding or removing an auditable event, you will fail the “updates” part even if you log everything.

Step 2: Build or refresh your “Audit Event Catalog” for the system

Create a table that becomes the backbone artifact for AU-2(3). Minimum fields:

• Event category (authentication, privileged actions, data access, admin changes, configuration changes)
• Specific event(s) and where generated (application, OS, database, cloud service, identity provider, third party)
• Log source and collection method (agent, API, native integration)
• Retention destination(s) (central logging, immutable store)
• Rationale (risk/mission justification)
• Alerting/monitoring linkage (if applicable)
• Data sensitivity notes (avoid logging secrets; privacy constraints)
• Owner and last review date (NIST SP 800-53 Rev. 5)

Step 3: Define review triggers (the “update” forcing functions)

Write down triggers that require an AU-2(3) review outside the normal cadence. Common triggers:

• Major release or architecture change (new services, new auth path, new logging framework)
• Identity or access changes (SSO provider change, MFA rollout, privileged access tooling)
• New third party integrations that touch regulated data or admin access
• Incident, near miss, or detection gap identified in tabletop or real response
• New data types, new tenancy model, or new regulated workload within the system boundary (NIST SP 800-53 Rev. 5)

Then embed these triggers into change management and incident postmortems so reviews happen without heroics.

Step 4: Run the review meeting using a tight checklist

Use a repeatable agenda. Keep it evidence-friendly:

1. Confirm system boundary and major changes since last review.
2. Walk the audit event catalog and flag: missing events, low-value noise, duplicative sources, or privacy risks.
3. Confirm log collection health: onboarding status, parsing quality, and access controls to logs.
4. Decide outcomes: add/remove events, adjust verbosity, add new source, update alerts, update documentation, or “no change with rationale.”
5. Assign actions with owners and due dates, and link to tickets/changes. (NIST SP 800-53 Rev. 5)

Step 5: Implement updates through controlled change

For each approved change:

• Create a change record (ticket, pull request, infrastructure-as-code change, SIEM connector change).
• Capture approvals.
• Validate post-change: confirm events are arriving, correctly parsed, and searchable.
• Update the audit event catalog and any related SOPs/runbooks. (NIST SP 800-53 Rev. 5)

Step 6: Package evidence continuously (don’t scramble before the audit)

Store artifacts in a control evidence repository mapped to AU-2(3). Daydream is a natural fit here because teams typically need a single place to map AU-2(3) to an owner, an implementation procedure, and recurring evidence artifacts, then track completion over time. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Assessors usually want to see both governance proof and technical proof.

Governance artifacts

• AU-2(3) procedure: how reviews are initiated, who attends, approval path, and documentation standard (NIST SP 800-53 Rev. 5)
• Review schedule and/or trigger definition (embedded in change management / IR processes)
• Meeting minutes or review memos showing decisions and rationale
• Updated audit event catalog with version history and “last reviewed” marker

Technical artifacts

• Logging architecture diagram (high level is fine)
• Samples of relevant log entries (redacted as needed)
• SIEM/log platform configuration exports (connectors, rules, parsers) where feasible
• Change records: tickets/PRs, approvals, and implementation notes tied to review outcomes (NIST SP 800-53 Rev. 5)

Common exam/audit questions and hangups

Use these to pre-brief control owners.

What auditors ask	What they’re really testing	What to show
“How do you decide what events are auditable?”	Existence of a defined event selection process	Audit event catalog with rationale (NIST SP 800-53 Rev. 5)
“When was this last reviewed?”	AU-2(3) cadence and governance	Review memo + catalog version showing review date (NIST SP 800-53 Rev. 5)
“What changed as a result of the last review?”	Updates are real, not performative	Linked change tickets/PRs + post-change validation proof (NIST SP 800-53 Rev. 5)
“What triggers an out-of-cycle review?”	Responsiveness to change and risk	Trigger list embedded in change/IR workflows (NIST SP 800-53 Rev. 5)
“Who approves removing an event?”	Preventing logging regression	Approval workflow + rationale for removals (NIST SP 800-53 Rev. 5)

Frequent implementation mistakes (and how to avoid them)

1. Only reviewing the SIEM, not the event requirements. A connector inventory is not an audit event catalog. Maintain the “what and why” list, then map tooling to it. (NIST SP 800-53 Rev. 5)
2. No documented outcomes. Teams hold a meeting but can’t prove decisions. Write a short decision memo every time, even for “no change.” (NIST SP 800-53 Rev. 5)
3. Updates bypass change control. Logging changes pushed ad hoc are hard to evidence and easy to break. Route updates through tickets/PRs and keep approvals. (NIST SP 800-53 Rev. 5)
4. Ignoring privacy and sensitive data. Over-logging can create compliance issues if secrets or regulated data land in logs. Add a privacy check to the review checklist. (NIST SP 800-53 Rev. 5)
5. Unclear ownership across app and platform teams. Fix by assigning “event owners” per domain (identity, database, application) and a single AU-2(3) coordinator. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite specific actions. Practically, weak AU-2(3) execution increases operational and compliance risk: investigations take longer, incident scope is harder to prove, and you can’t demonstrate consistent control operation during assessments. (NIST SP 800-53 Rev. 5)

Practical execution plan (30/60/90-day)

The requirement doesn’t mandate a specific timeline, so treat this as an execution playbook rather than a regulatory deadline. (NIST SP 800-53 Rev. 5)

First 30 days (Immediate)

• Assign AU-2(3) owner and define system boundary for the review.
• Draft the audit event catalog and align it to major risk areas (authn/authz, privileged actions, configuration changes, sensitive data access).
• Define triggers and embed them into change management intake questions and incident postmortem templates.
• Stand up an evidence folder or Daydream control record with required artifacts and owners. (NIST SP 800-53 Rev. 5)

Days 31–60 (Near-term)

• Run the first formal AU-2(3) review and produce a decision memo.
• Execute the highest-risk logging gaps as controlled changes (new sources, new events, improved parsing).
• Add a lightweight validation step: confirm events arrive and are searchable after each change.
• Update runbooks for responders so they know where to find the logs you claim to collect. (NIST SP 800-53 Rev. 5)

Days 61–90 (Ongoing operating rhythm)

• Run a second review or an out-of-cycle review if a trigger occurs, to prove repeatability.
• Normalize metrics you can show qualitatively (for example, “connector health checks exist,” “alerts mapped to key events exist”) without inventing numeric claims.
• Lock in quarterly (or appropriate) governance: agenda template, attendee list, approval path, and evidence packaging checklist. (NIST SP 800-53 Rev. 5)

Frequently Asked Questions

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

A review is a documented decision event where you evaluate the audit event catalog against current system risk and changes, then record outcomes and approvals. A calendar invite without minutes and resulting updates usually won’t satisfy assessors. (NIST SP 800-53 Rev. 5)

Do we have to change our logging every time we review?

No. You need evidence that the review occurred and that you made an explicit decision. “No change” is acceptable if you document rationale and confirm assumptions (system changes, threats, and data flows). (NIST SP 800-53 Rev. 5)

How do we tie AU-2(3) to engineering change management?

Add review triggers to your change intake (for example, new auth flows, new third party integrations, new sensitive data paths) and require a link to the audit event catalog update when relevant. Then retain the ticket/PR trail as evidence. (NIST SP 800-53 Rev. 5)

What’s the minimum artifact set to keep auditors moving?

Keep an audit event catalog with last reviewed date, a recurring review memo template, and linked change records showing updates were implemented and approved. Store samples or screenshots that prove logs are generated and collected. (NIST SP 800-53 Rev. 5)

How do we handle third party services where we can’t control the log format?

Document the event requirement, what the third party provides, and compensating steps (API exports, native audit logs, contract terms, or monitoring). The AU-2(3) review should explicitly revisit third party logging limits after changes or incidents. (NIST SP 800-53 Rev. 5)

Where does Daydream fit without turning this into a tooling project?

Use Daydream as the control system of record: map AU-2(3) to a named owner, a review procedure, and recurring evidence requests, then track review completion and store artifacts with clear versioning. Keep engineering work in your existing ticketing and IaC workflows. (NIST SP 800-53 Rev. 5 OSCAL JSON)