The new scoop on PCI compliance scope

Image for post
Image for post
Photo by Jen Theodore on Unsplash

Introduction — why scope?

The spirit and intent of that article and our follow-up piece in End-to-End Encryption: The PCI Security Holy Grail provided some clarity and an approach to help organizations reduce PCI DSS compliance scope to the absolute minimum. The articles offered a soothsayer’s glimpse into what the future might hold for PCI compliance and scoping.

Much has changed since then; the ubiquitous adoption of virtualized systems, the introduction of streamlined and stripped down e-commerce solutions including shared hosting, and implementation of encrypt-at-the-swipe payment card solutions, EMV compatible processing and more.

As technology, processes, and people have marched forward, the promise of measurable PCI scope reduction appears to have been offset by questions and concerns concerning the scoping of new technology implementations. Just as was the case when PCI-DSS version 1 was released, many are still struggling to come to grips with PCI compliance scoping, even with PCI-DSS version 3.2.

Why segment?

PCI DSS states that any device that’s involved in the storage, processing, or transmission of cardholder data (CHD) is considered part of the segment. To keep things as simple as possible, designers should segment the network to include only those resources that are needed for transaction processing and storage.

The reasons to segment are compelling, some of the main ones being:

  • reduction in costs associated with your PCI assessment — the lesser the scope, the less you’ll have to pay a QSA firm
  • better security — segmentation by nature means limiting access. And when it comes to the CDE, less access is better.

PCI guidance on segmentation

To review, PCI applies to all system components included in or connected to the cardholder data environment (CDE). The CDE comprises people, processes, and technologies that store, process, or transmit CHD or sensitive authentication data.

The official definition of a system component is: any network component, server, or application included in or connected to the CDE. Some examples of system components include, but are not limited to:

  • systems that provide security services (authentication servers) facilitate segmentation (internal firewalls) or may impact the security of (name resolution or web redirection servers) to the CDE
  • virtualization components (virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, hypervisors)
  • network components (firewalls, switches, routers, wireless access points, network appliances, other security appliances)
  • servers (web, application, database, authentication, mail, proxy, timing, DNS)
  • applications (purchased and custom applications, internal and external developed
  • any other component or device located within or connected to the CDE

Add to the above is the follow-up section on what constitutes adequate logical segmentation, and it would appear that the PCI SSC has finally clarified these topics to a level that makes PCI compliance scoping a straightforward endeavor. The authors of this article agree that much progress has been made to help merchants and service providers get this right. However, there continues to be much confusion and consternation as to the implications of such new clarifications in the face of new PCI technologies and processes.

Zero trust networks

ZTN is a concept the authors like, albeit with its complexity. A hot topic, when it’s finally released, Zero Trust Networks: Building Trusted Systems in Untrusted Networks looks to be a valuable reference.

The zero trust model is based on the notion that all network traffic should be considered untrusted. There are three concepts to ZTN are that there’s no longer a:

  1. trusted and an untrusted interface on security devices
  2. trusted and untrusted networks
  3. trusted and untrusted users

The follow-on to that is for a security architect to ensure that anything added to the network is trusted, and to secure that trusted resource adequately. It also notes that networks must be designed from the inside out, which fits quite well with the notion of PCI DSS segmentation. By proactively designed security in the CDE, segmentation can be achieved.

While Kindervag’s ZTN may be too forward-thinking for many organizations and require too much reengineering, its core concepts should be considered when considering PCI segmentation.

Non-Listed Encryption Solutions

In 2009, we wrote End-to-End Encryption: The PCI Security Holy Grail. The piece offered some forward-looking conjecture and speculation about the potential scope reduction capabilities and security enhancements of end-to-end encryption of payment card related transaction data.

In late 2012, the PCI SSC began publishing their original P2PE suite of compliance standards. The documents were formidable in their range and breadth, and have since further evolved into a comprehensive set of security and compliance requirements that address all aspects of P2PE implementation for merchants, service providers, supporting technology, and payment application vendors. Both at P2PE’s original inception and now, industry assertions are that significant PCI scope reduction can be enjoyed by merchants and service providers who invest in P2PE certified solutions.

Industry adoption of the P2PE standards was initially quite slow due to public perception of the overall complexities and costs associated with certified P2PE architectures. Additionally, some merchants and their QSA counterparts began to seriously consider cherry-picking and implementing some of the more impactful P2PE scope reducing attributes.

An excellent example of such a P2PE-lite implementation is the use of PTS approved point-of-interaction (POI) devices that provide encrypt-at-the-swipe capabilities, but not further embracing all the other P2PE mandated security controls. At times, only using the specifications in a secure decryption environment to decrypt the data.

Over time, many proponents of such implementations asserted that such P2PE-lite solutions afforded the same protection and PCI scope-reduction capabilities as properly certified P2PE solutions. After a while, this PCI urban myth began to gain momentum, and eventual solutions proliferated as POI vendor and service provider marketing representatives touted their PCI scope reduction (and in some instances even total PCI scope elimination) of their custom-tailored solutions.

This scenario eventually created quite a bit of controversy, confusion, and disagreement amongst PCI professionals and their clients. Merchants and service providers implementing such solutions insisted on getting PCI scope credit equivalent to fully certified P2PE architectures.

To deal with this, the PCI SSC issued a concerted response to this scenario, and have formally published Assessment Guidance for Non-Listed Encryption Solutions and Frequently Asked Questions: Assessment Guidance for Non-Listed Encryption Solutions.

The PCI SSC has now clearly stated that only fully certified P2PE solutions can offer the maximum PCI scope reduction for merchants and service providers. They have also stated that merchants who are considering implementing, or have already implemented non-listed encryption solutions (NLES) will need to incorporate the following to make legitimate PCI scope reduction claims regarding their implemented POI solutions:

  1. A merchant implementing an NLES should request a scope reduction determination to be made by their acquirer. The acquirer and relevant payment application vendor should then engage with a P2PE QSA to complete a P2PE gap assessment of the NLES (E2EE) application with respect to all applicable P2PE requirements.
  2. The P2PE QSA will assess the architecture and subsequently create a non-listed encryption solution assessment (NESA) report. Such a report will address determine whether or not any gaps exist between what is required for a P2PE certified solution and the proposed NLES solution. The P2PE QSA will determine whether any gaps exist, or whether-or-not the NLES merits any PCI scope reduction as claimed.
  3. Merchants should request to have their NLES payment application vendor provide a NEAS report at least annually, and any time the application changes.

If the preceding steps are completed before an upcoming PCI DSS assessment, the attesting QSA of record can evaluate both the actual implementation and P2PE QSA feedback to determine if all compliance criteria have been properly met. If so, the attesting QSA of record can then choose to acknowledge any PCI DSS scope reduction claims made by the P2PE QSA, merchant and acquirer.


Network segmentation and logical abstraction of payment application components are two compelling concepts currently applicable for reducing PCI scope within many cardholder data environments. Proper interpretation of PCI scoping impacts and possible reduction is both equal parts art and science. Industry consensus regarding these concepts is paramount to ensuring compliance and security controls consistency across the associated PCI disciplines.

Note: This article was co-written with David Mundhenk, CISSP, QSA, PCIP. He is a Senior Security Consultant with the Herjavec Group. He has extensive multi-organizational experience providing a myriad of professional security services to business & government entities worldwide. David has successfully completed 200+ PCI DSS assessments, scores of PA-DSS assessments.

I work in information security at Tapad. Write book reviews for the RSA blog, & a Founding member of the Cloud Security Alliance and Cybersecurity Canon.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store