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.
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.
"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:
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:
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.
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:
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:
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.
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.
“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:
1. Identify where and how you receive cardholder data (CHD)Here’s a summary of the steps to maintain PCI DSS compliance after scoping:
1. Maintain your inventoryThe 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.
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.”
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:
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:
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.