AU-6(6): Correlation with Physical Monitoring

AU-6(6) requires you to correlate system audit records (for example, authentication, admin actions, and sensitive data access) with physical access monitoring data (for example, badge readers and visitor logs) so you can detect suspicious activity that would be missed in either dataset alone. Operationalize it by defining correlation rules, integrating physical signals into your SIEM, and retaining evidence that investigations consistently use both sources. ¹

Key takeaways:

• You must join cyber audit events to physical presence signals to strengthen detection and investigation. ¹
• Auditors expect repeatable correlation logic, clear ownership, and proof the correlations are actually reviewed and acted on.
• Evidence needs to show both data feeds, the correlation rules, and resulting triage and case handling.

AU-6(6): Correlation with Physical Monitoring is a requirement-level expectation that your security monitoring program does not treat “cyber” and “physical” as separate worlds. The control is narrow but operationally demanding: you need a workable way to connect audit records generated by information systems with records generated by physical access monitoring, and you need to use that connection to spot suspicious, inappropriate, unusual, or malevolent activity. ¹

For a CCO, GRC lead, or security governance owner, the fastest way to make this real is to translate it into three deliverables: (1) defined correlation use cases (what you detect), (2) a technical integration pattern (how you match identities, locations, and time), and (3) an evidence bundle (how you prove it runs and produces action). This page focuses on getting you to an auditable operating model, not a slide deck: clear scope boundaries, concrete steps, artifacts to retain, and audit questions you can pre-answer.

Regulatory text

Requirement (verbatim): “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 meaning: you are expected to:

• Collect and retain audit records from relevant systems (authentication, privileged activity, access to regulated data, security-relevant configuration changes).
• Collect and retain physical access monitoring records (badge/door events, visitor management logs, security desk logs, camera system events, mantrap/turnstile logs where applicable).
• Correlate them in a way that supports detection and investigation. Correlation can be automated (preferred for alerting) and/or procedural (acceptable for investigations if documented), but it must be intentional and repeatable.
• Use the correlated view to identify suspicious patterns that would not be obvious in a single dataset. ¹

Plain-English interpretation (what “correlate” means in practice)

Correlation is the act of answering questions like:

• “A VPN login happened from an employee account. Was that person badged into the building, in a known travel state, or recorded as a visitor elsewhere at that time?”
• “A database admin export occurred. Did the operator physically enter the data center or secure suite around that window?”
• “A privileged action came from a workstation assigned to a secure room. Do we have door events or visitor records that confirm who was present?”

In scope terms, AU-6(6) is an audit analysis enhancement: it strengthens your ability to interpret audit records by adding the physical context that often distinguishes legitimate access from impersonation, stolen credentials, insider misuse, or procedural breakdowns. ¹

Who it applies to (entity and operational context)

You should treat AU-6(6) as applicable when:

• You operate federal information systems or environments aligned to NIST SP 800-53 requirements. ²
• You are a contractor system handling federal data, including hosted environments, managed services, or SaaS platforms where physical access to offices, data centers, or secure areas could affect confidentiality, integrity, or availability. ¹

Operational contexts where auditors commonly expect real correlation:

• Secure facilities: data centers, cages, network rooms, SOC/NOC floors, labs, records rooms.
• Privileged access environments: jump boxes, admin workstations, break-glass accounts.
• Regulated data processing: systems handling sensitive federal data, mission systems, or high-impact workloads.
• Hybrid orgs: physical security is managed by Facilities or a third party while cyber monitoring is owned by Security; AU-6(6) forces coordination.

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

Use this as a build checklist. Keep each step tied to an artifact you can show.

1) Name an owner and define operating cadence

• Assign an accountable owner (often Security Operations with GRC oversight).
• Define when correlation occurs:
  • Real-time/near-real-time for high-risk use cases (privileged access, remote access).
  • Investigation-time correlation as a minimum for all security incidents that involve identity, access, or asset tampering.
• Document escalation routes: Facilities, corporate security, and any physical security third party.

Deliverable: AU-6(6) control card/runbook with objective, triggers, steps, and exceptions (for example, sites without badge systems). This aligns with the “control card” best practice reflected in the provided guidance set.

2) Define correlation use cases (start small, pick “high signal”)

