Facility Entry Controls for CDE
PCI DSS 4.0.1 Requirement 9.2.1 requires you to put facility entry controls in place that restrict physical access to systems in the Cardholder Data Environment (CDE). Operationally, you must define the CDE physical boundary, control who can enter it (badges/locks/guards), and retain evidence that access is authorized, monitored, and reviewed. (PCI DSS v4.0.1 Requirement 9.2.1)
Key takeaways:
- Define and document the physical scope: which rooms/racks/cages are “CDE areas.”
- Enforce entry restrictions with real controls (badges, keys, mantraps, guards) tied to authorization.
- Keep evidence assessors expect: access lists, logs, visitor records, and periodic reviews.
“Facility entry controls for CDE” sounds straightforward until you have to prove it under assessment: what exactly counts as the CDE area, who is authorized, how access is granted and removed, and what you can show an assessor on request. Requirement 9.2.1 is not asking for a specific technology. It is asking for a working access-control system that reliably restricts physical entry to systems in the CDE. (PCI DSS v4.0.1 Requirement 9.2.1)
For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a boundary-and-evidence problem. First, draw the boundary of spaces that contain CDE systems (including network gear that is in-scope for PCI). Second, pick controls appropriate to the facility risk and operations (badge readers, locks, guards, or a combination). Third, set up governance so HR/IT/Security can answer: “Who has access right now, why do they have it, and where is the proof?”
This page gives requirement-level implementation guidance you can execute quickly, including step-by-step tasks, the artifact set to retain, common audit hangups, and a practical phased rollout plan.
Regulatory text
Excerpt: “Appropriate facility entry controls are in place to restrict physical access to systems in the CDE.” (PCI DSS v4.0.1 Requirement 9.2.1)
What an operator must do: implement physical entry controls that (1) define where CDE systems live, (2) prevent unauthorized people from entering those areas, and (3) allow you to demonstrate that access is limited to authorized individuals. “Appropriate” means the control strength matches your environment (for example, a staffed data center will differ from a locked IDF closet), but in every case the goal is to restrict physical access to CDE systems. (PCI DSS v4.0.1 Requirement 9.2.1)
Plain-English interpretation
You need barriers between “public/office space” and “CDE space,” plus a controlled way to pass through the barrier. If someone can walk up to a CDE server, network device, or storage system without being explicitly authorized to enter that area, you will struggle to meet the requirement. Controls can be electronic (badge readers), mechanical (locks), or human (guards), as long as they actually restrict entry and you can prove they are used. (PCI DSS v4.0.1 Requirement 9.2.1)
Who it applies to (entity and operational context)
This applies to any merchant, service provider, or payment processor with systems in the CDE located in a facility you operate or control (corporate office, call center, on-prem data center, retail back office, co-lo cage you manage, etc.). (PCI DSS v4.0.1 Requirement 9.2.1)
Operationally, it applies wherever any of the following are true:
- You host or manage CDE servers, storage, hypervisors, or network/security devices that are part of cardholder data processing, transmission, or storage.
- You have “mixed-use” spaces, such as an IT room shared by in-scope and out-of-scope systems.
- You rely on a third party facility (colocation) but still control access authorization for your cabinets/cages.
If your CDE is fully outsourced, you still need to validate how your third party provides physical access controls for the CDE components they operate for you, but your direct obligations depend on your PCI responsibility model and scope decisions. (PCI DSS v4.0.1 Requirement 9.2.1)
What you actually need to do (step-by-step)
1) Define the physical CDE boundary (scope you can point to)
- Inventory where in-scope systems are located (room, closet, cage, rack).
- Decide the “CDE area” boundary that will be controlled (entire room vs. caged rack).
- Produce a simple CDE physical boundary description (diagram or written definition) that a non-expert can follow.
Practical rule: if the boundary is ambiguous, assessors will expand scope. Make the boundary crisp.
2) Select entry controls that match the facility
Use one or more of these, as appropriate to the space:
- Badge reader or access control system on the CDE room door
- Keyed lock with strict key control
- Guarded reception plus controlled inner door
- Mantrap or two-door vestibule for higher-risk sites
- Locked rack/cabinet or caged area where the “room” is not exclusive
Your job is not to buy a specific product; it is to ensure the control reliably restricts entry to authorized individuals. (PCI DSS v4.0.1 Requirement 9.2.1)
3) Establish authorization rules (who gets access and why)
Create an access standard for CDE spaces:
- Define eligible roles (IT operations, network/security admins, facilities, approved third party techs).
- Require a business justification and owner approval for each person.
- Require least-privilege for physical access (access only to the needed room/cage, not all IT spaces by default).
4) Implement joiner/mover/leaver (JML) for physical access
Operationalize access lifecycle:
- Provisioning: request ticket, manager approval, security/admin grant, and recording in the access system.
- Changes: role change triggers access review and adjustment.
- Deprovisioning: HR termination/contract end triggers same-day removal from physical access lists and badge disablement.
Common audit snag: badge access persists after offboarding. Build a tight handoff between HR and whoever manages the badge system.
5) Control and log visitors and third parties
For any non-authorized person entering CDE areas (including maintenance, cleaning, auditors, and third party technicians):
- Require sign-in/sign-out and identity verification.
- Issue a visitor badge distinct from employee badges.
- Require escort by an authorized person, unless you have a defined exception process.
- Record where they went (which CDE area) and why.
Even if your control is “guard + logbook,” the logbook must be complete and retained.
6) Monitor and review access
Put governance around the system:
- Periodically review the list of people with access to CDE areas for appropriateness.
- Review anomalies (for example, access outside expected hours) based on your risk model and facility operations.
- Test doors/locks/readers for proper operation and document exceptions and repairs.
7) Align physical controls to your CDE change process
Any time CDE scope moves, your physical boundary may change:
- New rack added, server relocated, network gear moved to a different closet, office remodel.
- Your change process should include a checkpoint: “Does this change modify the physical CDE boundary or facility entry controls?”
8) Make it assessable (walkthrough-ready)
Assessors typically validate by interview, observation, and sampling. Prepare:
- A walkthrough route with someone who can explain the boundary and demonstrate entry controls.
- A sample set of access approvals, visitor logs, and access review records that tie to the boundary.
Where Daydream fits
If your evidence is scattered across facilities, IT, and HR systems, assessments fail on retrieval speed as often as on control design. Daydream can act as your control evidence hub: map the CDE physical boundary narrative to Requirement 9.2.1, assign owners, and collect artifacts (access lists, visitor logs, reviews) into an assessor-ready packet aligned to PCI DSS 4.0.1. (PCI DSS v4.0.1 Requirement 9.2.1)
Required evidence and artifacts to retain
Keep artifacts that prove the control exists, is enforced, and is governed:
CDE boundary and control design
- Physical CDE boundary description (diagram or written)
- List of CDE areas (rooms, cages, racks)
- Facility entry control description (badge system/locks/guards), including where applied
Authorization and access management
- Current authorized access list for each CDE area
- Access request/approval records (tickets, forms, emails) tied to individuals
- Offboarding records showing badge/access removal for terminated employees and ended contractors
Operational records
- Visitor logs (sign-in/sign-out, identity check, escort, area visited, purpose)
- Access control system logs or reports (where available)
- Evidence of periodic access reviews and resulting removals/changes
- Records of door/reader/lock issues and remediation (if a control breaks, show how you handled it)
Common exam/audit questions and hangups
Assessors and internal audit teams commonly push on:
- “Show me exactly where the CDE is.” If you cannot point to a boundary, you cannot prove restriction. Expect a walkthrough request.
- “Who has access right now, and why?” Be ready with an authorized list and approvals.
- “How do you remove access?” They will test leavers and contractors; have deprovision evidence.
- “How do visitors and third parties get in?” Visitor handling is often informal. Expect sampling.
- “What about shared spaces?” If the room contains both in-scope and out-of-scope systems, your boundary choice must still restrict access to the in-scope systems.
Frequent implementation mistakes and how to avoid them
| Mistake | Why it fails | Fix |
|---|---|---|
| Treating “locked office building” as the control | It does not restrict access to the CDE area | Put controls at the CDE boundary (room, cage, rack) (PCI DSS v4.0.1 Requirement 9.2.1) |
| Badge access granted by default to IT | Overbroad access violates least-privilege expectations | Define eligible roles and require approvals per person |
| Visitor logs are incomplete or missing escorts | You cannot prove restriction for non-authorized access | Standardize sign-in/out, identity check, escort requirement |
| Offboarding doesn’t reach badge admins | Former staff retain access | Tie HR termination to automatic or ticketed badge disablement |
| CDE moved but physical controls didn’t | Scope drift creates unprotected CDE systems | Add “physical CDE impact” to change management |
Enforcement context and risk implications
No public enforcement cases were provided in the supplied sources for this requirement, so this page avoids naming specific actions. Practically, weak facility entry controls increase the likelihood of physical tampering, theft, or unauthorized access to CDE systems. In PCI assessments, physical access gaps also drive scope expansion: if you cannot prove restriction to the CDE boundary, assessors may treat broader facility areas as in-scope to compensate. (PCI DSS v4.0.1 Requirement 9.2.1)
Practical execution plan (30/60/90-day)
Because no source-backed timelines are provided, treat these as phases you can run at your pace.
Immediate phase (stabilize and scope)
- Identify all locations with CDE systems and draft the physical boundary definition.
- Walk the sites and document current entry points, locks, badge readers, and any “back doors.”
- Freeze ad hoc access grants; route new access through a ticket with approval.
- Start visitor logging for CDE entries if it is not already in place.
Near-term phase (control build-out and governance)
- Implement or tighten entry controls at each CDE boundary (door reader/lock/guard).
- Establish the authorized access list per area and validate it with area owners.
- Implement JML procedures for badges/keys, including contractor end dates.
- Create a repeatable access review and visitor review routine; document outcomes.
Ongoing phase (audit readiness and continuous control)
- Run periodic access reviews and remove stale access quickly.
- Sample-check visitor logs for completeness and escort compliance.
- Test doors/readers/locks and document issues and remediation.
- Keep a standing assessor packet in Daydream (or your GRC repository) with the current boundary, access lists, reviews, and visitor records mapped to Requirement 9.2.1. (PCI DSS v4.0.1 Requirement 9.2.1)
Frequently Asked Questions
What counts as “facility entry controls” for the CDE?
Controls that restrict entry into areas containing CDE systems, such as badge readers, locks, or guards. The key is that they actually prevent unauthorized access and you can show evidence they are in place. (PCI DSS v4.0.1 Requirement 9.2.1)
If my CDE systems are in a shared server room, do I have to secure the whole room?
You need a defined boundary that restricts physical access to the CDE systems. That can be the entire room or a cage/locked rack inside the room, as long as unauthorized people cannot physically reach the CDE systems. (PCI DSS v4.0.1 Requirement 9.2.1)
Do I need electronic badge logs to pass PCI for Requirement 9.2.1?
The requirement calls for “appropriate facility entry controls,” not a specific technology. If you use mechanical locks or guards, you still need strong authorization practices and records that demonstrate restricted entry. (PCI DSS v4.0.1 Requirement 9.2.1)
How should we handle third party technicians who need occasional access?
Put them through a documented process: identity verification, sign-in/sign-out, purpose-of-visit recorded, and escort by an authorized person unless you have a documented exception. Keep the visitor records as evidence. (PCI DSS v4.0.1 Requirement 9.2.1)
What evidence is most likely to be requested by an assessor?
Expect requests for your CDE physical boundary definition, the current authorized access list, samples of access approvals and removals, and visitor logs for entries into CDE areas. Be ready to demonstrate the controls during a walkthrough. (PCI DSS v4.0.1 Requirement 9.2.1)
What’s the fastest way to fail this requirement during an assessment?
Having an unclear physical CDE boundary or being unable to produce evidence that only authorized individuals can enter the CDE area. Missing visitor logs and stale badge access for leavers are also common failure points. (PCI DSS v4.0.1 Requirement 9.2.1)
Frequently Asked Questions
What counts as “facility entry controls” for the CDE?
Controls that restrict entry into areas containing CDE systems, such as badge readers, locks, or guards. The key is that they actually prevent unauthorized access and you can show evidence they are in place. (PCI DSS v4.0.1 Requirement 9.2.1)
If my CDE systems are in a shared server room, do I have to secure the whole room?
You need a defined boundary that restricts physical access to the CDE systems. That can be the entire room or a cage/locked rack inside the room, as long as unauthorized people cannot physically reach the CDE systems. (PCI DSS v4.0.1 Requirement 9.2.1)
Do I need electronic badge logs to pass PCI for Requirement 9.2.1?
The requirement calls for “appropriate facility entry controls,” not a specific technology. If you use mechanical locks or guards, you still need strong authorization practices and records that demonstrate restricted entry. (PCI DSS v4.0.1 Requirement 9.2.1)
How should we handle third party technicians who need occasional access?
Put them through a documented process: identity verification, sign-in/sign-out, purpose-of-visit recorded, and escort by an authorized person unless you have a documented exception. Keep the visitor records as evidence. (PCI DSS v4.0.1 Requirement 9.2.1)
What evidence is most likely to be requested by an assessor?
Expect requests for your CDE physical boundary definition, the current authorized access list, samples of access approvals and removals, and visitor logs for entries into CDE areas. Be ready to demonstrate the controls during a walkthrough. (PCI DSS v4.0.1 Requirement 9.2.1)
What’s the fastest way to fail this requirement during an assessment?
Having an unclear physical CDE boundary or being unable to produce evidence that only authorized individuals can enter the CDE area. Missing visitor logs and stale badge access for leavers are also common failure points. (PCI DSS v4.0.1 Requirement 9.2.1)
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream