Does PCI DSS Require an Incident Response Plan?

Date: 13 August 2026

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.

Does PCI DSS Require an Incident Response Plan? What Requirement 12.10 Actually Demands

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.

The Seven Sub-Requirements Behind 12.10

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.

Why This Reads as "One Requirement" but Assesses as Seven

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:

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.

The Requirements That Feed 12.10 From Elsewhere in the Standard

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:

• Requirement 10 (audit logging, log protection, log review, retention, time synchronisation, and detection of control failures) supplies the evidence trail 12.10.5's alert-response process actually acts on.
• Requirement 11 (intrusion detection and prevention, file integrity monitoring, and payment page tamper detection) generates the alerts 12.10.5 requires a structured response to.
• Requirements 5, 6 and 12.3.1 (anti-malware, timely patching, and the targeted risk analysis) directly set the training frequency 12.10.4.1 requires.
• Requirements 12.8 and 12.9 (third-party service provider risk and their acknowledged responsibilities) determine which incident duties sit with the organisation versus its service providers.

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.

Two Things PCI DSS Does Differently From NIS2 and DORA

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.

Structuring the Evidence: Categories, Numbering and a Master Register

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.

Common Gaps Assessors Find in 12.10 Documentation

• A plan document that never mentions 24/7 staffing, training frequency or the stored-PAN scenario. 12.10.1's plan can look complete on paper while several of the other six sub-requirements remain unevidenced elsewhere.
• Training delivered on a fixed annual schedule with no targeted risk analysis behind it. 12.10.4.1 specifically requires the frequency to be set by a risk analysis performed under 12.3.1, not a default calendar interval.
• No dedicated procedure for stored PAN found where not expected. 12.10.7 is often the most overlooked sub-requirement, since it addresses a discovery scenario rather than an active attack.
• A plan that hasn't changed since it was first written. 12.10.6 explicitly requires evolution driven by lessons learned and industry developments — an unchanged plan is itself evidence of a gap.
• No link between monitoring alerts and a documented response procedure. 12.10.5 requires more than having monitoring tools in place; it requires a defined process for what happens when those tools generate an alert.

Getting Started

1. Map your current documentation against all seven 12.10 sub-requirements individually, not against "having an incident response plan" as a single checkbox.
2. Confirm your training frequency is backed by a targeted risk analysis under 12.3.1, rather than an assumed annual cadence.
3. Check for a dedicated stored-PAN discovery procedure — 12.10.7 is easy to miss precisely because it isn't an active-breach scenario.
4. Benchmark the full set against the PCI DSS Incident Response Document Library to see where your existing documentation sits across all 13 categories.
5. Assign owners and review dates using the accompanying master register, so the documentation stays assessment-ready between cycles rather than being rebuilt from scratch before each one.

Key Terms

• Cardholder Data Environment (CDE): The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, and any connected systems, which Requirement 12.10 protects.
• Requirement 12.10: The PCI DSS v4.0.1 requirement to respond immediately to suspected and confirmed security incidents that could impact the CDE, comprising seven sub-requirements from 12.10.1 to 12.10.7.
• Targeted Risk Analysis: The risk-analysis process required under Requirement 12.3.1 that determines incident response training frequency under 12.10.4.1, rather than a fixed default interval.
• Required Document: A PCI DSS document status indicating the artefact directly evidences a defined requirement and is expected to be reviewed by an assessor.
• Supporting Evidence: A PCI DSS document status indicating the artefact strengthens the incident response capability without being the primary evidence for a single requirement.
• Unexpected Stored PAN: Primary account number data discovered outside its expected, approved storage locations, addressed specifically under Requirement 12.10.7.

Frequently Asked Questions About PCI DSS

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.