AU-6(6): Correlation with Physical Monitoring

To meet the au-6(6): correlation with physical monitoring requirement, you must correlate system audit records (for example, authentication, admin actions, and data access logs) with physical access monitoring data (for example, badge reader events and visitor logs) to detect suspicious or inappropriate activity and to prove you reviewed and acted on the results. This is an operational control, not a paper control.

Key takeaways:

• Correlation must join cyber audit events to physical access events so analysts can spot “impossible” or policy-violating activity.
• You need defined use cases, ownership, and recurring reviews, not just a data feed into a SIEM.
• Audit readiness hinges on evidence: data mappings, correlation rules, review records, and incident outcomes tied to real examples.

AU-6(6) is one of those requirements that gets marked “implemented” too easily because teams already have a SIEM and already have badge readers. Auditors and assessors usually want more: a demonstrable process that combines two different monitoring domains (logical and physical) to improve detection and investigation quality.

Operationally, this control sits at the intersection of Security Operations (SOC), Physical Security/Facilities, and Identity and Access Management (IAM). If those teams do not share data and agree on investigation workflows, you will miss the point of the requirement and struggle to produce defensible evidence during an assessment.

This page gives you requirement-level implementation guidance: what “correlate” means in practice, what systems and environments it applies to, how to build correlation use cases that matter, and what artifacts you must retain. The goal is fast operationalization: clear ownership, a minimal viable set of correlation rules, and repeatable review cycles you can prove.

Regulatory text

Requirement statement: “Correlate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent activity.” ¹

Operator interpretation: You must (1) collect relevant system audit records and physical access monitoring records, (2) correlate them in a way that supports detection and investigation, and (3) use the correlated view to identify and respond to suspicious activity. The test of “correlate” is whether an analyst can answer, from evidence, questions like: Was this privileged login consistent with the user being physically present where policy says they must be? ²

Plain-English interpretation (what “correlation” means)

Correlation is not “we store badge logs somewhere.” Correlation means you can link events across domains using shared attributes and time context, then alert or report on meaningful mismatches.

Typical correlation objects:

• Identity: employee ID, badge ID, username, contractor ID
• Location: facility/site, building, floor, secure room, data center cage
• Time: normalized timestamps, time zone, drift handling, grace windows you define
• Asset/system: workstation, privileged access workstation (PAW), admin jump box, server cluster, OT console

Typical suspicious patterns you should be able to detect:

• Impossible presence: user badges into Facility A but logs into an admin system from Facility B shortly after.
• Remote admin policy violations: privileged admin action occurs without a corresponding entry to an approved secure area when policy requires it.
• After-hours anomalies: physical entry to a restricted area followed by unusual system activity outside normal change windows.
• Visitor/escort gaps: visitor entry without a registered host, followed by access to sensitive systems from nearby terminals.

Who it applies to (entity and operational context)

This requirement is most relevant where the environment has material physical security controls and auditable system activity that could indicate compromise or insider risk:

• Federal information systems and contractor systems handling federal data that align to NIST SP 800-53 controls ².
• Enterprises running:
  • Data centers, labs, secure manufacturing areas, SCIF-adjacent operations, or regulated R&D spaces
  • Shared office spaces with badge access and centralized identity
  • OT/ICS environments where console access is physically constrained

If you are mostly remote-first with limited controlled facilities, you can still meet intent by correlating with whatever physical access telemetry exists (office badge system, server room access) and clearly scoping where the control applies.

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

1) Set scope and ownership (make it assessable)

• Name a control owner (often SOC manager or GRC with SOC accountable).
• Document in-scope facilities (sites, buildings, restricted rooms) and in-scope systems (identity provider, VPN, admin consoles, critical apps).
• Define what “physical monitoring” sources count (badge readers, turnstiles, mantraps, visitor management, security desk logs, camera event logs if you have them).

Deliverable: a one-page AU-6(6) control implementation summary that states scope, owners, and review cadence.

