PCI DSS 10.7.2: Failures of critical security control systems are detected, alerted, and addressed promptly
PCI DSS v4.0.1 control 10.7.2: 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
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.
- Change-detection mechanisms.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
- Audit log review mechanisms.
- Automated security testing tools (if used).
Summary
When a security control stops working, you find out promptly rather than at the next assessment.
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.2.a | 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.2.b | 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. |
One of the most consequential controls in v4.0.1 and, for merchants, newly applicable at this level: failures of critical security control systems must be detected, alerted and addressed. The named list is specific and includes network security controls, IDS/IPS, change-detection mechanisms, anti-malware, physical access controls, logical access controls, audit logging and segmentation. The pattern it exists to prevent is a control that fails silently and keeps reporting success: an anti-malware agent that stopped updating, a log source that went quiet, a change-detection mechanism nobody noticed had been disabled. Its counterpart is 10.7.3, which requires the failure to be responded to, not merely noticed.
What to prepare
- The list of critical security control systems in your environment, mapped to the named categories.
- The detection and alerting in place for each, and where the alert goes.
- Records of past failures, showing they were detected and addressed.
How to implement it
1. Alert on silence, not only on errors. Most of these fail by stopping, and a stopped component raises no error. A heartbeat or a last-seen check is what catches it.
2. Route alerts somewhere staffed. A failure detected into an unmonitored channel satisfies detection and fails alerting, which the requirement names separately.
3. Include the change-detection mechanism itself. 11.6.1 watches your payment page; something has to watch that it is still watching.
4. Keep the records. 10.7.3 is assessed against real failures, and an environment with no recorded failures in a year is usually one that is not detecting them.
Where this commonly fails
- Monitoring for errors while the actual failure mode is a process that stopped.
- Alerts sent to a mailbox nobody reads.
- Segmentation and physical access controls omitted, though both are named.
- No failure records at all, which reads as no detection rather than as no failures.
Related controls
Others in section 10.7:
| Control | What it requires |
|---|---|
| 10.7.1 | Service providers: 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.7.1 · All controls · 10.7.3 →
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.