PCI DSS 1.5.1: Security controls are implemented on any computing devices
PCI DSS v4.0.1 control 1.5.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.5.
Requirement 1: Install and Maintain Network Security Controls › Section 1.5
Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:
- Specific configuration settings are defined to prevent threats being introduced into the entity’s network.
- Security controls are actively running.
- Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.
Summary
Devices that are on the internet and also reach the cardholder data environment carry defined security controls, running, and users cannot turn them off.
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 | |
|---|---|
| 1.5.1.a | Examine policies and configuration standards and interview personnel to verify security controls for computing devices that connect to both untrusted networks, and the CDE, are implemented in accordance with all elements specified in this requirement. |
| 1.5.1.b | Examine configuration settings on computing devices that connect to both untrusted networks and the CDE to verify settings are implemented in accordance with all elements specified in this requirement. |
The laptop control. The scope trigger is a device that connects to both untrusted networks and the CDE, which is the ordinary corporate laptop: on a hotel network in the morning and connected to the CDE in the afternoon. It is a bridge between the two, and this control is what stops it carrying something across. Two things are worth reading closely. Employee-owned devices are explicitly named, so a bring-your-own-device arrangement does not sit outside this, and an entity permitting personal laptops to reach the CDE has to be able to evidence controls on hardware it does not own. And the third element is the same shape as 5.3.5: controls not alterable by users unless specifically documented and authorised by management for a limited period, so a user with local administrator rights and no tamper protection defeats it.
What to prepare
- The population of devices meeting the both-networks trigger, including any personally owned.
- The defined configuration settings for them, as policies and standards.
- Evidence the controls are actively running on a sample, which 1.5.1.b examines on the devices.
- The approval process for any user-authorised exception, with expiry.
How to implement it
1. Define the population before defining controls. The trigger is specific, and an entity that has not identified which devices bridge both networks cannot show the controls reach them.
2. Resolve the personal-device question deliberately. Either bring them into management with evidence, or stop them reaching the CDE. Permitting unmanaged personal devices and hoping is the position this control is written against.
3. Enforce non-alterability technically. Tamper protection and removal of local administrator rights, since the element is that users cannot alter the controls rather than that they are asked not to.
4. Check the controls are running, not just installed. 1.5.1.b examines settings on the devices, and an agent installed and stopped satisfies nothing.
Where this commonly fails
- Bring-your-own-device arrangements treated as out of scope, when the requirement names employee-owned devices.
- Controls defined in policy and not verified on the devices themselves.
- Local administrator rights with no tamper protection, so users can disable what is running.
- Contractor laptops reaching the CDE with no equivalent controls, because they belong to another company.
Related controls
← 1.4.5 · All controls · 2.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.