PCI Compliance Scope: How to Define and Reduce Your Cardholder Data Environment

PCI DSS scope, often called your PCI compliance scope, is every system, person and process that stores, processes or transmits cardholder data (the cardholder data environment, or CDE), plus anything that connects to the CDE or could affect its security. You define it by mapping card data flows, finding stray card data, building an inventory and proving that everything you treat as out of scope is isolated. Requirement 12.5.2 says you must confirm it at least every 12 months, or every six months if you are a service provider.

Scope decides how much of your organisation has to meet the standard. Too narrow, and you risk a failed assessment or an unprotected system. Too broad, and you pay to secure and assess systems that never needed to be involved. This guide explains how to get it right under PCI DSS v4.0.1, and our free PCI compliance check gives a quick first view of where you stand.

Key takeaways

• Scope is the CDE plus everything connected to it or able to affect its security.
• Requirement 12.5.2 requires documented scope confirmation at least every 12 months and after significant change.
• Out-of-scope claims need evidence, usually tested segmentation.
• The biggest reductions come from not handling card data at all: outsourcing, tokenisation and P2PE.
• Scope creeps in through change, so build scoping into change management.

What is the cardholder data environment (CDE)?

The CDE is the people, processes and technology that store, process or transmit account data, plus system components with unrestricted connectivity to them. Account data means two things:

System components include network devices, servers, virtual machines, containers, cloud services, applications and end-user devices. The PCI SSC’s scoping and segmentation guidance, in the PCI SSC document library, gives worked examples.

Which systems are in scope for PCI DSS?

The PCI SSC guidance describes three broad categories.

Active Directory is a frequent surprise. If CDE systems rely on the corporate domain, the domain controllers are in scope, and so is much of what they manage.

How do you define your PCI compliance scope?

1. Map the data flows. Start with every way card data enters the organisation: websites, apps, telephone orders, call centres, terminals, mail and email. Follow each flow through authorisation, settlement, refunds, chargebacks and storage. Talk to finance, customer service and sales, not just IT; they often have their own workarounds.
2. Find card data you did not expect. Card numbers turn up in log files, support tickets, spreadsheets, email and call recordings. A data discovery exercise, using tools and manual review, is the only way to trust your data flow diagram.
3. Build the inventory. Requirement 12.5.1 requires an inventory of in-scope system components with a description of their function. Reconcile it against network scans, cloud asset lists and configuration management records.
4. Identify service providers. List every third party that stores, processes or transmits card data for you, or could affect its security, and manage each under Requirement 12.8.
5. Decide the boundary. Record which systems sit in each category and the evidence for every out-of-scope decision.
6. Document and confirm. Keep the output. Your assessor will ask for it.

How often must you confirm PCI scope?

At least every 12 months and after any significant change to the in-scope environment (12.5.2). The confirmation must cover all data flows, all locations of stored account data, all connected systems and any segmentation controls. Service providers must repeat it at least every six months (12.5.2.1), and must also review scope after significant changes to their organisational structure (12.5.3).

Scope creeps in through change: a new integration, cloud service or reporting tool with access to the payments database. Add scoping questions to your change process so anyone introducing a system asks whether it touches card data or connects to the CDE.

How can you reduce PCI DSS scope?

Reducing scope is the most effective way to cut the cost and effort of compliance. The options below run roughly in order of impact.

Outsourcing reduces scope but not responsibility. You still manage each provider under Requirement 12.8 and secure the parts you control. See our guide to PCI P2PE for how listed solutions are validated.

Does network segmentation take systems out of scope?

Yes, if it works and you can prove it. Segmentation is not required by PCI DSS, but without it every system that can reach the CDE is in scope. Effective segmentation isolates the CDE using firewalls, security groups, access-controlled VLANs or separate cloud accounts.

Three points catch organisations out:

• The segmentation controls themselves are in scope.
• Shared services, such as a single Active Directory or shared admin accounts across zones, can undermine segmentation.
• Segmentation must be proved by segmentation testing at least every 12 months for merchants (11.4.5) and every six months for service providers (11.4.6), and after changes to the controls.

A firewall configuration review shows whether your rule sets enforce the boundaries you have drawn. Our guide to PCI DSS firewall requirements covers the rule base and six-monthly review that Requirement 1 expects. Our article on how to build a PCI compliant network covers segmentation design in more depth.

How does scope affect the cost of PCI compliance?

More than anything else. Every system in scope needs hardening, patching, logging, access control, scanning and evidence, and every one adds to the time an assessor spends sampling. A merchant that takes card data out of its own systems can often move to a much shorter SAQ. Our guide to PCI compliance cost shows how scope drives the budget.

What does an assessor check about your scope?

For entities that complete a Report on Compliance, the Qualified Security Assessor must verify that your scope is accurate, not simply accept it. The assessor reviews your data flows, inventory and segmentation evidence, and will widen the scope if exclusions are not supported. Agreeing scope in a workshop before the assessment starts avoids surprises and wasted effort.

Getting help

Getting scope right is the foundation of every other part of PCI DSS. Sovereign Secure is a PCI SSC-approved Qualified Security Assessor company. Our PCI DSS consultancy team runs scoping workshops and scope reduction reviews, and we carry out the formal PCI compliance audit once your boundaries are settled. Contact us with a short description of your payment channels to arrange a scoping workshop.