PCI DSS Scope Reduction: Minimising Compliance Burden

Every system that stores, processes, or transmits cardholder data falls within the scope of PCI DSS. So does every system connected to those systems. For many organisations, this creates an enormous compliance surface: hundreds or even thousands of servers, workstations, network devices, and applications that must meet the full weight of PCI DSS requirements. The cost and effort scale directly with scope. More systems in scope means more vulnerability scans, more penetration tests, more access controls to manage, more logs to monitor, and more evidence to collect during assessments.

Scope reduction is the single most effective strategy for lowering PCI DSS compliance costs, shortening audit timelines, and reducing security risk. By minimising the number of systems that interact with cardholder data, organisations shrink their attack surface and their compliance burden simultaneously. The strategies in this guide are not theoretical. They are the same approaches used by thousands of merchants and service providers to move from complex, sprawling cardholder data environments to tightly controlled, well-segmented architectures.

Why Scope Matters More Than Any Other Decision

Before investing in controls, monitoring tools, or audit preparation, organisations should invest in scope reduction. The maths is straightforward: a merchant with 500 systems in scope faces fundamentally different compliance economics than one with 15 systems in scope.

PCI DSS v4.0 contains over 250 individual requirements. Each in-scope system must be assessed against the requirements relevant to its role. Quarterly vulnerability scans, annual penetration tests, file integrity monitoring, log aggregation, access reviews, encryption management, and configuration hardening all multiply with each additional system. Assessor fees increase. Internal labour increases. The probability of a compliance gap increases.

Scope also determines which Self-Assessment Questionnaire (SAQ) you qualify for. SAQ D, the most comprehensive questionnaire, contains over 300 questions and applies to merchants who do not qualify for a reduced SAQ. SAQ A, by contrast, contains only 22 questions and applies to merchants who have fully outsourced all cardholder data processing. The difference in effort between these two questionnaires can represent months of work and tens of thousands of pounds in costs.

The goal of every scope reduction strategy is the same: move cardholder data out of your environment, or isolate it so thoroughly that the rest of your environment is no longer connected to it.

Tokenisation: Removing Cardholder Data Entirely

Tokenisation is the most powerful scope reduction technique available. It works by replacing sensitive cardholder data, typically the primary account number (PAN), with a surrogate value called a token. The token is randomly generated and has no cryptographic or mathematical relationship to the original PAN. Unlike encryption, where the original data can be recovered with the correct key, a token cannot be reversed without access to the token vault maintained by the tokenisation provider.

How Tokenisation Reduces Scope

When a payment is processed through a tokenisation service, the cardholder’s PAN is captured at the point of entry and immediately sent to the token provider. The provider stores the PAN in their own PCI DSS-compliant vault and returns a token to your systems. From that point forward, your application, database, and downstream systems only ever handle tokens, never real card numbers.

Systems that only store, process, or transmit tokens are generally considered out of PCI DSS scope, provided the tokens cannot be used to retrieve the original PAN without additional authentication and authorisation through the token provider. This means your application servers, databases, analytics platforms, CRM systems, and reporting tools can all operate outside of PCI DSS scope.

Tokenisation Implementation Considerations

Not all tokenisation approaches offer the same scope reduction benefits. Format-preserving tokens, which maintain the same length and character pattern as a real PAN, may cause assessors to scrutinise systems more carefully because the tokens resemble real card numbers. Random tokens with a clearly different format provide cleaner scope exclusion.

The tokenisation provider’s security is critical. You must verify that your provider is PCI DSS Level 1 certified and that the token vault is fully isolated from your environment. Your agreement with the provider should clearly define responsibilities, and you should obtain their Attestation of Compliance (AOC) annually.

Organisations should also consider where the initial card capture occurs. If cardholder data enters your environment before being sent to the tokenisation provider, those entry-point systems remain in scope. The most effective architecture routes cardholder data directly to the provider without it ever touching your infrastructure.

Point-to-Point Encryption (P2PE)

