The first step of PCI DSS? Nailing your scope. This comprehensive guide covers PCI scoping from A to Z. Experts share how to determine what’s in scope, explain new PCI v4.0 rules, and explore the best strategies to reduce your scope to the essentials.

What is PCI scope?

PCI scope refers to the systems, people, and processes subject to PCI DSS requirements. If a system component can affect cardholder security, it is in scope. Organizations must apply PCI security controls to everything in scope to be PCI-compliant.

In general, anything that can process, store, transmit, or impact the security of cardholder data (CHD) is in the scope of the Payment Card Industry Data Security Standard (PCI DSS). Cardholder data includes information like a primary account number (PAN), personal identification numbers (PINs), and PIN blocks.

Your organization’s scope includes systems that directly handle cardholder data and those that can access or affect those systems. This might consist of backup servers, network devices, or specific personnel. Essentially, if a system can impact cardholder security or access cardholder data, it falls under PCI scope.

According to the PCI Security Standards Council (SSC), the first step in preparing for a PCI DSS assessment is to determine your scope accurately. This means identifying all the system components, personnel, and processes that must follow PCI security rules. In PCI terms, a “system component” includes any device, server, or application that handles or impacts cardholder data security.

Depending on your PCI standard level, you will verify your scope through internal reviews and annual assessments, or your PCI Qualified Security Assessor (QSA) will confirm it during your security control assessment.

Since PCI DSS has strict security rules that can be costly and time-consuming to implement, organizations should limit the systems that handle cardholder data. This approach narrows the organization's PCI scope and reduces its security burden.

Michelle Strickler, Information Security and Data Privacy Compliance Strategist at Strike Graph, explains that applying strict PCI security measures to an organization’s entire infrastructure could be expensive, difficult, and unnecessary.

"We don’t want to apply strong security controls where they don’t make sense from a risk mitigation perspective," she says. "Instead, organizations aim for an appropriate scope so they only apply PCI-level security controls on systems that handle or connect to cardholder data. This way, they focus their PC security efforts on these critical areas."

Key Takeaways:

• Determining your PCI scope involves figuring out which systems, networks, people, or processes touch cardholder data
• Minimizing your PCI scope saves money and resources and provides flexibility by allowing you to focus security efforts on fewer critical systems.
• Start PCI scoping by making a list of all systems, people, and processes that handle cardholder data, directly or indirectly.
• The new PCI DSS v4.0.1 requires all organizations to review their PCI scope every year before their official assessment.
• One of the best ways to reduce your PCI scope is by using network segmentation to separate the cardholder data environment from other systems on your network.
  
  

What are PCI scoping categories?

PCI scoping categories include "in-scope" systems that handle cardholder data and "connected-to" systems that indirectly affect it. Both are in scope and require PCI DSS security measures. "Out-of-scope" systems don't impact cardholder data and aren’t in scope for PCI DSS.

The PCI Standards Council (PCI SSC) defined three categories to help organizations classify their systems and determine their scope:

• In-scope systems: These systems are in the cardholder environment (CDE) and directly handle cardholder data (CHD) or sensitive authentication data (SAD).
  
  
• Connected-to or impacting systems: These systems connect to or could affect the security of in-scope systems, even if they don’t directly handle cardholder data.
  
  
• Out-of-scope systems: These systems don’t interact with or impact the security of cardholder data and are not part of the PCI scope.
  
  

The PCI SSC suggests using these categories to organize and manage your systems. Although following these categories is a best practice, it is not required.

Here’s a detailed description of each category and common examples from Stephen Ferrell,  CISA CRISC, and Chief Strategy Officer at Strike Graph.

• In-scope cardholder data environment (CDE) systems:
  In-scope for PCI DSS review: YES
  
  Description: Components within the CDE that directly handle, store, or transmit cardholder data (CHD) or sensitive authentication data (SAD). This category includes components on the same network segment as those that handle CHD or SAD.
  
  Examples: Point-of-sale terminals, payment servers, databases storing cardholder data, internal systems, and networks handling cardholder data.
  
  
