AU-6(3): Correlate Audit Record Repositories

AU-6(3) requires you to analyze and correlate audit records across different repositories so security and compliance teams can detect cross-system activity and maintain organization-wide situational awareness. Operationally, this means normalizing key log fields, centralizing or federating search, running defined correlation rules, and retaining evidence that correlation occurs on a recurring basis. ¹

Key takeaways:

• Correlation is a control activity, not a tool purchase; define rules, ownership, cadence, and evidence.
• You must correlate across repositories (cloud, endpoint, identity, network, apps), not within a single log platform.
• Auditors look for repeatable operation: runbooks, sample correlated detections, case records, and remediation tracking.

AU-6(3): Correlate Audit Record Repositories sits in the NIST 800-53 Audit and Accountability (AU) family and is aimed at a familiar failure mode: logs exist, but they are fragmented across teams and tools, so nobody can reconstruct what happened end-to-end. The control’s requirement is short, but the operational bar is not. You need a defined method to analyze and correlate audit records across different repositories, and you need to show that the method runs in practice, not only on paper. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AU-6(3) as a requirement you can “control-card” into existence: name an owner, define the repositories in scope, set correlation objectives, specify the correlation rules or use cases, document the execution cadence, and standardize the evidence bundle. Then test it with a few concrete incident-reconstruction scenarios (for example: “suspicious admin login → privilege change → data access → outbound transfer”) that force cross-repository correlation.

This page is written to help you operationalize AU-6(3) quickly: what it means, who it applies to, how to implement it step-by-step, what evidence to retain, and where audit reviews usually get stuck.

Regulatory text

Requirement (AU-6(3)): “Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.” ¹

Operator interpretation (what you must do):

1. Identify “different repositories” in your environment (examples: cloud provider logs, endpoint telemetry, identity provider logs, network/security device logs, application audit logs, database logs, EDR, email security).
2. Perform analysis that correlates events across those repositories, so you can see multi-step activity spanning systems.
3. Demonstrate situational awareness outcomes: correlation should support detection, investigation, and reporting across the organization, not just within a single team’s tool. ¹

NIST’s control text does not prescribe a specific architecture (SIEM vs. data lake vs. federated search) or a specific set of correlation rules. That flexibility increases your burden to document what “correlate” means in your environment and to preserve evidence that you do it consistently. ¹

Plain-English requirement: what “correlate repositories” means in practice

Correlation means you can connect related activity that is logged in separate places into one investigative thread. Typical joins include:

• Identity to endpoint: a user signs in (IdP) and shortly after a process executes (EDR).
• Endpoint to cloud: a workstation token is used to access a cloud console (cloud audit logs).
• Privilege to data access: a role change (IAM/audit) precedes access to sensitive records (DB/app logs).
• Admin action to configuration drift: an admin changes firewall rules (network device logs) and outbound traffic patterns shift (network telemetry).

A practical definition that stands up in exams: “We have a documented set of cross-source correlation use cases, implemented as queries/rules, that run on a defined cadence or continuously in our monitoring stack; we track resulting alerts/cases and verify log sources remain connected and normalized.”

Who it applies to

AU-6(3) commonly applies when you have to align to NIST SP 800-53, including:

• Federal information systems implementing NIST 800-53 controls. ¹
• Contractor systems handling federal data, including environments where customers or primes require NIST 800-53-aligned controls in security requirements, system security plans, or supplier security addenda. ¹

Operationally, it applies anywhere you have multiple log-producing platforms and more than one team with partial visibility (cloud team, IT, SecOps, app engineering, data team). If your logging is centralized but correlation is ad hoc, you still have an AU-6(3) gap because “centralized storage” is not the same as “correlated analysis.”

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

1) Create a control card (owner, objective, cadence, exceptions)

Write a one-page “requirement control card” that includes:

• Objective: organization-wide situational awareness through cross-repository audit correlation. ¹
• Control owner: usually Head of Security Operations, Detection Engineering, or Security Engineering; GRC is accountable for evidence quality.
• In-scope repositories: list the authoritative log sources and their owners.
• Execution model: continuous correlation rules plus scheduled reviews, or scheduled correlation runs if you lack a SOC.
• Exception rules: how you handle systems that cannot log, cannot export, or are isolated. Require documented risk acceptance and compensating monitoring.

