PCI DSS Scope: A Clear Guide to All 3 Categories

PCI DSS scope is the first decision of a compliance programme and the one that
determines its cost. Get it too wide and you are hardening systems that never touch card data. Get it
too narrow and your assessor finds the gap, usually late, usually expensively. Almost everything else
in PCI DSS is downstream of this one judgement.

What PCI DSS scope actually covers

The cardholder data environment — the CDE — is the starting point, but it is not the
whole of scope. PCI DSS reaches beyond the systems holding card data to the systems that can affect
their security, which is the part organisations consistently underestimate.

PCI SSC’s scoping guidance works through system components in a strict priority order, and the
order matters because a system can appear to fit more than one description:

The rule that decides the hard cases is the one people skip. To be out of scope, PCI SSC’s guidance
says a system must meet “ALL the criteria of the out-of-scope category and NONE” of a higher one. It
is not a balance of probabilities. One qualifying criterion anywhere above pulls the system in.

The category everyone gets wrong

Category two. Systems that never see a card number but could compromise the CDE if breached are in
scope, and that catches infrastructure nobody thinks of as payment infrastructure: Active Directory,
the jump host, the patching server, the SIEM collector, the backup system, the monitoring agent
installed everywhere.

The test is not “does card data pass through it?” but “could a compromise of this system affect the
security of the CDE?” Applied honestly, that question usually expands a first-draft scope
considerably — which is uncomfortable, and much cheaper to discover now than during an
assessment.

The categories are guidance, not law

Worth knowing, because most PCI DSS scope articles present this three-way split as though it were
mandatory. PCI SSC’s own supplement is explicit that the categories are illustrative examples and
their use is not required — an organisation may use another evaluation process at its
discretion.

What is not optional is the outcome: knowing which systems are in scope and being able to justify
it. The categories are a well-tested route to that answer, and if you use another one, the burden of
explaining it to your assessor is yours.

Confirming PCI DSS scope is a requirement in its own right

Under PCI DSS v4.x, Requirement 12.5.2 obliges an entity to document and confirm
its PCI DSS scope at least once every 12 months, and after any significant change to the environment.
Scope is not a one-off exercise recorded in a project document; it is a maintained artefact with a
review cycle, and the confirmation itself is evidence an assessor will ask to see.

The version position matters here too. PCI DSS v4.0.1 is the only active version
— v3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024. Of the 64 new requirements
introduced in v4.x, 51 were future-dated and became effective on 31 March 2025, so
they are no longer best practice: they are assessed.

How to define PCI DSS scope, in order

1. Find the card data first. Follow the payment channels end to end —
   e-commerce, terminals, telephone, post, refunds, chargebacks. Card data discovery tooling is worth
   running even when you are confident, because it finds the call recordings and the spreadsheet nobody
   mentioned.
2. Draw the data flows. Every path card data takes into, through and out of the
   business, including third parties. A flow diagram is where scope arguments get settled, and its
   absence is where they start.
3. List every system component. Servers, endpoints, network devices, virtual
   machines, containers, cloud services, applications. If it is not on the inventory, it has not been
   scoped.
4. Apply the categories in priority order. CDE first, then connected-to and
   security-impacting, then out of scope — and remember that out of scope requires meeting all of
   that category’s criteria and none of a higher one.
5. Decide about segmentation deliberately. Segmentation is not required, but without
   it the flat network is the CDE. If you segment, the controls have to be tested, and that testing is
   itself an assessed activity.
6. Document the justification, not just the answer. For each significant exclusion,
   one line on why. This is the difference between a scope an assessor accepts and one they
   re-litigate.
7. Put the annual confirmation in a calendar with an owner, alongside the trigger
   for re-confirmation after significant change.

Third parties narrow scope; they do not remove it

Outsourcing payment processing genuinely reduces PCI DSS scope, sometimes dramatically. It does not
transfer accountability. You remain responsible for confirming which requirements your provider covers
and which remain yours, and that split needs to be written down — which is what a shared
responsibility matrix is for.

The common failure is assuming a provider’s compliance covers everything they touch. It covers what
their attestation says it covers, and the boundary is frequently narrower than the sales conversation
implied.

Modern architectures moved the problem

The original scoping guidance was written for networks with perimeters. PCI SSC published a newer
information supplement, PCI DSS Scoping and Segmentation Guidance for Modern Network
Architectures, in September 2024, addressing micro-segmentation, multi-cloud and the verification
of scope and segmentation controls in environments where “the network” is a set of policies rather
than a set of cables. If your CDE lives in a cloud account or a service mesh, that is the document to
read alongside the standard.

Reducing PCI DSS scope legitimately

Scope reduction is the highest-return work in a PCI programme, because every system removed is
removed from all twelve requirement areas at once. Four approaches do most of the work, and all of
them are architectural rather than documentary.

• Stop storing what you do not need. Sensitive authentication data must not be
  retained after authorisation at all. Stored card numbers you no longer have a business reason to hold
  are pure scope with no upside — find them and delete them.
• Move the card entry off your systems. Hosted payment pages and iframes shift the
  capture point to the provider. Done properly this is the single largest reduction available to an
  e-commerce merchant.
• Tokenise. Replacing stored card numbers with tokens removes the data that made
  those systems CDE systems in the first place, provided the token cannot be reversed within your
  environment.
• Segment, then prove it. Isolating the CDE keeps the rest of the network out
  — but only where the controls are real and tested. Segmentation asserted on a diagram and not
  verified is the most common way a reduced scope collapses at assessment.

What does not reduce PCI DSS scope is describing it differently. Redrawing a boundary without
changing where card data flows or what can reach it produces a document that disagrees with the
network, and the network wins.

Frequently asked questions

What is PCI DSS scope?
Every system component that stores, processes or transmits cardholder data, plus every system that
connects to or could affect the security of those systems. It is broader than the systems holding card
data.

Is network segmentation required?
No. Segmentation is optional, but without it the whole network is generally in scope. Where it is
used, the segmentation controls must be tested and the testing evidenced.

How often must PCI DSS scope be confirmed?
Requirement 12.5.2 requires documented confirmation at least once every 12 months, and after
significant changes to the environment.

Does using a payment service provider put us out of scope?
It narrows scope, often substantially, but does not eliminate it. You still need to confirm which
requirements the provider covers and document the ones that remain yours.

Which PCI DSS version applies?
v4.0.1 — the only active version since v4.0 was retired on 31 December 2024. The 51 future-dated
requirements have been effective since 31 March 2025.

References

• PCI SSC Document Library — the standard, SAQs and information supplements.
• PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures — PCI SSC information supplement, 9 September 2024.
• Just Published: PCI DSS v4.0.1 — PCI SSC on the limited revision and the retirement of v4.0.

More on PCI DSS

• PCI DSS scope — you are here
• PCI DSS documentation — the evidence checklist
• PCI DSS validation — who requires it
• PCI DSS v4.0 compliance
• ISO 27001 scope — the same discipline, a different standard

All of these are covered by the PCI-DSS Toolkit, or start with the free ISO templates.