AU-6(4): Central Review and Analysis

AU-6(4) requires you to implement a centralized capability to collect, review, and analyze audit records across multiple system components so security-relevant activity is visible in one place and can be acted on quickly. Operationally, this means defining log sources, routing them to a central platform, running consistent reviews, and retaining proof that reviews happened and issues were tracked to closure. ¹

Key takeaways:

• Centralization is the requirement: auditors will test that multiple components feed a common review and analysis workflow. ¹
• “Capability” means tooling plus procedure: collection, normalization, detection/analysis, escalation, and evidence retention. ²
• The fastest path is a control card + minimum evidence bundle + recurring health checks tied to tickets and outcomes. ¹

AU-6(4): Central Review and Analysis is one of those controls that fails quietly: individual teams may “have logs,” and security may “check alerts,” but you still cannot prove that audit records from key components are centrally reviewed and analyzed as a single operating control. Examiners and customer auditors tend to probe this area because fragmented logging is a common root cause of missed incidents and weak investigations.

For a CCO, GRC lead, or security compliance owner, the operational goal is straightforward: define which components must produce auditable events, ensure those events are routed into a central place where analysis can happen, and then run a repeatable review process with durable evidence. The central platform can be a SIEM, a managed detection platform, or a purpose-built logging pipeline, but it must support cross-component review, correlation, and follow-through.

This page is written to help you turn AU-6(4) into an assignable control: named owner, in-scope systems, step-by-step execution, and an evidence bundle that survives audits and customer diligence. The emphasis is on what to implement and how to prove it operated.

Regulatory text

Requirement (excerpt): “Provide and implement the capability to centrally review and analyze audit records from multiple components within the system.” ¹

What the operator must do:

1. Provide the capability: Stand up or adopt a centralized mechanism that receives audit records from multiple components (not just one server or one application). ¹
2. Implement it in production: Demonstrate that the mechanism is connected to real components, is actually ingesting records, and supports review/analysis workflows. ²
3. Enable review and analysis centrally: Show that people and/or detections can analyze activity across components in a single place (for example, identity + endpoint + cloud control plane + app). ¹

Plain-language translation: if audit records remain scattered across consoles, local files, and team-owned dashboards, you have not met AU-6(4). The requirement expects a central “truth” where investigation and review happen.

Plain-English interpretation (what “central review and analysis” means in practice)

AU-6(4) is not a policy requirement. It is an operational capability requirement. You should be able to answer, with proof:

• Which components generate auditable events, and which event types matter for your environment (authentication, privilege changes, administrative actions, data access, configuration changes).
• Where those events go, centrally.
• How the organization reviews and analyzes them (automated detections plus human review), and how issues become tracked remediation.

Central review also implies cross-component correlation. A reviewer should be able to connect an identity event to an endpoint event to a cloud API call without jumping across four tools and losing context.

Who AU-6(4) applies to

Entity types (typical):

• Federal information systems and programs aligning to NIST SP 800-53 Rev. 5. ²
• Contractors and third parties operating systems that handle federal data and must meet 800-53 control expectations through contracts, ATO packages, or customer flow-down requirements. ²

Operational context:

• Any environment with multiple components that produce audit records: identity provider, endpoints, servers, network devices, cloud control plane, CI/CD, databases, SaaS admin consoles, and security tooling.
• Especially important where teams are segmented (IT, cloud, app, security) and logs naturally fragment by ownership.

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

Use this as a build-and-run checklist. Treat each step as testable.

1) Define scope: which components must feed the central review

Create an “AU-6(4) log source register” for the system boundary:

• Identity (SSO/IdP), privileged access management (if present)
• Cloud control plane (AWS CloudTrail / Azure Activity Logs / GCP Admin Activity)
• Core network/security devices (firewalls, VPN, WAF)
• Endpoints/servers (EDR, OS audit logs)
• Key applications and data stores (admin actions, auth events, sensitive data access)
• CI/CD and code hosting (admin changes, token use, pipeline execution)

Make the register owned: a system owner signs off that the list matches the boundary.

2) Stand up the central collection and normalization path

Implement a central platform and routes:

• Choose the central analysis point (SIEM, centralized logging platform, MDR portal).
• Configure ingestion from each in-scope component.
• Normalize enough fields to support analysis across components (time, actor, source, action, target, result).
• Ensure time sync across components so timelines are defensible during investigations.

Acceptance test: demonstrate that a sampled event from each component appears in the central platform with searchable fields and an identifiable source.

3) Define what “review and analysis” means (minimum operating procedure)

Write a short runbook that answers:

• What gets reviewed (alerts, dashboards, reports, queries).
• Who reviews (named role, on-call function, backup).
• What “analysis” includes (triage, correlation, scoping, decision, escalation).
• How findings become actions (ticketing, incident workflow, change control).
• Exception handling (what happens if a source stops sending logs, or the platform is degraded).

This is where many programs fail: tooling exists, but review is informal and not evidenced.

4) Implement detections and correlation across multiple components

Start with a small detection set that clearly demonstrates cross-component analysis, for example:

• Suspicious login + privileged action within a short window
• New admin role assignment + high-risk configuration change
• Service account token creation + unusual API activity

Your goal is not to catch everything immediately. Your goal is to prove you can centrally analyze multi-component audit records and generate actionable outcomes. ¹

5) Create the evidence bundle (design + operating)

Define a minimum evidence bundle per review cycle:

• Log source register (current version) and ownership
• Ingestion health evidence (source-to-central pipeline status, failures, and remediation)
• Sample central queries/dashboards used for review
• Review output: tickets, cases, or review attestations that show what was checked and what was found
• Escalations: incident records or investigation notes when relevant
• Remediation tracking to closure for gaps (missing logs, broken collectors, noisy detections)

