PCI DSS 12.10.5: The security incident response plan includes monitoring and responding to alerts from security
PCI DSS v4.0.1 control 12.10.5: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 12.10.
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.10
The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to:
- Intrusion-detection and intrusion-prevention systems.
- Network security controls.
- Change-detection mechanisms for critical files.
- The change-and tamper-detection mechanism for payment pages. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
- Detection of unauthorized wireless access points.
Summary
The incident response plan says what happens when each of your detection systems raises an alert.
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 | |
|---|---|
| 12.10.5 | Examine documentation and observe incident response processes to verify that monitoring and responding to alerts from security monitoring systems are covered in the security incident response plan, including but not limited to the systems specified in this requirement. |
This is the control that connects the plan to the machinery. The requirement names five sources and they map onto controls elsewhere: intrusion detection and prevention, the network security controls in Requirement 1, change detection on critical files in 11.5.2, the payment page change-and-tamper detection in 11.6.1, and detection of unauthorised wireless access points. The list is "including but not limited to", so it is a floor. The bullet most often absent is the payment page one: it was published as future-dated, became mandatory on 31 March 2025 with the rest of the v4.x future-dated controls, and incident response plans written before then do not mention it. The procedure observes incident response processes as well as reading the plan, so a plan listing the sources while nobody monitors one of them is visible.
What to prepare
- The plan section covering alert monitoring and response, checked against all five named sources.
- The detection systems themselves, so the plan and the estate can be compared.
- Who receives each alert type and what they do with it.
- Recent examples of an alert being actioned.
How to implement it
1. Check the payment page bullet specifically. It is the newest and the one an older plan will be missing, and it is the source tied to the script-integrity work this product exists to support.
2. Name the destination for each source. "Alerts are monitored" is not a response process. Who sees it, in what tool, and what they do next is.
3. Cover the wireless bullet even if you think you have no wireless. Detecting unauthorised access points is the point, and an entity with no sanctioned wireless still needs to notice an unsanctioned one.
4. Treat the list as a floor. Anything else that detects a security event belongs in the plan too, which is what "including but not limited to" is asking for.
Where this commonly fails
- The payment page mechanism absent, because the plan predates the effective date.
- Sources listed in the plan with no named recipient, so the alert has nowhere to go.
- The wireless bullet dismissed as not applicable by an entity that runs no wireless, which is the case it is written for.
- A plan that describes monitoring the entity does not actually do, which the observation in the procedure surfaces.
Related controls
Others in section 12.10:
| Control | What it requires |
|---|---|
| 12.10.1 | An incident response plan exists and is ready to be activated in the event of a suspected… |
| 12.10.2 | At least once every 12 months, the security incident response plan… |
| 12.10.3 | Specific personnel are designated to be available on a 24/7 basis to respond to suspected… |
| 12.10.4 | Personnel responsible for responding to suspected and confirmed security incidents… |
| 12.10.4.1 | The frequency of periodic training for incident response personnel is defined in the entity’s… |
| 12.10.6 | The security incident response plan is modified and evolved according to lessons learned… |
| 12.10.7 | Incident response procedures are in place, to be initiated upon the detection of stored PAN… |
← 12.10.4.1 · All controls · 12.10.6 →
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.