PCI DSS 9.3.1.1: Physical access to sensitive areas within the CDE for personnel is controlled
PCI DSS v4.0.1 control 9.3.1.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 9.3.
Requirement 9: Restrict Physical Access to Cardholder Data › Section 9.3
Physical access to sensitive areas within the CDE for personnel is controlled as follows:
- Access is authorized and based on individual job function.
- Access is revoked immediately upon termination.
- All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination.
Summary
Inside the cardholder data environment, sensitive areas get their own access control, revoked immediately on termination, with every key and card returned.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 9.3.1.1.a | Observe personnel in sensitive areas within the CDE, interview responsible personnel, and examine physical access control lists to verify that: • Access to the sensitive area is authorized. • Access is required for the individual’s job function. |
| 9.3.1.1.b | Observe processes and interview personnel to verify that access of all personnel is revoked immediately upon termination. |
| 9.3.1.1.c | For terminated personnel, examine physical access controls lists and interview responsible personnel to verify that all physical access mechanisms (such as keys, access cards, etc.) were returned or disabled. |
A tighter ring inside 9.3.1. That control governs the CDE; this one governs the sensitive areas within it, typically the data centre, the server room, or wherever the card data actually lives. Access there is based on individual job function, so being in the CDE team is not itself a reason. Two words carry weight: immediately upon termination, which is the same standard as 8.2.5 and not the next access review, and all physical access mechanisms returned or disabled, which 9.3.1.1.c tests by examining access lists for terminated people. A key that was never handed back fails this even after the badge was deactivated.
What to prepare
- The list of sensitive areas within the CDE, agreed rather than assumed.
- The access list for each, with the job function justifying each person.
- The register of physical access mechanisms issued: cards, keys, fobs, combinations.
- Recent terminations, with evidence of same-day revocation and return.
How to implement it
1. Define sensitive areas explicitly. The control depends on the boundary, and an entity that has not drawn it cannot show access to it is controlled.
2. Justify by job function, one person at a time. Group-based physical access is how a list grows to include everyone who once needed it.
3. Track keys as issued items. Cards can be disabled centrally; keys cannot, and 9.3.1.1.c asks about all mechanisms. Without an issue register there is nothing to check a return against.
4. Change the combination when someone leaves. A shared code is a physical access mechanism that cannot be returned, so leaving it unchanged means access was not revoked.
Where this commonly fails
- Badge disabled and a physical key never returned, which fails on the mechanism the entity forgot it issued.
- Access granted by team rather than by job function, so the list outgrows the need.
- Revocation at the next review rather than immediately.
- Door codes unchanged after a departure, since nobody thinks of a code as something to return.
Related controls
Others in section 9.3:
| Control | What it requires |
|---|---|
| 9.3.1 | Procedures are implemented for authorizing and managing physical access of personnel… |
| 9.3.2 | Procedures are implemented for authorizing and managing visitor access to the CDE… |
| 9.3.3 | Visitor badges or identification are surrendered or deactivated before visitors leave… |
| 9.3.4 | Visitor logs are used to maintain a physical record of visitor activity both within… |
← 9.3.1 · All controls · 9.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.