Updated: 3 July 2026
What is the PCI DSS certification scope? The PCI DSS scope is the set of all systems, networks, devices, and processes that store, process, or transmit cardholder data (CHD) or that could affect the security of that data. It defines the boundaries of the Cardholder Data Environment (CDE). The wider the scope, the more requirements must be satisfied, the higher the assessment cost, and the longer the certification cycle. Defining scope correctly is the first and most consequential decision in any PCI DSS project.
PCI DSS scope – at a glance:
- Scope covers the CDE (systems that store/process/transmit CHD), systems connected to the CDE, and security control systems – not only database servers
- Tokenisation and P2PE are the most effective scope reduction methods – they can eliminate entire environments from the CDE
- Network segmentation (firewalls, VLANs) effectively isolates the CDE from the wider infrastructure, but requires annual technical verification by the QSA
- Scope assessment must be documented in writing and confirmed by the QSA – a verbal declaration is not sufficient
- Connected-to systems fall within scope even if they do not handle cardholder data directly – this is the most common surprise in a first PCI DSS assessment
- Patronusec as an accredited QSA conducts scope assessment at the pre-audit stage, identifying optimisations before an organisation commits an internal team to a full implementation project
Table of Contents
What is the Cardholder Data Environment (CDE) and what falls within scope?
The CDE is the core of PCI DSS scope. It encompasses all systems that store, process, or transmit the full card number (PAN), sensitive authentication data (CVV, PIN, magnetic stripe data), or other CHD elements defined in PCI DSS v4.0.1.
The three categories of in-scope systems:
| Category | Definition | Examples |
|---|---|---|
| CHD systems | Directly store, process, or transmit cardholder data | Database servers, POS terminals, payment gateways, e-commerce application servers |
| Connected-to systems | Have network access to CHD systems or could affect their security | Active Directory servers, SIEM systems, helpdesk with CDE access, monitoring platforms |
| Security control systems | Provide security services to the CDE | Firewalls, IDS/IPS, log management solutions, anti-malware |
What is NOT in scope:
Systems that:
- have no network connectivity to the CDE,
- are effectively isolated by segmentation (subject to QSA technical verification),
- process only payment tokens or encrypted data (without access to decryption keys).
Patronusec Insight: The most common surprise in a first PCI DSS assessment is the inclusion of Active Directory or infrastructure management systems within scope. The client says: “but those servers never touch card data” – and they are correct, but as systems managing access to CHD servers they are connected-to and fall within scope. In our scope assessments, we map all network flows and classify every system before issuing a proposal – the client receives an accurate quotation, not a surprise halfway through the project. Learn about our PCI DSS scope assessment.
How do you effectively reduce PCI DSS scope before the assessment?
Scope reduction is one of the most valuable activities before certification – every system excluded from the CDE means fewer requirements to satisfy and a lower overall programme cost.
Method 1: Tokenisation
Tokenisation replaces the PAN (primary account number) with a randomly generated token in business systems. A token has no value to an attacker and does not fall within PCI DSS scope. If your CRM, ERP, and helpdesk systems operate only on tokens – they are outside the CDE.
When tokenisation is most effective: organisations where the original PAN is processed only by the payment provider (processor or gateway), while all internal systems see only the token. A correctly implemented tokenisation arrangement can reduce the assessment scope from SAQ D (300+ questions) to SAQ A (approximately 22 questions).
Method 2: P2PE (Point-to-Point Encryption)
A PCI SSC-validated P2PE solution encrypts cardholder data at the terminal hardware before it enters any merchant system. Merchants using a validated P2PE solution can qualify for SAQ P2PE (33 questions) for their physical payment channels. Only solutions on the PCI SSC validated P2PE list produce this scope reduction – unvalidated terminal encryption does not.
Method 3: Network segmentation
Network segmentation isolates the CDE from the wider infrastructure through firewalls, VLANs, or zero-trust controls. Systems on the non-CDE side of the segmentation boundary are out of scope. Segmentation is not mandatory under PCI DSS but is cost-effective – the one-time investment in segmentation yields scope reduction in every subsequent annual assessment.
Segmentation must be verified technically: PCI DSS Requirement 11.4.4 requires segmentation testing at least annually. A network diagram asserting that segmentation exists is not sufficient – a QSA expects technical test evidence that traffic between CDE and non-CDE segments is blocked.
Not sure how wide your CDE actually is – or whether scope reduction through tokenisation or segmentation makes financial sense for your organisation?
Patronusec conducts scope assessments as a standalone service before any certification project. Within 2 to 3 weeks: a complete CDE map, connected-to system list, and an assessment of scope optimisation options with indicative cost savings.
Book a PCI DSS scope assessment
How do you document the PCI DSS scope for a QSA assessment?
Scope documentation is one of the first subjects the QSA reviews – absent or outdated documentation stalls Stage 1 of the audit.
Documents that define and evidence scope:
Network diagram: A current, dated diagram showing all systems in the CDE and connected-to, network segments, firewall positions, and data flows. “Current” means reflecting the live environment – not the environment from two years ago before the cloud migration.
Data Flow Diagram (DFD): A diagram showing the flow of PAN through the environment – from where it enters (payment terminal, e-commerce form, API call) through every processing step to where it exits (payment processor). The DFD is separate from the network diagram. It answers “where does PAN go?” rather than “how are systems connected?”
System inventory: A list of all in-scope systems with their classification (CHD, connected-to, security control), IP addresses, function, and owner.
Scope definition document: A written document confirming the scope boundaries, justification for any systems declared out of scope through segmentation or tokenisation, and confirmation from the QSA of scope acceptance.
How often scope must be reviewed:
PCI DSS v4.0.1 Requirement 12.5.2 requires that scope is confirmed and documented at least annually and after any significant change to the environment. A scope document that is 14 months old is a finding.
Patronusec Insight: In the assessments we conduct, the network diagram is the most consistently outdated document in client packs. Organisations with dynamic cloud environments often have diagrams that predate a significant infrastructure change – while the QSA’s first task is to verify the diagram against the live environment. An inaccurate diagram signals to the QSA that the client’s understanding of their own environment may be incomplete. We treat scope documentation as a deliverable of the scope assessment, not a by-product of the audit – so it is ready and current before the QSA arrives.
What is segmentation testing and why does PCI DSS require it annually?
Segmentation testing is a technical verification that the network controls separating the CDE from the rest of the infrastructure actually work as intended. It is required by PCI DSS v4.0.1 Requirement 11.4.4 at least annually and after any change to segmentation.
What segmentation testing involves:
- Attempting to establish connections from non-CDE network segments to CDE systems and confirming they are blocked
- Attempting to establish connections from the CDE to non-CDE segments (verifying unintended outbound connectivity)
- Verifying that only the permitted traffic flows described in firewall rules are actually permitted
- Confirming that no unintended connectivity exists between CDE and out-of-scope systems
Who can conduct segmentation testing:
- An internal team with appropriate skills and documented independence from the systems being tested
- An external penetration testing firm (Patronusec offers this as a standalone service)
- The QSA as part of the formal assessment (though early testing avoids surprises)
Why it matters beyond compliance:
Segmentation testing discovers misconfigured firewall rules, forgotten network connections, and test or development systems unintentionally connected to the CDE. Finding and correcting these before the QSA does is always preferable to finding them during Stage 2.
FAQ – PCI DSS scope
Can I define my own PCI DSS scope without a QSA?
Yes – for SAQ assessments, the merchant defines the scope themselves and attests to it. However, the QSA (if engaged) or the acquirer may challenge an incorrectly defined scope. A scope assessment by a QSA before the project begins provides confidence that the scope definition will withstand scrutiny.
Does migrating to the cloud change PCI DSS scope?
Yes – but the direction of change depends on the model. Cloud systems that store, process, or transmit CHD fall within the CDE in the same way as on-premises systems. Cloud provider infrastructure (hardware, hypervisor) falls within the provider’s responsibility per the Shared Responsibility Model – but the customer’s configuration, data, and access controls remain in scope.
How often does the PCI DSS scope need to be re-confirmed?
At least annually (Requirement 12.5.2) and after any significant environmental change. Examples of significant changes triggering re-scope: new cloud workloads, migrating payment flows to a new provider, adding new locations, restructuring network architecture.
Do cloud management consoles (AWS Console, Azure Portal) fall within PCI DSS scope?
If the management console is used to manage systems in the CDE, it is a connected-to system and falls within scope. MFA for cloud console access in CDE scope is now explicitly required by PCI DSS v4.0.1 Requirement 8.4.2 (mandatory from 31 March 2025).
How does Patronusec conduct a PCI DSS scope assessment?
We review the current network architecture and data flow documentation, map all systems that touch CHD or are connected-to, verify segmentation claims (if segmentation is used for scope reduction), and produce a written scope document confirming the CDE boundary. We identify scope reduction opportunities and provide indicative cost savings. After scope assessment, we provide a fixed-price quotation for the full certification engagement.
How much does a PCI DSS scope assessment cost with Patronusec?
Scope assessment is a standalone, separately priced service – it is not bundled into a certification proposal without being conducted first. After a free 30-minute initial call, we provide a fixed quotation for the scope assessment. For clients who subsequently engage us for the full certification, scope assessment costs are credited towards the certification proposal.
PCI DSS scope assessment – free consultation
Patronusec as an accredited QSA conducts scope assessments for organisations at every stage of their PCI DSS journey – from a first assessment where scope has never been formally defined, to annual re-confirmation for organisations seeking to optimise their scope before renewal.
In a free 30-minute consultation we will help you:
- Understand which systems in your environment fall within the CDE and which are connected-to
- Assess the potential for scope reduction through tokenisation, P2PE, or segmentation
- Identify the required documentation for your QSA
- Estimate the impact of scope changes on the cost and timeline of your next assessment
Free consultation | PCI DSS certification | Gap analysis PCI DSS | Penetration testing | Vulnerability scans