Point-to-Point Encryption is a standard developed by the PCI Security Standards Council specifically for card-present transactions. A validated P2PE solution encrypts cardholder data within a PCI-approved secure cryptographic device (the payment terminal) at the point of interaction. The data remains encrypted as it travels through the merchant’s environment and is only decrypted within the solution provider’s secure decryption environment.

Validated P2PE Solutions and SAQ P2PE

The distinction between validated and non-validated encryption is critical. Only P2PE solutions that appear on the PCI SSC’s list of validated solutions provide the scope reduction benefits that allow merchants to use SAQ P2PE. This questionnaire contains just 33 questions, compared to over 300 in SAQ D.

A validated P2PE solution must meet rigorous requirements covering encryption key management, device manufacturing, device provisioning, terminal management, and the decryption environment. The solution provider undergoes a full P2PE assessment by a qualified P2PE assessor (P2PE QSA).

What P2PE Means for Your Environment

When you deploy a validated P2PE solution, the encrypted card data passes through your network in an unreadable format. Because you have no ability to decrypt the data, the systems through which it passes are removed from PCI DSS scope. Your network, servers, and workstations in the transaction path are no longer considered part of the cardholder data environment.

However, the payment terminals themselves remain in scope and must be managed according to the P2PE Instruction Manual (PIM) provided by the solution vendor. This includes physical security of the devices, tamper inspection procedures, and inventory management. Staff who handle payment terminals must be trained on these procedures.

P2PE is most effective for brick-and-mortar retailers, hospitality businesses, and any organisation that processes card-present transactions. It does not apply to e-commerce or card-not-present transactions, where tokenisation and hosted payment pages are the appropriate scope reduction strategies.

Network Segmentation: Isolating the Cardholder Data Environment

Network segmentation is the practice of dividing a network into separate segments or zones, with controls governing traffic between them. For PCI DSS, the objective is to isolate the cardholder data environment (CDE) from all other network segments so that systems outside the CDE cannot communicate with systems inside it.

How Segmentation Reduces Scope

Without segmentation, every system on your network is considered connected to the CDE and therefore in scope. Segmentation creates a boundary that, if properly implemented and validated, removes systems outside the boundary from PCI DSS scope.

Effective segmentation typically involves a combination of firewalls, access control lists (ACLs), VLANs with enforced routing policies, and in some cases, physically separate network infrastructure. The segmentation controls must prevent both inbound and outbound traffic between the CDE and out-of-scope segments, except for specifically defined and justified traffic flows.

Validating Segmentation

PCI DSS requires that segmentation controls be validated through penetration testing at least every six months for service providers and annually for merchants. The penetration test must confirm that segmentation controls are operational and effective, meaning that systems outside the CDE truly cannot access systems inside it.

Many organisations make the mistake of implementing segmentation but failing to test it rigorously. VLANs without proper access control enforcement, firewalls with overly permissive rules, and misconfigured routing tables are common findings during assessments. Segmentation that appears correct on paper but fails under active testing provides no scope reduction benefit.

Common Segmentation Pitfalls

The most frequent segmentation failures include flat VLANs that rely on VLAN tagging alone without access control enforcement, management networks that span both CDE and non-CDE segments, shared services such as Active Directory or DNS that bridge the segmentation boundary, and jump servers or bastion hosts that create indirect connectivity between segments.

Any system that provides services to both CDE and non-CDE systems is considered a connected system and is in scope. Organisations often overlook shared logging servers, monitoring platforms, patch management systems, and backup infrastructure. Each shared service must be evaluated and either segmented to serve only the CDE or brought fully into scope.

Outsourcing to PCI-Compliant Service Providers

Outsourcing cardholder data processing to third-party service providers is one of the most common and effective scope reduction strategies, particularly for e-commerce merchants. Providers such as Stripe, Adyen, and Braintree offer payment processing platforms that handle the capture, transmission, and storage of cardholder data entirely within their own PCI DSS-certified environments.