• Connected-to and security-impacting systems
  In-scope for PCI DSS review: YES
  
  Description: Connected-to components have access to the CDE but are on a separate network. Security-impacting systems either provide security services for the CDE or support other PCI DSS requirements.
  
  Examples: Firewalls, routers, or switches that connect to the CDE or affect its security.
  
  
• Out-of-scope systems:
  In-scope for PCI DSS review: NO
  
  Description: These system components do not meet the criteria for in-scope, connected-to, or security-impacting categories.  They do not store, process, or transmit sensitive data, cannot connect with the CDE, and do not impact security controls for in-scope systems. Systems that are out of scope cannot compromise any in-scope system.
  
  Examples: Systems that have nothing to do with cardholder data, like employee HR systems.
  

When are systems considered in scope?

Systems fall into scope if they affect cardholder data security. Systems that handle, process, transmit, or store cardholder data and operate within the cardholder data environment (CDE) are in scope. Components that connect to the CDE or impact its security also fall into scope.

All systems that fall under the “in-scope” or connected to or security-impacting” categories fall in scope for PCI DSS. Here’s a streamlined breakdown of how the PCI SSC describes systems that are in scope and subject to PCI DSS requirements.

PCI DSS applies to:

• The CDE (in-scope category):
  • System components, people, and processes that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD).
  • System components with unrestricted access to any component that stores, processes, or transmits CHD or SAD.
    
    
• Systems that could affect the security of CHD or SAD (connected-to and security-impacting category):
  
  This list includes various system components, people, and processes that might impact data security and therefore are subject to PCI DSS requirements. The PCI SSC provides the following examples:
  
  
  • Devices and systems
    • • Systems that store, process, or transmit account data (like payment terminals, authorization systems, and shopping carts)
      • Systems that provide security services (like authentication servers, access controls, anti-malware).
      • Systems for segmentation (like network security controls).
      • Systems impacting account data or the CDE (like name resolution servers).Virtual machines, virtual switches, cloud infrastructure, and services.
        
        
  • Virtual cloud components
    • • Virtual machines, virtual switches, virtual appliances, hypervisor
      • Cloud infrastructure
        
        
  • Network components:
    • • Security authentication controls, switches, routers, VoIP devices, and wireless access points.
        
        
  • Server types:
    • • Web, application, database, authentication, and other types of servers.
        
        
  • End-user devices:
    • • Computers, laptops, tablets, and mobile devices
        
        
  • Data storage
    • Account data in various formats (paper, data files, images)
      
      
  • Applications and software
    • All types of software that you purchase or subscribe to (like SaaS)
      
      

When are systems considered out of scope?

Systems are out of scope if they don’t affect cardholder data. This means they are not involved in the cardholder data environment (CDE). Also, they cannot connect to it and do not impact the security controls for any in-scope systems.

To be out of scope, a system must meet ALL of the following criteria, defined by the PCI SSC:

• System component does NOT store, process, or transmit CHD or sensitive authentication data (SAD)
• System component is NOT in the same network segment as any systems that store process or transmit CD or SAD
• System component cannot connect to any system in the CDE
• System component is NOT connected to or doesn’t impact the security of any in-scope systems
  
  

PCI scoping process

The PCI scoping process identifies which system components fall into the scope of a PCI assessment. It involves examining your cardholder data environment and connected systems. The goal is to minimize the scope by applying PCI security controls only to systems that must handle or connect to cardholder data.

Don’t let scoping be a difficult challenge. Download our PCI Scoping Toolkit now and take control of your PCI compliance journey.

PCI scoping steps

To determine your PCI scope, follow these steps: Identify where you receive cardholder data. Second, define your cardholder data environment (CDE). Third, maintain an updated inventory of in-scope areas and use strategies to minimize scope. Finally, apply PCI requirements to all in-scope areas.

Here’s the broad scoping approach recommended by Blazej Jedras, Head of IT Governance at Compliance Path, an Ideagen Software Company:

“Start by mapping out the steps in your payment process to determine where you receive, process, and store cardholder data. This approach will help you create a data flow diagram to show how your cardholder data moves through your system,” he says.

