PCI DSS 10.7.2: When a security control stops working, you find out promptly rather than at the next assessment.

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.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

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 has ten entries: network security controls, IDS/IPS, change-detection mechanisms, anti-malware, physical access controls, logical access controls, audit logging mechanisms, segmentation controls (if used), audit log review mechanisms, and automated security testing tools (if used). The last two are new since 10.7.1, which this control superseded on 31 March 2025. 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. A typical failure is a component that stops or goes offline, 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 records of real failures, so a year with none recorded is worth checking against the detection itself.

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.

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…

Terms

Glossary entries that name this control, each with its own example, limits and sources:

← 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.