2) Inventory and onboard data sources (logical + physical)

For cyber audit records, prioritize:

• Authentication logs (IdP, VPN, privileged access management)
• Admin activity logs (PAM session logs, directory changes)
• Endpoint or server audit logs where privileged actions occur

For physical monitoring, prioritize:

• Badge access control system exports (entry/exit, door, result)
• Visitor management system (check-in/out, host, location)
• Security incident logs (forced door, tailgating alarms) if available

Key engineering requirement: time normalization and unique identifiers. If badge IDs do not map to IAM identities, correlation will be brittle.

Deliverable: a data source register that lists each feed, owner, retention, fields, and ingestion path.

3) Create an identity mapping and location model

Build a mapping table (even if manual at first) with:

• Person → badge ID(s)
• Person → usernames (corp, admin, shared admin constraints)
• Person → role (employee/contractor), home site, authorized sites
• High-risk flags (privileged users, data center access)

Also define a location taxonomy:

• Site > building > controlled area > door
• Which systems are “associated” with which controlled areas (for example, admin jump box physically located in data center, or PAWs in a secure room)

Deliverable: “Correlation mapping spec” (data dictionary + mapping rules).

4) Implement correlation use cases in your SIEM (or equivalent)

Start with a small set that you can defend and operate:

• Privileged login without corresponding physical entry to required secure area (if your policy requires physical presence).
• Badge entry to restricted area + unusual admin actions within a defined time window.
• Physical access denied + repeated account login failures (possible credential stuffing plus attempted on-site entry).
• Terminated user badge activity correlated with authentication activity (requires HR feed integration; if you cannot integrate, document compensating monitoring).

Each use case should have:

• Trigger logic (fields, joins, time window assumptions)
• Severity and routing (SOC queue, physical security queue)
• Investigation steps and closure criteria

Deliverable: correlation rule list with rule IDs, logic summaries, and triage runbooks.

5) Operationalize triage across SOC and Physical Security

Define who does what:

• SOC validates cyber event authenticity and scope.
• Physical security validates badge events (lost badge, tailgating, door held open).
• IAM/HR confirms employment status and access entitlements.
• Incident Response coordinates if thresholds are met.

Create a single workflow for “cyber-physical correlation alerts”:

1. Alert fires and is ticketed.
2. Analyst checks identity match confidence (mapping table).
3. Analyst checks physical access context (entry/exit sequence, visitor status).
4. Analyst checks cyber context (source IP, device, MFA outcome, session recordings).
5. Escalate, contain, or close with rationale.

Deliverable: one cross-functional SOP plus ticket templates.

6) Review results and tune (prove you used it)

AU-6 is in the Audit and Accountability family, so expect scrutiny on whether you reviewed and acted on correlated results, not just built detections.

Set a recurring review:

• Review a sample of alerts, false positives, and closed tickets.
• Adjust mappings, time windows, and door-location associations.
• Track systemic issues (stale badge mappings, shared admin accounts, missing exit readers).

Deliverable: recurring review minutes or sign-offs, plus tuning records.

Required evidence and artifacts to retain

Auditors commonly ask for “show me” evidence. Keep these artifacts organized by assessment period:

Control design artifacts

• AU-6(6) control narrative (scope, systems, facilities, ownership)
• Data source inventory (cyber logs + physical logs) with retention notes
• Identity-to-badge mapping approach and data dictionary
• Correlation use case list + logic summaries
• SOP/runbook for triage and escalation

Operating effectiveness artifacts

• Screenshots or exports of correlation rules/configuration
• Sample correlated alert records showing joined cyber + physical fields
• Tickets with investigation notes and outcomes (closed/contained/escalated)
• Evidence of recurring review (meeting notes, sign-off, tuning changes)
• Exceptions register (sites without badge telemetry, broken readers, compensating controls)

If you use Daydream for control management, store the above as linked evidence to the AU-6(6) requirement, with a recurring request schedule so SOC and Physical Security attach the same artifact types each cycle.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers:

