PCI DSS 10.7.1 (service providers): Failures of critical security control systems are detected, alerted, and addressed promptly
PCI DSS v4.0.1 control 10.7.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.7.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.7
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- FIM.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
Summary
Service providers: detect, alert on and promptly address failures of the security controls that matter, from a named list.
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 | |
|---|---|
| 10.7.1.a | Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement. |
| 10.7.1.b | Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert. |
Service providers only, and its general counterpart 10.7.2 applies to all entities, so a service provider meets both and the substance is the same. What makes this control worth reading closely is the named list: network security controls, intrusion detection and prevention, file integrity monitoring, anti-malware, physical access controls, logical access controls, audit logging mechanisms, and segmentation controls where used. That is eight system types, and it is "including but not limited to", so it is a floor. The gap it exposes is a familiar one: entities monitor whether systems are up and rarely whether controls are still functioning. A file integrity monitoring agent that stopped, or a firewall in a failed-open state, leaves the host healthy and the control absent.
What to prepare
- The inventory of critical security control systems, checked against all eight named types.
- How failure of each is detected, which is not the same as host monitoring.
- Alert destinations and the promptness expectation.
- Recent examples of a detected failure, which 10.7.1.b observes.
How to implement it
1. Monitor control health, not host health. An agent installed and stopped, or a service running with its policy unapplied, is the failure mode this control names.
2. Work the list of eight one at a time. Each has a different failure signature, and the physical access controls entry is the one most often outside the monitoring estate entirely.
3. Detect silence. For logging and monitoring controls the most reliable signal is a source that stopped reporting, which the equipment itself cannot tell you.
4. Define prompt and hold to it. The word appears in the requirement and an undefined threshold cannot be assessed or met.
Where this commonly fails
- Host uptime monitoring offered as control failure detection.
- Physical access controls omitted, since they sit with facilities rather than IT.
- Segmentation controls excluded, though the requirement names them where used.
- Alerts generated with no defined response time, so "promptly" means nothing.
Related controls
Others in section 10.7:
| Control | What it requires |
|---|---|
| 10.7.2 | Failures of critical security control systems are detected, alerted, and addressed promptly… |
| 10.7.3 | Failures of any critical security control systems are responded to promptly… |
← 10.6.3 · All controls · 10.7.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.