This directly addresses a common audit failure: teams cannot show who owns the requirement, how often it runs, or which evidence proves it is operating. ¹

2) Inventory repositories and define “minimum viable correlation”

Build a log repository inventory with these fields:

• System / platform
• Log types available
• Transport method (agent, API, syslog, export job)
• Retention location
• Data classification considerations
• Parsing status (normalized fields vs raw)

Then define a small set of cross-repository correlation “must-haves” tied to your threat model and audit scope, for example:

• Identity sign-in anomalies joined with privileged role changes
• New service principal or API key creation joined with data access logs
• Endpoint malware detection joined with lateral movement indicators

Keep the initial scope tight; expand after you can prove repeatable operation.

3) Normalize fields needed for joining events

Correlation fails when fields do not match across sources. Define and implement normalization for:

• Actor: user ID, service account, workload identity
• Asset: hostname, instance ID, container/workload ID
• Time: consistent timestamps and time zones
• Action: event name/category
• Outcome: success/failure, allow/deny
• Source: repository name, product, environment (prod/dev)

Your evidence should show mapping standards (a data dictionary or field-mapping doc) and examples of parsed events from each repository.

4) Implement correlation rules and document the “how”

Whether you use a SIEM, security data lake, XDR, or federated search:

• Create named correlation rules/use cases with:
  • Purpose and risk addressed
  • Data sources required
  • Query/rule logic (stored in the tool and exported for evidence)
  • Tuning notes and known false positives
  • Severity/triage routing

Include at least one multi-hop correlation (more than two sources) to demonstrate organization-wide visibility, not pairwise joining only.

5) Operationalize: triage, escalation, and feedback loops

Correlation that triggers alerts but never gets triaged will not survive scrutiny. Define:

• Alert routing (queue, on-call rotation, ticketing integration)
• Triage steps (what to check first, what to enrich with)
• Escalation criteria (legal, privacy, IR lead, system owner)
• Post-incident feedback (rule tuning, missing logs, parsing fixes)

Track remediation items to closure (missing logs, broken connectors, parsing gaps). This supports sustained operation. ¹

6) Prove it works with a repeatable “correlation drill”

Run a tabletop-plus-log drill using realistic scenarios:

• “Compromised credentials used from unusual geo → MFA fatigue → privileged role grant → access to sensitive app → unusual outbound traffic”
• “New admin API key created → used from CI runner → unusual S3 bucket reads → bulk download alert”

Capture the timeline across repositories and store it as evidence. This is persuasive in audits because it demonstrates situational awareness outcome, not just configuration.

Required evidence and artifacts to retain

Treat evidence as a minimum bundle you can produce quickly for an auditor, customer, or internal risk committee.

Design-time artifacts

• AU-6(3) control card: owner, scope, cadence, exceptions. ¹
• Repository inventory and data-flow diagram (sources → collection → correlation → alerting).
• Field normalization standard / logging schema mapping.
• Correlation use case catalog (names, purpose, sources, routing).

Run-time (operational) artifacts

• Exported correlation rules/queries and change history (PRs, approvals, tool audit trails).
• Samples of correlated alerts/cases showing multi-repository enrichment (redact sensitive content as needed).
• Triage tickets and closure notes tied back to correlation rules.
• Control health checks: connector status, parsing failures, ingestion gaps, rule firing and tuning notes. ¹
• Exceptions: risk acceptance and compensating controls for systems not integrated.

Retention note Store evidence in a controlled repository with access control and a clear naming convention. Auditors commonly fail teams for “we have it somewhere in Slack.”

Daydream fits cleanly here as the system of record for the AU-6(3) control card, the evidence checklist per run cycle, and the remediation tracker that proves sustained operation without hunting across tools.

Common exam/audit questions and hangups

What auditors ask

