You reduce PCI DSS scope by cutting the number of people, processes and systems that store, process or transmit cardholder data, then proving the boundary you drew actually holds. The four levers that work are: stop keeping card data you do not need, send payments through a validated third party so card numbers never touch your network, replace card numbers with tokens, and segment what is left. None of them makes PCI DSS go away. They make the part you must protect, test and document smaller.
TL;DR
- Scope is every person, process and technology that touches cardholder data, plus anything connected to it or able to affect its security.
- The biggest wins come from not handling card data at all: hosted payment pages, validated P2PE terminals and tokenization.
- Segmentation is recommended, not required, and it only counts if you test it and keep the controls on shared services in place.
- Outsourcing moves work, not responsibility: you still manage your providers and confirm your own compliance.
- Review scope at least once a year and after any significant change to the environment.
Table of Contents
- Why organizations reduce PCI DSS scope
- What is actually in scope
- Step 1: Map every payment data flow
- Step 2: Stop storing and handling data you do not need
- Step 3: Take payments off your network
- Step 4: Segment what remains
- Step 5: Prove the boundary and keep it current
- A worked example
- Common mistakes that quietly rebuild your scope
- Perspective: why one accountable team helps
- Get help shrinking your environment
- FAQ
- Sources
Why organizations reduce PCI DSS scope
Scope sets the size of everything else. Every system inside it needs configuration standards, patching, logging, access control, vulnerability scanning and evidence for the assessor. The PCI Security Standards Council says segmentation, for example, may reduce assessment scope and cost, and the cost and difficulty of implementing and maintaining controls, as well as risk to payment account data. Google Cloud's architecture guidance makes the same point in practical terms: fewer in-scope systems means less complexity and a simpler assessment.
For a small business, that usually means the difference between a short self-assessment and a long one. For a mid-sized company, it can mean the difference between auditing a handful of segments and auditing the whole corporate network. For a healthcare provider taking card payments at the front desk and online, it means keeping billing terminals away from clinical systems.
There is a security argument too. Data you never store cannot be stolen from you. A smaller environment is easier to monitor around the clock, and alerts mean more when the monitored estate is tight. Our own view is that scope reduction is a security project first and an audit project second, and the audit savings follow.
If you are still working out what the project costs, our guide to PCI compliance cost for US businesses shows where the budget goes, and our overview of PCI DSS requirements and the evidence auditors want shows what each in-scope system has to produce.
What is actually in scope
Before you can reduce anything, you need an honest picture of the starting point. PCI DSS defines scope around the cardholder data environment (CDE): the people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data. The standard then extends scope to systems connected to the CDE or able to affect its security. That includes security services such as authentication servers and log collectors, and the systems that provide network segmentation.
Three categories are worth keeping in your head:
- CDE systems. Anything that stores, processes or transmits card data: payment applications, databases, terminals, web servers that handle card entry, call-recording systems that capture spoken card numbers.
- Connected systems. Anything that can reach the CDE without a control that stops it: a flat network segment, a jump host, an admin workstation, a shared file server.
- Security-impacting systems. Directory services, patching tools, SIEM, backup systems, remote access tools. They may never see a card number, yet a compromise could open the door to the CDE.
The usual surprise in a first scoping exercise is category two and three. Teams know where the payment app lives. They forget the shared domain controller, the vulnerability scanner with credentials, and the support laptop used to remote into the point-of-sale server.
Step 1: Map every payment data flow
Scope reduction starts on paper. Follow the card from the moment a customer hands it over to the moment the money settles, for every channel you accept: in-store, online checkout, phone orders, mail order, invoices paid by card, recurring billing, refunds and chargeback handling.
For each flow, record:
- where card data enters (terminal, web form, phone agent, email, paper form);
- every system, network segment and person it passes through;
- where it is stored, for how long, and why;
- which third parties receive, process or can affect it.
The PCI Council's guidance expects entities to identify all data flows, keep accurate diagrams and document the systems inside or connected to the CDE. Treat the diagram as a living document. If you want a checklist approach to keeping documentation current as sites and pages change, the same discipline applies to any recurring technical audit; a tool such as a structured data audit for AI search shows how a repeatable, page-by-page review is run, and the same habit suits payment page inventories.
One practical tip: run the mapping exercise with people from finance, customer service and operations, not only IT. The most expensive scope surprises come from a spreadsheet of card numbers on a shared drive, or a support agent who writes numbers on a notepad. Neither appears in a network diagram.
Step 2: Stop storing and handling data you do not need
The cheapest system to secure is the one that does not hold card data. Data minimisation means finding every place a primary account number (PAN) sits and asking whether the business needs it. Common culprits are old order databases, exported reports, email threads, call recordings, support ticket attachments and test environments seeded with production data.
Work through it in this order:
- Search. Use data discovery tooling across file shares, databases, cloud storage and mailboxes to find PAN patterns.
- Decide. For each location, set a business reason or delete. "We might need it someday" is not a reason.
- Purge and prevent. Delete what is not needed, then block it coming back: input masking, email filtering, call-recording pause-and-resume, and staff training on never accepting card details in chat or email.
- Consolidate what remains. If some storage is genuinely required, keep it in one place rather than ten.
Sensitive authentication data, such as the card verification code, must not be kept after authorization, so any copy of it you find is a straightforward deletion, not a judgment call.
Minimisation habits carry over to newer tools too. Healthcare teams adopting AI assistants face the same question of what data should enter a system at all, and a walk-through of HIPAA-compliant LLM deployment shows the same "keep sensitive data out of the wrong place" thinking applied to protected health information.
Step 3: Take payments off your network
The largest single reduction usually comes from changing the payment flow so card data goes straight from the customer to a validated payment provider.
Hosted payment pages and redirects
On an e-commerce site, a redirect to the provider's hosted page, or a provider-hosted field embedded in your page, means your servers do not receive the card number. Your site still influences the security of the payment page, so the script and page integrity of your checkout remains something you must protect. The scope falls sharply, but it does not fall to zero.
Validated P2PE for card-present payments
Point-to-point encryption encrypts card data at the terminal and keeps it encrypted until it reaches the processor. Merchants using a validated P2PE solution can qualify for the shortest self-assessment questionnaire; as one university finance office puts it, SAQ P2PE is shorter because validated P2PE significantly reduces the scope of requirements. Eligibility depends on the solution covering all your card data and on you not storing sensitive payment data electronically after authorization, so confirm both with your acquirer before you assume the shorter form.
Tokenization
Tokenization replaces the PAN with a token that is useless to a thief. The Council's tokenization guidance explains that tokenization can reduce scope by replacing PAN with tokens, and pairing it with P2PE can limit PAN to a secure, PTS-approved terminal. Read the limit just as carefully: any system or process with access to the tokenization system or the de-tokenization process is in scope. So the systems that can request de-tokenization need rigorous isolation, and tokens that can be turned back into card numbers by a casual API call do not shrink anything.
Outsourcing is not a transfer of responsibility
Handing payments to a third party is the point of this step, but read the fine print. The standard states that outsourcing payment environments or operations does not remove your responsibility to ensure account data is protected. In practice you must:
- choose providers that can show their own PCI DSS compliance;
- keep a written record of which requirements the provider covers and which you cover;
- monitor the provider's compliance status at least annually;
- keep your own controls on the pages, terminals and staff that connect to the provider.
Third-party risk is a topic in its own right, and our guide to the types of third-party cybersecurity risks covers how to assess the vendors you now depend on.
Step 4: Segment what remains
Some card handling cannot be outsourced: a legacy order system, a call centre, a back-office reconciliation process. The next tool is network segmentation, which isolates the CDE from everything else so that the other systems can fall out of scope.
Two facts frame the decision. First, segmentation is not a PCI DSS requirement but is strongly recommended. Without it, the whole connected network is in scope. Second, segmentation only works if it is real: a firewall rule set that permits broad access from the office network into the CDE does not isolate anything.
What a good boundary looks like
- The CDE sits in its own network zone with deny-by-default rules in both directions.
- Only named systems and named roles can reach it, and only on the ports they need.
- Administration comes through a controlled path with multi-factor authentication, not from any workstation.
- The principle of least privilege applies to access and to system connectivity; Google Cloud's guidance calls it a fundamental technique for keeping clear, defensible boundaries between in-scope components and untrusted systems.
For design patterns, zone models and common mistakes, see our network segmentation best practices guide. If your teams reach servers with remote desktop, tighten that route too with the RDP security hardening checklist, because remote access tools are a classic way around a segment boundary.
When a segmented system stays in scope
A system is out of scope only if it cannot connect to or reach the CDE and cannot affect its security. The Council's wording is that a system remains in scope if it can connect to or access the CDE, or impact its security, including by providing authentication, logging or management services. That is why the following stay in scope even when they sit in a different VLAN:
| System | Why it stays in scope |
|---|---|
| Domain controller or identity provider used by CDE admins | Provides authentication to the CDE |
| Central log collector or SIEM receiving CDE logs | Provides logging and monitoring services |
| Patch and configuration management server | Can push changes to CDE systems |
| Firewall or segmentation gateway | It is the control that defines the boundary |
| Jump host or remote-access gateway | Provides a path into the CDE |
| Backup server holding CDE images | May hold card data and can restore CDE systems |
Out of scope does not mean unprotected either. The Council's guidance warns that a system outside scope could still pose risks to the network and give attackers a path to the CDE. Keep baseline hardening, patching and monitoring on everything.
Step 5: Prove the boundary and keep it current
A scope reduction that you cannot demonstrate is just a claim. Validation has three parts.
Documentation. Maintain current data-flow and network diagrams, an inventory of in-scope systems, and a record of the reasoning for each system you treat as out of scope.
Testing. Segmentation controls are verified through penetration testing. Under the standard, validating the effectiveness of segmentation includes annual penetration testing of the segmentation controls, and the tests should try to cross the boundary from out-of-scope networks into the CDE. Our guide to penetration testing types explains how to match network, web and cloud tests to risk, and if the CDE is hosted in a public cloud, read the notes on cloud penetration testing without provider suspension before you schedule anything.
Review cadence. Organizations must review scope at least annually, and service providers every six months, as well as after significant changes to the environment. Triggers worth writing into your change process include a new payment channel, a new processor, a cloud migration, an acquisition, a new office network and a new remote-access tool.
Remember who owns the answer. The assessor's role is to confirm that you have accurately defined and documented your scope, but this does not replace your own responsibility to confirm it.
A worked example
Consider a regional clinic group with twelve sites, a patient portal and front-desk card terminals. Before the project, terminals connect over the same network as clinical workstations, the portal takes card details on its own servers, and the billing team keeps a spreadsheet of cards on file.
- Map. The mapping exercise finds three flows: front-desk terminals, the portal, and phone payments taken by billing staff.
- Minimise. The spreadsheet is deleted, and card-on-file is replaced by provider-held tokens.
- Take off network. Terminals move to a validated P2PE solution, and the portal moves to a provider-hosted payment page.
- Segment. Phone payments, the one flow left, are handled on a small isolated workstation group with its own firewall rules.
- Prove. The clinic documents the flows, tests the boundary, and sets an annual scope review.
The result in this example is an environment of a few workstations and a provider relationship to manage, instead of twelve sites of mixed clinical and payment systems. The clinic still has duties, including provider monitoring and the controls on the isolated group, but the assessment surface is a fraction of the original. This is an illustration of the method, not a client result.
Common mistakes that quietly rebuild your scope
- Declaring scope by org chart. Scope follows data and connectivity, not departments.
- Forgetting shared services. Identity, logging and management tools keep nearby systems in scope.
- Trusting a provider's logo. Ask for the provider's current compliance evidence and a responsibility matrix.
- Segmenting once and forgetting. A firewall change six months later can reopen the path. Retest after significant change.
- Leaving encrypted data keys exposed. If encrypted card data is stored and the keys sit within reach, the encryption does not help. Our note on data encryption at rest and key security explains how to choose the layer and then protect the keys.
- Custom payment code without secure development. If you build your own checkout, apply secure development practice; the secure software development lifecycle guide is a good starting point.
Perspective: why one accountable team helps
We see the same pattern in scope projects. The technical levers are well known. What stalls a project is that the pieces sit with different vendors: one runs the network, another the cloud, a third the monitoring, and a fourth writes the compliance paperwork. Nobody owns the boundary.
When one team designs the segmentation, monitors the CDE around the clock, runs the segmentation tests and prepares the evidence, the boundary stays consistent from design to audit. That is how we approach it: one point of accountability across network infrastructure, cybersecurity, cloud and compliance, with senior practitioners rather than generalists on the work.
Our advice is to treat scope reduction as the first workstream of any PCI effort, not a cleanup after it. Every system you take out of the environment is a system you never have to harden, patch, log or defend in front of an assessor.
Nick - Sr. Executive
Get help shrinking your environment
If you want a second pair of eyes on your payment flows, we can help you map the CDE, design segmentation, run the boundary tests and prepare compliance evidence under a single contract. Our services cover cybersecurity, cloud solutions, network infrastructure, managed IT, compliance and risk, and data protection, with one accountable team behind them.
See how the pieces fit on our services page, or start from the Nexus home page and tell us which payment channels you run.
FAQ
Does outsourcing payments take me out of PCI DSS scope entirely?
No. Outsourcing can shrink your scope considerably, but the standard says it does not remove your responsibility to ensure account data is protected. You must still manage and monitor the provider, and keep controls on the pages, terminals and people that connect to it. Ask your acquirer which questionnaire applies to your setup.
Is network segmentation required for PCI DSS?
No, it is not a requirement, but the Council strongly recommends it because it can lower assessment scope, cost and risk. Without it, every system on the connected network is treated as in scope. If you do rely on it, plan for annual testing of the boundary.
Does tokenization remove a system from scope?
It can, for systems that only ever see tokens. Systems with access to the tokenization system or the de-tokenization process stay in scope, so isolate those carefully. Pairing tokens with validated P2PE terminals limits where the card number exists.
How often should I review my PCI DSS scope?
At least once a year and whenever the environment changes significantly, such as a new payment channel, processor or network design. Service providers must confirm scope every six months, per the PCI DSS v4.0 requirements. Your assessor will check your documentation, but the confirmation is your job.
Can a smaller business use a shorter self-assessment?
Often yes, if the payment setup qualifies. A validated P2PE solution that covers all card data can make the short SAQ P2PE available. Your acquirer or payment brand decides your validation requirements, so confirm with them before choosing a form.
Sources
- Payment Card Industry Data Security Standard v4.0.1
- Guidance for PCI DSS Scoping and Network Segmentation
- PCI DSS v4.0 standard
- PCI DSS Information Supplement: Tokenization Guidelines
- PCI DSS Quick Reference Guide
- Limiting scope of compliance for PCI environments in Google Cloud
- PCI DSS Self-Assessment Questionnaire (SAQ) Types