AU-6(5): Integrated Analysis of Audit Records

AU-6(5) requires you to correlate audit log analysis with at least one other telemetry source (for example, vulnerability scan results, performance metrics, or system monitoring data) to improve detection of unusual or inappropriate activity. Operationalize it by defining correlation use cases, integrating the data in your SIEM or analytics platform, and retaining evidence that the correlations run and produce actionable outcomes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Correlation is the requirement: logs alone are insufficient for AU-6(5); you must analyze them together with other security/ops datasets. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Auditors look for repeatable operation: named ownership, defined cadence or triggers, documented rules, and ticketed outcomes.
• Evidence must show end-to-end flow: inputs (data feeds), the correlation logic, and resulting investigations/remediation.

AU-6(5): Integrated Analysis of Audit Records is a “detection maturity” requirement. It pushes you beyond collecting logs and reviewing alerts in isolation. Instead, you need to combine audit records (authentication events, privilege changes, data access, admin actions, API calls, etc.) with at least one other source of truth, such as vulnerability scanning outputs, performance data, system monitoring, or other relevant datasets, to improve your ability to identify suspicious behavior. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat AU-6(5) as a small set of defined correlation “use cases” with clear ownership and measurable outputs: alerts, investigations, and remediation tickets. Your job is to ensure (1) the organization picked the additional datasets intentionally, (2) correlation rules exist and run, and (3) results drive action and are retained as evidence.

This page gives you requirement-level guidance you can hand to Security Operations, IT, and platform owners, plus the evidence bundle you will need for assessments (FedRAMP, agency ATOs, or customer due diligence) aligned to NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI)

Regulatory text

Requirement (AU-6(5)): “Integrate analysis of audit records with analysis of [one or more of: vulnerability scanning information; performance data; system monitoring information; [data/information collected from other sources]] to further enhance the ability to identify inappropriate or unusual activity.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What this means for an operator

You must do three things, and all three must be provable:

