Monitoring Physical Access to CDE

To meet the PCI monitoring physical access to CDE requirement, you must continuously monitor individual entry and exit at sensitive CDE areas using video and/or physical access control systems, protect those monitoring mechanisms from tampering, and keep monitored data reviewed, correlated, and retained for at least three months unless law restricts it (PCI DSS v4.0.1 Requirement 9.2.1.1).

Key takeaways:

  • Cover every entry/exit point of sensitive CDE areas with cameras, access control logs, or both (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Implement tamper resistance and tamper detection for cameras, readers, panels, and log pipelines (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Review and correlate physical monitoring data with other records, and retain it for at least three months unless law restricts it (PCI DSS v4.0.1 Requirement 9.2.1.1).

“Monitoring physical access to CDE” is operationally simple but audit-sensitive: you need provable coverage of doors and entry/exit paths to sensitive areas in your cardholder data environment (CDE), and you need evidence that monitoring is protected, reviewed, correlated, and retained. If your environment includes a server room hosting CDE systems, a cage in a colocation facility, an on-prem network closet containing CDE segmentation gear, or a payments operations room where cardholder data is handled, this requirement is about showing who entered, when they entered, and how you would detect and investigate inappropriate access.

For most compliance teams, the hard parts are scoping (“what counts as a sensitive area?”), building an evidence package that ties physical events to investigations, and ensuring retention and review actually happen. Auditors will not accept “we have cameras” unless you can prove coverage of entry/exit points, tamper controls, and a working review-and-correlation routine.

This page gives requirement-level implementation guidance you can hand to Facilities, Security, IT, and your QSA-facing team to close gaps quickly and produce audit-ready artifacts.

Regulatory text

PCI DSS requires that: “Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: entry/exit points to/from sensitive areas are monitored, monitoring devices or mechanisms are protected from tampering or disabling, and collected data is reviewed and correlated with other entries and stored for at least three months unless otherwise restricted by law.” (PCI DSS v4.0.1 Requirement 9.2.1.1)

Operator translation (plain English)

You must be able to reconstruct physical access to sensitive CDE areas from trustworthy records:

  • Monitor every way in and out of the sensitive area (door(s), mantrap, cage gate, and any alternative entry points) using cameras, badge logs, or both (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Harden the monitoring system so someone cannot easily disable a camera, defeat a badge reader, or erase/alter logs without detection (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Review and correlate records so events are meaningfully checked (e.g., badge entry aligns with video, visitor log, work order, or ticket) and store the data for at least three months unless local law limits that (PCI DSS v4.0.1 Requirement 9.2.1.1).

Who it applies to

Entity types: Merchants, service providers, and payment processors with a CDE (PCI DSS v4.0.1 Requirement 9.2.1.1).

Operational contexts where this commonly lands:

  • On-prem data centers, server rooms, network closets with CDE firewalls/switches, secure print rooms for cardholder reports.
  • Colocation cages or cabinets where you control physical access (shared facilities still count if your gear is in-scope).
  • Office “secure rooms” where cardholder data is processed or where CDE admin consoles are accessible.
  • Third-party hosted physical spaces, where your contract and attestations must prove equivalent monitoring for your sensitive areas. If the third party controls access, you still need assurance evidence.

Scope trigger: “Sensitive areas within the CDE” means areas where physical access could lead to compromise of CDE systems or cardholder data. Treat this as a scoping exercise you must document and defend.

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

1) Define “sensitive areas” and entry/exit points (scope first)

  1. List all CDE locations: racks, rooms, cages, closets, and workspaces.
  2. Identify which locations qualify as sensitive areas (where physical presence enables access to CDE systems/media).
  3. For each sensitive area, enumerate all entry/exit points. Don’t stop at the main door; include:
    • Secondary doors, emergency exits, shared hallways leading into the room, cage gates, ladder access, or ceiling/raised-floor access if realistic in your facility.
  4. Produce a simple “sensitive area register” with: location, owner, entry points, monitoring method, and record retention location.

Audit focus: Your register is how you prove you didn’t miss a door.

2) Choose monitoring method per entry/exit (camera, access control, or both)

PCI DSS allows cameras, physical access controls, or both (PCI DSS v4.0.1 Requirement 9.2.1.1). Choose based on risk and practicality:

Scenario Minimum that usually holds up Stronger pattern
Server room with a single controlled door Badge reader + logs at the door Badge reader + camera covering the doorway and the approach
Colocation cage Cage lock + access logs from provider Provider access logs + your own camera inside/at cage access
Office “secure room” Badge reader + visitor control Camera + badge reader + visitor log (especially with contractors)

Design goal: Monitoring should let you identify the individual and confirm the event. If your badge system can be tailgated, cameras help prove who entered.

3) Implement tamper protection for monitoring mechanisms

The requirement explicitly calls for protection from tampering or disabling (PCI DSS v4.0.1 Requirement 9.2.1.1). Treat this as both physical and logical control.

Practical controls to implement:

  • Cameras: secure mounts, protected cabling, restricted access to NVR/VMS admin, alerts for camera offline events, time sync, and restricted export/deletion permissions.
  • Badge readers/panels: locked panels, supervised door contacts where possible, restricted admin access to access-control system, and change control for access rules.
  • Logging pipeline: ensure logs can’t be altered without detection; restrict who can delete footage/logs; document retention settings.

Evidence trick: Auditors often ask “How do you know the camera wasn’t disabled?” Have offline alerts and a response record.

4) Set up review and correlation (make it operational, not theoretical)

