Every PCI DSS requirement matters, but Requirement 12.10 is the one that determines whether your organization can actually respond when something goes wrong. Having firewalls, encryption, and access controls in place is necessary. Knowing what to do when those controls fail is what separates organizations that survive breaches from those that end up in the news.
The challenge with Requirement 12.10 is that it demands more than a document. Your QSA needs to see a living, tested incident response plan that covers specific scenarios, assigns clear responsibilities, and demonstrates that your team can execute under pressure. A plan that sits in a SharePoint folder untouched since it was written will not pass assessment.
We review incident response plans regularly as part of our PCI DSS penetration testing engagements, and the gap between what organizations think they have and what Requirement 12.10 actually demands is consistently the widest compliance gap we encounter.
What Requirement 12.10 Actually Requires
Requirement 12.10 is structured as a series of sub-requirements that collectively define what your incident response capability must look like. Understanding each one individually matters because QSAs evaluate them separately, and a failure in any single sub-requirement is a finding against the entire requirement.
12.10.1: The incident response plan itself
Your plan must be a documented, formal artifact that is ready to activate at any time. PCI DSS v4.0 specifies that the plan must include all of the following elements:
- Roles, responsibilities, and communication strategies in the event of a suspected or confirmed compromise, including notification of the payment brands at minimum
- Specific incident response procedures for different types of incidents, not just a generic flowchart
- Business recovery and continuity procedures that address how operations will continue during and after an incident
- Data backup processes and procedures for restoring systems to a known good state
- Analysis of legal requirements for reporting compromises, including state breach notification laws, GDPR obligations, and contractual requirements
- Coverage of all critical system components within the cardholder data environment
- Reference to or inclusion of incident response procedures from the payment brands such as Visa's Compromised Account Recovery program and Mastercard's Account Data Compromise program
That last point catches organizations off guard frequently. Each payment brand has specific notification timelines and procedures that must be referenced in your plan. Visa requires notification within 24 hours of discovering a compromise. Mastercard has similar requirements. Your plan must document these brand-specific obligations explicitly.
12.10.2: Annual testing
The plan must be tested at least once every 12 months. "Tested" does not mean "reviewed." Your QSA expects to see evidence that the plan was actually exercised through a tabletop exercise, simulation, or full-scale drill. The test must verify that personnel understand their roles, that communication channels work, and that the plan's procedures are actionable.
12.10.3: 24/7 availability
Specific personnel must be designated and available around the clock to respond to alerts and evidence of unauthorized activity. This does not mean you need a 24/7 SOC staffed with full-time employees, but it does mean you need an on-call rotation with documented escalation procedures and response time commitments.
12.10.4: Training
Personnel with incident response responsibilities must be trained appropriately and the training must be documented. Annual security awareness training does not satisfy this. IR-specific training covering your plan, your tools, your escalation procedures, and your communication protocols is required.
12.10.4.1: Periodic IR skills verification (v4.0)
PCI DSS v4.0 added a requirement to periodically verify that incident response personnel have the skills necessary to perform their roles. This can be satisfied through the annual testing requirement combined with documented training records, but the key is demonstrating competency rather than simply attendance.
12.10.5: Alerts from security monitoring
The incident response plan must include monitoring and responding to alerts from security systems including intrusion detection, intrusion prevention, logging and monitoring systems, and file integrity monitoring. This ties directly to Requirement 10 and creates a dependency between your SIEM deployment and your IR plan.
12.10.6: Evolution of the plan
The plan must be modified and evolved based on lessons learned and industry developments. After every real incident and every test exercise, the plan must be reviewed and updated. Your QSA will look for documented post-incident reviews with specific plan modifications that resulted from them.
12.10.7: Procedures for responding to stored PAN detection (v4.0)
PCI DSS v4.0 introduced this requirement specifically for situations where PAN is detected in unexpected locations. Your plan must include procedures for identifying how the PAN ended up there, determining whether additional PAN is stored in unexpected locations, and eliminating or securing the data.
Incident Classification for PCI Environments
Your IR plan needs a classification system that maps incident severity to response procedures. Not every security event warrants the same response. A generic three-tier severity model is not sufficient for PCI. Your classification must account for whether cardholder data was potentially exposed, which changes the response obligations entirely.
| Classification | Criteria | Response Requirements |
|---|---|---|
| Critical | Confirmed compromise of cardholder data, active data exfiltration, ransomware affecting CDE systems | Immediate activation of full IR plan, payment brand notification within 24 hours, forensic investigation, legal counsel engagement, breach notification assessment |
| High | Suspected compromise of CDE systems, unauthorized access to CDE network segment, malware detected on CDE systems | IR team activation within 1 hour, containment procedures, forensic preservation, escalation to critical if CHD exposure confirmed |
| Medium | Suspicious activity on CDE-adjacent systems, failed intrusion attempts, policy violations involving CDE access | Investigation within 4 hours, log analysis, scope assessment, containment if threat is validated |
| Low | Security events on non-CDE systems, phishing attempts not targeting CDE personnel, vulnerability discoveries with no evidence of exploitation | Documented investigation within 24 hours, tracking to resolution, trend analysis |
The critical distinction is between incidents that may involve cardholder data and those that do not. An incident involving a compromised web server in your CDE triggers payment brand notification obligations, potential PCI Forensic Investigator engagement, and state breach notification requirements. The same incident on a system outside your CDE does not carry those obligations, though it may still require response under other frameworks.
What Your IR Plan Must Contain to Pass Assessment
Having reviewed dozens of IR plans that failed QSA assessment, the failures fall into predictable patterns. Here is what your plan must contain beyond the basic Requirement 12.10 elements to actually pass.
Contact lists and escalation matrices
Your plan must include specific contact information for everyone involved in incident response, including internal teams, external forensic investigators, legal counsel, payment brand contacts, acquiring bank contacts, and law enforcement contacts. These must be current. A contact list with phone numbers from two years ago is a finding.
QSA checkpoint: Assessors will verify that contact information is current by cross-referencing names and roles with your organizational chart. They may also ask how frequently the contact list is updated. Best practice is quarterly review with updates triggered by any personnel change.
Containment procedures by incident type
Generic containment steps are insufficient. Your plan needs specific containment procedures for the incident types most relevant to your environment:
- Compromised web application: Isolate the application, preserve application and web server logs, disable compromised accounts, assess scope of data access
- Compromised payment terminal: Remove terminal from network, preserve terminal logs and memory, replace terminal, notify terminal vendor
- Malware in CDE: Isolate affected systems, capture memory images before shutdown, identify lateral movement, scan all CDE systems
- Insider threat: Disable account access, preserve user activity logs, coordinate with HR and legal, assess data access history
- Third-party compromise: Disable third-party access, assess shared credential exposure, contact the third party's IR team, review segmentation controls between your environment and theirs
Evidence preservation procedures
When an incident may result in legal action, law enforcement involvement, or PCI Forensic Investigator engagement, evidence integrity is critical. Your plan must document chain of custody procedures, forensic image creation processes, and log preservation requirements. Specify who is authorized to create forensic images and where evidence is stored.
Communication templates
Under the stress of an active incident is not the time to draft communications. Your plan should include templates for internal stakeholder notifications, payment brand notifications, acquiring bank notifications, customer breach notification letters, regulatory notifications, and public statements. These templates will need to be customized for each incident, but having a starting point dramatically reduces response time.
Testing Requirements and What Counts
Annual testing is required, but the standard does not prescribe a specific format. Different testing approaches satisfy the requirement with varying degrees of effectiveness.
| Test Type | What It Tests | QSA Acceptance |
|---|---|---|
| Tabletop Exercise | Decision-making, communication, role clarity, plan completeness | Accepted. Most common approach. Must include realistic scenarios and documented outcomes |
| Functional Drill | Technical response procedures, tool effectiveness, response times | Accepted and preferred. Tests actual execution capability, not just knowledge |
| Full Simulation | End-to-end response including containment, eradication, recovery, and communication | Accepted. Provides the most comprehensive validation but requires significant planning |
| Plan Review Only | Document accuracy, contact information currency | Not sufficient alone. Does not satisfy "tested" requirement under 12.10.2 |
Regardless of which testing method you choose, your documentation must include the date of the test, the scenario used, the participants involved, the findings identified, and the plan modifications that resulted from the test. A test that identifies no areas for improvement is a test that was not rigorous enough, and your QSA will recognize that.
Designing effective tabletop scenarios
The most effective tabletop exercises for PCI environments use scenarios that force participants to make decisions about cardholder data exposure. Consider scenarios such as:
- A web application vulnerability has been exploited, and the attacker has accessed the database containing encrypted cardholder data. The encryption keys are stored on a separate server. Has CHD been compromised?
- Your segmentation controls have been bypassed. A system in your corporate network has been communicating with a system in the CDE for an unknown period. What is your first action?
- A third-party payment processor notifies you that their systems were compromised. They had access to your tokenization vault via API. What are your notification obligations?
- An employee reports that they accidentally emailed a spreadsheet containing unmasked PANs to an external recipient. The email left your mail server two hours ago. What steps do you take?
Common Audit Findings for Requirement 12.10
Based on our experience supporting organizations through PCI DSS assessments, these are the findings that come up most frequently for Requirement 12.10.
- Plan exists but has never been tested. This is the single most common finding. The plan was written during the last assessment cycle and never exercised. No tabletop, no drill, no simulation
- No 24/7 response capability. The plan names an IR team but has no on-call rotation, no after-hours contact procedures, and no documented response time expectations
- Missing payment brand procedures. The plan references "notify relevant parties" but does not include specific payment brand notification timelines, contact information, or procedures
- Stale contact information. Key personnel have changed roles or left the organization, and the contact list has not been updated. The person listed as IR lead has been in a different department for six months
- No post-incident review process. The plan does not document how lessons learned are captured, who reviews them, or how they feed back into plan modifications
- Scope gaps. The plan covers the primary CDE but omits connected systems, cloud environments, or third-party integrations that are within PCI scope
- No procedures for unexpected PAN discovery. The v4.0 requirement under 12.10.7 is frequently missing from plans that were originally written for v3.2.1 compliance
Breach Notification Obligations
When a PCI-related incident involves confirmed or suspected compromise of cardholder data, a cascade of notification obligations activates. Your IR plan must document each of these and assign responsibility for executing them.
Payment brand notification
Each payment brand has specific notification requirements. Visa and Mastercard generally require notification within 24 hours of discovering a compromise. Your acquiring bank is typically your first point of contact, and they will coordinate with the payment brands. The plan must document your acquiring bank contact information and the escalation path.
PCI Forensic Investigator engagement
For confirmed compromises, the payment brands may require engagement of a PCI Forensic Investigator (PFI). PFIs are organizations approved by the PCI SSC to conduct forensic investigations of payment card breaches. Your plan should identify at least two PFI firms that you could engage, with pre-negotiated engagement terms if possible. Waiting until an active breach to find and contract a forensic investigator adds days to your response timeline.
State breach notification laws
All 50 US states plus DC, Guam, Puerto Rico, and the Virgin Islands have breach notification laws. The notification timelines range from 30 to 90 days after discovery, with some states like California and New York having additional requirements for content of the notification. If you operate in multiple states, your plan must account for the most restrictive requirements applicable to your customer base.
Key consideration: The encryption status of compromised data affects your notification obligations. Most state breach notification laws include safe harbor provisions for encrypted data where the encryption key was not also compromised. Your IR plan's classification procedures must explicitly assess whether encryption keys were exposed alongside encrypted cardholder data.
International obligations
If your organization processes cards for European customers, GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. Cardholder data is personal data under GDPR. Your plan must document which supervisory authority to notify and who is responsible for that notification.
Integrating IR with Other PCI Requirements
Requirement 12.10 does not exist in isolation. Your IR plan must connect to and reference other PCI DSS requirements to function effectively.
- Requirement 1 (Network Security Controls): Your IR plan should document how network segmentation is maintained during an incident and how firewall rules are modified for containment
- Requirement 6 (Secure Development): Application-level incidents require coordination with development teams. Your IR plan should include procedures for emergency patching and code deployment
- Requirement 9 (Access Control): Containment procedures often require revoking access. Your IR plan must document emergency access revocation procedures and who has authority to execute them
- Requirement 10 (Logging and Monitoring): Your SIEM alerts feed into your IR process. The plan must document which alerts trigger which response procedures and escalation paths
- Requirement 11 (Vulnerability Scanning): Vulnerability discoveries may require incident classification. Your plan should define thresholds for when a discovered vulnerability becomes an incident
Building the Plan: A Practical Approach
If you are building an IR plan from scratch or substantially revising an existing one for PCI DSS v4.0 compliance, here is the approach we recommend based on what QSAs consistently accept.
Step 1: Scope the plan to your environment
Map every system component in your CDE and every connected system. Your IR plan must explicitly cover each of these. If your cloud environment is in scope, the plan must address cloud-specific incident response procedures including provider notification, shared responsibility considerations, and cloud-native forensic capabilities.
Step 2: Define roles with named individuals
Avoid role-only definitions. "The Security Team Lead will..." is insufficient. Name the individuals who fill each role, their backups, and the contact information for both. Roles typically needed include IR Lead, Technical Lead, Communications Lead, Legal Counsel, Executive Sponsor, and External Liaison.
Step 3: Build procedures for your actual threat landscape
Generic IR plans fail assessment because they do not reflect the organization's actual environment. If you are an e-commerce company, your plan needs web application compromise procedures. If you process card-present transactions, you need terminal compromise procedures. If you use network segmentation to reduce scope, you need segmentation failure procedures.
Step 4: Document the notification cascade
Create a flowchart or decision tree that maps incident classification to notification obligations. When a Critical incident is declared, who gets notified, in what order, within what timeframe, and using what communication channel? This cascade should include internal notifications, acquiring bank notification, payment brand notification, legal notification, regulatory notification, and customer notification.
Step 5: Schedule and plan the annual test
Do not wait until month 11 of your assessment cycle to test the plan. Schedule the test early enough that you have time to remediate any findings before your assessment. Document the test plan, execute it, capture the results, and update the IR plan based on what you learn.
IR Plan Maintenance Checklist
Your IR plan is a living document. These activities must occur on a regular cadence to keep it assessment-ready.
- Review and update contact information quarterly
- Conduct annual tabletop exercise or functional drill
- Update the plan after every real incident with lessons learned
- Update the plan after every test exercise with identified improvements
- Review payment brand notification procedures annually for changes
- Update legal requirements section when operating in new jurisdictions
- Review and update the plan when significant changes occur to the CDE
- Verify that IR training has been completed for all designated personnel
- Validate that 24/7 on-call rotation is current and functional
- Confirm PFI pre-engagement agreements are current
Need help with your PCI DSS incident response plan?
We help organizations build and test incident response plans that satisfy Requirement 12.10 and withstand QSA scrutiny. From tabletop exercises to full plan development, we ensure your IR capability meets PCI DSS v4.0 requirements.
