www.schellman.com Open in urlscan Pro
2606:2c40::c73c:671c  Public Scan

Form analysis
3 forms found in the DOM

<form onsubmit="event.preventDefault();headerSearch(this);">
  <input type="text" class="header--main--search--input--input" placeholder="Search">
  <input type="submit" class="visuallyhidden" value="Submit">
</form>

<form onsubmit="event.preventDefault();mobileSearch(this);">
  <input type="text" class="mobilenav--search--input" placeholder="Search">
  <input type="submit" class="visuallyhidden" value="Submit">
  <a class="mobilenav--search--submit">
                      <i class="fas fa-search mobilenav--search--submit--icon"></i>
                    </a>
</form>

/search

<form class="bop--mobilemenu--search" action="/search" type="POST">
  <input class="bop--mobilemenu--search--input" name="term" placeholder="Search" type="text">
  <input class="visuallyhidden" name="type" readonly="" type="text" value="BLOG_POST">
  <input class="visuallyhidden" type="submit" value="Submit">
</form>

Text Content

Contact a Specialist
Services
SOC & Attestations
Payment Card Assessments
ISO Certifications
Privacy Assessments
Federal Assessments
Healthcare Assessments
Penetration Testing
Cybersecurity Assessments
Crypto and Digital Trust
Schellman Training
ESG & Sustainability
AI Services
Build Your Compliance Roadmap
Industry Solutions
Cloud Computing & Data Centers Meet a broad range of regulatory and industry
compliance mandates for your customers
Financial Services & Fintech Cybersecurity assessments for both the banking
industry and the financial service providers
Healthcare Reporting to manage risk and adhere to applicable laws and
regulations
Payment Card Processing Validate compliance with the various forms of the PCI
DSS
US Government Achieve authorization to work for federal agencies, DoD, and the
associated contractor base
Higher Education & Research Laboratories Reinforce your commitment to securing
your student's and institution's data.
View All Industry Solutions
Learning Center
Our Technology
About Us
Leadership Team
Careers
Corporate Social Responsibility
Strategic Partnerships
Visit About Us

Services
Industry Solutions
Learning Center
Our Technology
About Us
Contact a Specialist
Services
View All Services
SOC & Attestations
Payment Card Assessments
ISO Certifications
Privacy Assessments
Federal Assessments
Healthcare Assessments
Penetration Testing
Cybersecurity Assessments
Crypto and Digital Trust
Schellman Training
ESG & Sustainability
AI Services
SOC & Attestations
Payment Card Assessments
ISO Certifications
Privacy Assessments
Federal Assessments
Healthcare Assessments
Penetration Testing
Cybersecurity Assessments
Crypto and Digital Trust
Schellman Training
ESG & Sustainability
AI Services
Industry Solutions
View All Industry Solutions
Cloud Computing & Data Centers
Financial Services & Fintech
Healthcare
Payment Card Processing
US Government
Higher Education & Research Laboratories
Cloud Computing & Data Centers
Financial Services & Fintech
Healthcare
Payment Card Processing
US Government
Higher Education & Research Laboratories
About Us
About Schellman
Leadership Team
Careers
Corporate Social Responsibility
Strategic Partnerships
Leadership Team
Careers
Corporate Social Responsibility
Strategic Partnerships
 * 



«  View All Posts



By: Roberto Davila

Print/Save as PDF


INCIDENT RESPONSE IN PCI DSS V4.0: A BREAKDOWN OF REQUIREMENT 12.10

Payment Card Assessments

 * Share:
 * 
 * 
 * 
 * 

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.

IMPORTANT NOTE REGARDING AUTOMATED DATA DISCOVERY SOLUTIONS: While these do
facilitate the required actions in incident response in addition to supporting
other PCI DSS requirements—such as scope validation—the standard does not
currently require their use. Rather, it does require you to create and implement
data discovery methodology to identify locations where account data is stored,
processed, and transmitted (Requirement 12.5.2).


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.


ABOUT ROBERTO DAVILA

