Appropriate PCI Management Scoping Under Version 4.0.1

Jeffrey A. Palgon, Sean McAloon
12/3/2025
Appropriate PCI Management Scoping Under Version 4.0.1

PCI DSS v4.0.1 makes scoping a shared responsibility. Our specialists outline how to build a repeatable, defensible methodology for compliance.

After the arrival of Payment Card Industry Data Security Standard (PCI DSS) version 4.0.1, scoping became a formal requirement, and the PCI Security Standards Council clarified that organizations, not just assessors, must own the scoping process. A methodical approach can help organizations conduct their scoping with clarity and confidence.

Why scoping matters more than ever

Under PCI DSS v4.0.1, management is responsible for defining and documenting the full scope of the cardholder data environment (CDE). This means identifying all people, processes, and technologies that store, process, or transmit cardholder data – or that could affect its security. It’s a more comprehensive requirement than many organizations were prepared for, especially those used to relying heavily on their Qualified Security Assessor (QSA) to define scope on their behalf. In addition, an organization’s assessment and the assessor’s assessment must align, and any discrepancies need to be documented.

The key takeaway is that scoping is not a one-time checklist – it’s a living process. Done well, it provides a clear understanding of risk exposure and control coverage. Done poorly, it can introduce risk, compliance gaps, and costly surprises during assessment.

Start with methodology, not assumptions

Many organizations struggle with where to begin. While PCI DSS outlines what’s in scope, it doesn’t specify how to go about identifying all cardholder data in an organization’s systems and processes. That’s where a defined methodology comes in.

Begin with a formal scoping methodology tailored to the organization, focused on people, processes, and technology. This typically includes:

  • People. Conduct employee surveys and interviews to understand how cardholder data is used in business processes.
  • Processes. Perform walk-throughs of physical and digital processes to uncover all data flows and storage. Analyze vendor relationships to identify potential entry or exit points for cardholder data.
  • Technology. Review system inventories and configurations to identify supporting and security-impacting systems.

Scope expands quickly – Track it at every layer

Understanding the full scope requires more than knowing what’s in the CDE. PCI DSS v4.0.1 expects organizations to map out the following layers:

  • Business processes involving cardholder data
  • Applications that support those processes
  • Infrastructure components that support those applications (servers, databases, etc.)
  • Network segments that touch or influence those components
  • Physical locations of those segments
  • Systems that support and offer security in those locations
  • Third-party providers that have access to or could affect security of those systems

For each business process, it’s important to consider user access, system configurations, and even security tooling such as source code management or centralized authentication. The scope tends to spread outward, especially as organizations realize how many components support the CDE either directly or indirectly.

Determine which layers or components are in scope

Once organizations have components identified, it’s time to determine which are in scope.

  • CDE systems. Systems are in scope if they store, process, or transmit cardholder data – or if they exist on the same network that stores, processes, or transmits cardholder data.
  • Connected-to or security-impacting systems. Components are in scope if they connect to the CDE (directly or indirectly), affect the configuration of the CDE, provide security services to the CDE, are responsible for segmentation controls, or support PCI requirements.
  • Out-of-scope systems. A component is out of scope if it does not store, process, or transmit cardholder data; if it’s not in the same segment as other CDE systems; and if there is no connection to CDE systems.

Documentation is critical

Scoping isn’t complete without documentation that satisfies PCI DSS test procedures and aligns with assessor expectations. In each case, assessors expect documentation to be updated consistently as part of the scoping exercise. This includes the following:

  • Create data flow diagrams that trace account data from entry to exit of in-scope systems, including data storage and destruction.
  • Use network diagrams to highlight in-scope segments, controls, and segmentation boundaries. (While highlighting out-of-scope segments is not a requirement, it can be helpful in reporting.)
  • Start with identifying business processes, and then expand to include applications, infrastructure, security services, user computing devices, network segments, physical and digital locations, and third-party involvement.

Combining business process maps with technical diagrams provides a clear, comprehensive view to support compliance and enable better communication across teams and with an organization’s QSA.

Scope is dynamic – Build for change

PCI DSS requires annual scoping at a minimum, but real-world environments change more frequently than once per year. Mergers, new applications, cloud migrations, and staff changes can all shift the scope. Organizations should implement processes to trigger scoping reviews when these events occur.

Change-control processes, configuration management, and asset inventories should all feed into the scoping life cycle. Embedding scope awareness into business and IT governance processes helps organizations stay ahead of changes – and prevents surprises during an assessment.

Scoping is a shared responsibility

Scoping ownership doesn’t lie solely with compliance or IT teams. Business units, security leaders, third-party managers, and end users all play a role. A successful scoping process draws from across the organization to build an accurate picture.

When organizations take this ownership seriously – and adopt a repeatable, collaborative methodology – the results can be tangible. They are more likely to align with assessors, increase efficiency, and gain deeper visibility into the systems and processes that touch sensitive data. For organizations that find scoping difficult, it can be helpful to engage with an experienced third party to help with scope identification as well as overall strategy.

Extensive PCI validation experience
Our PCI compliance assessment team can objectively test your processes and procedures against the latest PCI compliance standards.

Contact us


Our team is here to answer your PCI compliance questions. Contact us today to see how we can help your organization. 

Jeffrey Palgon
Jeffrey A. Palgon
Partner, IT Assurance
Sean McAloon
Sean McAloon
IT Assurance