The FBI's Internet Crime Complaint Center logged 1,008,597 complaints and $20.877 billion in reported losses during 2025, a 26% rise over 2024, with debit and credit cards among the payment types victims lost money through most often.

To combat this, the five card brands wrote the Payment Card Industry Data Security Standard (PCI DSS) in 2006 to cut fraud on their own networks, and accepting their cards means following it. Card data triggers the standard. The criteria for a system to fall under PCI DSS is that card data touches it, or because that system can reach another system where card details are stored. This standard exclusively applies to card data.

PCI scope defines the size of your annual assessment carried out by a Qualified Security Assessor (QSA) that determines how secure/compliant your system is. Every system inside it has to comply with all applicable security controls, including firewall rules, encryption of stored card data, unique logins, access limits by job role, logging, patching, anti-malware, and security testing. The assessor requires evidence for each one in the form of screenshots, config exports, logs, and written policies.

If the scope is wide enough, it pulls in servers, laptops, and even network gear that doesn't hold card data, and every one of them gets the same treatment.

The Payment Card Industry Data Security Standard (PCI DSS) sets rules for sorting systems into in scope and out of scope. Applying those rules produces a scope an assessor accepts. It also shows you what to cut.

What Is PCI Scope?

PCI scope is the people, processes, and technology that PCI DSS rules apply to. The Payment Card Industry Security Standards Council sets three groups for an environment.

• One group forms the cardholder data environment, or CDE.
• Another covers systems that connect to the CDE or affect how well it is protected.

The rest sits out of scope. Your PCI DSS level sets which validation path you follow. It could be anything from a self-assessment questionnaire up to a full audit. The scope sets the size of the job.

What Is In Scope for PCI DSS

Two groups of systems are in scope.

1. Systems in the cardholder data environment

• Systems that store, process, or send cardholder data or sensitive authentication data. Cardholder data means the primary account number (PAN), cardholder name, expiration date, and service code
• Any system on the same network segment as those systems, even if it touches zero card data
• Payment apps, checkout pages, and every script running on them
• Card readers, payment kiosks, and point-of-sale terminals
• Phone systems, call recordings, and agent desktops used for taking card numbers over the phone
• Databases, file shares, and backups holding card data, including old archives
• Virtual machine hosts and container platforms running any of the above

2. Systems that connect to the CDE or affect its security

• Login servers, directory services, and identity providers controlling CDE access
• DNS, time, and patch servers the CDE relies on
• Admin laptops and jump servers used to reach CDE systems
• Logging, monitoring, scanning, and anti-malware tools covering CDE systems
• Firewalls, routers, and switches keeping the CDE separated
• Reporting and analytics systems fed with card data

PCI DSS applies the same controls to the second group, because, for instance, a login server with access to the CDE could give an attacker a route to card data.

What Is Out of Scope for PCI DSS

A system is out of scope when all five of these hold true.

• It stores, processes, and sends zero cardholder data and zero sensitive authentication data
• It sits on a network segment cut off from the CDE, using controls an assessor can test
• It has no connection to any CDE system and no way to reach one
• It has no effect on the security controls protecting the CDE
• It sits outside the definitions for connect-to and security-affecting systems

Common examples include marketing sites hosted away from checkout, HR and payroll tools, test environments running fake data, and office networks with their own internet connection. Each one needs evidence. Segmentation testing produces that evidence, and an assessor asks for the results before accepting the exclusion.

Where Tokenization Helps Shrink Your Scope

A token is a stand-in value for a card number, with no math linking it back to the original. Systems holding only tokens fall out of scope when the real data sits in a third party's vault and you hold no way to reverse the token. The data creating scope never reaches your environment. Tokenization cuts PCI scope for that reason.

Truncated card numbers follow similar logic. The first six and last four digits stay out of scope as long as the middle digits appear nowhere in your systems. Handing card capture to a PCI-compliant service provider moves whole systems out of your assessment, with one job left on your side. Requirement 12.8 makes you responsible for tracking each provider's compliance status, so collect their Attestation of Compliance every year and watch the expiry date.

Systems That Come Into Scope Later

Scope grows through ordinary decisions made after the lines were drawn.

• One directory service handling both office logins and payment system admins
• A flat network where a firewall rule opened for a project was never closed
• Support tools catching card numbers in chat logs, emails, or tickets
• Backup and disaster recovery sites copying CDE data elsewhere
• Third-party scripts added to checkout by marketing, analytics, or chat vendors
• Cloud admin consoles with control over CDE workloads
• Paper receipts, order forms, and mail orders carrying full card numbers

Each situation ends the same way. The full set of PCI DSS rules now covers that system, and someone on your team owns the job of proving those rules work.

How to Confirm Your PCI Scope Each Year

PCI DSS v4.0.1 Requirement 12.5.2 tells merchants to document and confirm scope at least once every 12 months, and again after any large change to the environment. Service providers repeat the exercise every six months under Requirement 12.5.2.1. Six tasks cover the work.

• Map every place card data enters, moves through, and leaves your systems
• Draw a current data flow diagram and a network diagram marking the CDE
• List the systems in the CDE and the systems connected to them
• Test that separated network segments really are separated, yearly for merchants and every six months for service providers
• Write down why each out-of-scope system qualifies
• Check the compliance status of every provider handling card data for you

Documentation matters most here. An assessor asks why a system sits out of scope, and a dated diagram with a written justification answers in minutes. Recording decisions as you make them shortens the review.

How to Cut the Number of Systems in Scope

Scope drops when card data stays off your infrastructure.

• Capture cards through hosted fields or an iframe run by a compliant provider
• Tokenize card data the moment it arrives, so everything downstream gets a token
• Put the CDE on its own network with tested separation
• Give CDE admins separate logins used for nothing else
• Strip card data out of call recordings and tickets with pause-and-resume recording or dual-tone multi-frequency (DTMF) masking
• Set retention limits and delete stored card data once you no longer need it

Every system you remove means fewer controls to prove and a shorter assessment. Compliance costs drop with it. Scope also decides which validation path applies, so knowing who needs to be PCI compliant and at what level gives you a target to design toward. A PCI compliance checklist turns what remains into working tasks.

To understand your PCI scope, talk with the PCI experts over at IXOPAY