Why did my PCI DSS Scope Explode?

It can be extremely frustrating for a compliance team to realize that additional systems are in-scope. It means additional and unexpected security controls and validation. The most stressful time of year for PCI compliance staff, during an onsite assessment, is the worst time to discover new scope. Yet, this problem affects many organizations. Report on Compliance assessments often uncover these unknown scope components, so you are not alone if this happened to you.

Incorrect Scope is probably the number one cause of PCI failures. And lack of understanding of PCI’s scoping rules is frequently the reason. Questions like: Why is that system in scope? Does this requirement even apply to this system? That doesn’t even store, process or transmit cardholder data. And, what do you mean by “Security Impacting”? are often the result.

We sometimes call this ‘Scope Creep’ and it can result from system connections, newly discovered cardholder data flows, or additional requirements which were supposed to be covered by your service provider. This can really add up in terms of cost and effort. These unexpected scope changes often cause delays as well. It’s very difficult to effectively scope an environment and ensure the entire organization continues to maintain the identified scope without new processes for card payments. As a team of Qualified Security Assessors and security professionals, we empathize with these struggles and want to help ensure smooth assessments.

How can we help you avoid Scope Creep?

Begin with a little planning and a change of mindset. The unpleasant surprise of finding a growing PCI scope often emerges from seemingly small changes in the way cardholder data (CHD) is processed. CHD is the best starting point to consider the scope of your environment. The PCI DSS requirements apply to more than just all system components included in or connected to the cardholder data environment (CDE) along with any supporting systems. This includes people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data or that have the potential to impact the security of CHD.

When it comes to scoping, begin by considering where CHD enters, exits, and any potential CHD storage locations within your environment. If possible, it’s best to avoid storing CHD data. Don’t store it, or leverage technical solutions, such as tokenization or P2PE, to enable transaction processing and other business functions without actually storing CHD. If you can reduce storage or confine it to specific systems, this can reduce scope. In our experience, some of largest changes to scope arise from these high-level issues.

• Wrong or incomplete knowledge of CHD scope (e.g. lack of understanding or overlooked data flow)
• Immature change impact assessment (e.g. changes to CHD flows such as unexpected storage or replacing technologies with more security requirements)
• Misunderstanding security impacting scope (e.g. The new enterprise solution for anti-virus needs to be included in your PCI scope if it is used to meet PCI DSS requirements.)
• Incomplete due diligence (e.g. failure to fully understand outsourcing responsibilities: not confirming compliance status or not completing a full review of your third parties detailed PCI responsibility matrix). Shifting to third party platforms and cloud providers like SalesForce or AWS can help with compliance but they don’t do everything for you and depending on how you choose to use them you can still have significant responsibilities.
• Not following implementation guidance with certified solutions (e.g. Installing a PA-DSS application on the wrong OS or middleware, not following the PA-DSS Implementation Guide or P2PE Implementation Manuals).
• Failure to segment/isolate CHD from non-CHD systems leaving the entire network in-scope.

Segmentation is not a specific PCI requirement but from a practical standpoint, it’s absolutely essential to segment a network to reduce scope and ensure the environment is manageable from a compliance perspective. Effective segmentation should isolate your CDE from other systems providing additional security to those CDE systems and removing other systems from your PCI scope.

Unfortunately, segmentation is not a magic solution to all scope concerns, as business processes and supporting systems may require some connections into your CDE, increasing scope. Limiting scope is the most manageable way to maintain compliance which is critical after compliance is achieved.

We at Control Gap understand scope and we’d rather help you control scope and simplify your compliance rather than spending your time and effort protecting and assessing a larger than necessary environment. Just ask us how!

Learn More

• Official Scoping Guidance https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
• PCI DSS v3.2.1, “PCI DSS Applicability Information”, “Scope of PCI DSS Requirements”, and “Best Practices for Implementing PCI DSS into Business-as-Usual Processes” https://www.pcisecuritystandards.org/documents/PCIDSSv3-2-1.pdf
• The Entity - Who’s responsible for what in PCI https://controlgap.com/blog/the-entity-a-scary-pci-monster
• Connected-to - Scoping Overview https://controlgap.com/blog/connected-to-pci
• All applicable requirements (Footprints) https://controlgap.com/blog/pci-compliance-footprints
• Call Centers and PCI Compliance: Things You Need to Know https://controlgap.com/blog/call-centers-pci-compliance
• Understanding P2PE, NESA, E2EE, and PCI Compliance https://controlgap.com/blog/understanding-encryption-and-pci-compliance
• Control Gap PCI articles https://controlgap.com/tags/pci/