New PCI DSS Scoping Guidance Corroborates Coalfire’s Approach

Shawn Shifflett, CISSP, QSA, Senior Practice Director, PCI

On Friday, December 6th 2016, the PCI Security Standards Council released their formal information supplement titled, Guidance for PCI DSS Scoping and Network Segmentation. This particular information supplement has been eagerly anticipated in the PCI DSS industry for several years. The document seeks to address some of the numerous, and often extremely varying, interpretations of scoping and segmentation requirements across the QSA population. These scoping choices have immediate impact on near-term costs and attainment of compliance, but ultimately they significantly impact a company’s security posture. The new guidance seeks to address security and risk issues as mentioned in the PCI SSC press release:

"Requirement 1.1 states that organizations need to maintain a cardholder flow diagram to help identify which systems are in scope and need protection. Yet data breach investigation reports continue to find that companies suffering compromises were unaware that cardholder data was present on their compromised systems."

The 25-page document goes into detail to address several specific areas of misunderstanding and offers a couple example use cases of the new guidance. Additionally, the scoping information supplement provides a very useful PCI SSC-endorsed replacement for the Open Scoping Toolkit workflow:

How does this affect Coalfire customers? The impact should be fairly limited if you have worked with Coalfire and accepted our recommendations to align with the information that we had from our involvement in the PCI Community. The most common areas of concern that are detailed below include:

  • Inclusion of Administrator workstations even when utilizing a bastion host to access the CDE
  • Achieving complete isolation of the CDE network to reduce scope and eliminate scope expansion

Coalfire customers have already benefited from the Coalfire approach to scoping and segmentation. Coalfire has always approached scoping with a focus on compliance outcomes that support our customers’ security and business objectives.

I’ve summarized the areas that the PCI SSC has clarified in the information supplement below:

  1. Systems located within the CDE are in scope, irrespective of their functionality or the reason why they are in the CDE
  2. Systems that connect to a system in the CDE are in scope, irrespective of their functionality or the reason they have connectivity to the CDE
  3. In a flat network, all systems are in scope if any single system stores, processes, or transmits account data
  4. Connected-to and/or security-impacting systems are always in scope
    • Connected-to and/or security-impacting systems must be evaluated against all PCI DSS requirements to determine the applicability of each requirement
  5. To be considered out-of-scope a system must not have any access to the CDE
  6. Shared services such as authentication services (LDAP, Active Directory) between in-scope and out-of-scope systems and networks is possible assuming that:
    • Administrative access to shared services are logged and monitored
    • Administrative access to the CDE or CDE systems is permitted only from systems within the CDE or from designated systems in the shared services network (e.g. no allow-all rules from the shared services network to the CDE)
    • Multi-factor authentication is used for all administrative access from the shared services systems to the CDE, and administrative access is logged and monitored
    • Accounts used to access shared services from any out-of-scope networks do not also have access to the CDE
  7. Administrative systems (workstations, laptops, servers, mobile devices) are always in scope for PCI DSS regardless of the path or existence of bastion hosts used to access the CDE. In scope administrative systems can be considered as not extending scope to any other system residing on the same network as the administrative systems using the following guidelines
    • Connections to the bastion host from out-of-scope networks and systems are restricted to designated personnel
    • Administrative systems are unable to access the CDE directly, and must use the bastion host
    • All PCI DSS requirements apply to the administrative systems
    • The administrative systems must not store, process, and/or transmit CHD
    • Access to the bastion host from the administrative systems are via different user accounts than those used to administer the CDE
    • Access to the bastion host from administrative systems requires multi-factor authentication for individuals, and at least one of the multi-factor methods is independent of the administrative system (e.g. host-based certificates are not to be used for access to the bastion host)

The new scoping clarifications are very useful but still need to be applied in line with the latest version of the PCI DSS and multiple scoping rules released by the Council. Not a straightforward process. If you’d like to understand its impact on your compliance program or are concerned about your existing assessment scope in light of these clarifications, please contact us for more information on the new guidance, or our scope definition and advisory services.

Shawn Shifflett


Shawn Shifflett — CISSP, QSA, Senior Practice Director, PCI

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit 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 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 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