The Shared Responsibility Model

Outsourcing payment processing does not eliminate your PCI DSS obligations. It shifts the scope of your obligations from managing cardholder data directly to managing your relationship with the service provider and securing the systems that interact with the payment flow.

Under PCI DSS, you must confirm that each service provider handling cardholder data on your behalf is PCI DSS compliant. This is done by obtaining the provider’s current Attestation of Compliance (AOC) or confirming their listing on the Visa Global Registry of Service Providers or Mastercard’s SDP list. You must also maintain a written agreement that clearly defines each party’s PCI DSS responsibilities.

Choosing the Right Integration Model

The level of scope reduction depends on how the payment provider is integrated into your systems. There are two primary integration models for e-commerce:

Redirect/hosted payment page: The customer is redirected to the payment provider’s hosted page to enter card details. Your systems never receive cardholder data in any form. This model typically qualifies for SAQ A, the simplest questionnaire.

Embedded payment form (iFrame or JavaScript SDK): The payment form is rendered within your website using the provider’s code, but card data is submitted directly from the customer’s browser to the provider. Your servers do not handle cardholder data, but your website serves the page containing the payment form. This model may qualify for SAQ A or SAQ A-EP, depending on the specific implementation and the degree to which your website could influence the payment page.

The distinction matters significantly. SAQ A-EP contains substantially more requirements than SAQ A and includes obligations around vulnerability scanning, penetration testing, and web application security that SAQ A does not require.

Cloud-Specific Scoping: AWS, Azure, and GCP

Cloud hosting adds a layer of complexity to PCI DSS scoping because responsibilities are shared between the cloud service provider (CSP) and the customer. All three major cloud platforms, AWS, Azure, and Google Cloud Platform, maintain PCI DSS Level 1 certifications for their infrastructure, but that certification covers only the portions of the environment they manage.

The Cloud Shared Responsibility Matrix

The division of responsibility varies by service model:

Infrastructure as a Service (IaaS): The CSP secures the physical facilities, hypervisor, and network infrastructure. You are responsible for the operating system, middleware, application, data, encryption, identity management, firewall configuration, and network controls within your virtual environment.

Platform as a Service (PaaS): The CSP additionally manages the operating system and platform runtime. You remain responsible for your application code, data, user access, and application-level security configurations.

Software as a Service (SaaS): The CSP manages nearly everything. You are typically responsible only for user access management, data classification, and ensuring the service is configured securely.

Practical Cloud Scoping Steps

Begin by obtaining the CSP’s AOC and their responsibility matrix document. AWS provides the AWS PCI DSS Compliance Package, Azure offers the Azure PCI DSS Blueprint, and GCP publishes PCI DSS compliance documentation through their compliance offerings portal. Map each PCI DSS requirement to either the CSP or your organisation.

Use cloud-native security services to reduce scope further. Managed databases with transparent encryption, managed key vaults, and identity federation services all shift responsibilities to the CSP. However, every managed service you use must be verified against the CSP’s AOC to confirm it is included in their PCI DSS assessment scope.

Virtual private clouds, security groups, and network access control lists serve as segmentation controls in the cloud. The same validation requirements apply: segmentation must be tested through penetration testing and confirmed to be effective.

Hosted Payment Pages vs Embedded Payment Forms

The choice between hosted payment pages and embedded payment forms has a direct impact on your SAQ eligibility and overall PCI DSS scope. Understanding the differences is essential for any e-commerce merchant seeking to minimise compliance effort.

Hosted Payment Pages (SAQ A Eligibility)

With a hosted payment page, the customer clicks a payment button on your site and is either redirected to the payment provider’s domain or presented with a payment page served entirely by the provider. Your website contains a link or redirect, nothing more. Cardholder data never touches your systems, and your website does not serve any code that could intercept or influence the payment form.