“Next, inventory the components within scope, such as important devices, personnel, and processes. Explore strategies like network segmentation to minimize your scope to the essentials. From there, you’ll have your finalized scope and can begin to apply the proper security controls to what’s in scope to remain compliant.”

“Start by mapping out the steps in your payment process to determine where you receive, process, and store cardholder data. This approach will help you create a data flow diagram to show how your cardholder data moves through your system,” he says.

“Next, inventory the components within scope, such as important devices, personnel, and processes. Explore strategies like network segmentation to minimize your scope to the essentials. From there, you’ll have your finalized scope and can begin to apply the proper security controls to what’s in scope to remain compliant.”

Here's a detailed summary of steps to determine your PCI DSS scope:

• Map data entry points: Find all locations and methods where CHD enters your organization, like payment terminals.

• Track data transmission: Determine how and where CHD moves across your systems and networks, including any third-party services like public cloud providers.
  

• Map CHD flows: Draw diagrams that show how cardholder data flows through your systems, covering data input, processing, storage, and transmission. Creating these diagrams meets PCI DSS requirements 1.1.2 and 1.1.3

• Personnel: List all employees and contractors who access or interact with the CDE.
• Processes: Identify business and technical processes that handle or impact cardholder data, such as data entry, transaction processing, and data management.
• System components: Catalog all system components like servers, network devices, and applications that interact with or could impact the CDE.
• •  

• Segment the CDE: Set boundaries to separate the CDE from other parts of your network. This may involve network segmentation or implementing controls to limit access.

Here’s a summary of the steps to maintain PCI DSS compliance after scoping:

• Update inventory: Regularly update and review your inventory of in-scope hardware and systems. Conduct a documentation review annually. Maintaining this inventory fulfills PCI DSS requirement 2.4.
• Document changes: Keep detailed records of changes to system components, processes, or personnel that affect PCI scope.
  
  

• Apply controls: Adopt and follow a PCI policy to apply the correct security controls to all in-scope systems.  Most organizations will validate these controls and other compliance efforts on their self-assessment questionnaire.

• Monitor regularly: Perform a scope validation and scoping exercise annually. Assessing your scope annually fulfills PCI DSS requirement 12.5.1.

Steps to Determine Your PCI Scope

How did PCI DSS v4.0 change scoping validation requirements?

The PCI DSS v4.0 standard requires organizations to treat scoping as an ongoing process. It requires an annual scoping exercise before their PCI assessment. It also offers guidelines to help organizations determine if modern technology like cloud systems are in scope.

PCI DSS v4.0 is the latest PCI standard and now includes a wording update with PCI DSS v4.0.1. Most of the v4.0 rules went into effect on March 31, 2024, but some don’t until March 31, 2025.

“PCI v4.0 emphasizes treating security, including scoping, as an ongoing process, not just something to focus on during PCI assessment time,” says Ferrell. “For example, there’s a new rule in v4.0 that requires organizations to check their scope annually and stay aware of where they hold cardholder data.”

In v4.0, there’s a new annual scope validation exercise requirement. Here’s a summary of that new scoping requirement.

• Requirement 12.5.2: This new requirement took effect on March 31, 2024. It requires organizations to document and confirm their PCI DSS scope annually, or whenever there is any significant change to the in-scope environment, before the annual assessment.
  
  

Ferrell adds, “Along with this new formal requirement, the PCI v4.0 standard also provides more examples to help guide organizations when they’re trying to determine the scope of more complex systems that third-party providers offer, like cloud storage.”

How did PCI DSS v4.0 change scoping requirements for service providers?

Under PCI DSS v4.0, service providers will need to formally assess their scope every six months, or whenever there is a significant change to their cardholder data environment. This rule goes into effect on March 31, 2025.

Under the latest PCI DSS standard, service providers must assess their scope more often than merchants. Here’s a summary of this new requirement:

• Requirement 12.5.2: After March 31, 2025, service providers will need to perform this assessment every six months or every time they make a significant change to their cardholder data environment.
  
  

How to determine if public cloud servers are in scope

