PCI DSS Requirement 12.10 gets summarised everywhere as "have an incident response plan." That's true, but it undersells what an assessor actually checks — a single plan document doesn't evidence seven sub-requirements spanning 24/7 staffing, annual testing, risk-based training frequency, and a defined response to a very specific and often-missed scenario: stored account data turning up somewhere it was never supposed to be.
Yes — but "an incident response plan" is the smallest part of what Requirement 12.10 actually asks for. PCI DSS v4.0.1's Requirement 12.10 is titled "Respond immediately to suspected and confirmed security incidents that could impact the cardholder data environment," and it's built from seven distinct sub-requirements, each one needing its own evidence trail, not a single narrative document that mentions all of them in passing.
12.10.1 — The plan and its required elements. This is the core: a documented incident response plan, ready to activate, covering roles and responsibilities, communication strategies, business recovery and continuity procedures, data backup processes, legal requirements for reporting compromises, and coverage of all critical system components. It's the anchor document, but it's one document among many that 12.10 requires.
12.10.2 — Annual review and test. The plan has to be reviewed, updated as needed, and tested — including every element required by 12.10.1 — at least once every 12 months. A plan that was correct at go-live and never revisited fails this sub-requirement regardless of how good it originally was.
12.10.3 — 24/7 personnel. Specific personnel must be available around the clock to respond to suspected or confirmed incidents. This needs to be evidenced with a roster, not asserted as a general capability.
12.10.4 and 12.10.4.1 — Training and its risk-based frequency. Personnel responsible for responding to incidents must be appropriately and periodically trained — and 12.10.4.1 specifically requires that training frequency be set by a targeted risk analysis performed under Requirement 12.3.1, not an arbitrary annual default.
12.10.5 — Responding to alerts from security monitoring. The plan has to include a structured response to alerts generated by security monitoring systems — intrusion detection, file integrity monitoring, change-detection mechanisms and change-and-tamper detection for payment pages all feed into this.
12.10.6 — Lessons learned and plan evolution. The incident response plan must be modified and evolved according to lessons learned and to incorporate industry developments — meaning static plans that never change after an incident are themselves a compliance gap.
12.10.7 — Response to stored PAN found where not expected. A specific, separate requirement covering what happens when primary account number data is discovered somewhere outside its expected, approved storage locations — a scenario distinct from a breach in progress, and one many incident response plans overlook entirely.
The confusion is understandable — 12.10 is a single requirement number, and most general security guidance treats "incident response plan" as one deliverable. But an assessor working through 12.10 during a PCI DSS assessment walks each sub-requirement separately, and each one has a distinct type of evidence:
|
Sub-requirement |
What gets evidenced |
Typical artefact |
|
12.10.1 |
The plan itself and its required elements |
Incident response plan, roles matrix, recovery and continuity plan |
|
12.10.2 |
Annual review and testing |
Test and exercise plan, tabletop exercise report, annual review record |
|
12.10.3 |
24/7 responder availability |
On-call roster, team charter |
|
12.10.4 / 12.10.4.1 |
Training and its risk-based frequency |
Training plan, training register, targeted risk analysis |
|
12.10.5 |
Structured response to monitoring alerts |
Alert triage procedure, escalation matrix, alert register |
|
12.10.6 |
Lessons-learned-driven plan evolution |
Post-incident review, root cause analysis, plan update record |
|
12.10.7 |
Response to unexpected stored PAN |
Dedicated procedure and finding record |
A single "incident response plan" document, however well-written, cannot carry all seven rows of evidence on its own — which is exactly why PCI DSS incident response documentation runs to dozens of distinct artefacts rather than one.
Requirement 12.10 doesn't stand alone — several of its sub-requirements depend on evidence generated under other parts of PCI DSS v4.0.1:
This cross-referencing is why a documentation set built purely around 12.10 in isolation, without pulling in its supporting requirements, tends to have gaps an assessor finds quickly.
Organisations juggling multiple regulatory incident response obligations should note two structural differences. First, PCI DSS sets no fixed external reporting clock — there's no 24-hour or 4-hour deadline written into the standard itself; notification of payment brands and acquirers, and any legal reporting, follows the payment brands' own programmes and applicable law instead. Second, PCI DSS explicitly distinguishes required documents from supporting evidence — every document can be assessed as either directly evidencing a defined requirement (which an assessor expects to see) or strengthening the response capability without being the primary evidence for any single requirement.
Because 12.10's seven sub-requirements pull in evidence from across governance, monitoring, logging, recovery, testing, training and reporting, the practical way to manage this is by category rather than by requirement number alone. The PCI DSS Incident Response Document Library organises the full set into 13 categories — spanning governance and plan, roles and 24/7 readiness, procedures and containment, monitoring and alerting, logging, control-failure response, malware and change detection, account data compromise response, recovery and backups, testing, training, lessons learned, and reporting and evidence — with every one of the 67 documents inside carrying a clear "Required by PCI DSS" or "Supporting evidence" status and a direct mapping to the specific requirement number it evidences.
Keeping that many documents current requires more than a folder structure. The accompanying master register tracks ownership, PCI DSS requirement mapping, review frequency, retention and evidence location for every document in one Excel-ready sheet — the working control document a compliance team actually maintains between assessments, rather than a static reference read once and forgotten.
1. Does PCI DSS require a written incident response plan?
Yes. Requirement 12.10.1 requires a documented incident response plan, ready to activate, covering roles and responsibilities, communication strategies, recovery and continuity procedures, data backup processes, and legal reporting requirements for any incident that could impact the cardholder data environment.
2. Is having an incident response plan enough to satisfy Requirement 12.10?
No. Requirement 12.10 comprises seven sub-requirements, from 12.10.1 through 12.10.7, covering the plan itself, annual review and testing, 24/7 responder availability, risk-based training frequency, structured response to monitoring alerts, lessons-learned-driven plan evolution, and a specific response process for unexpected stored account data. A single plan document typically cannot evidence all seven on its own.
3. How often must the PCI DSS incident response plan be tested?
Requirement 12.10.2 requires the plan to be reviewed, updated as needed, and tested, including every element required by 12.10.1, at least once every 12 months.
4. How is incident response training frequency determined under PCI DSS?
Requirement 12.10.4 requires personnel responsible for incident response to be periodically trained, and 12.10.4.1 requires that training frequency be set by a targeted risk analysis performed under Requirement 12.3.1, rather than a fixed calendar default applied uniformly.
5. What does PCI DSS require if stored cardholder data is found somewhere it shouldn't be?
Requirement 12.10.7 requires a defined response process for primary account number data discovered outside its expected, approved storage locations, a distinct scenario from an active breach and one commonly missing from generic incident response plans.
6. Does PCI DSS set a fixed timeframe for reporting an incident, like NIS2's 24 hours or DORA's 4 hours?
No. PCI DSS sets no fixed external reporting clock of its own. Notification of payment brands and acquirers, and any legal reporting obligations, follow the payment brands' own programmes and applicable law rather than a hardcoded deadline in the standard.
7. What's the difference between a "required" and a "supporting evidence" document under PCI DSS incident response documentation?
A required document directly evidences a defined PCI DSS requirement and is expected to be reviewed by an assessor, such as the incident response plan under 12.10.1. A supporting evidence document strengthens the response capability and provides useful context without being the primary evidence for any single requirement.
8. How many documents are typically needed to fully evidence PCI DSS Requirement 12.10?
A comprehensive set spans 67 documents across 13 categories, covering governance, roles and readiness, procedures, monitoring, logging, detection, recovery, testing, training, lessons learned, and reporting, reflecting how many of Requirement 12.10's sub-requirements draw on evidence generated elsewhere in the standard.