Create 6–10 use cases that are auditable and actionable. Examples:

• Remote login without physical presence: privileged VPN or admin console access while the user is not badged into any facility that day.
• After-hours access pairing: sensitive application access outside business hours paired with physical entry after hours.
• Impossible travel (physical + cyber): user badges into Office A while an interactive login occurs from a workstation assigned to Office B.
• Data center/admin room access + config change: network device configuration change within a window around data center entry.
• Visitor + access anomaly: visitor log indicates escort by employee X; employee X account triggers unusual authentication failures or privilege elevation.

Deliverable: Use-case register with fields: purpose, in-scope systems, physical data source, correlation logic, severity, responder, and expected evidence.

3) Inventory and onboard data sources (cyber + physical)

Cyber sources typically include:

• Identity provider logs (SSO, MFA, directory events)
• Endpoint/security logs (EDR, workstation authentication)
• Privileged access management logs
• Cloud audit logs (where applicable)
• Application audit trails for sensitive systems

Physical sources typically include:

• Badge access control system events (door, time, location, grant/deny)
• Visitor management system entries (visitor identity, escort, duration)
• Security desk logs for exceptions (lost badge, manual entry)
• Camera event metadata (you do not need to ingest raw video to meet AU-6(6); keep video as supporting evidence when used)

Deliverable: Data source matrix with owner, retention, access method, and field mapping.

4) Solve identity and time alignment (the real work)

Correlation breaks without consistent identifiers.

• Establish a crosswalk: employee ID, badge ID, directory user ID, email, and any contractor identifiers.
• Normalize time: consistent timezone and clock sync assumptions across systems.
• Define matching logic: exact match (badge ID ↔ employee ID) where possible; fallback match using HR roster where needed.

Deliverable: Identity mapping document and data dictionary (fields used, join keys, known gaps).

5) Implement correlation in your SIEM/case workflow (or documented manual process)

Preferred pattern:

• Ingest physical access logs into your SIEM.
• Build correlation rules that enrich cyber events with “physical presence context” (present, absent, unknown).
• Trigger alerts for your defined use cases.
• Route alerts into a ticketing/case platform with required fields.

If SIEM ingestion is not feasible in some locations:

• Document a standard investigation step: analysts must query the physical access system (or request from Facilities) during triage for specific alert types and all access-related incidents.

Deliverable: Correlation rule configurations (or screenshots/export), and investigation SOP steps requiring physical checks.

6) Make it executable: triage, response, and exceptions

Define what “action” looks like:

• Triage steps, required queries, and decision points.
• When to notify Facilities or corporate security.
• How to handle “unknown physical status” (badge system outage, remote worker, travel, contractor site).

Deliverable: Triage playbooks for each use case with clear closure criteria.

7) Run control health checks and track fixes

You need proof the control keeps working:

• Check ingestion health for physical logs.
• Sample alerts and confirm analysts performed the physical correlation step.
• Track gaps (missing sites, unmapped badges, time drift, new door controllers).

Deliverable: Control health check records and remediation tracker with validated closure.

Required evidence and artifacts to retain

Auditors typically want “design + operation” evidence. Maintain:

• Control card/runbook for AU-6(6): owner, scope, triggers, steps, exceptions.
• Data source matrix and identity crosswalk (including contractors where applicable).
• Correlation use-case register and the rule logic (SIEM correlation queries, detection rule IDs, or saved searches).
• Sample correlated events: redacted cases showing a cyber event and the associated physical access context.
• Incident/ticket records: show the investigation included physical checks.
• Health check logs: ingestion monitoring, periodic review notes, and remediation tickets.
• Retention and access control evidence: who can access physical logs and how you prevent tampering (policy + system permissions).

Store evidence in a known audit repository with stable naming conventions. Daydream can help by packaging AU-6(6) into a requirement control card, defining the minimum evidence bundle per run cycle, and tracking health checks and remediation to closure in one place.

Common exam/audit questions and hangups

Expect questions like:

• “Which physical monitoring sources are in scope, and which sites are excluded? Show the rationale.”
• “Show me how you match a badge ID to a user identity. What happens for contractors?”
• “Demonstrate an alert or an investigation where physical access data changed the outcome.”
• “How do you handle badge system outages or manual security desk entries?”
• “Who reviews the correlation rules for continued relevance after org changes (site moves, new doors, new SSO)?”

