PCI DSS 12.10.2 incident response testing
PCI DSS v4.0.1 asks in-scope merchants and service providers to review and test their incident response plan at least once every 12 months, including every element listed in Requirement 12.10.1.
What 12.10.1 asks your plan to cover
PCI DSS at a glance
- Framework
- PCI DSS v4.0.1
- References
- 12.10.2
- Where testing comes up
- Requirement 12.10.2: review and test the incident response plan, including every element listed in 12.10.1.
- Does the text require it?
- Yes, for in-scope merchants and service providers.
- How often
- At least once every 12 months.
Note: Calmdrill is designed to help you run and document the test. Whether it satisfies 12.10.2 for your environment is for your QSA to decide.
In summary, the plan covers:
- roles and responsibilities
- communication and contact strategies, including notifying payment brands and acquirers
- containment and mitigation for different kinds of incident
- business recovery and continuity
- data backup
- analysis of legal reporting requirements
- coverage of critical system components
- the payment brands’ own response procedures.
A good test touches as many of these as it can. That is why a realistic scenario with injects from legal, support and leadership beats a checklist walk-through.
Scenarios that exercise the 12.10.1 elements
Harbourline, our fictional company, uses Stripe and never stores card data, so the scenarios are not about payment-card data as written. Tell the Game Master about your cardholder data environment and it re-skins the drill, including a payment-brand and acquirer notification thread.
| Scenario | Elements it naturally tests |
|---|---|
| CD-07 Keys in the Wild | Roles, containment, legal reporting analysis, communications |
| CD-09 Poisoned Package | Containment, critical components, recovery (rebuilding from known-good) |
| CD-10 The Open Door | Communications, legal reporting, leadership decisions |
| CD-04 The Restore That Wasn’t | Business recovery, continuity, data backup |
Evidence your QSA will typically look for
- A dated record of the test
- Who took part
- Gaps found, and how they were fixed
- Evidence that the plan was updated (12.10.6, lessons learned)
The record beside this list is filled in from the sample report: an internal scripted playtest of CD-01 at Harbourline, a fictional company. CD-01 is a reliability drill, not a cardholder-data one. It shows the shape of the record.
- Rollback before evidence (T+00:02 to T+00:10)
- Restart approved without evidence (T+00:12)
- Break-glass single point of failure. Tom, the third approver, was unreachable
- IC checklist: "errors first, then changes. No rollback or restart without one line of evidence and a named approver". Owner: IC rotation (Sam). Due: 9 Oct 2026
- Break-glass contact tree: a fourth named approver, phone numbers for all approvers and a 2 a.m. call order. Owner: Security. Due: 13 Oct 2026
- Add the "evidence before rollback/restart" checklist to the incident template
- Publish a break-glass runbook with a fourth named approver, phone numbers and a 2 a.m. call order
Start with one drill
The Kit has all twelve scenarios, the Game Master and the evidence templates. $149 once, for your whole organisation.
Load the Game Master into a Claude or ChatGPT project, describe your cardholder data environment in a few lines, and tell it the exercise is for PCI DSS 12.10.2. It notes that in the report header.