To determine if a cloud is in scope, experts suggest checking if your provider is PCI-compliant. Include any parts of the cloud that handle cardholder data in your scope. It can be difficult to determine the scope because the provider and your organization share PCI responsibility.

In PCI DSS, a public cloud service is provided by a third-party company. This company manages the cloud and performs services on your behalf. However, these services can affect the security of your cardholder data or sensitive authentication data. Many companies find it challenging to decide whether to include cloud-hosted components in their PCI scope.

"Even though the cloud provider manages the cloud infrastructure, you control how you set up and use their services," says Ferrell.

Jedras advises that even if a cloud provider claims to be PCI-compliant, you should double-check. "If you’re using a public cloud, you need to make sure they are really PCI DSS-compliant. Don’t just take their word for it—check their security controls thoroughly."

Ferrell recommends these steps to determine if a public cloud service provider is in your PCI scope:

• Ensure the provider is PCI DSS-complaint
  • Request and review the cloud provider’s attestation of compliance (AOC) and report on compliance (ROC) to understand their compliance and how it affects your PCI DSS responsibilities.
    
    
• Define responsibilities
  • Document which parts of the cloud environment the provider is responsible for and ensure you have a clear contract outlining these responsibilities.
    
    
• Identify relevant components
  • Determine which cloud components handle cardholder data. They might include servers, databases, or storage.

• • Ensure that any component accessing cardholder data or affecting its security is part of your PCI scope and meets PCI DSS requirements. Alternatively, use strategies like tokenization or encryption to reduce cloud data from your scope.
    
    

How to reduce PCI DSS scope

To reduce your PCI DSS scope, use network segmentation to isolate the cardholder data environment (CDE). You can also use tokenization and encryption to replace sensitive data with non-sensitive data. Also, consider outsourcing some services to third parties.

Ferrell highlights the benefits of reducing your PCI scope.

“You save money by securing and assessing fewer systems,” he says. “A smaller scope also lowers the risk of breaches. Managing fewer systems makes your organization more flexible: by keeping more components out-of-scope, you can make changes and updates more freely without worrying about PCI DSS compliance.”

He also emphasizes that correctly implementing and validating strategies is crucial. “Limiting scope is important, but organizations must apply and check their strategies properly to make sure they reduce scope effectively and protect cardholder data.”

Here's a summary of the strategies to reduce PCI DSS scope. 

• Network segmentation:
  Segmentation involves isolating your cardholder environment into separate zones to isolate the cardholder data environment (CDE) from other networks.
  
  

"You can think of segmentation controls as drawing boundaries around your sensitive cardholder data," says Strickler. "This approach means you only need to apply the more stringent PCI security controls to the isolated environment with just the systems, personnel, and processes that handle the data. Without segmentation, you’d have to apply these complex controls to your entire system, which is usually unnecessarily difficult and costly to manage." 

Jedras explains there are two types of network segmentation: logical and physical.

• • Logical segmentation: "Logical segmentation uses technology like software firewalls or hypervisors to separate different networks within a single device," he says.”
• • Physical segmentation: "Physical segmentation involves using different physical devices, like firewalls, servers, and storage devices, to keep networks separate," he adds. "This method physically separates networks so they don't share the same hardware. Today, physical segmentation is less common because modern technology allows us to use logical segmentation on a single device to split networks within a single device, rather than across many.”
    
    
• Tokenization:
  “Tokenization involves replacing sensitive data with non-sensitive placeholders called tokens,” explains Ferrell. “For example, you can substitute sensitive data like credit card numbers with tokens, which are random strings with no inherent value. Only the systems that handle or manage these tokens and map them to the original sensitive data need to be in scope. This approach allows you to send sensitive data along transmission channels as tokens, which takes those channels out of scope.”
  
  
• Point-to-point encryption (P2PE):
  This process encrypts cardholder data as soon as you collect it and keeps it encrypted until it reaches a secure location where it can be decrypted. “Point-to-point encryption keeps cardholder data safe during transmission,” says Ferrell. “This means you don't need to worry about including every system the data passes through in your PCI scope. Since the data is encrypted during its journey, even if someone accesses these systems, they won’t be able to see the unencrypted data.”
  
  
