AU-6(3): Correlate Audit Record Repositories

To meet the au-6(3): correlate audit record repositories requirement, you must analyze and correlate audit records across different log repositories so your security team can detect cross-system activity and achieve organization-wide situational awareness (NIST SP 800-53 Rev. 5 OSCAL JSON). Operationalize it by centralizing or federating logs, normalizing identities and timestamps, running correlation rules, and retaining evidence that correlations occur and produce triageable outcomes.

Key takeaways:

• AU-6(3) expects cross-repository correlation, not isolated log review (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Passing assessments depends on repeatable procedures + evidence, not tool names.
• Your fastest path is a defined scope of repositories, a normalization standard, and documented correlation use cases tied to response workflows.

AU-6(3) sits in the NIST SP 800-53 Audit and Accountability family and focuses on a practical problem: attackers and failures rarely stay inside one system. If your Windows logs, cloud control plane logs, application logs, and third-party service logs are reviewed separately, you can miss the story that only appears when events are connected (for example, the same identity used across VPN, SSO, and a sensitive database).

The requirement is short, but assessors tend to probe it deeply because correlation is where logging becomes detection. “Correlation” can mean a SIEM with rules, a data lake with analytics, or a managed detection platform. What matters is that you can show (1) you ingest audit records from defined repositories, (2) you normalize key fields so joining is possible, (3) you run correlation analyses on an ongoing basis, and (4) you route results into a workflow where someone can act.

This page gives requirement-level implementation guidance you can put into a control narrative, a runbook, and an evidence binder quickly, with a focus on scope, operational steps, and what auditors ask for.

Regulatory text

Requirement (excerpt): “Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: You need a defined, repeatable way to connect audit events across separate log stores (on-prem, cloud, SaaS, security tools) so you can see multi-step activity spanning systems. “Situational awareness” is the outcome; correlation is the method. Assessors will look for proof that correlation happens in operations, not just that logs exist.

Plain-English interpretation (what AU-6(3) really demands)

AU-6(3) requires more than “we have a SIEM.” It expects that your program can answer cross-system questions such as:

• Did the same user authenticate to multiple systems in a short window from unusual locations?
• Did a privileged action in a cloud control plane coincide with an endpoint alert and a new access token?
• Did a third-party support account access production shortly before a data export job ran?

In practice, correlation depends on four foundations:

1. Repository coverage (which log sources are in scope).
2. Normalization (consistent timestamps, identities, asset identifiers).
3. Correlation logic (rules/queries/detections that connect events).
4. Actionability (triage, escalation, and response tracking).

Who it applies to (entity and operational context)

AU-6(3) commonly applies to:

• Federal information systems and programs aligned to NIST SP 800-53.
• Contractor systems handling federal data (including environments supporting federal contracts) where NIST controls are contractually required.

Operational contexts where AU-6(3) becomes a gating issue:

• Hybrid enterprises with separate logging planes (endpoint, network, cloud, SaaS).
• Organizations with multiple identity providers or mixed SSO and local accounts.
• Environments with regulated boundary crossings (production vs. corporate, enclaves, classified/unclassified segmentation).
• Heavy third-party dependence (MSSPs, cloud platforms, managed apps) where “audit records” live outside your primary tooling.

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

Use this as an implementation checklist you can assign to control owners.

Step 1: Name the control owner and operating model

• Assign a primary owner (usually SecOps/SOC lead) and a GRC owner (control narrative, testing, evidence).
• Decide who executes correlation: internal SOC, MSSP, or hybrid.
• Document RACI for: onboarding log sources, detection engineering, alert triage, incident escalation, and evidence collection.

Deliverable: AU-6(3) control record with owners, in-scope systems, and operating cadence.

Step 2: Define “audit record repositories” in scope

Create an inventory of audit log repositories that matter for cross-system detection. Start with:

• Identity/authentication logs (IdP, SSO, MFA, directory services)
• Endpoint security telemetry
• Network/security devices (firewalls, proxies, DNS)
• Cloud control plane logs (IaaS/PaaS)
• Key applications handling sensitive data
• Privileged access management (PAM) logs
• Ticketing/remote support tools used by third parties

Be explicit about exclusions and why (for example, “legacy system cannot export logs; compensating control is X; remediation planned”).

Deliverable: “AU-6(3) correlation scope” list, aligned to your system boundary and data classifications.

Step 3: Centralize or federate logs so correlation is technically possible

You need a correlation plane. Common patterns:

• Central SIEM ingesting logs from each repository.
• Security data lake with analytics queries and scheduled detections.
• Managed detection platform where your provider correlates sources on your behalf.

Key requirement: correlation must run across repositories, so ensure you can query/join events from multiple sources in one place or through a federated query layer.

Deliverable: Architecture diagram and data flow description showing how repositories feed the correlation capability.

Step 4: Normalize the fields that correlation depends on

Correlation fails when identities and time don’t match. Set standards for:

• Time synchronization and consistent timezone handling.
• Identity mapping: UPN/email, employee ID, service accounts, PAM accounts, third-party accounts.
• Asset identifiers: hostname, instance ID, device ID, cloud resource ID.
• Event taxonomy: authentication, privilege change, data access, configuration change.

A practical approach is to define a small “minimum viable schema” for correlation and enforce it during onboarding of each source.

Deliverable: Normalization standard (field mapping table) and onboarding checklist.

Step 5: Define correlation use cases tied to risk and response

Pick a set of correlation use cases that are defensible and testable. Examples:

• Impossible travel / unusual geo across IdP + VPN + cloud console
• Privilege escalation chain: role assignment + token creation + sensitive API calls
• Data access anomaly: new device login + mass read/export + egress signal
• Third-party access monitoring: support tool session + privileged commands + change in production

For each use case, document:

• Data sources required
• Correlation logic (rule/query) and thresholds (qualitative is fine)
• Expected alert output
• Triage steps and escalation criteria
• False positive tuning approach

Deliverable: Correlation use case register with links to detections and runbooks.

Step 6: Operationalize: run, review, tune, and escalate

AU-6(3) is operational. Build a loop:

• Run detections continuously or on a scheduled basis appropriate to your environment.
• Triage results in a case management workflow.
• Tune correlation logic based on outcomes and changes (new systems, new identity flows).
• Track exceptions with compensating controls and a remediation plan.

Deliverable: Monthly (or defined cadence) correlation review notes, tuning tickets, and closed cases.

Step 7: Make it assessable: write the procedure and bind evidence

Document a short procedure that an assessor can follow:

• Where logs come from
• How they are normalized
• What correlations run
• How results are handled
• How you prove it happened

If you use Daydream for control operations, map AU-6(3) to the control owner, the step-by-step procedure, and the recurring evidence artifacts so audits become a packaging exercise instead of a scramble (NIST SP 800-53 Rev. 5 OSCAL JSON).

Required evidence and artifacts to retain

Aim for evidence that proves design and operation.

Design evidence (static or semi-static)

• Control narrative for AU-6(3) referencing the requirement text (NIST SP 800-53 Rev. 5 OSCAL JSON)
• In-scope audit record repository inventory
• Logging/correlation architecture diagram and data flow
• Normalization/field mapping standard
• Correlation use case register (with data sources and runbooks)
• RACI and escalation paths

Operating evidence (recurring)

• Screenshots or exports showing onboarded sources and ingestion health
• Sample correlated alerts/cases demonstrating multi-repository linkage (with sensitive data redacted)
• Ticket/case history showing triage, disposition, and escalation when warranted
• Tuning/change records for correlation rules (change management linkage)
• Periodic review sign-off (SOC lead or security manager)

Common exam/audit questions and hangups

Assessors tend to probe these areas:

1. “Show me correlation, not aggregation.” They will ask for an example where two or more repositories were joined to produce one detection or investigative view.
2. “What’s your scope?” If you cannot name your repositories and coverage rationale, the control looks aspirational.
3. “How do you handle identity mismatches?” They will test whether you can connect “jsmith,” “john.smith@domain,” and a PAM checkout account.
4. “Who reviews outcomes?” Tooling without an accountable team and workflow reads as shelfware.
5. “What happens when logs are missing?” Expect questions about ingestion failures, backlog, or excluded systems.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating SIEM onboarding as “correlation.”
Fix: Maintain a correlation use case register and show cases where multiple sources were required.

Mistake 2: No normalization standard.
Fix: Publish a minimum field mapping (time, user, host/resource, action, outcome) and enforce it via onboarding checklists.

Mistake 3: Correlations exist but no one owns the outcomes.
Fix: Tie each correlation to a triage runbook and a case queue with named roles.

Mistake 4: Over-scoping early and failing silently.
Fix: Start with the repositories that matter most for identity, privilege, and sensitive data access; expand after the operational loop works.

Mistake 5: Evidence is ad hoc.
Fix: Predefine the recurring artifacts (cases, reviews, tuning tickets) and collect them on a schedule.

Risk implications (why operators get burned on AU-6(3))

If you cannot correlate across repositories, investigations degrade into manual stitching: analysts export CSVs, compare timestamps, and guess at identity links. That causes missed detections and slow containment, especially for identity-driven attacks and third-party access paths. For regulated programs, the immediate risk is an assessment finding framed as “audit record review is insufficient to support situational awareness” under AU-6(3) (NIST SP 800-53 Rev. 5 OSCAL JSON).

Practical 30/60/90-day execution plan

Use time-boxed phases, but keep deliverables concrete.

First 30 days (stabilize scope and plumbing)

• Assign AU-6(3) control owner(s) and define SOC/MSSP responsibilities.
• Publish the in-scope repository list and exclusions with rationale.
• Stand up the correlation plane (SIEM/data lake/managed platform) for the top-priority sources.
• Define normalization standards for timestamp and identity fields.
• Draft the AU-6(3) procedure and evidence list in your GRC system.

Days 31–60 (build correlation that produces cases)

• Implement a small set of correlation use cases focused on identity, privilege, and sensitive data paths.
• Connect correlation outputs to case management (ticketing or SOAR) with clear triage steps.
• Run tabletops on at least one correlated scenario to validate escalation and ownership.
• Start recurring evidence capture (sample cases, tuning notes, ingestion health).

Days 61–90 (prove repeatability and audit readiness)

• Expand repository coverage to remaining critical systems and key third parties.
• Tune correlations based on false positives/negatives and document changes.
• Perform an internal control test: select a time window and demonstrate cross-repository correlation and investigation notes.
• Package the evidence binder and update the control narrative to match reality.

Frequently Asked Questions

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

No. AU-6(3) requires cross-repository correlation and analysis, not a specific tool (NIST SP 800-53 Rev. 5 OSCAL JSON). A SIEM is common because it simplifies ingestion, normalization, and alerting, but managed platforms or data lake analytics can also work if you can prove correlation and outcomes.

What counts as “different repositories”?

Separate log stores or telemetry systems that would otherwise be reviewed independently, such as IdP logs, endpoint logs, cloud control plane logs, application audit logs, and third-party service logs (NIST SP 800-53 Rev. 5 OSCAL JSON). The key is that your process connects events across them.

How do we prove correlation to an assessor?

Show a detection or investigation artifact where the alert narrative includes events from multiple sources, plus the underlying query/rule configuration and the triage case record. Pair that with your repository inventory and a written procedure that describes how correlation runs (NIST SP 800-53 Rev. 5 OSCAL JSON).

We have an MSSP. Can we inherit AU-6(3) from them?

You can outsource execution, but you still own the requirement. Get contractual clarity on which repositories they ingest, what correlations they run, how they handle identity mapping, and how you receive evidence (case records, reports, and tuning/change logs).

How should we handle third-party and SaaS logs we can’t export reliably?

Document the limitation, apply compensating monitoring where possible (for example, IdP logs for access to the SaaS), and track a remediation plan. Assessors usually accept exclusions only when you can show risk-based reasoning and an active plan.

What’s the minimum viable set of correlation use cases?

Start with identity and privilege chains across IdP/PAM/cloud and the applications that handle sensitive data. Pick use cases you can operate end-to-end with triage and escalation, then expand once your ingestion and normalization are stable (NIST SP 800-53 Rev. 5 OSCAL JSON).