What is included in PCI DSS scope?

All systems, people, processes, and technologies that store, process, or transmit cardholder data, plus connected-to and security-impacting systems. This includes payment terminals, e-commerce servers, databases containing PANs, firewalls, IDS/IPS, SIEM platforms, Active Directory, DNS servers, backup systems, and any jump hosts or administrative workstations with connectivity to the cardholder data environment.

How can I reduce my PCI DSS scope?

The four primary scope reduction techniques are tokenisation (replacing PANs with non-sensitive tokens), network segmentation (isolating the CDE from the rest of your network), P2PE (encrypting cardholder data at the point of interaction so your systems never see cleartext data), and outsourcing payment processing to PCI DSS validated service providers. Each technique reduces scope differently, and they can be combined for maximum effect.

Who is responsible for determining PCI DSS scope?

The assessed entity (merchant or service provider) is responsible for determining their own PCI DSS scope. However, Qualified Security Assessors (QSAs) validate the accuracy of scope during the assessment. Getting scope wrong can invalidate your entire assessment, so it is critical to invest time in accurate scope determination before assessment activities begin.

Does using a payment gateway reduce PCI DSS scope?

Using a payment gateway can reduce your PCI DSS scope significantly, but it does not eliminate it entirely. You still have responsibilities based on your SAQ type and how your systems interact with the payment gateway. For example, a merchant using a fully hosted checkout redirect may qualify for SAQ A with approximately 22 requirements, while one using a JavaScript-based integration may need SAQ A-EP with approximately 139 requirements.

How often should PCI DSS scope be reviewed?

PCI DSS scope should be reviewed at least annually and whenever there are changes to your payment processing infrastructure, network architecture, or business processes that affect cardholder data. PCI DSS 4.0.1 requires scope to be documented and confirmed at least every 12 months. Changes such as adding new payment channels, migrating to cloud environments, or onboarding new service providers should all trigger a scope review.

← PCI DSS 4.0.1 Compliance Guide

Scope Determination

PCI DSS Scope Determination Guide

Accurately defining your PCI DSS scope is the single most important step in any compliance programme. Get scoping wrong and everything that follows — assessment, remediation, reporting — is built on a flawed foundation.

This guide covers CDE identification, connected-to systems, scope reduction techniques, and the common mistakes that lead to assessment failures.

Start Scope Assessment Talk to a PCI Expert

PCI DSS scope determination is the process of identifying all systems, people, and processes that store, process, or transmit cardholder data — or that could affect the security of cardholder data. Accurate scoping is the foundation of every PCI DSS assessment and directly determines the cost, complexity, and duration of your compliance programme.

What Is the Cardholder Data Environment (CDE)?

The Cardholder Data Environment (CDE) encompasses all people, processes, and technologies that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). The CDE is the core of your PCI DSS scope — every system within it must meet all applicable PCI DSS requirements.

Identifying the CDE requires a thorough understanding of where cardholder data enters your environment, how it moves through your systems, where it is stored, and how it is ultimately disposed of. Common examples of CDE systems include:

Payment terminals (POS devices) that read or accept card data

E-commerce servers that host checkout pages or payment forms

Databases that store primary account numbers (PANs)

Call recording systems that capture card numbers spoken by customers

Application servers that process payment transactions

File servers containing exports or reports with cardholder data

Connected-to and Security-Impacting Systems

PCI DSS scope extends beyond the CDE itself. Two additional categories of systems are in scope: connected-to systems and security-impacting systems. Failing to identify these systems is one of the most common scoping errors.

Connected-to Systems

Systems that have network connectivity to the CDE, even if they do not directly handle cardholder data. These systems could be used as an attack path to reach the CDE.

•Jump hosts and bastion servers used to access CDE systems

•Log aggregation servers that collect logs from CDE systems

•DNS servers that provide name resolution for the CDE

•Active Directory (AD) servers that authenticate CDE users

•Backup systems that store copies of CDE data or configurations

•Monitoring and management platforms with CDE visibility

Security-Impacting Systems

Systems that do not connect directly to the CDE but could affect its security posture if compromised or misconfigured.

•Firewalls and network security appliances protecting the CDE

•IDS/IPS systems monitoring CDE network traffic

•SIEM platforms collecting and correlating CDE security events

•Patch management systems responsible for CDE system updates

•Anti-malware and endpoint protection management servers

•Authentication servers (MFA, RADIUS) used by CDE personnel

How to Reduce PCI DSS Scope

Reducing scope is one of the most effective ways to lower the cost and complexity of PCI DSS compliance. These four techniques can dramatically shrink your cardholder data environment.

Tokenisation