1. Choose at least one non-log dataset to pair with audit records (for example: vulnerability scans, EDR telemetry, infrastructure monitoring, application performance metrics, identity governance signals). (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Perform integrated analysis (correlation) between logs and that dataset, not just side-by-side dashboards. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. Use the integrated view to detect unusual activity and route results into your incident handling or investigation workflow. (NIST SP 800-53 Rev. 5 OSCAL JSON)

If your “integration” is a quarterly meeting where teams compare findings, you may still be weak on “integrated analysis” unless you can show consistent, repeatable correlation outputs tied to specific audit records.

Plain-English interpretation (what AU-6(5) is asking you to prove)

AU-6(5) expects you to connect dots. A single log event can look normal until you add context:

• A successful admin login becomes higher risk if the host is missing critical patches (vulnerability scanning data).
• A burst of database reads becomes suspicious if the application’s performance metrics show an unusual spike off-hours (performance data).
• A new service account token becomes more suspicious if endpoint telemetry shows new persistence mechanisms (system monitoring).

The requirement is satisfied when you can show that your monitoring program routinely combines audit logs with at least one other dataset and produces investigations that would be harder to identify using audit logs alone. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entity types

• Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls as part of their security program. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational context (where it shows up in real life)

• SOC/SIEM monitoring programs (central log management plus correlation rules)
• Cloud security operations (CloudTrail/Azure Activity logs plus CSPM findings)
• Identity and access monitoring (IdP audit logs plus HR data or IAM governance signals)
• Vulnerability management programs that feed security operations prioritization
• Managed security service providers (MSSPs) supporting federal customers, where integrated detection is an explicit expectation

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

Use this as a control runbook your teams can execute.

Step 1: Assign ownership and write the “control card”

Create a one-page operational spec that answers:

• Owner: SOC lead, Detection Engineering, or Security Operations Manager (with a GRC control owner accountable).
• Scope: which environments (prod only vs prod + corp), which log sources, which business systems.
• Trigger: continuous correlation, daily batch, or event-driven for high-risk events.
• Outputs: alerts, cases, tickets, and metrics.

Many AU-6(5) failures are governance failures: nobody can say who runs it, how often, or what “done” looks like.

Step 2: Pick your “other datasets” deliberately

Choose at least one, and document why it improves detection. Common pairings:

• Vulnerability scanning information (scanner outputs, severity, exploitability notes) (NIST SP 800-53 Rev. 5 OSCAL JSON)
• System monitoring information (EDR alerts, file integrity, process creation, network telemetry) (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Performance data (APM, latency, throughput anomalies, error rates) (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Other sources (HR termination feed, CMDB, ticketing/changes, DLP alerts) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Decision rule: pick the dataset you already trust operationally. AU-6(5) is easier to evidence when the source is already governed and has stable identifiers (hostnames, asset IDs, usernames).

Step 3: Define 5–10 integrated correlation use cases

Write them as detection statements with logic and expected actions. Examples:

• “Privileged login on a host with critical vulnerabilities” → alert severity increases; open investigation ticket.
• “New admin user created outside approved change window” (audit log + change ticket system) → create a case and request approval evidence.
• “Unusual data access volume plus performance anomaly” (DB audit logs + APM) → triage for exfiltration vs batch job.
• “Repeated failed logins plus EDR credential dumping signal” → escalate to incident response.

For each use case, document:

• Data sources required
• Correlation keys (user ID, asset ID, account, IP, device ID)
• Threshold/logic (even if simple)
• Triage owner and SLA expectations (qualitative is fine if you can’t commit to numbers)

Step 4: Implement integration in your analytics stack

Typical implementation patterns:

• SIEM correlation rules combining normalized events + enrichment fields
• SOAR playbooks that enrich audit log alerts with vuln posture or EDR context
• Data lake + detection queries (for mature programs)

Minimum bar: you can demonstrate that audit logs are enriched/correlated with the chosen dataset(s) and produce alerts/cases.

If you use Daydream for third-party risk and due diligence, treat AU-6(5) as a control you can “productize” internally: a control card, mapped evidence bundle, and recurring health checks. Daydream is useful when you need consistent evidence packaging across many systems and service owners, especially for audits and customer questionnaires.

Step 5: Wire results into operations (tickets, cases, escalation)

AU-6(5) is weak if correlation produces alerts that nobody works. Require:

• A case management path (SIEM case, SOAR case, or ticketing system)
• Investigation notes captured (what was reviewed, decision, closure reason)
• Escalation criteria into incident response

Step 6: Prove it runs (control health checks)

Run recurring checks that answer:

• Are all required feeds connected and current?
• Are correlation rules enabled, not in “test” mode?
• Did rules produce alerts/cases in the period, and were they handled?
• Were tuning changes approved and tracked?

Required evidence and artifacts to retain

Aim for an “evidence bundle” that a reviewer can validate quickly:

Design-time evidence (static)

• AU-6(5) control card/runbook (owner, scope, triggers, outputs)
• Data flow diagram or integration description (log sources + enrichment sources)
• Detection catalog: list of correlation use cases, with logic descriptions
• Access control evidence for the monitoring tools (who can change rules)

Operating evidence ¹

• Screenshots or exports showing:
  • Data sources connected (audit + at least one other category) (NIST SP 800-53 Rev. 5 OSCAL JSON)
  • Correlation rules enabled and last modified
• Sample alerts/cases showing enrichment fields (vuln context, monitoring context)
• Tickets/cases with investigation notes and closure
• Change records for rule tuning (what changed, who approved, why)
• Control health check results and remediation tracker

Retention should follow your system’s audit/log retention policy, but your key need is consistency: keep enough history to show sustained operation across assessment cycles.

Common exam/audit questions and hangups

Auditors and assessors commonly ask:

1. “Show me integrated analysis, not separate tools.” Be ready to demonstrate a single query/alert/case where audit events are enriched with vulnerability or monitoring context. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Which datasets qualify as ‘other sources’?” If it materially improves detection and you can show correlation, it qualifies under the bracketed options. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. “How do you ensure it runs continuously?” Show rule schedules, enabled status, and health checks.
4. “Who owns tuning and false positive management?” Point to a named owner and a change workflow.
5. “How do you connect alerts to action?” Show tickets, investigations, or incident records tied to correlated alerts.

Hangup to avoid: “We have a SIEM” is not evidence of AU-6(5). The assessor wants proof of correlation between audit records and another dataset. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes (and fixes)

Mistake	Why it fails AU-6(5)	Fix
Only ingesting data sources; no correlation rules	Ingestion is not “integrated analysis”	Publish correlation use cases and implement rules/queries tied to them
Correlation exists, but no case management	You can’t show improved detection leads to action	Require tickets/cases for sampled alerts and retain investigation notes
One-off “pilot” detections with no repeatability	Hard to prove ongoing operation	Add control health checks, rule ownership, and change management
Enrichment keys don’t match (asset IDs/user IDs inconsistent)	Correlation breaks silently	Standardize identifiers, document mapping, monitor feed quality
Evidence scattered across teams	Audit response becomes slow and incomplete	Define a minimum evidence bundle and a single retention location

Enforcement context and risk implications

No public enforcement cases were provided in the source material for AU-6(5). Your practical risk is assessment failure or customer trust impact: if you can’t demonstrate integrated detection, reviewers may conclude you are collecting logs without the ability to detect multi-signal threats or prioritize response effectively. (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI)

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Appoint AU-6(5) operational owner and GRC accountable.
• Inventory audit log sources in scope and pick at least one additional dataset category to integrate. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Draft the control card and evidence bundle checklist.
• Define initial integrated correlation use cases and success criteria (alert → case → closure).

Days 31–60 (implement and prove correlation)

• Connect/enrich data feeds in SIEM/SOAR/data platform.
• Build and enable correlation rules for the initial use cases.
• Create a ticketing/case workflow and escalation path.
• Run a tabletop: generate test events, confirm alerts fire, and confirm triage steps produce artifacts.

Days 61–90 (stabilize and operationalize)

• Tune rules, document changes, and formalize approvals.
• Add control health checks (feed status, rule status, sample case reviews).
• Start periodic reporting to GRC: what ran, what fired, what was remediated.
• Package evidence for assessors in a consistent location (this is where tools like Daydream help by standardizing control cards, evidence requests, and recurring health checks across owners).

Frequently Asked Questions

What counts as “integrated analysis” for AU-6(5)?

You need correlation between audit records and at least one other dataset category listed in the control text, producing an alert, case, or investigative output. A separate dashboard in a separate tool is weak unless you can show a repeatable workflow that combines the data. (NIST SP 800-53 Rev. 5 OSCAL JSON)

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

No specific tool is required. You can meet the requirement with a SIEM, a data lake plus detection queries, or SOAR-driven enrichment, as long as you can show correlated analysis and outcomes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Can vulnerability scan results alone satisfy the “other source” requirement?

Yes, vulnerability scanning information is explicitly listed as an acceptable dataset to integrate with audit record analysis. You still need to show real correlation logic and resulting investigations or triage outcomes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How many correlation use cases are “enough”?

NIST does not specify a number. Pick a small set that covers your highest-risk scenarios (privilege, remote access, sensitive data access) and expand as your detection program matures. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence should we show if alerts are rare?

Keep test results, rule enabled status, and health check outputs, plus at least a few worked examples from prior periods or controlled tests. Also retain change logs for tuning and documented triage procedures.

Does AU-6(5) apply to third parties or outsourced SOCs?

If a third party operates monitoring or logging for systems in scope, you still own the requirement and must ensure the provider performs and evidences integrated analysis. Contract terms and reporting should require access to correlation logic and case artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Footnotes

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