An Analysis of PCI DSS Requirement and the Compliance Expectations

Jason Pieters, Product Director, PCI, Coalfire

For some organizations, understanding, navigating, and complying with the Payment Card Industry (PCI) Data Security Standard (DSS), especially after the release of the latest version (v3.2) released in April 2016, has become confusing and/or challenging because of the inclusion of phased-in applicability of requirements. The most common questions that Coalfire receives from clients are regarding requirement

  • PCI DSS Requirement - Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

    Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.

  • Testing Procedures - Examine the results from the most recent penetration test to verify that:
    • Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.
    • The penetration testing covers all segmentation controls/methods in use.
    • The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE. Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

  • Guidance - Note: This requirement applies only when the entity being assessed is a service provider.

    For service providers, validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives


There are three distinct points that need to be made about this requirement to understand what is expected of those entities to which it applies:

  • First, this only applies to service providers, so merchants do not need to worry about this specific requirement except when managing and understanding the compliance of third-party service providers with which they do business.
  • Second, the requirement calls for additional testing if segmentation is used to reduce scope, and the testing must be specific to segmentation. This will be elaborated on later in this article, but preparing now will help reduce effort and save time while also alleviating some of the anxiety as the January 31, 2018 effective date approaches.
  • Third, it is important for service providers to understand the dates that their Qualified Security Assessor Company (QSAC) will be using for testing the requirement during the annual PCI DSS assessment.

What is the impact on merchants? Essentially, this requirement applies to the awareness and management of a merchant’s third-party service provider management program. After January 31, 2018, it will be important for merchants to ensure that service providers not only provide an Attestation of Compliance (AOC) and responsibility matrix, but also assure that the requirement has been tested appropriately and is clearly identified as the service provider’s responsibility. This specific requirement cannot, by its definition, be the responsibility of the customer, and any assertion otherwise should be closely investigated.

Understanding the difference, or similarities, of penetration testing versus segmentation testing is extremely important. Until recently, the challenge was that there was not a clear distinction between the expected penetration test and the second annual segmentation test. This confusion led to two interpretations:

  1. A service provider must have a full penetration test performed twice a year. Essentially, this entailed conducting the same test twice with the same scope of work and level of effort.
  2. A service provider must have a full penetration test performed once a year, and another test (the extent of which was not clearly defined) six months later.

The SSC clarified its position in a September 2017 clarification/guidance document, “Information
Supplement: Penetration Testing Guidance.”

Coalfire analyzed the PCI DSS requirements and the information supplement language around “segmentation testing” and concluded that:

  1. The second interpretation (full penetration test, followed by a limited test six months later) is the appropriate understanding of the requirement and guidance.
  2. Service providers are required to have a qualified resource perform an annual penetration test that thoroughly addresses the security of the environment, including analyzing the segmentation controls used to limit the scope of a PCI Cardholder Data Environment (CDE).
  3. After six months, another technical test must be performed that is focused solely on the segmentation controls used to limit the scope of a PCI CDE. This test would evaluate the connectivity between in-scope and out-of-scope networks and would be a reduced scope test instead of a full penetration test. More information about penetration testing and segmentation testing will be available from the Coalfire Labs team. Coalfire recognizes that achieving a perfect six-month timeframe in between tests can be challenging. Our current guidance to clients is six months in between tests, with a leeway of no more than four weeks. Remediation of high risk/exploitable vulnerabilities should be carried within a reasonable timeframe, and re-testing must occur after such remediation efforts are concluded. The six-month window starts after the initial test is conducted, not after remediation efforts have concluded. The leeway in testing timeframes and remediation timeframes must be discussed and agreed upon between an organization’s leadership and their QSAC.
  4. When validating segmentation testing, the report must demonstrate that connections attempted from out-of-scope networks and systems are denied, and that any failures to properly segment are remediated and appropriately retested. While compensating controls are a good way for organizations to demonstrate compliance when dealing with many of the PCI DSS requirements, compensating controls cannot be written for scope.  The scope of the assessment must be expanded until remediation has occurred.  Segmentation test findings should be remediated within 60 days and retested to confirm proper segmentation is implemented. If remediation will take longer, the Service Provider should consult with their QSAC on the implications of a longer remediation period and the additional controls that should be considered to demonstrate compliance.

Finally, service providers must be aware of the expectations and implications as the deadline nears and they plan for their 2018 PCI DSS validation. Since the cost of additional testing and planning for this type of effort can be difficult within an organization, the SSC has laid out specific milestones and dates for complying with the new requirement. Below is a table outlining the milestone, dates, and the types of evidence a Qualified Security Assessor (QSA) might request.

There are three distinct points that need to be made about this requirement to understand what is expected of those entities to which it applies:

With a phased integration of the requirement, businesses have some time before additional testing must be performed. Planning now will ensure that there aren’t any undue stresses on an organization and their security and compliance program. This guidance is provided without a specific environment/client in mind, and thus individual scenarios are not covered. Any questions about requirement should be researched on the PCI SSC website or with guidance from a QSAC. If you wish to speak with a Coalfire representative about this, other PCI questions, or penetration testing topics, please call us or submit a “speak with an expert” request found on right side of this page.


Payment Card Industry (PCI) Data Security Standard - Requirements and Security Assessment Procedures

Jason Pieters


Jason Pieters — Product Director, PCI, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit Azure bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 CPRA credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail RISE Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS