PCI DSS 9.1.1: All security policies and operational procedures that are identified in Requirement 9
PCI DSS v4.0.1 control 9.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 9.1.
Requirement 9: Restrict Physical Access to Cardholder Data › Section 9.1
All security policies and operational procedures that are identified in Requirement 9 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 9 are written down, current, followed, and known to the people they apply to.
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.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 9 are managed in accordance with all elements specified in this requirement. |
Every requirement opens with this control and identical wording, so what matters is what Requirement 9 does to it. Requirement 9 is the only requirement whose procedures are carried out almost entirely by people outside IT. Reception staff issue visitor badges, security guards escort, facilities hold keys, retail assistants stand next to the card readers, and a storage vendor holds the backup tapes. Many of them would not recognise "PCI DSS" as something that concerns them, which makes known to all affected parties the element that fails here and the reason it fails different from anywhere else. Turnover compounds it: the roles performing Requirement 9 tend to be the highest-churn roles in the business, so this awareness decays faster than any other requirement's. Note also that one document inside the requirement has its own dedicated control, 9.5.1.3 for POI personnel training, which is the same shape Requirement 8 has with 8.3.8 and Requirement 11 with 11.4.1. That leaves 9.1.1 covering visitor procedures, media handling and badge administration, which have no equivalent push.
What to prepare
- The Requirement 9 documents as a set: physical access, visitor management, media handling and storage, POI device procedures.
- An owner and a review date on each.
- Who the affected parties are per document, which here means naming non-IT roles and third parties.
- Evidence the procedures reached those people, in a form they would actually read.
How to implement it
1. Write for the person doing the job. A visitor procedure written in the register of an information security policy will not be followed at a reception desk, and "in use" is tested by watching what happens there.
2. Include contracted staff as affected parties. Guards, cleaners and facilities contractors perform Requirement 9 activities and are frequently employed by someone else.
3. Refresh on turnover, not on a calendar. The roles here change more often than the annual cycle, so onboarding is where this element is won.
4. Do not let 9.5.1.3 stand in for the rest. POI training is one document with its own control; the visitor and media procedures have no such mechanism.
Where this commonly fails
- Procedures written for an IT audience and handed to people who do not work in IT.
- Contracted security or facilities staff never counted as affected parties.
- Awareness accurate at the last assessment and eroded by turnover since.
- A document set assembled for the assessment and used at no other time.
Related controls
Others in section 9.1:
| Control | What it requires |
|---|---|
| 9.1.2 | Roles and responsibilities for performing activities in Requirement 9 are documented, assigned… |
← 8.6.3 · All controls · 9.1.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.