• “What does correlation mean in your environment?” Show your use case list and a real example alert with both data types.
• “Which facilities and doors are in scope, and why?” Provide a scope statement tied to sensitive systems and threat scenarios.
• “How do you ensure identity matching is correct?” Show mapping logic, owner, and update process for joins.
• “Who reviews these alerts and how often?” Produce tickets plus review evidence.
• “What happens when physical logs are missing?” Show exception handling and compensating monitoring.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Ingesting badge logs but never joining them to identities	You cannot tie behavior to a person	Build and maintain an identity mapping table owned by IAM + Physical Security
Correlation rules exist, but no one owns triage	Alerts rot; auditors see “shelfware”	Assign SOC ownership with a defined escalation path to Physical Security
Overly complex correlation on day one	High false positives and abandonment	Start with a small set of high-signal use cases and tune
Ignoring time drift and time zones	Joins fail and investigations stall	Normalize timestamps, document time sources, and define windows
Forgetting visitor workflows	Real-world physical access often includes visitors	Integrate visitor management logs or document manual checks

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AU-6(6) as an assessment and contractual compliance risk rather than tie it to a specific regulator penalty in this guidance.

Risk-wise, weak cyber-physical correlation increases:

• Insider threat dwell time (activity looks “legitimate” without location context)
• Investigation cost (manual cross-team data pulls)
• Exposure from badge sharing, tailgating, or compromised credentials where physical context would have raised suspicion

Practical 30/60/90-day execution plan

First 30 days (stand up a minimal viable control)

• Confirm in-scope sites and systems; name control owner and backups.
• Onboard at least one badge log source and one core audit log source into your monitoring platform.
• Define the identity mapping method (even if manual extracts).
• Implement one correlation rule and a simple runbook.
• Start ticketing and retain evidence from the first investigations.

By 60 days (make it operational across teams)

• Expand to a small portfolio of correlation use cases tied to privileged access and restricted areas.
• Formalize the cross-functional workflow (SOC + Physical Security + IAM).
• Add recurring review and tuning, with sign-offs and evidence retention.

By 90 days (make it resilient and audit-ready)

• Address gaps: missing doors, poor badge-to-identity mapping, sites out of scope, and shared admin account issues.
• Demonstrate operating effectiveness with a clean evidence set: rule configs, alerts, tickets, review records.
• Add exception handling and compensating controls where correlation cannot be performed.

Frequently Asked Questions

Do we have to correlate CCTV footage with logs to meet AU-6(6)?

The requirement says “monitoring physical access,” which is commonly satisfied with badge and visitor monitoring data correlated to audit records ¹. If you do use camera event logs, treat them as an additional source, not a substitute for identity-linked access records.

What if our badge system doesn’t store an employee ID that matches IAM?

Create and govern a mapping table that links badge identifiers to user identities, with an owner and update workflow. Auditors usually accept a documented, maintained mapping approach if it produces reliable joins during investigations.

How do we scope this for a mostly remote workforce?

Scope to the physical locations that still matter: headquarters, labs, data centers, network closets, and any space where sensitive systems can be accessed. Document exclusions and add compensating monitoring where physical telemetry is limited.

Is it enough to correlate only privileged users?

Privileged users are the fastest path to meaningful coverage, but assessors may ask whether other high-impact systems or restricted areas should be included. Start with privileged access, then expand based on your risk assessment and facility criticality.

What evidence is most persuasive in an assessment?

A real correlated alert example, a ticket showing investigation steps across cyber and physical teams, and proof of recurring review/tuning. Config screenshots alone rarely satisfy operating effectiveness.

Our physical security team is outsourced to a third party. Can we still comply?

Yes, but you must define data access, handoffs, and investigation SLAs in the third party agreement and operating procedures. Keep evidence that your SOC can obtain physical access context promptly and that cases are resolved with documented outcomes.

Footnotes

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

2. NIST SP 800-53 Rev. 5