You must review and correlate collected data with other entries (PCI DSS v4.0.1 Requirement 9.2.1.1). In practice, define:

  • What gets reviewed: door events, forced-door alarms, denied access attempts, after-hours entries, visitor entries, camera health alerts.
  • What it’s correlated with: visitor logs, work orders, change tickets, on-call schedules, HR termination lists, and incident tickets.
  • Who does it and how often: name the role (Security Operations, Facilities Security, Data Center Ops), and specify the review cadence in your procedure.

Minimum viable correlation examples:

  • Badge event shows entry at 02:00; correlate to an approved change ticket and on-call roster.
  • Visitor sign-in shows “ISP technician”; correlate to escort record and access logs for the time window.
  • Camera footage confirms only the badge-holder entered (tailgating check).

5) Configure retention and retrieval

You must store monitoring data for at least three months unless law restricts it (PCI DSS v4.0.1 Requirement 9.2.1.1). Implement:

  • Retention settings in your video system and access-control system.
  • A retrieval process that can export a time-bounded clip/report with chain-of-custody notes.
  • A legal/privacy check for jurisdictions where video retention is constrained, and document the constraint if applicable (PCI DSS v4.0.1 Requirement 9.2.1.1).

6) Build the evidence pack (so you can pass an assessment quickly)

Create a single folder (or GRC control record) that contains the artifacts listed below. This reduces scramble and prevents “we have it but can’t prove it.”

Required evidence and artifacts to retain

Keep evidence that shows coverage, tamper protection, review/correlation, and retention (PCI DSS v4.0.1 Requirement 9.2.1.1):

Scope & design

  • Sensitive area register (location, entry/exit points, monitoring method).
  • Floor plans or diagrams marking monitored entry/exit points.
  • Camera placement diagram or screenshots from VMS showing camera list and locations.
  • Access control configuration summary (doors in scope, reader IDs, access groups).

Tamper protection

  • Admin role list for VMS/access-control system.
  • نمونه of alerts: camera offline, door forced open, panel tamper (as applicable).
  • Change records for camera/access-control configuration changes.

Review & correlation

  • Written procedure: what’s reviewed, cadence, and escalation path.
  • Review logs or tickets showing periodic checks (attach examples).
  • Correlation examples tying physical events to visitor logs or change tickets.

Retention

  • System settings screenshots for retention.
  • Sample exports (video clip and access log report) with timestamps.
  • If retention is restricted by law, retain documented rationale and the compensating handling process (PCI DSS v4.0.1 Requirement 9.2.1.1).

Common exam/audit questions and hangups

Expect these:

  1. “Define sensitive areas within the CDE.” Show your register and why each area is in or out.
  2. “Prove every entry/exit is monitored.” Auditors may walk the site. Your diagrams must match reality (PCI DSS v4.0.1 Requirement 9.2.1.1).
  3. “Show me tamper controls.” Demonstrate alerts, locked cabinets, restricted admin access, and how you respond to outages (PCI DSS v4.0.1 Requirement 9.2.1.1).
  4. “Show review and correlation evidence.” A procedure alone rarely satisfies; provide completed review records and an investigation example (PCI DSS v4.0.1 Requirement 9.2.1.1).
  5. “Show retention of at least three months.” Be ready to retrieve older records during the assessment window (PCI DSS v4.0.1 Requirement 9.2.1.1).

