PCI DSS 12.10.2: At least once every 12 months, the security incident response plan
PCI DSS v4.0.1 control 12.10.2: 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
At least once every 12 months, the security incident response plan is:
- Reviewed and the content is updated as needed.
- Tested, including all elements listed in Requirement 12.10.1.
Summary
Review and test the incident response plan at least once a year, covering every element it is required to contain.
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.2 | Interview personnel and review documentation to verify that, at least once every 12 months, the security incident response plan is: • Reviewed and updated as needed. • Tested, including all elements listed in Requirement 12.10.1. |
The counterpart that makes 12.10.1 real. That control requires the plan to exist and to be ready to activate; this one requires it to be reviewed, updated as needed, and tested annually, and the test must cover all elements listed in 12.10.1. That last phrase is the one to plan against: a tabletop exercise about ransomware does not test payment brand notification, business recovery or the data backup processes, and those are named elements. Note also that 12.10.1.b already examines documentation from previous incidents, so a real incident worked through the plan is strong evidence for both controls.
What to prepare
- The dated review record, and what changed as a result.
- The test record, mapped element by element against 12.10.1 so coverage is demonstrable.
- Participant list and the findings the test produced.
- Evidence the findings were acted on before the next cycle.
How to implement it
1. Map the test to the elements, on paper. The cheapest way to satisfy "including all elements" is a table of the seven elements with what exercised each. It also shows immediately which ones your scenario never touched.
2. Test the notification path for real. Confirming you hold the acquirer's current incident contact is the single most valuable minute of the exercise, and it is the element most likely to have gone stale.
3. Use a real incident where you had one. Working the plan during an actual event and writing it up covers this control and 12.10.1.b together, and it is more convincing than any exercise.
4. Record what the test found. A test with no findings usually means it was a walkthrough, and the findings are what makes the annual review non-trivial.
Where this commonly fails
- A tabletop covering one scenario, presented as testing all elements.
- Reviewed annually with no evidence of a test, when both are required.
- Contacts unverified, so the notification element is untested in the one way that matters.
- Findings raised and never closed, so each year's test rediscovers them.
Related controls
This control refers to 12.10.1.
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.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.10.1 · All controls · 12.10.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.