Hangups that slow audits:

• Facilities owns physical systems and Security cannot produce logs on demand.
• Identity joins depend on manual spreadsheets with no update process.
• Video exists but isn’t searchable; teams confuse “we have cameras” with “we correlate monitoring.”

Frequent implementation mistakes (and how to avoid them)

1. Treating correlation as a one-time build.
   Avoidance: add a health check step that confirms ingestion, join accuracy, and analyst behavior.

2. No defined “unknown” logic.
   Avoidance: codify “unknown physical presence” outcomes and escalation rules. Unknown should not auto-close high-severity events.

3. Over-scoping to raw video.
   Avoidance: focus on event metadata (door/badge/visitor events). Pull video only when needed for investigations.

4. No clear ownership across Security and Facilities.
   Avoidance: write an interlock: who provides logs, within what SLA, and who approves exceptions.

5. Correlation rules that produce noise.
   Avoidance: start with privileged access and sensitive systems. Add use cases only after triage is stable.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-6(6), so this page does not list enforcement examples.

Risk-wise, AU-6(6) is about preventing and detecting blended threats:

• Stolen credentials used while the legitimate user is not physically present.
• Insider risk where physical access and system actions align suspiciously (after-hours entry + data access).
• Process failures (shared badges, tailgating, poor visitor controls) that show up as cyber anomalies only after physical context is added. ¹

A practical 30/60/90-day execution plan

You asked for speed, but you also need audit-grade outputs. Use phases with clear deliverables.

First 30 days (design + minimum viable correlation)

• Publish the AU-6(6) control card: owner, scope, triggers, exceptions.
• Pick initial use cases: prioritize privileged access and remote access.
• Inventory physical monitoring sources per site; document gaps.
• Build identity crosswalk approach (HR roster + badge system + directory).
• Implement one correlation path (SIEM rule or documented analyst step) and test it with sample events.

Days 31–60 (integration + operational workflow)

• Ingest badge/visitor logs into SIEM for at least one high-value site, or formalize the on-demand log request workflow with Facilities.
• Create ticket templates that require physical presence checks for defined alert types.
• Train SOC/IR staff on the playbooks and what evidence to attach.
• Start control health checks: ingestion status, mapping drift, and sample case review.

Days 61–90 (expand scope + prove sustained operation)

• Expand to additional sites and additional systems (PAM, sensitive apps).
• Tune rules to reduce false positives and document tuning decisions.
• Run a tabletop or targeted test where a scenario forces physical correlation (lost badge + account login).
• Package an “audit-ready evidence bundle” with redacted examples, run logs, and remediation closure.

Frequently Asked Questions

Do we have to ingest physical access logs into our SIEM to satisfy AU-6(6)?

The requirement is correlation of audit records with physical monitoring information, not a specific tool mandate. If you can prove analysts consistently pull physical access records during investigations with a documented SOP and retained tickets, you can meet the intent. ¹

What counts as “physical monitoring” for this control?

Badge/door events and visitor management logs are the usual baseline. Security desk exception logs and camera event metadata can support investigations when door data is incomplete. ¹

How do we handle remote employees or staff who rarely badge into an office?

Define an “expected physical presence” model by role and system. For remote roles, correlation may focus on “no badge expected” plus stronger identity proofing (MFA signals, device posture) and visitor logs when they do come onsite.

What if Facilities or a third party owns the badge system and won’t give Security direct access?

Treat it as a control dependency and formalize it: a documented request path, response time expectations, and a designated approver for exceptions. Auditors care that correlation happens; they will still ask for evidence you can produce without delays.

How much evidence is enough for auditors?

Keep design evidence (use cases, rules, mapping) plus operating evidence (sample correlated tickets/cases and health check records). A small set of well-documented examples is better than a pile of screenshots without context.

How does Daydream fit without adding another monitoring tool?

Daydream is a good fit when your gap is governance: clear ownership, a control card/runbook, the minimum evidence bundle per cycle, and health checks with tracked remediation. You can keep your SIEM and physical systems as-is and still make AU-6(6) audit-ready.

Footnotes

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

2. NIST SP 800-53 Rev. 5