In PCI DSS, scope is the cost driver. Every system component in scope must meet every requirement that applies to it, and your assessor tests each one. Fewer in-scope systems means less work, less evidence and fewer places a finding can come from.
Most teams know this and still carry more scope than they need. Card numbers turn up in places nobody designed them to be. Shared infrastructure pulls unrelated systems in. Reduction efforts stop at the obvious step and never reach the less obvious ones.
This article explains what puts a system in scope, how to find where account data actually lives, the reduction options in order of effect, and the measures that look like reduction but are not. Tokenization and network segmentation each get their own article later in this series; here they appear as options among several.
What puts a system in scope
PCI DSS applies to the cardholder data environment (CDE): the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. It also applies to system components that are connected to the CDE or could affect its security, even if they never see a card number. The primary account number (PAN) is the defining element. If you never store, process or transmit PAN, the cardholder data requirements do not apply to you.
The Council's guidance on scoping and segmentation sorts systems into three groups:
CDE systems store, process or transmit account data, or sit on the same network segment as systems that do.
Connected-to or security-impacting systems do not handle account data but can reach the CDE or affect its security. Identity providers, logging platforms, patch servers, jump hosts and CI/CD pipelines that deploy to the CDE are typical.
Out-of-scope systems cannot connect to any CDE system and cannot affect the security of the CDE.
The middle group is where most scope surprises come from. A system does not need to touch a card number to be in scope. It needs only to be able to reach or influence something that does.
Start by finding where account data is
You cannot reduce scope you have not measured. Requirement 12.5.2 asks you to document and confirm scope at least once every 12 months and on significant change, and part of that confirmation is identifying every location where account data is stored, processed or transmitted, including outside the CDE you think you have.
Look beyond the payment database. Card numbers commonly end up in:
Application and web server logs that captured a request body
Support tickets, chat transcripts and email where customers typed their card number
Call recordings and screenshots taken during support
Analytics and session-replay tools attached to a checkout page
Backups and exports of systems that once held PAN
Spreadsheets used for refunds, chargebacks or reconciliation
Automated data discovery tools help, but they need to search the places above, not only the databases. Requirement 12.10.7 asks for incident response procedures for the case where PAN is found somewhere it should not be, which tells you the Council expects it to happen.
The reduction options, in order of effect
The most effective options remove account data from your systems entirely. The weaker ones leave it in place and draw a boundary around it.
| Option | What leaves scope | What stays in scope |
|---|---|---|
| Stop storing PAN you do not need | The stores you delete, once the data is securely removed | Whatever still holds PAN, and your retention controls under 3.2.1 |
| Stop receiving PAN by outsourcing capture | Your servers, if the provider serves the entire payment page | Your management of the provider under 12.8, and anything that can alter the page or redirect |
| Replace stored PAN with tokens | Systems that hold only tokens and cannot reach the tokenization system | The tokenization system and anything that can detokenize |
| Encrypt at the point of capture with a validated P2PE solution | Most of your card-present environment | The terminals and their handling, under the SAQ P2PE requirements |
| Segment what remains | Systems that segmentation controls genuinely isolate | The CDE, connected systems and the segmentation controls themselves |
Two notes on the table. First, deletion only counts once it is complete. A retired database that still exists in a snapshot is still a location of account data. Second, outsourcing changes which self-assessment questionnaire fits, which is covered in choosing the right PCI DSS SAQ.
Sensitive authentication data is a separate case. Requirement 3.3.1 says it must not be retained after authorization, even if encrypted. That is not a scope decision you make; it is a prohibition. If you find full track data, card verification codes or PIN data stored after authorization, the answer is deletion and a root cause, not a scope boundary.
What does not reduce scope
These measures are often presented as scope reduction. They help security, but they do not take a system out of scope on their own.
Encrypting PAN you can still decrypt
Encryption under requirement 3.5.1 protects stored PAN. It does not remove the system from your scope while you hold the keys or can obtain the cleartext. The Council's published guidance treats encrypted account data as potentially out of scope only for an entity that cannot decrypt it. Confirm the position for your design with your assessor.
A policy that says you do not store PAN
A statement is not discovery. If your assessor finds PAN in a log file that your policy says cannot exist, you have a finding and a larger scope than you documented.
A separate account or subnet without controls
Putting the payment service in its own cloud account or subnet is a good start. It reduces scope only if network security controls actually prevent connections to and from everything else, and if shared services that reach both sides are counted as connected systems.
Outsourcing without managing the provider
A compliant payment provider takes much of the work, not the accountability. Requirements 12.8.1 to 12.8.5 still apply: a list of providers, written agreements, due diligence, annual monitoring of their compliance status, and a record of which requirements each provider manages.
Keeping scope reduced
Scope grows back. New features, a new support tool, an analytics tag on the checkout page or a debug log level left on in production can each bring account data or connectivity back into places you removed it from.
Three habits keep the gains:
Make scope part of change review. Any change that touches payment flows, checkout pages or connectivity to the CDE should answer "does this change PCI scope" before approval.
Run discovery on a schedule. Repeat the search for PAN in logs, tickets and exports, and keep the results as evidence for 12.5.2.
Revisit scope at the required interval. Merchants confirm scope at least once every 12 months. Service providers must do it at least once every six months under 12.5.2.1, and review scope after significant changes to organizational structure under 12.5.3.
The PCI DSS framework page lists the requirements that apply once scope is set, and the summary of what changed in PCI DSS 4.0 explains why the scope confirmation became a formal requirement.
How TrustLynce helps
TrustLynce runs continuous monitoring against in-scope systems and routes failures to their owners, so drift in a segmented environment surfaces between assessments. Payment providers and their attestation dates live in the vendor inventory, with reassessment due dates for 12.8.4.