Roberto Davila is a manager at Schellman. Prior to joining the firm, Roberto was
the lead resource and Internal Security Assessor for a large cruise line where
he specialized in security assessments and remediation activities for Payment
Card Industry, HIPAA and Data Privacy. Before joining the cruise line, Roberto
performed security and compliance services at a consulting agency where he
gained experience in audit, compliance, and information security.

 * 
 * 
 * 
 * 


SUBSCRIBE TO THE SCHELLMAN ADVANTAGE BLOG

Get unique insights, industry news and exclusive advice from our highly
experienced professionals.

No thanks, I am not interested.



SCHELLMAN

4010 W Boy Scout Boulevard, Suite 600
Tampa, FL 33607

U.S. 1.866.254.0000

Outside the U.S. 1.813.288.8833



SERVICES

 * SOC & Attestations
 * ISO Certifications
 * Federal Assessments
 * Payment Card Assessments
 * Healthcare Assessments
 * Privacy Assessments
 * Penetration Testing
 * Cybersecurity Assessments
 * Crypto and Digital Trust
 * Schellman Training

INDUSTRIES

 * Cloud Computing & Data Centers
 * Financial Services & Fintech
 * Healthcare
 * Payment Card Processing
 * U.S. Government
 * Higher Education & Research Laboratories

RESOURCES

 * Resources
 * OpenAPI

COMPANY

 * About Us
 * Careers
 * Contact Us

© SchellmanPrivacy PolicyTerms

“Schellman” is the brand name under which Schellman & Company, LLC and Schellman
Compliance, LLC provide professional services. Schellman & Company, LLC and
Schellman Compliance, LLC practice as an alternative practice structure in
accordance with the AICPA Code of Professional Conduct and applicable law,
regulations and professional standards. Schellman & Company, LLC is a licensed
certified public accounting firm (Florida license number AD62941) registered
with the Public Company Accounting Oversight Board (PCAOB) that provides attest
services to its clients, and Schellman Compliance, LLC provides nonattest
cybersecurity and compliance professional services to its clients. Schellman
Compliance, LLC is not a licensed CPA firm. Schellman & Company, LLC and
Schellman Compliance, LLC are independently owned and are not liable for the
services provided by any other entity providing services under the Schellman
brand. Our use of the terms “our firm” and “we” and “us” and terms of similar
import, denote the alternative practice structure conducted by Schellman &
Company, LLC and Schellman Compliance, LLC.







Schellman uses cookies to enhance user experience and to analyze performance and
traffic on our website. For more information, please review your cookie
preferences options and Schellman’sPrivacy Notice

Manage Choices Required only Accept all



PRIVACY PREFERENCE CENTER

When you visit any website, it may store or retrieve information on your
browser, mostly in the form of cookies. This information might be about you,
your preferences or your device and is mostly used to make the site work as you
expect it to. The information does not usually directly identify you, but it can
give you a more personalized web experience. Because we respect your right to
privacy, you can choose not to allow some types of cookies. Click on the
different category headings to find out more and change our default settings.
However, blocking some types of cookies may impact your experience of the site
and the services we are able to offer.
More information
Allow All


MANAGE CONSENT PREFERENCES

STRICTLY NECESSARY COOKIES

Always Active

These cookies are necessary for the website to function and cannot be switched
off in our systems. You can set your browser to block or alert you about these
cookies, but some parts of the site will not then work.

FUNCTIONAL COOKIES

Functional Cookies

These cookies enable the website to provide enhanced functionality and
personalisation. They may be set by us or by third party providers whose
services we have added to our pages. If you do not allow these cookies then some
or all of these services may not function properly.

PERFORMANCE COOKIES

Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and
improve the performance of our site. They help us to know which pages are the
most and least popular and see how visitors move around the site. All
information these cookies collect is aggregated and therefore anonymous. If you
do not allow these cookies we will not know when you have visited our site, and
will not be able to monitor its performance.

TARGETING COOKIES

Targeting Cookies

These cookies may be set through our site by our advertising partners. They may
be used by those companies to build a profile of your interests and show you
relevant adverts on other sites. They do not store directly personal
information, but are based on uniquely identifying your browser and internet
device. If you do not allow these cookies, you will experience less targeted
advertising.

Back Button


BACK



Search Icon
Filter Icon

Clear
checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label

Reject All Confirm My Choices