PCI scope reduction means cutting the number of people, processes and systems that store, process or transmit card data, or that could affect its security. You do it by removing card data you don’t need, replacing it with tokens, encrypting it at the point of capture, isolating the systems that remain, and handing payment functions to validated providers. A smaller scope lowers audit cost and breach exposure. It never removes your obligations.
This guide is for operations, CX and compliance leaders at ecommerce, healthcare, legal and financial services organizations. It covers how to find your scope, the six levers that shrink it, and what your customer support operation has to do with it.
TL;DR
- Scope is wider than the card database. It includes people, processes, connected systems and third parties, not only servers that hold card numbers.
- Start by assuming everything is in scope. Exclude a component only after you verify the controls that keep it out.
- Six levers work: eliminate stored data, tokenize, use validated P2PE, segment the network, outsource payment functions, and keep agents away from raw card data.
- No technology removes every requirement. You still validate, document and monitor providers.
- Support teams are part of scope. How agents take payments, by phone, chat or email, can enlarge or shrink your footprint.
Table of Contents
- What PCI scope actually covers
- Step one: map where card data actually lives
- Six ways to reduce PCI scope
- What scope reduction does not do
- How to verify and document the reduction
- Where customer support and outsourced teams fit
- Our perspective on scope and customer operations
- Build support operations around your payment design
- FAQ
- Sources
What PCI scope actually covers
The PCI Security Standards Council (PCI SSC) defines scope as the people, processes and system components that store, process or transmit cardholder or sensitive authentication data, plus components that connect to or could affect the security of that data. That last clause is where most organizations get surprised. A help desk platform that never sees a card number can still be in scope if it sits on a network with the systems that do.
The set of in-scope components is often called the cardholder data environment, or CDE. Three groups matter:
- Systems that handle card data directly: payment applications, databases, terminals, call recording storage.
- Connected systems: anything that communicates with the CDE or shares its network without effective isolation.
- Security-impacting systems: authentication servers, logging, patching and management tools whose compromise would expose the CDE.
People and processes count too. An agent who hears a card number read aloud is part of your scope. So is the process for handling a customer who pastes a card number into a chat window.
Step one: map where card data actually lives
You can’t shrink what you haven’t mapped. PCI SSC’s scoping guidance recommends starting with the assumption that everything is in scope, then excluding components only after effective controls and boundaries have been verified. The same guidance asks you to identify and document every cardholder-data location and flow, connected systems, people, processes and third parties, and to retain the evidence for your assessor.
A practical discovery pass looks like this:
- Trace every channel where a customer can give you a card. Web checkout, phone orders, chat, email, mail-in forms, in-person terminals, and any agent-keyed entry.
- Follow each flow end to end. Where does the number enter, which systems touch it, where is it logged or recorded, and where does it leave?
- Search for strays. Old exports, call recordings, ticket attachments, spreadsheets, backups and test data often hold primary account numbers (PANs) nobody remembers.
- List every third party in the flow. Processors, gateways, call platforms, outsourced support teams.
- Write it down. A current data-flow diagram and asset inventory are what an assessor will ask for.
PCI SSC assessor Jacob Ansari describes scope as foundational: without a clear boundary, you can’t know where requirements apply or validate that boundary. Treat the map as a living document, not a one-time project.
Six ways to reduce PCI scope
The approaches below stack. Most mature programs use several together.
| Lever | What it does | What stays in scope |
|---|---|---|
| Eliminate stored data | Removes PAN you have no business reason to keep | Systems that still process or transmit it |
| Tokenization | Replaces PAN with a token outside the tokenization environment | Token vault, detokenization, and the path to them |
| Validated P2PE | Encrypts card data at the terminal, before your systems see it | Terminals, and the P2PE provider’s instructions |
| Network segmentation | Isolates the CDE from everything else | The CDE and the segmentation controls |
| Outsourcing | Moves payment handling to a compliant third party | Provider oversight and validation |
| Agent-free capture | Keeps staff from hearing or typing card data | The payment channel itself |
1. Stop storing what you don’t need
The cheapest scope reduction is deletion. SecurityMetrics advises mapping inflows and outflows and eliminating unnecessary PAN storage before reaching for technology. Ask a blunt question about every location that holds card numbers: what business purpose does this serve? If the answer is “nobody knows” or “we might need it,” purge it and prevent it from coming back.
Common culprits are CRM notes, support tickets, shared inboxes and call recordings. Block free-text card entry where you can, and write a procedure for what an agent does when a customer sends a card number in an email.
2. Tokenize
Tokenization swaps the PAN for a surrogate value. PCI SSC’s tokenization guidance explains that it can reduce the number of system components to which PCI DSS requirements apply, while the need to maintain and validate compliance remains. Adequately isolated systems that handle only tokens may sit outside the CDE. The token vault, detokenization, any remaining PAN storage, access paths and your own tokenization implementation stay in scope.
The trap is partial implementation. SecurityMetrics cautions that scope reduction depends on actually removing PAN from the environment, including old caches, not adding tokens while PAN stays reachable. If a legacy database still holds the original numbers, those systems are still in scope.
3. Use validated point-to-point encryption (P2PE)
A PCI-listed P2PE solution encrypts card data at the point of interaction so your own systems never see clear text. The PCI SSC’s SAQ instructions say the P2PE questionnaire applies to merchants who use only a validated, PCI-listed P2PE solution, have no access to clear-text account data and store no account data electronically. Eligibility also requires that terminals be the only merchant systems touching account data and that you follow the provider’s P2PE Instruction Manual.
Assessor Jacob Ansari recommends PCI-validated P2PE and suggests that merchants using nonvalidated encryption ask their providers to pursue validation. The word “validated” matters: encryption that isn’t on the PCI list doesn’t earn the same scope treatment.
4. Segment the network
Segmentation keeps out-of-scope systems from communicating with or affecting the CDE. PCI SSC notes it can use logical controls, physical controls, or both. When it works, the CDE is separated from systems that can then fall outside assessment.
Segmentation is only as good as its proof. Document firewall rules, test that traffic can’t cross the boundary, and keep the evidence. The same principle applies to the business platforms around your payments: clear platform security documentation helps your team define which systems, users and integrations sit on which side of a boundary.
5. Outsource payment functions to a compliant provider
When a third party handles payment processing and you never store, process or transmit cardholder data, the requirements applying directly to you can shrink. PCI SSC’s FAQ on outsourcing is clear that you still must verify the provider’s PCI DSS compliance, document responsibilities, monitor compliance at least annually and complete the applicable validation.
This is a shared-responsibility model. The provider performs the function. You keep governance, due diligence and monitoring. A written responsibility matrix that says who owns which requirement is the document auditors most often find missing.
6. Keep agents out of the card data path
People and processes are in scope, so the way your support team accepts payments is a scope decision. If agents hear or key card numbers, then their workstations, call recordings, screens, networks and the facility become part of the picture. If a customer completes payment through a hosted, isolated payment step while the agent stays on the line, far fewer components touch the data.
The design choice is yours: route payment capture to a validated provider’s flow, and restrict agents to confirming outcomes rather than handling numbers. Then write the procedure for the exceptions, such as a customer who reads a card number aloud anyway.
What scope reduction does not do
The PCI SSC guidance states plainly that no technology eliminates all PCI DSS requirements. Encryption or tokenization may reduce risk, reduce the applicability of some requirements or shrink the CDE. Your job is to know which requirements apply after the change, and to prove it.
PCI SSC CTO Troy Leach frames the logic as data minimization: fewer systems with access to account numbers make security and compliance more focused and manageable. That is the right way to think about the project. You aren’t looking for a loophole. You are building an environment that is easier to defend.
How to verify and document the reduction
A reduction that exists only in a slide deck won’t survive an assessment. Build verification into your annual scope review:
- Check token use. Confirm cardholder data is not retrievable outside the defined CDE and that tokens are used as intended, as the tokenization guidance describes for annual scope validation.
- Re-test segmentation. Confirm systems you consider out of scope are adequately segmented from the CDE.
- Refresh the data-flow diagram. New tools, integrations and channels change flows quietly.
- Re-confirm provider status. Collect current compliance evidence from each payment-related third party and keep your responsibility matrix current.
- Retain the evidence. Keep scoping decisions, test results and diagrams together for your assessor.
Where customer support and outsourced teams fit
Most scope-reduction content stops at infrastructure. In practice, contact centers are where card data leaks back in. Phone orders, billing disputes, refund requests and subscription changes all invite a customer to share a card number with a person.
If you outsource support, the partner’s agents, workspaces and tools become part of your third-party picture. That is manageable when you define it up front:
- Decide the payment channel before the contract. Specify whether agents ever handle card data, and if not, how payment is handed off.
- Require remote-work controls. Our guide to remote agent security controls lists what to demand from a nearshore team working outside a traditional site.
- Write security into the agreement. See the board-level controls that secure data in BPO partnerships and the contract terms to demand for cloud contact center security.
- Ask how controls are tested over time. Our explainer on SOC 2 for BPOs covers how Type II reports examine controls across a period.
- Connect fraud and disputes. Payment-related queues carry their own risks, covered in our ecommerce fraud review workflow and chargeback dispute playbook.
Our perspective on scope and customer operations
We see the same pattern in the organizations we talk to. The infrastructure team has a tidy diagram, then someone points out that agents take payments over the phone and the diagram is wrong.
Our view is that scope reduction is an operating-model decision, not only a technology purchase. The best outcome comes from designing the support workflow so agents never need card numbers at all. Fewer people touching sensitive data means fewer controls to evidence and fewer places for mistakes.
That is how we approach managed customer support and team extension. We build the workflow, the scripts and the escalation paths around your payment design, and we put clear responsibilities in writing. Our bilingual nearshore teams are meant to work inside your security boundaries, following the procedures you set, so your compliance team keeps a clear line of sight.
If you are choosing a support partner while redesigning your payment flows, bring both conversations to the same table. The answer to “who handles the card?” should be settled before the first agent is trained.
Daniela
Build support operations around your payment design
If you’re rethinking how your support team fits into your PCI boundary, we can help you structure it. Altiam CX provides nearshore customer experience, technical support, back-office operations and managed team extension, with industry-specific programs for healthcare, legal, ecommerce and financial services.
See how managed customer experience and team extension services work, or talk to us about a support model that matches your payment architecture.
FAQ
What is the fastest way to reduce PCI scope?
Delete card data you have no reason to keep, then stop it from re-entering through tickets, email and recordings. This costs the least and often removes whole systems from the picture. After that, tokenization or validated P2PE addresses the data you must still accept.
Does outsourcing payments make me PCI exempt?
No. Outsourcing can reduce the requirements that apply directly to you when you never store, process or transmit cardholder data. You still have to verify the provider’s compliance, document who is responsible for what, monitor it at least annually and complete the applicable validation.
Does tokenization take a system out of scope?
It can, if the system handles only tokens and is adequately isolated, and if the original PAN can’t be recovered from it. The token vault, detokenization and any PAN storage remain in scope. Leaving old PAN in caches or legacy databases defeats the reduction.
Is network segmentation required for PCI DSS?
Segmentation isn’t a requirement in itself. It is a way to keep out-of-scope systems from communicating with or affecting the CDE. If you don’t segment, the whole network connected to the CDE is generally treated as in scope, so effective segmentation usually shrinks the assessment.
How often should I review my PCI scope?
Review it at least annually and whenever you add a payment channel, vendor, integration or support workflow. Scope validation should include checking token use, confirming segmentation still works and updating your data-flow documentation.
Sources
- Guidance for PCI DSS Scoping and Network Segmentation (v1, December 2016)
- Guidance for PCI DSS Scoping and Network Segmentation (v1.1, May 2017)
- Assessor Viewpoint: Q&A on Scoping and Segmentation Guidance
- Council CTO Discusses Scoping and Segmentation Guidance
- PCI DSS Information Supplement: Tokenization
- Does PCI DSS apply to merchants who outsource all payment processing operations?
- Self-Assessment Questionnaire Instructions and Guidelines
- PCI Consultants Say: Reduce PCI DSS Scope
