Common Compliance Hurdles Part 1: Increased PCI Scope
Looking over the findings of the last few dozen PCI gap assessments that NetSPI has performed, I am struck by the fact that today, well into version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS, or just DSS), one of our most common findings remains increased scope due to lack of network segmentation. For example, we have seen numerous merchants with relatively simple payment processing environments that have a very large and complicated PCI scope and must bear the associated costs (e.g., develop and apply hardened system configurations, pay for external scanning services, etc.). In some cases, the merchant may not even have a real business need to store cardholder data (i.e. they could simplify their business processes and complete a Self Assessment Questionnaire C rather than the much longer SAQ D) but, even if they do, the scope of compliance is often far larger than necessary. Limiting the scope of the systems that are required to meet PCI DSS compliance gives merchants and service providers the best “bang for their buck” in terms of reaching their compliance goals, yet it seems that many merchants struggle with defining and implementing the controls necessary to do just this. The first step in reducing the PCI scope through segmentation is to determine exactly which systems store, process, or transmit cardholder data. While this may be very straightforward for some organizations, it may be helpful to create a cardholder data flow diagram for more complex environments. Once cardholder data systems have been identified, a process of isolation and segmentation can begin. Ideally, cardholder data systems should be segregated off in a “PCI island” by a stateful firewall; Internet-facing systems should be placed in a separate DMZ segment. Once these major changes have occurred, locking down and documenting the firewall ruleset, implementing the necessary management processes, and other items detailed in Requirement 1 are much easier to address. Though this process may look simple on paper, it can often involve the rearchitecture of not just the network but also individual systems, as PCI-related applications and functions should be isolated from other business functions (e.g., a database containing a parts inventory along with invoicing and payment information should be separated into individual databases in isolated network zones). However, through proper segmentation, merchants and service providers can significantly reduce the cost and scope of compliance and need only apply the DSS to systems and devices that store, process, or transmit PCI data.
Explore More Blog Posts
PHP2Shell Unauthenticated RCE on PHP: CVE-2026-109618 & CVE-2026-109619
The PHP project has disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting all PHP installations that serve web requests. Both vulnerabilities carry a CVSS 4.0 score of 9.2 (Critical).
Introducing the NetSPI Platform MCP
Discover how the new NetSPI Platform Model Context Protocol (MCP) integration gives you a live view of vulnerabilities in your environment and the speed of remediation needed to counter fast-paced attackers.
Administrating the Administrator, An OCI Identity Domains Permission Bypass
Discover how a permission bypass in Oracle Cloud Infrastructure (OCI) identity domains allowed lower-level administrator roles to create API keys for Identity Domain Administrators, leading to an unauthenticated privilege escalation path.