When it comes to protecting payment card data, timing is everything. If something goes wrong, how quickly and effectively you respond can make all the difference. That’s why PCI DSS Requirement 12.10 has long focused on Incident Response Planning (IRP). In PCI version 4.0.1, those requirements have become more detailed and prescriptive.
What is an Incident Response Plan?
An Incident Response Plan (IRP) is a documented set of procedures that an organisation must follow when a security incident, such as a data breach, occurs.
To objective of an IRP is to:
- Detect and identify security incidents quickly.
- Contain the threat to prevent it from spreading or causing more damage.
- Eradicate the threat by removing malicious actors, software, or vulnerabilities.
- Recover systems and data so normal operations can resume safely.
- Review and improve—learn from the incident to prevent future occurrences.
IRPs are comprehensive and act as an easy-to-follow playbook for your organisation to follow if and when you need to. As such, it should reflect your organisation’s unique characteristics and environment.
Stratica has worked with organisations across numerous industries to refine their response plans, so they’re ready when a security incident strikes. Here’s what you need to know about PCI DSS 4.0.1’s incident response expectations and how to meet them.
Requirement 12.10: The Incident Response Framework
Requirement 12.10 is your incident response playbook. It’s made up of seven key parts, each helping your business stay prepared to detect, respond to, and recover from security incidents affecting payment card data.
Let’s look at what each one involves – and what you should be doing.
First Things First: Monitor Smart, Respond Fast
When you suspect an incident, speed and clarity are everything. That starts with tight monitoring of your security environment – your early warning system.
Keep a close eye on these essential tools:
- Network security checkpoints – These are your front-line guards, monitoring all traffic in and out of your systems.
- Intrusion detection systems (IDS) – Think of these like motion sensors. They detect suspicious activity before it becomes a problem.
- File monitoring and – Unexpected file changes and malicious code can be signs of compromise. Modern tools with behavioural detection are essential here.
- Email security (DMARC, SPF, DKIM) – These protocols help confirm emails are from who they say they are—important for fending off phishing and spoofing.
- Wireless networks – These often get overlooked but require the same level of attention and protection as your wired infrastructure.
- Payment pages – Because these handle sensitive data, they need extra layers of defense against tampering and data theft.
By monitoring these systems actively, you’ll be in a stronger position to catch issues early and deal with them before they escalate.
Requirement 12.10.1 – What Your Incident Response Plan Should Include
The core of Requirement 12.10 is having a documented, actionable Incident Response Plan (IRP) for both suspected and confirmed incidents. PCI DSS v4.0.1 lays out exactly what this Plan must cover:
- Roles and responsibilities.
- Communication and contact strategies (including how you’ll notify acquirers and payment brands).
- Response procedures for containing and mitigating different types of incidents.
- Business continuity and recovery processes.
- Data backup details.
- Legal reporting obligations.
- Coverage of all critical systems.
- Inclusion or reference to brand-specific procedures.
Each of these should be clearly defined and tailored to your organisation’s environment.
Tip: Refer to NIST SP 800-61 Rev. 2 for detailed guidance on structuring and maintaining a strong IRP.
Requirement 12.10.2 – Annual Testing and Review
Your incident response plan isn’t a “set and forget” document. It needs to be tested and updated at least annually. A practical way to do this is through a tabletop exercise – a simulated incident walk-through that brings your IRP to life.
Who should join? Anyone who plays a part in an incident response (such as information and cyber security staff, legal, server operations, networking, and senior management).
What should happen? Participants walk through the IRP in a realistic scenario, document their actions, and complete a mock incident report.
What comes after? A post-mortem. What worked? What didn’t? Where were the gaps? Use these insights to improve your IRP. Then test again!
Requirement 12.10.3 – Always-On Availability
Someone needs to be available to respond 24/7. That includes your front-line staff monitoring for alerts, and potentially others (e.g. IT, legal) depending on the nature of the incident.
Make sure availability expectations are clearly defined and understood.
Requirement 12.10.4 – Role-Specific Training
Not all training is created equal. PCI DSS v4.0.1 expects your incident response training to be:
- Targeted – Match training to each person’s role in an incident
- Appropriate – Use a risk analysis to define how often each team member needs it
- Relevant – Include specific instruction on the tools and platforms in your environment
Generic, one-size-fits-all training no longer cuts it.
Requirement 12.10.5 – Real-Time Monitoring and Alerting
Your IRP must show how your organisation responds to alerts from critical security systems, including:
- Firewalls and network controls
- IDS/IPS tools
- File integrity or change detection
- Anti-malware, EDR, UBA solutions
- Phishing detection
- Wireless intrusion prevention (NAC/WIPS)
- Tamper detection for payment pages.
This requirement ties everything back to your active monitoring and reinforces the need for clearly defined response protocols.
Requirement 12.10.6 – Evolving Your IRP
Your environment will change. So will the threats you face. That’s why the IRP must be updated not just annually, but also:
- When your business or systems change.
- After major incidents.
- After lessons learned from tests.
Post-mortems from tabletop exercises are great for identifying needed updates to your IRP.
Requirement 12.10.7 – Responding to PAN in the Wrong Place
If cardholder data (Primary Account Numbers, or PANs) are found somewhere they shouldn’t be, you need to act immediately. Your plan should outline how you’ll:
- Securely retrieve and delete the PAN
- Identify any sensitive authentication data with it
- Figure out how it got there
- Fix any process gaps or control failures
- Migrate the data into your defined Cardholder Data Environment (if applicable)
This isn’t just about damage control. It’s about preventing future data leaks.
PCI DSS 4.0.1 raises the bar for incident readiness response, and for good reason. A well-designed and frequently tested incident response plan protects your business, limits damage, and supports your compliance posture.
If you’re reviewing or building your plan, now’s the time to take a fresh look. At Stratica, we help businesses turn compliance obligations into operational resilience. If you need support refining your IRP or running a tabletop exercise, we’re ready to help.
To get started, contact us to book a complimentary security review.