PCI DSS scoping and segmentation: how to find, shrink and prove your cardholder data environment

What falls inside the PCI DSS scope

Which parts of the business must meet the twelve requirements? PCI DSS does not let you choose: the scope follows the data. Any system component that stores, processes or transmits cardholder data or sensitive authentication data belongs to the cardholder data environment, the CDE, and so do the people and processes that handle that data. Around it sits a second ring: systems that connect to the CDE or could change its security, such as directory services, jump hosts, logging platforms and the firewalls at its edge. Those are in scope too.

Everything else is out of scope only if you can show that its compromise could not reach the card data. That proof is yours to give, and your QSA will test it.

Cardholder data and sensitive authentication data

The two kinds of account data are treated differently. Cardholder data is the primary account number (PAN), together with the cardholder name, expiry date and service code when they appear with it. It may be kept where the business needs it, with the PAN rendered unreadable. Sensitive authentication data is the full magnetic stripe or chip data, the card verification code and PINs or PIN blocks. It must never be retained after authorisation, not even encrypted. Wherever it lingers, in a voice file, a ticket or a debug log, that place is in scope and failing requirement 3.

Finding the data: flow diagrams and data discovery

Scoping starts with a map of every channel through which a card number enters the business: web checkout, app, store terminals, telephone and mail orders, recurring billing, refunds and chargebacks. For each, trace which systems touch the number, where it rests even briefly, which third parties receive it and how it leaves. The resulting data-flow diagram sits beside the network diagram, and the assessor compares both with what they find.

Interviews and diagrams record what people believe. A data discovery exercise tests that belief. Scanning tools search file shares, databases, mailboxes, tickets, backups and cloud storage for PAN-like patterns, and each hit is checked by hand. A first discovery run seldom comes back clean: old spreadsheets from a finance team, card numbers pasted into customer service notes and exports forgotten on a shared drive are typical. Each is purged or brought into scope with its controls.

The output is a scope inventory: CDE components, connected and security-impacting systems, out-of-scope systems with the reason for each, third parties and locations. The gap analysis and the assessor's sampling both start from it.

System categories and how they are scoped

How common system types are usually treated; your architecture decides the real answer, so use this as a starting point with your QSA, not a ruling.

Segmentation: optional, powerful and tested

PCI DSS does not require segmentation. On a flat network, though, every server, laptop and printer that can reach the payment systems is in scope. Segmentation isolates the CDE so the rest of the estate reaches it only through controlled, justified paths, and it is usually the largest lever on the size of the programme.

Firewalls, VLANs with access control lists, cloud security groups, micro-segmentation or separate physical networks can all do the job. The assessor cares about the result, not the technology.

Proving that the segmentation works

A segmentation claim needs evidence, and PCI DSS asks for penetration testing of the segmentation controls under requirement 11. It is performed at least once every twelve months and after any change to the segmentation controls or methods; service providers must test at least every six months. The tester must be qualified and organisationally independent of the systems tested. Rule reviews support the claim but do not replace the test. A failed test pulls the exposed segments back into scope until the gap is closed and retested.

Shrinking the CDE: tokenisation, P2PE and outsourced payment pages

Stronger still is to stop card data arriving at all.

• Tokenisation. A token replaces the PAN in your systems and the provider holds the real number. Systems that see only tokens can fall out of scope; anything able to detokenise stays in.
• Point-to-point encryption. A PCI-listed P2PE solution encrypts card data inside the terminal, so your network carries only data it cannot decrypt, provided the solution is used exactly as listed.
• Outsourced payment pages. With a redirect or an embedded form served by a compliant provider, the card number goes straight to the provider. Your web server still controls what the browser loads, so it keeps a smaller set of requirements, including payment page script controls.
• Contact centre controls. Keypad entry with tone masking, or pause-and-resume recording, keeps card details out of agents' screens and recordings.

Each option moves responsibility to a third party rather than removing it, so collect the provider's AOC and agree a responsibility matrix. SAQ eligibility for each option is covered in Which SAQ applies to you: eligibility explained.

The annual scope confirmation

Scope is not settled once. PCI DSS requires the entity to document and confirm its scope at least once every twelve months and after any significant change to the in-scope environment; service providers must repeat the exercise more often. The confirmation revisits every data flow, the location of stored account data, the segmentation boundaries, the connections to third parties and the results of a fresh data discovery run. It is signed off, kept as evidence and reviewed by the QSA. The wider rhythm of scans, reviews and revalidation is described in The PCI DSS annual cycle.

Scoping mistakes that surface in the assessment

• A flat network described as segmented. VLANs without access controls, or firewall rules that allow any traffic from the corporate range, do not isolate anything, and the segmentation test shows it.
• Forgotten call recordings. Recordings and screen captures that hold card verification codes are stored sensitive authentication data, whatever the retention period.
• Logs holding PANs. Application and debug logs that write full card numbers bring the log platform, and everyone with access to it, into the CDE.
• Third parties left off the list. A managed service provider with administrative access to CDE systems is in scope for the services it performs, and its AOC must cover them.
• A scope written once. New channels and cloud migrations change the data flows long before the next assessment.

PCI DSS scoping and segmentation: questions buyers ask