PCI DSS 9.5.1.3: Training is provided for personnel in POI environments to be aware of attempted tampering
PCI DSS v4.0.1 control 9.5.1.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 9.5.
Requirement 9: Restrict Physical Access to Cardholder Data › Section 9.5
Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:
- Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.
- Procedures to ensure devices are not installed, replaced, or returned without verification.
- Being aware of suspicious behavior around devices.
- Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel.
Summary
Train the people who work near card readers to spot tampering, to check who repair engineers really are, and to report what they see.
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.5.1.3.a | Review training materials for personnel in POI environments to verify they include all elements specified in this requirement. |
| 9.5.1.3.b | Interview personnel in POI environments to verify they have received training and know the procedures for all elements specified in this requirement. |
Four elements, and the first is the one that stops the actual attack: verifying the identity of any third party claiming to be repair or maintenance personnel before granting them access to a device. Real skimmer installations are frequently social: someone arrives in a uniform, says they are here to service the terminal, and is shown to it. No inspection regime catches a device tampered with by someone the staff helped. The second element extends that to devices not being installed, replaced or returned without verification, which covers the delivery that nobody ordered. Procedure 9.5.1.3.b interviews the personnel, so this is assessed on what the staff on the shop floor actually know, not on the existence of a training deck.
What to prepare
- The training material, checked against all four elements.
- Training records for personnel in POI environments, including part-time and seasonal staff.
- The verification procedure staff are expected to follow for an unexpected engineer.
- The reporting route, which staff should be able to name.
How to implement it
1. Give staff a script and permission to refuse. Verification works only if declining to grant access is an acceptable outcome, and the person on the counter needs to know that before an engineer is standing in front of them.
2. Name who to call to verify. "Check with the manager" fails when the manager is off. A number that confirms whether a visit was scheduled is what makes the first element usable.
3. Cover seasonal and part-time staff. They work the busiest periods and are the least likely to have been trained, which is the combination an attacker wants.
4. Make reporting easy and blameless. The fourth element is reporting, and staff will not report a suspicion they think might be wrong if being wrong is costly.
Where this commonly fails
- Training that covers what tampering looks like and not how to verify an engineer, which is how devices are actually compromised.
- Staff who have the training on record and cannot describe it, which the interview finds.
- Seasonal staff untrained, at exactly the times sites are busiest.
- No named verification contact, so an unexpected engineer is judged on their uniform.
Related controls
Others in section 9.5:
| Control | What it requires |
|---|---|
| 9.5.1 | POI devices that capture payment card data via direct physical interaction with the payment… |
| 9.5.1.1 | An up-to-date list of POI devices is maintained… |
| 9.5.1.2 | POI device surfaces are periodically inspected to detect tampering and unauthorized substitution |
← 9.5.1.2 · All controls · 10.1.1 →
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.