• “Which repositories are in scope, and who owns each?”
• “Show me a correlation rule that joins identity and cloud audit logs.”
• “How do you know correlation runs consistently?”
• “What happens when a log source stops ingesting?”
• “Show one investigation timeline built from multiple repositories.” ¹

Hangups that slow reviews

• Over-reliance on “we have a SIEM” with no documented use cases.
• Correlation logic exists but cannot be exported or is not under change control.
• No proof of triage; alerts exist but no cases, no tickets, no decisions.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating central log storage as correlation.
   Fix: maintain a use case catalog with cross-source rules and sample outputs.

2. Mistake: Ingesting everything, correlating nothing.
   Fix: define a small set of high-value correlations tied to privileged activity and sensitive data access first.

3. Mistake: Missing identity resolution across systems.
   Fix: standardize actor identifiers and document mapping for service accounts and workload identities.

4. Mistake: No operational ownership.
   Fix: assign a named owner and backup, document triage steps, and track health checks and remediation. ¹

5. Mistake: Evidence scattered across tools with no “audit packet.”
   Fix: pre-assemble an AU-6(3) evidence bundle template and store each period’s artifacts in a single folder location.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-6(3). The practical risk is still clear: without cross-repository correlation, you cannot reliably detect lateral movement, privilege misuse, or multi-step data exfiltration patterns that only become visible when events are stitched together across identity, endpoint, cloud, and application layers. ¹

For regulated customers and federal-aligned assessments, the most common negative outcome is an assessment finding framed as “log correlation not implemented” or “situational awareness not demonstrated,” which then drives corrective action plans and increased oversight.

Practical 30/60/90-day execution plan

Because this requirement page cannot cite a source-backed timeline, treat the phases below as sequenced work, not duration promises.

Phase 1: Immediate (establish control ownership and scope)

• Publish the AU-6(3) control card with owner, in-scope repositories, and evidence bundle checklist. ¹
• Inventory repositories and confirm log access paths and owners.
• Pick an initial set of correlation use cases tied to privileged identity actions and sensitive data access.

Phase 2: Near-term (implement correlations and prove operations)

• Normalize required join fields across the chosen repositories.
• Implement correlation rules/queries and route outputs into ticketing or case management.
• Run a correlation drill and save the investigation timeline as evidence.
• Start a recurring control health check and a remediation tracker for ingestion/parsing gaps. ¹

Phase 3: Ongoing (scale coverage and mature change control)

• Expand repository coverage (more apps, more cloud services, SaaS audit logs).
• Add detection engineering hygiene: tuning notes, version control, approvals for rule changes.
• Add executive reporting: correlation coverage by repository and open gaps by risk priority.
• Periodically revalidate correlations with drills, especially after platform changes.

Frequently Asked Questions

Do we need a SIEM to meet AU-6(3)?

No specific tool is mandated. You need a repeatable method to analyze and correlate audit records across repositories and produce evidence that it operates. ¹

What counts as “different repositories”?

Separate authoritative log stores or platforms, such as identity logs, cloud provider audit logs, endpoint telemetry, network/security device logs, and application audit logs. The key is that correlation crosses boundaries that teams or tools usually manage separately. ¹

How do we show “organization-wide situational awareness” to an auditor?

Provide at least one end-to-end investigation timeline built from multiple repositories, plus the documented correlation rules and the tickets/cases those rules generated. This demonstrates you can reconstruct events across systems. ¹

What evidence is most persuasive during an assessment?

A tight evidence packet: control card, repository inventory, correlation use case catalog, exports of active rules, and a handful of correlated case records with triage outcomes. Auditors want proof of operation, not screenshots of dashboards.

How do we handle systems that cannot send logs to the central platform?

Document an exception with scope, rationale, compensating monitoring, and an expiration date or revisit trigger. Keep the exception and approval as part of the AU-6(3) evidence bundle. ¹

Our logs are centralized, but different teams own detections. Is that a problem?

It can be if no one can prove cross-repository correlation runs consistently. Assign a single control owner and require a shared catalog of correlation use cases with consistent evidence collection. ¹

Footnotes

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