Incident Response in PCI DSS v4.0: A Breakdown of Requirement 12.10

Incident response has always been an important component of PCI DSS—in Requirement 12.10, the standard provides critical guidelines for the timeliness, preparedness, and continuous improvement of incident response management. That being said, new related requirements and clarifications have been introduced under v4.0 that add complexity and effort to the mandates from v3.2.1.

As highly experienced PCI assessors, we have made a lot of effort to disseminate different aspects of the new version to assist organizations in their preparation. Now, we’re going to do the same for the incident response requirements.

In this article, we’ll explore the intricacies of PCI DSS Requirement 12.10 through a breakdown of its sub-requirements and the role they play in supporting your data security and resilience against evolving threats.

What is PCI DSS v4.0 Requirement 12.10?

Altogether, Requirement 12.10 is made up of 7 sub-requirements:

• Requirement 12.10.1 – What Should be Covered
• Requirement 12.10.2 – Annual Reviews and Testing
• Requirement 12.10.3 – 24/7 Availability
• Requirement 12.10.4 – Training
• Requirement 12.10.5 – Security Monitoring Systems and Alerting
• Requirement 12.10.6 – Evolution
• Requirement 12.10.7 – Response to Cardholder Data Discovery

Requirement 12.10 – Incident Response Plan

Nevertheless, the first notable change to incident response is in the base Requirement 12.10—in v4.0, the PCI SSC has clarified that organizations must respond immediately to not only confirmed security incidents but also suspected events.

While this change does help those seeking compliance to be more proactive and agile when attempting to thwart attacks or limit damage caused by a breach—as noted in 12.10.5 and elsewhere—your immediate response to suspected events must include active monitoring of event logs and alerts from security monitoring systems. This includes:

• Network security controls;
• Intrusion detection and/or prevention systems (IDS/IPS);
• File-integrity monitoring or change-detection mechanisms;
• Anti-malware software, endpoint detection and response (EDR) solutions, and/or user behavior analytics (UBA) tools;
• Anti-phishing mechanisms such as Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM);
• Network access control (NAC) or wireless IDS/IPS; and
• Change-and-tamper-detection mechanisms on payment pages.

Requirement 12.10.1 – What Should be Covered

Requirement 12.10 mandates an incident response plan (IRP) for both suspected and confirmed incidents. Requirement 12.10.1 in v4.0 lays out a bulleted list of what to actually include in IRP—that list includes the following:

• Roles, responsibilities, communication duties, and contact strategies in the event of a suspected or confirmed security incident, including the notification of payment brands and acquirers, at a minimum:
  • Incident response procedures with specific containment and mitigation activities for different types of incidents
  • Business recovery and continuity procedures
  • Data backup processes
  • Analysis of legal requirements for reporting compromises
  • Coverage and responses of all critical system components
  • Reference to or inclusion of incident response procedures from the payment brands

Each item on the above list should be addressed in detail to ensure you have a robust plan in place. For additional information and specific procedures to consider for your IRP, refer to NIST SP 800-61 Rev. 2 Computer Security Handling Guide.

Requirement 12.10.2 – Reviews and Testing

Once you’ve established your organization’s plan, Requirement 12.10.2 directs that you review, update, and test it annually. To do so, we recommend conducting a tabletop exercise:

• Who Should Participate? Anyone who may be involved in the incident response process, which may mean team members from your information security, network, server administration, and legal teams (among others).
• How Should It Work? Those taking part should follow the steps and procedures outlined in the IRP in dealing with a simulated problem—they should document meeting minutes for the exercise and complete an incident report as if it were a real-world incident.
• What Should Happen After? A post-mortem or lessons learned should be conducted and documented to capture successes, failures, or gaps in the incident response plan. Any gaps or failures identified during IRP testing should be remediated, and the IRP itself updated to reflect new plan elements.

Conducting a tabletop exercise with these steps will ensure that your incident response team is prepared to respond to security incidents promptly and efficiently.

Requirement 12.10.3 – Availability

Speaking of your incident response team, Requirement 12.10.3 obligates personnel with responsibility for responding to suspected or confirmed incidents to be available 24/7.

While this specifically applies to those who are trained in responding to alerts from security monitoring systems as your first line of defense, you should also consider making personnel from other teams similarly available if their actions may be required in the event of a compromise.

Requirement 12.10.4 – Training

You’re also required to train your incident response team periodically and appropriately, as per Requirement 12.10.4—the key word here being “appropriate.”

While you’re required to perform a targeted risk analysis to define and justify the frequency of this incident response training, it also won’t do to provide blanket education to everyone responsible for responding to incidents—no matter how frequently you’re training them.

To comply with this stipulation, you must provide training that specifically applies to each individual’s incident response responsibilities, including instruction regarding the security monitoring tools and platforms used in your environment.

Requirement 12.10.5 – Security Monitoring Systems and Alerting

Regarding those security monitoring systems mentioned above, Requirement 12.10.5 lists which are required—your incident response plan must include details for monitoring and responding to alerts from systems that include but are not limited to any of your:

• Network security controls;
• IDS/IPS;
• File-integrity monitoring or change-detection mechanisms;
• Anti-malware software, EDR solutions, and/or UBA tools;
• Anti-phishing mechanisms;
• NAC or wireless IDS/IPS; and
• Change-and-tamper-detection mechanisms on payment pages.

Requirement 12.10.6 – Evolution

Though 12.10.2 also requires updates to your incident response plan, Requirement 12.10.6 specifically calls for your plan to be modified and evolved to reflect changes in your organization’s environment, emerging threats, and lessons learned from the required testing or past incidents.

We mentioned earlier that you should incorporate a post-mortem into your annual tabletop exercise—that is because it can help identify areas of improvement and gaps in your process to consider for updates to your incident response plan.

Requirement 12.10.7 – Response to Cardholder Data Discovery

And finally, Requirement 12.10.7 requires the implementation of specific incident response procedures upon the detection of Primary Account Number (PAN) data anywhere it’s not expected, including processes to address:

• The retrieval and secure deletion of any PAN discovered outside the CDE, as well as how you’ll migrate it into your currently defined CDE (should that become applicable)
• Identification of any sensitive authentication data stored with PAN
• Determination of where the account data came from and how it ended up where it was not expected
• Remediation of data leaks or process gaps that resulted in the account data being where it was not expected

In the event cardholder data is discovered in unexpected locations, having the above incident response procedures in place will help to pinpoint the source of the data, identify control gaps that resulted in the data being where it should not be, and help to identify corrective actions to prevent future leaks.

Moving Forward with PCI DSS v4.0

Incident response is an important component of cybersecurity—something PCI DSS v4.0 recognizes, given the complexities of its requirements for such. But now that you understand the changes to the standard and what you’ll need to create and implement for compliance, you can move forward more confidently.

Of course, the approach incident response isn’t the only thing v4.0 has changed—to learn more about all the new and different aspects of this new version of the standard, check out our extensive library that breaks down all these PCI DSS v4.0.

And if you find yourself with more specific questions, don’t hesitate to reach out to our dedicated PCI team, who would be happy to address any concerns you may have.