• Outsourcing services to a third party:
  Many organizations outsource certain business functions to external providers to reduce their PCI DSS scope. When you outsource, the third-party provider is responsible for protecting cardholder data, which can lower the number of systems you need to include in your PCI assessment.
  
  For example, organizations might outsource payment processing or data storage. What you decide to outsource depends on your organization’s size, needs, and internal capabilities. Smaller businesses often outsource payment processing to companies like Stripe or PayPal. These providers handle the PCI compliance requirements, reducing the merchant’s scope. Conversely, a large organization that processes many transactions may manage payment processing in-house due to its capacity but may still outsource other functions, such as data storage. The decision to outsource depends on your specific business model and needs.
  
  

How Strike Graph can simplify your PCI scoping process and certification

Strike Graph customizes PCI solutions to fit your needs. It helps you identify what’s in scope and manage security controls. Then, you can apply evidence only where you need to. With Strike Graph, complying with PCI – and any other framework – is more targeted and efficient.

Strike Graph designs its PCI DSS solutions so you can adapt them as you move along your unique compliance journey. Its asset inventory template helps you easily organize your components and determine which are in scope and which aren’t. Then, assign and manage your PCI security tasks within a dedicated time within the software. Strike Graph will assign specific tasks to your team members and send reminders so you can collect and organize your required evidence and be ready for an assessment.

For organizations using multiple frameworks, Strike Graph lets you split and use evidence across different standards. You can match evidence with specific controls, like linking a PCI risk assessment to both PCI DSS and general assessments.

Whether you need a PCI DSS solution or support across multiple frameworks, Strike Graph’s personalized solutions have you covered.

PCI DSS scoping FAQs

Find answers to all the top questions about PCI scoping in one convenient place. Learn whether segmentation always reduces your scope, how often to re-assess it, how scope relates to virtual credit cards, and more.

Does segmentation always reduce your PCI scope?

Segmentation usually helps reduce PCI scope by separating cardholder data from other systems. But it won’t always work if not set up correctly. You must validate segmentation to ensure it isolates your cardholder data effectively and reduces PCI scope.

Is encrypted cardholder data within PCI DSS scope?

Encrypted cardholder data is not under PCI DSS scope, but the systems that handle encryption and decryption are in PCI DSS scope. You need to include these systems in your PCI scope to meet PCI security requirements.

How often should I re-assess my PCI scope?

Under v4.0, PCI scope should be re-assessed annually or whenever there are significant changes to your systems or processes. Service providers will need to reassess every six months, starting on March 31, 2025.  This process ensures that your security measures are up to date.

How do I determine my PCI DSS scope?

To determine your PCI DSS scope, identify all systems, processes, and people that handle or affect cardholder data. Then, apply any possible strategies to minimize your scope, and re-assess your scope inventory. Regularly review and update this scope to ensure you are protecting cardholder data.

Is cardholder data that uses tokenization within PCI DSS scope?

Tokenization replaces sensitive cardholder data with non-sensitive tokens. While the tokens themselves are not subject to PCI DSS, the systems that manage and replace these tokens are. You must include those systems in your PCI DSS scope.

What is the difference between in-scope and out-of-scope in PCI?

If something is in scope for PCI DSS, you must follow the requirements. This includes systems, processes, and people involved with cardholder data. Out-of-scope items do not affect cardholder data security and are not subject to PCI DSS requirements.

Is the internal transmission of cardholder data over VOIP in PCI DSS scope?

Yes, using VOIP to transfer cardholder data is within PCI DSS scope. All ways of sending cardholder and sensitive authentication data need to follow PCI DSS rules.

What is the gateway approach to reducing PCI DSS scope?

The gateway approach involves outsourcing payment processing and storage to a third party. This approach reduces your PCI DSS scope by shifting the compliance responsibility to the third-party provider.

Are virtual credit cards in scope for PCI DSS?

Yes, virtual credit cards are in scope for PCI DSS. Even though customers use these cards for online or temporary transactions, they still involve cardholder data. Organizations must protect this data to meet PCI DSS requirements.