PCI DSS Requirement 12.10.2 says to test your incident response plan at least once a year. Most organizations read that, schedule a tabletop, and assume they’re covered. Then their QSA starts asking questions, and it turns out the exercise didn’t actually test the plan — it tested whether people could sit in a room and nod along to a scenario.
Here’s what the requirement actually says, what your QSA is looking for, and what separates an exercise that passes from one that generates a finding.
What 12.10.2 actually says
The requirement is one sentence:
“Review and test the plan, including all elements listed in Requirement 12.10.1, at least once every 12 months.”
Two things matter here. First, “all elements listed in Requirement 12.10.1.” Not some of them. Not the ones your team feels comfortable with. All of them. Second, “at least once every 12 months” — and the test has to fall within your assessment period. An exercise from 14 months ago doesn’t count, no matter how thorough it was.
PCI DSS v4.0.1 didn’t change the wording of 12.10.2, but it expanded what your plan needs to cover — which means your exercise now needs to cover more ground too.
What 12.10.1 requires you to test
This is where most exercises fall short. Requirement 12.10.1 defines what your IR plan must include, and 12.10.2 says you have to test all of it. Here’s the list:
- Roles, responsibilities, and communication strategies — including notification of payment brands and acquirers
- Incident response procedures — specific to different types of incidents, not a one-size-fits-all playbook
- Business recovery and continuity procedures
- Data backup processes
- Legal requirements for reporting compromises — this varies by jurisdiction and card brand
- Coverage of all critical system components
- Reference to or inclusion of payment brand incident response procedures
That last bullet is the one that catches people. Your QSA wants to see that your exercise included a step where someone looked up the specific notification requirements for Visa, Mastercard, or whatever brands you process. Not “we’d notify the card brands” — the actual timelines, contacts, and procedures.
What changed in 4.0.1
Three additions in PCI DSS 4.0.1 expand the scope of what a compliant exercise should cover:
12.10.4.1 — Periodic IR training. Personnel involved in incident response must receive training at least annually, or more frequently based on a targeted risk analysis. Your exercise can serve double duty here — a well-run tabletop is training and testing in one.
12.10.7 — PAN discovery response. When payment card data shows up outside documented storage locations, your plan now needs a procedure for retrieving, securely deleting, or migrating that data into the CDE. This is a new incident type. If your exercise doesn’t cover it, you’re missing a requirement that went live in v4.0.1.
11.6.1 — Payment page monitoring. Change and tamper detection for payment pages is now required. A good exercise scenario should include detection of unauthorized changes to your checkout flow — skimming attacks, Magecart-style injections — because that’s what this requirement was built to catch.
What your QSA actually evaluates
There’s a gap between what the requirement says and what QSAs actually scrutinize. Here’s the real list:
The scenario has to involve card data. A generic ransomware tabletop doesn’t satisfy 12.10.2. Your QSA wants to see that you simulated a payment card data compromise — a breach of CHD, a skimming attack on your payment page, unauthorized access to stored PAN. The exercise needs to test your PCI-specific response, not your general IR capabilities.
Participation has to be cross-functional. Security running an exercise by themselves doesn’t demonstrate that legal knows the notification requirements, that comms has a customer communication plan, or that someone can actually reach the acquirer on a Saturday. QSAs check the participant list for breadth.
Decisions, not attendance. A sign-in sheet proves people were in the room. It doesn’t prove the plan was tested. QSAs want to see what the team decided at each step — who made the containment call, how long it took to identify notification obligations, whether anyone knew the forensic investigator requirements for card brands.
Remediation is non-negotiable. If the exercise surfaced gaps — and a good exercise always does — the QSA wants to see that those gaps were addressed. Updated contact lists, revised procedures, new monitoring rules. The closed loop matters as much as the exercise itself.
Look — QSAs have seen every version of “we technically did this.” The difference between a mature program and a checkbox exercise is whether the team actually practiced their specific payment card breach response, or just sat through a meeting with an incident response theme.
Common findings that fail assessment
Same gaps, every assessment cycle:
The exercise didn’t cover all 12.10.1 elements. The team tested detection and containment but never touched acquirer notification, legal reporting, or payment brand procedures. Partial coverage = partial credit = finding.
The scenario was a generic outage. “A server went down” is not a card data compromise. The exercise needs to simulate something that triggers PCI-specific response procedures — breach of CHD, compromised payment application, PAN discovered outside the CDE.
No remediation follow-through. The exercise found that nobody had the acquirer’s emergency contact number. Six months later, nobody still has it. Your QSA sees an exercise that identified a problem and an organization that ignored it.
Testing happened outside the assessment period. If your assessment covers January through December and your last exercise was the previous November, it doesn’t count. Timing matters.
Missing 4.0.1 coverage. The exercise predates your PCI DSS 4.0.1 transition and doesn’t cover PAN discovery response (12.10.7) or payment page monitoring incidents (11.6.1). Your QSA will note this.
Running a PCI DSS incident response test that passes
Pick a scenario involving card data. Simulate a web skimming attack on your payment page, unauthorized access to stored PAN, or a third-party processor compromise. Make it specific to your environment — your payment flow, your card brands, your acquirer relationships.
Get the right people in the room. At minimum: IR lead, security operations, legal, communications, and whoever manages your acquirer and payment brand relationships. For e-commerce, include your web development team. For POS environments, include your store operations contacts.
Walk through acquirer notification. Most card brand programs require notification within 24-72 hours. Your exercise should test whether your team knows the specific timelines, who makes the call, and what information the acquirer needs. This is the step most exercises skip and most QSAs flag.
Test the new 4.0.1 requirements. Include a scenario beat where PAN is discovered outside the CDE — maybe in a log file, a shared drive, or a dev environment. Walk through the 12.10.7 response: retrieve, delete, or migrate. This shows your QSA that your plan has been updated for the current standard.
Document decisions, not just attendance. At each decision point: What did the team know? What were the options? What did they choose? Why? This is what makes an exercise artifact useful evidence — not a calendar invite and a summary paragraph.
The documentation that passes without questions
Here’s what a clean exercise artifact looks like — the kind a QSA reviews and moves on:
| Element | Why it matters |
|---|---|
| Exercise date and duration | Proves testing fell within the assessment period |
| Participant names and roles | Proves cross-functional involvement |
| Scenario involving CHD/PAN | Proves PCI-specific testing, not generic IR |
| 12.10.1 element coverage | Proves all required plan elements were tested |
| Decision log with timestamps | Proves meaningful participation, not just attendance |
| Acquirer/brand notification walkthrough | Proves payment-specific procedures were tested |
| After-action findings | Proves the exercise surfaced actionable gaps |
| Remediation status | Proves findings were addressed — the closed loop |
This maps closely to what SOC 2 auditors look for — if you’re maintaining both certifications, a well-structured exercise can satisfy both with a single artifact.
Producing this manually — facilitator notes, formatted reports, chasing people for their observations — takes hours. That overhead is why most teams only test once a year, right at the compliance minimum.
We built Breachdeck to handle this automatically. Every exercise produces a scored debrief with timestamped decisions, competency breakdowns across four dimensions, and a one-click PDF that maps to every row in the table above. Run the demo — it takes five minutes, and the debrief it generates is the artifact your QSA is looking for.