A common pattern: store these artifacts in your GRC system or a controlled evidence repository and link them to the control record.

Daydream can help here by turning AU-6(4) into a requirement-level control card (owner, triggers, steps, exceptions) and by standardizing the evidence bundle so teams stop scrambling during audits.

6) Run control health checks and close gaps

Treat this as a live control:

• Periodically validate that each in-scope component is still sending logs.
• Validate that review is occurring and generating outcomes (even “no findings” should be recorded).
• Track gaps as remediation items with due dates and owners until validated closure.

This aligns to the practical expectation that you can show ownership, cadence, and evidence of operation, not just a one-time implementation. ¹

Required evidence and artifacts to retain (audit-ready)

Keep evidence in two buckets: control design and control operation.

Control design artifacts

• AU-6(4) control card/runbook: objective, owner, scope, trigger events, step-by-step, exceptions.
• System boundary and component inventory that maps to your log source register.
• Architecture diagram: sources → collectors/agents → central platform → alerting/ticketing.
• Role assignments: who reviews, who approves changes to the logging pipeline.

Control operating artifacts

• Central platform screenshots/exports showing ingestion from multiple components (with timestamps and source identifiers).
• Review records: saved queries, scheduled reports, case notes, tickets.
• Alert tuning/changes with approvals (where your change process requires it).
• Evidence of gap remediation: “source stopped logging” ticket, fix, and post-fix validation.

Retention period is typically driven by your broader audit/log retention requirements; AU-6(4) focuses on central review capability and operation rather than specifying a retention duration. ²

Common exam/audit questions and hangups

Expect auditors to ask questions like:

• “Show me all components in scope and prove each sends audit records to the central platform.”
• “Who performs the central review, and how do you prove it happened?”
• “What happens when a log source fails? Show an example ticket.”
• “Can you correlate an identity event to a cloud admin action and to an endpoint event?”
• “Is this system boundary truly centralized, or do you rely on separate team consoles?”

Hangup to anticipate: teams present a SIEM as proof, but cannot demonstrate coverage across multiple components or cannot show review artifacts.

Frequent implementation mistakes (and how to avoid them)

1. Central storage without central review. Fix: require a review output artifact per cycle (ticket, attestation, case log).
2. One “hero” integration, many missing sources. Fix: maintain a log source register and test ingestion source-by-source.
3. No ownership model. Fix: assign an AU-6(4) control owner plus per-source technical owners; document backup coverage.
4. Unsearchable logs. Fix: normalize core fields and enforce time sync so events can be correlated.
5. Alert-only mindset. Fix: add a documented human review path for central dashboards/reports, not just reactive alert handling.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-6(4). What you can still assume during audits: fragmented logging increases the chance you miss policy violations, cannot reconstruct incidents, and cannot prove monitoring was performed. That translates directly into ATO friction, customer diligence failures, and incident response weaknesses. ²

Practical 30/60/90-day execution plan

Use time-boxed phases to move from “we have logs” to “we operate AU-6(4).”

First 30 days (establish control shape)

• Name the AU-6(4) owner and publish the control card/runbook.
• Build the log source register for the system boundary.
• Choose the central platform of record (or confirm the existing one) and document the architecture.
• Onboard a small set of high-value sources (identity + cloud control plane + endpoint) and verify ingestion end-to-end.

Deliverable: control card + log source register + proof that multiple components are ingesting centrally.

Days 31–60 (make it auditable)

• Expand ingestion to remaining in-scope components based on the register.
• Implement baseline correlation/detections that demonstrate multi-component analysis.
• Establish the review workflow: what gets reviewed, by whom, and how outcomes are recorded.
• Define the minimum evidence bundle and where it is stored.

Deliverable: first completed review cycle with evidence (queries/reports + tickets/cases + any remediation items).

Days 61–90 (stabilize and prove sustained operation)

• Add ingestion health checks and failure handling (ticket automation, alerts for dropped sources).
• Tune detections and reduce noise so the review process is sustainable.
• Run a control health check and close the first round of gaps to validated closure.
• Prepare an audit walkthrough: “source register → central ingestion → review outputs → remediation.”

Deliverable: repeatable operation with at least two cycles of review evidence and closed-loop remediation.

Frequently Asked Questions

Does AU-6(4) require a SIEM?

The control requires a centralized capability to review and analyze audit records from multiple components, not a specific product category. A SIEM is a common way to meet the requirement if it supports ingestion and central analysis workflows. ¹

What counts as “multiple components”?

Any distinct parts of the system that generate audit records, such as identity, cloud control plane, endpoints, applications, databases, and network/security devices. Auditors typically expect more than one source type and evidence that the sources are centrally reviewable together. ¹

If we have an MDR provider, are we done?

Only if the MDR workflow is truly central for your in-scope components and you can retain evidence of review, analysis, and follow-through. Ask your provider for ingest coverage, case outputs, and proof of gap handling so you can defend the control. ²

What evidence is strongest for audits?

Source-to-central ingestion proof for each component, plus review artifacts that show what was analyzed and what actions resulted (tickets, cases, incident records). Evidence that you remediated missing logs or broken pipelines is often the difference between “designed” and “operating.” ¹

How do we handle systems we cannot centrally log (legacy or third-party hosted)?

Document the exception, define compensating monitoring (where feasible), and track a remediation plan to reduce the gap. Auditors will focus on whether you identified the gap, approved it, and can show a path to closure or an accepted risk decision. ²

How should this map into a GRC tool like Daydream?

Create a requirement-level control record with an owner, scope, and a recurring review task, then attach the minimum evidence bundle per cycle. The goal is one place to prove operation: ingestion coverage, review outputs, and remediation closure tied back to AU-6(4). ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5