This model provides the maximum scope reduction for e-commerce. SAQ A applies, requiring only 22 questions and no vulnerability scanning or penetration testing of your own infrastructure. Your compliance obligations are limited to ensuring the service provider is PCI DSS compliant, securing access credentials, and maintaining basic security policies.

Embedded Payment Forms (SAQ A or SAQ A-EP)

Embedded forms using iFrames or JavaScript SDKs, such as Stripe Elements or Braintree’s Drop-in UI, render the payment form within your website. The card data is captured by the provider’s code and transmitted directly to the provider without passing through your servers.

However, because your website controls the page that hosts the payment form, a compromise of your web server could theoretically allow an attacker to modify the page and redirect cardholder data to a malicious endpoint. Some assessors and card brands consider this sufficient to require SAQ A-EP rather than SAQ A, which adds requirements for quarterly vulnerability scans, web application firewalls, and change management controls.

The determining factor is whether your website can affect the security of the payment page. If your web server serves the page containing the payment form, you must carefully evaluate which SAQ applies with your QSA or ISA.

Common Scope Reduction Mistakes

Even organisations that invest heavily in scope reduction frequently make errors that undermine their efforts. Recognising these common mistakes early can save months of rework and avoid unpleasant surprises during assessments.

Assuming outsourcing eliminates all responsibility. Many organisations believe that using a PCI-compliant payment processor means they have no PCI DSS obligations. This is incorrect. You must still complete the appropriate SAQ, validate your provider’s compliance annually, maintain security policies, and secure any systems that interact with the payment flow.

Neglecting connected systems. Scope includes not only systems that directly handle cardholder data but also systems connected to those systems. Shared Active Directory domains, monitoring platforms, logging servers, and backup systems that span both CDE and non-CDE environments bring themselves into scope.

Failing to validate segmentation. Implementing segmentation controls without rigorous penetration testing provides no scope reduction benefit. Assessors will treat unsegmented and improperly segmented environments identically: the entire network is in scope.

Using non-validated encryption solutions and claiming P2PE benefits. Only solutions listed on the PCI SSC’s validated P2PE solutions list provide the scope reduction benefits associated with P2PE. End-to-end encryption solutions that are not validated may still provide security value, but they do not change your SAQ eligibility.

Overlooking staging and development environments. If development or staging environments use real cardholder data, they are in scope. Use synthetic or tokenised data in all non-production environments to keep them out of scope.

Ignoring the human element. Staff who handle payment terminals, process refunds manually, or have access to systems in the CDE are in scope. Training, background checks, and access reviews apply to every person, not just every system.

Comparison of Scope Reduction Strategies

The following table summarises the key scope reduction strategies, their primary use cases, and the SAQ eligibility they enable.

Building a Scope Reduction Programme

Scope reduction is not a one-time project. It is an ongoing programme that should be reviewed at least annually and whenever significant changes occur in your payment architecture, technology stack, or business operations.

Start by mapping your current cardholder data flows end to end. Identify every system, application, network segment, and third party that stores, processes, or transmits cardholder data, or is connected to systems that do. This data flow diagram is both a PCI DSS requirement (Requirement 1.2.4) and the foundation for every scope reduction decision.

Next, evaluate each scope reduction strategy against your business model. E-commerce merchants will benefit most from tokenisation and hosted payment pages. Brick-and-mortar retailers should prioritise validated P2PE. Organisations with complex hybrid environments will need a combination of strategies, layering network segmentation with outsourcing and tokenisation to achieve the smallest possible CDE.

Document every scope reduction decision, the rationale behind it, and the evidence supporting it. Your assessor will need to verify that each strategy is implemented correctly and that the claimed scope reduction is justified. Maintain this documentation as a living artefact, updated with each change to your payment environment.

Finally, treat scope reduction as a design principle rather than a remediation activity. When evaluating new payment integrations, product features, or infrastructure changes, always ask: does this increase or decrease the number of systems in scope? Organisations that embed this question into their architecture review process consistently maintain smaller, more manageable cardholder data environments and experience smoother, faster PCI DSS assessments.