Replace primary account numbers (PANs) with non-sensitive tokens that have no exploitable value if breached. Systems that only handle tokens instead of real PANs can be removed from PCI DSS scope entirely. Tokenisation is particularly effective for recurring billing, loyalty programmes, and any system that references card data after the initial transaction.

Network Segmentation

Isolate the CDE from the rest of your corporate network using firewalls, VLANs, and access control lists. Proper segmentation limits the number of systems that are in scope to only those within or connected to the CDE. Organisations that implement effective segmentation can reduce their in-scope system count by 70% or more.

Point-to-Point Encryption (P2PE)

Encrypt cardholder data at the point of interaction (the terminal) using a PCI-validated P2PE solution. Because the data is encrypted before it enters your environment and decrypted only by the solution provider, your systems never handle cleartext CHD. This can reduce merchants to SAQ P2PE with approximately 33 requirements.

Outsourcing to Service Providers

Shift payment processing to PCI DSS validated service providers. By using hosted checkout pages, payment redirects, or fully managed payment platforms, you transfer scope responsibility to the provider. While this does not eliminate your PCI DSS obligations entirely, it can significantly reduce the number of requirements you must address directly.

Scope Validation: How QSAs Verify Your Scope

QSAs do not simply accept the scope presented to them. They are responsible for independently verifying that all systems, networks, and processes that should be in scope have been correctly identified. Scope validation is one of the first activities in any PCI DSS assessment and sets the stage for all subsequent testing.

During scope validation, QSAs typically perform the following activities:

Data Flow Diagram Review

QSAs review data flow diagrams that trace cardholder data from the point of entry through processing, storage, and disposal. Gaps or inconsistencies in data flows often reveal systems that were missed during scoping.

Network Diagram Analysis

Network diagrams are examined to identify all connections to the CDE, including remote access paths, third-party connections, wireless networks, and inter-VLAN routing. The QSA verifies that segmentation controls match what is documented.

Personnel Interviews

QSAs interview personnel across the organisation to understand how cardholder data is actually handled in practice. Interviews frequently uncover undocumented processes or systems that should be in scope.

Segmentation Testing

If network segmentation is used to reduce scope, QSAs perform or review penetration testing that specifically validates segmentation controls. This testing confirms that systems outside the defined CDE cannot reach CDE systems through any path.

Common Scope Determination Mistakes

Forgetting Backup and Log Systems

Backup servers that store copies of CDE databases and log aggregation systems that collect security events from CDE systems are connected-to the CDE and must be included in scope. These systems are frequently overlooked because they are managed by operations teams rather than payment teams.

Assuming a Flat Network Is Acceptable

Operating on a flat network without segmentation means every system on the network is in PCI DSS scope. Implementing proper network segmentation can reduce the number of in-scope systems by 70% or more, dramatically lowering both assessment cost and compliance effort.

Not Including Call Centre Recordings

Call centre recording systems that capture customers reading out their card numbers store cardholder data and are fully in scope. Many organisations fail to recognise that recorded audio containing PANs is cardholder data under PCI DSS, leading to significant scope gaps.

Overlooking Cloud and Third-Party Connections

Cloud environments (AWS, Azure, GCP) that host payment applications or store cardholder data are in scope, as are API connections to third-party payment processors, fraud detection services, and other partners with access to CHD. Each connection must be documented and assessed.

Scope Determination Checklist

Map all cardholder data flows from entry to disposal

Identify all systems that store, process, or transmit CHD

Document connected-to systems (DNS, AD, backup, jump hosts)

Identify security-impacting systems (firewalls, SIEM, IDS)

Evaluate scope reduction opportunities (tokenisation, P2PE, segmentation)

Create data flow diagrams for each payment channel

Document network diagrams showing CDE boundaries

Verify scope with your QSA before formal assessment begins

How GRCTrack Helps with Scope Determination

Automated asset discovery and classification that identifies systems handling cardholder data across your environment

Interactive data flow mapping tools that visualise how CHD moves through your payment channels from entry to disposal

Built-in scope reduction analysis that evaluates tokenisation, segmentation, P2PE, and outsourcing opportunities specific to your architecture

Network diagram generation with automatic CDE boundary identification and connected-to system detection

QSA collaboration workspace where scope decisions are documented, versioned, and validated before assessment begins

Related PCI DSS Resources

PCI DSS 4.0.1 Guide Network Segmentation Guide SAQ Types Explained Evidence Requirements Compensating Controls

Start Your PCI DSS Scope Assessment

GRCTrack maps your cardholder data environment, identifies connected-to systems, and recommends scope reduction opportunities — so your assessment starts on the right foundation.

Create Free Account Contact Sales