PCI DSS 12.10.6: The security incident response plan is modified and evolved according to lessons learned
PCI DSS v4.0.1 control 12.10.6: 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
The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.
Summary
Change the plan when an incident teaches you something, and when the industry moves.
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.6.a | Examine policies and procedures to verify that processes are defined to modify and evolve the security incident response plan according to lessons learned and to incorporate industry developments. |
| 12.10.6.b | Examine the security incident response plan and interview responsible personnel to verify that the incident response plan is modified and evolved according to lessons learned and to incorporate industry developments. |
Two triggers, and the second is the one nobody evidences. Lessons learned is familiar: something happened, the plan was wrong about it, the plan changed. Industry developments has no incident behind it, so nothing prompts it, and it is the half most entities cannot show. Procedure 12.10.6.b examines the plan and interviews personnel, so the evidence is a plan that visibly changed rather than a process that says it would. The cheapest way to satisfy the second trigger is to make it an agenda item somewhere that already happens, since a new attack technique against payment pages or a new PCI SSC bulletin is a development the plan should absorb without waiting for it to happen to you.
What to prepare
- The documented process naming both triggers.
- A version history for the plan, showing what changed and why.
- Post-incident reviews and what they changed.
- At least one change traceable to an industry development rather than to an incident.
How to implement it
1. Version the plan and record the reason for each change. It is the whole evidence base for this control, and it costs nothing if done as you go.
2. Make lessons learned end in an edit or a decision not to edit. A review that produces observations and no plan change leaves the trigger unevidenced.
3. Give the industry-developments trigger an owner and a cadence. Attach it to the annual test in 12.10.2 if nothing else, so it happens.
4. Count near misses. They teach the same lessons at lower cost, and they are legitimate input to this control.
Where this commonly fails
- A plan unchanged for years in an environment that has changed a great deal.
- Post-incident reviews held and never connected to the document.
- The industry-developments trigger present in the process and absent from the version history.
- Changes made with no record of what prompted them, so neither trigger can be demonstrated.
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.5 | The security incident response plan includes monitoring and responding to alerts from security… |
| 12.10.7 | Incident response procedures are in place, to be initiated upon the detection of stored PAN… |
← 12.10.5 · All controls · 12.10.7 →
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.