PCI DSS 12.10.1: An incident response plan exists and is ready to be activated in the event of a suspected
PCI DSS v4.0.1 control 12.10.1: the requirement in full, the 2 testing procedures 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
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
- Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
- Incident response procedures with specific containment and mitigation activities for different types of incidents.
- Business recovery and continuity procedures.
- Data backup processes.
- Analysis of legal requirements for reporting compromises.
- Coverage and responses of all critical system components.
- Reference or inclusion of incident response procedures from the payment brands.
Summary
Have an incident response plan that names who does what, covers the specific things that could go wrong, and is ready to run before you need it.
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.1.a | Examine the incident response plan to verify that the plan exists and includes at least the elements specified in this requirement. |
| 12.10.1.b | Interview personnel and examine documentation from previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed. |
12.10.1.a examines the plan against the seven listed elements. 12.10.1.b is the harder one: it interviews personnel and examines documentation from incidents you have already had, to verify the plan was actually followed. A plan that exists and was ignored during a real incident fails this control. The element merchants most often miss is notification of the payment brands and acquirers, which is called out explicitly and is not something you want to be researching during an incident. For e-commerce merchants the realistic trigger is a payment page script alert from 11.6.1, so the plan should say what happens when that alert fires.
What to prepare
- The incident response plan, with each of the seven required elements identifiable in it.
- Your acquirer’s and payment brands’ incident notification requirements and contact details, referenced or included.
- Documentation from any incidents or alerts already handled, showing the plan was followed.
- Evidence the plan is current: a review date, and the names in it matched against people who still work there.
How to implement it
1. Write the contact list first and keep it outside the systems it protects. Roles, responsibilities and contact strategy are the first listed element, and a plan stored only on a system that may itself be compromised or unavailable is not ready to be activated. A printed copy or an out-of-band location is the usual answer.
2. Find your acquirer’s notification requirement now. It is an explicit element, the timescales are short, and every acquirer words it differently. Put the actual requirement and the actual contact in the plan rather than a reference to "notify the acquirer".
3. Make containment specific to your incidents. The requirement asks for containment and mitigation for different types of incident. For a hosted-payment-page merchant the realistic ones are an unauthorised script on the payment page, a compromised administrator account, and a provider notifying you of their own breach. Generic containment advice covers none of them well.
4. Rehearse against a real alert. 12.10.1.b looks for evidence the plan was followed. The cheapest way to have that evidence is to treat a genuine 11.6.1 script alert as an incident, work the plan, and write down what happened, including deciding it was benign.
5. Keep it short enough to be usable. A long plan nobody has read is worse evidence than a short one people have. The elements are a minimum content list, not an invitation to write a manual.
Where this commonly fails
- No payment brand or acquirer notification step, which is a named element of the requirement.
- A plan naming people who have left, or a distribution list that no longer resolves.
- Real alerts handled informally over chat, leaving nothing for 12.10.1.b to examine even though the response was competent.
- Containment written only for network intrusion, with nothing for a compromised third-party script, which is the likeliest incident for an e-commerce merchant.
- The plan stored only in the environment it is meant to protect, so it is unavailable exactly when it is needed.
Related controls
Others in section 12.10:
| Control | What it requires |
|---|---|
| 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.5 | The security incident response plan includes monitoring and responding to alerts from security… |
| 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.9.2 · All controls · 12.10.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.