PCI DSS 12.10.5: The incident response plan says what happens when each of your detection systems raises an alert.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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 payment page bullet needs a specific check: it was best practice until 31 March 2025, it is required now, and an incident response plan written before then may 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, an older plan may not have it, and its alerts come from the mechanism that 11.6.1 requires.
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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
- Incident Response Plan
- Intrusion Detection System (IDS)
- Intrusion Prevention System (IPS)
- Monitoring
- Wireless Access Point (WAP)
← 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.