Frequent implementation mistakes (and how to avoid them)

  • Mistake: Counting “building security” as sufficient. Building lobby cameras don’t cover the server room door. Map entry/exit points for the sensitive area itself (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Mistake: Cameras exist but are not reliably recording. Add health monitoring and a clear outage response so “camera offline” becomes a tracked event (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Mistake: No correlation, only storage. Keep examples tying badge events to visitor logs or change tickets, so “correlation” is demonstrable (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Mistake: Retention mismatch across systems. Video retains long enough but access logs don’t, or the reverse. Confirm retention for both data types you rely on (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Mistake: Third party spaces are ignored. If your CDE is in colocation or hosted facilities, collect the third party’s physical security evidence and ensure your sensitive areas are covered.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement. Treat the risk as direct: weak physical monitoring increases the chance that unauthorized individuals access CDE systems or networking equipment without detection, and it reduces your ability to investigate suspected compromise. Assessors also treat physical gaps as a scoping and compensating-controls problem that can expand your CDE boundary.

Practical execution plan (30/60/90-day)

Avoid calendar promises. Use phases you can start immediately and track to closure.

Immediate (stabilize and prove coverage)

  • Build the sensitive area register and validate each entry/exit point in person.
  • Confirm monitoring method at each entry/exit (camera, badge logs, or both).
  • Verify retention settings meet the minimum and confirm you can retrieve historical records (PCI DSS v4.0.1 Requirement 9.2.1.1).
  • Draft the review-and-correlation procedure and assign an accountable role.

Near-term (close gaps and operationalize review)

  • Install or reposition cameras/readers to eliminate uncovered entry/exit points.
  • Implement tamper measures: locks, restricted admin roles, offline/tamper alerts, and change control.
  • Start recurring review records (tickets or checklists) and store them with evidence.
  • Run a tabletop test: pick a sample access event and walk from badge log to correlated records to exported footage.

Ongoing (make it durable)

  • Add monitoring health to your operational dashboards (camera offline, storage full, logging gaps).
  • Periodically validate camera angles and door coverage after facility changes.
  • Keep correlation inputs current (e.g., updated on-call rosters, visitor processes, termination workflow).
  • If you manage compliance in a GRC system, Daydream can help centralize the control narrative, evidence requests to Facilities/Security, and recurring review attestations so the artifact trail stays assessment-ready.

Frequently Asked Questions

Do we need both cameras and badge readers at every sensitive CDE entry?

PCI DSS allows video cameras or physical access control mechanisms, or both (PCI DSS v4.0.1 Requirement 9.2.1.1). Use a risk-based approach, but be ready to prove individual access monitoring and support correlation with other records.

What counts as “reviewed and correlated” data?

“Reviewed” means someone checks monitoring data on a defined cadence; “correlated” means they match it to other records such as visitor logs, work orders, or change tickets (PCI DSS v4.0.1 Requirement 9.2.1.1). Keep completed review records that show the cross-check occurred.

Our cameras are managed by a third party (building security). Can we rely on them?

You can rely on third parties only if you can obtain evidence that entry/exit points to your sensitive CDE areas are monitored, protected from tampering, reviewed/correlated, and retained as required (PCI DSS v4.0.1 Requirement 9.2.1.1). Put evidence delivery and retention expectations into the contract or service terms.

How do we meet the tamper protection requirement for cameras?

Combine physical controls (protected mounts, secured wiring, restricted access to recording hardware) with system controls (role-based admin access, alerts when cameras go offline, and change control) (PCI DSS v4.0.1 Requirement 9.2.1.1). Preserve alert examples and response tickets as evidence.

What if privacy laws limit how long we can keep video footage?

The requirement permits shorter retention where restricted by law (PCI DSS v4.0.1 Requirement 9.2.1.1). Document the legal constraint, your approved retention setting, and how you compensate with stronger review/correlation or alternative records.

If we have badge access logs, do we still need video retention for three months?

The three-month retention applies to the “collected data” you use to monitor physical access (PCI DSS v4.0.1 Requirement 9.2.1.1). If badge logs are your primary monitoring mechanism, ensure those logs meet retention and review/correlation expectations.

Frequently Asked Questions

Do we need both cameras and badge readers at every sensitive CDE entry?

PCI DSS allows video cameras or physical access control mechanisms, or both (PCI DSS v4.0.1 Requirement 9.2.1.1). Use a risk-based approach, but be ready to prove individual access monitoring and support correlation with other records.

What counts as “reviewed and correlated” data?

“Reviewed” means someone checks monitoring data on a defined cadence; “correlated” means they match it to other records such as visitor logs, work orders, or change tickets (PCI DSS v4.0.1 Requirement 9.2.1.1). Keep completed review records that show the cross-check occurred.

Our cameras are managed by a third party (building security). Can we rely on them?

You can rely on third parties only if you can obtain evidence that entry/exit points to your sensitive CDE areas are monitored, protected from tampering, reviewed/correlated, and retained as required (PCI DSS v4.0.1 Requirement 9.2.1.1). Put evidence delivery and retention expectations into the contract or service terms.

How do we meet the tamper protection requirement for cameras?

Combine physical controls (protected mounts, secured wiring, restricted access to recording hardware) with system controls (role-based admin access, alerts when cameras go offline, and change control) (PCI DSS v4.0.1 Requirement 9.2.1.1). Preserve alert examples and response tickets as evidence.

What if privacy laws limit how long we can keep video footage?

The requirement permits shorter retention where restricted by law (PCI DSS v4.0.1 Requirement 9.2.1.1). Document the legal constraint, your approved retention setting, and how you compensate with stronger review/correlation or alternative records.

If we have badge access logs, do we still need video retention for three months?

The three-month retention applies to the “collected data” you use to monitor physical access (PCI DSS v4.0.1 Requirement 9.2.1.1). If badge logs are your primary monitoring mechanism, ensure those logs meet retention and review/correlation expectations.

Authoritative Sources

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream
PCI DSS 4.0: Monitoring Physical Access to CDE | Daydream