PCI DSS 12.10.2: Review and test the incident response plan at least once every 12 months, covering every element it is required to contain.

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.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

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 every 12 months, 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 at least once every 12 months, and the test must cover all elements listed in 12.10.1. That last phrase is the one to plan against: a tabletop exercise built on one scenario may never reach 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 takes a minute, and the guidance to 12.10.1 stresses keeping contact information current.

3. Use a real incident where you had one. Working the plan during an actual event and writing it up is evidence for 12.10.1.b, and it counts towards this control's test for the elements the event exercised. Test the others separately.

4. Record what the test found. A test with no findings may have been only a walkthrough, and the findings are what give the review every 12 months its substance.

Where this commonly fails

  • A tabletop covering one scenario, presented as testing all elements.
  • Reviewed at least once every 12 months 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.

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…

Terms

Glossary entries that name this control, each with its own example, limits and sources:


← 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.