PCI DSS Scoping for Service Providers: CDE, Segmentation and SAQ D

Most PCI DSS effort is decided by scope before anyone writes a control. Draw the boundary too wide and every system needs card-grade controls; draw it too narrow and an assessor, or an attacker, finds the gap. For a payment service provider the stakes are higher, because the standard adds service-provider-only requirements and leaves you exactly one self-assessment questionnaire.

I'm the payments-domain expert on a multi-tenant payment aggregator. On a payment orchestration platform I work on, I co-planned a PCI DSS v4.0.1 self-assessment study (SAQ D for Service Providers) with one other engineer: I built the review and estimation template and own half of the 12 principal requirements. The platform in this article is a generic example, not the architecture of any system I work on. Everything here refers to PCI DSS v4.0.1, the current version (part 1 covers the changes).

PCI SSC defines a service provider as a business, other than a payment brand, that stores, processes or transmits cardholder data for another entity, or whose services control or could affect the security of that data. Payment gateways and PSPs are the obvious examples, but managed firewall and hosting providers count too. A merchant accepts payment cards for its own goods or services. One company can be both: a PSP that bills its own merchants by card is a merchant for that flow and a service provider for everything it processes on their behalf.

Service providers carry extra requirements and have fewer validation options:

PCI SSC's scoping and segmentation supplement starts from one rule: treat every system as in scope until you have shown it isn't. It then sorts system components into three categories and evaluates them in order. A component that meets any CDE criterion is a CDE system, whatever else it does; it is out of scope only if it meets every out-of-scope criterion and none of the higher ones. The categories are a suggested method, not a mandatory one, and this 2017 supplement remains the baseline that newer PCI SSC guidance builds on.

The cardholder data environment (CDE) is the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Any component on the same network segment as those systems, such as the same subnet or VLAN, is also a CDE system, even if it never touches a card number.

A connected-to system has a communication path to a CDE system, directly or through another system such as a jump server. A security-impacting system can change the CDE's configuration or security without touching card data: authentication, traffic filtering, patch distribution, time servers, audit log storage, name resolution and the controls that provide segmentation. Both kinds are fully in scope; which requirements apply depends on what each component does.

An out-of-scope system holds no account data, sits on no CDE segment, cannot reach any CDE system directly or through an in-scope system, and cannot affect a CDE security control. It may talk to a connected-to system only if controls stop it from pivoting into the CDE. Secure such systems anyway: the supplement notes that attackers often start from systems an entity considered out of scope.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

Three placements surprise teams most often:

• Logs. One debug line that dumps a request body moves the whole logging pipeline into the CDE. Mask card data at the source, then scan the logs to prove it.
• CI/CD. The pipeline never sees a card number, but it decides what code runs in the CDE, so it is security-impacting.
• Admin tooling. A support screen with a "reveal card number" button processes cardholder data, which makes the back-office app a CDE system.

If merchants embed your hosted card fields or payment page in their checkout, the scripts on those pages bring their own requirements; part 6 covers Requirements 6.4.3 and 11.6.1.

No. The scoping supplement states that isolating the CDE from the rest of the network is not a PCI DSS requirement, but it strongly recommends it because it can cut assessment scope, cost and risk. Without segmentation you have a flat network, and every system on it is in scope.

Segmentation also has to be real. A separate VLAN or subnet does not count on its own; the supplement asks for purpose-built controls that hold even if an attacker gets administrator access on an out-of-scope system. And it has to be tested: Requirement 11.4.5 has every entity that uses segmentation penetration-test it at least every 12 months and after changes to it, and Requirement 11.4.6 tightens that to every six months for service providers.

In September 2024 PCI SSC published an information supplement on scoping and segmentation for modern network architectures, produced by a 2023 special interest group. It covers zero trust, micro-segmentation, multi-cloud and inventories of short-lived workloads. The points most useful for engineers:

• In a zero-trust design, scope follows which identities and workloads can reach CDE workloads, so validating least-privilege access belongs in every scope review.
• Testing a Kubernetes or service-mesh policy takes more than a port scan from one host outside the segment: policies may reference named resources instead of IP addresses, and routes inside a cluster differ from routes outside it.
• For ephemeral workloads, an automated inventory is the practical way to keep the Requirement 12.5.1 component list accurate.

The supplement adds no requirements; it explains how existing ones apply to newer architectures.

Both reduce scope; neither removes it. The scoping supplement says no technology eliminates all PCI DSS requirements. Encryption and tokenization can shrink the CDE or make some requirements easier to meet, but they must be configured, managed and verified like any other control.

Tokenization replaces the primary account number (PAN) with a surrogate value, a token, that can be exchanged back for the PAN only through the tokenization system. PCI SSC's tokenization guidelines place every part of that system in the CDE: token generation, the token-to-PAN mapping, the card-data vault and cryptographic key management. Anything with access to tokenization or detokenization is in scope as well.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

Systems that handle only tokens can fall out of scope, but the guidelines set conditions. The PAN must not be computationally recoverable from the tokens. The systems must be segmented from anything that can request detokenization or reach the vault or its keys. They must not receive card data through any other channel. And any card data they stored before tokenization arrived must be securely deleted.

That last condition is where migrations fail: an old backup full of card numbers keeps a "tokenized" database in scope. The guidelines date from 2011 and target merchants, but the logic holds for a provider tokenizing inside its own platform.

Point-to-point encryption (P2PE) encrypts card data inside a secure device at the point of interaction and decrypts it only inside a defined decryption environment, so no clear-text card data exists in between (P2PE v3.1). It mainly helps card-present merchants and does nothing for card-not-present API traffic. If you run the decryption environment, it is your CDE, and the P2PE standard adds requirements for solution providers.

PCI SSC writes the standard but does not enforce compliance or define validation reporting; the payment brands run the compliance programs, usually through acquirers. The brands also assign service provider levels. Visa's guidance, for example, has Level 1 service providers complete an annual on-site assessment with an attestation signed by a Qualified Security Assessor (QSA), while Level 2 providers can submit a signed SAQ D.

Confirm the route with your acquirer or the brands before you plan anything; PCI SSC's SAQ bulletin for v4.0.1 gives the same advice.

A self-assessment questionnaire (SAQ) is the validation form for entities allowed to assess themselves. Merchants choose from several types depending on how they accept cards. Service providers that are eligible to self-assess have exactly one: SAQ D for Service Providers, available from the PCI SSC Document Library.

FAQ 1578 explains why a service provider can't borrow merchant eligibility criteria to shorten its list. Merchant SAQs are short because those merchants hand card handling to a compliant service provider, and the omitted controls are assumed to be covered there. A provider meeting only that reduced set would lack the very controls its merchants rely on, and several service-provider-only requirements appear in no merchant SAQ. Mark a requirement not applicable only when it genuinely doesn't apply, such as software development requirements for a provider that writes no software.

These are the service-provider-only items I'd put on an engineering team's radar, summarized from BDO's overview of the v4.0 changes and the Requirement 11 text on Microsoft Learn. The ones added in v4.0 were future-dated and, like the other future-dated requirements, have been mandatory since 31 March 2025.

"Multi-tenant" has a narrow meaning here. FAQ 1221 says Appendix A1 targets providers whose customers share resources and manage their own environment or administer their own segment. It excludes providers running a single, unified environment where customers see only their own data through a common platform and the provider manages all access. A payment platform where merchants share one dashboard and API may well be in that excluded group, so settle early with your QSA whether Appendix A1, and the multi-tenant wording in 11.4.7, applies to you.

Scope is not a one-time diagram. The scoping supplement makes the entity responsible for keeping scope accurate; the assessor checks how you determined it. The steps I'd follow:

1. Draw the data flows. Requirement 1.2.4 asks for an accurate data-flow diagram of all account data flows, and 1.2.3 for a network diagram of every connection to the CDE (Requirement 1 text on Microsoft Learn). Trace where a PAN enters, rests, moves and leaves, including files exchanged with acquirers and every third-party connection.
2. Build the inventory. List every in-scope component with its function, generated from cloud, Kubernetes and CI/CD APIs rather than a spreadsheet nobody updates.
3. Classify and justify. Give each component a category and a one-line reason. For each out-of-scope system, name the control that blocks its path to the CDE.
4. Confirm on a schedule. Every entity confirms scope at least every 12 months (12.5.2); service providers also every six months and after significant change (12.5.2.1). Keep the evidence of how scope was determined.
5. Catch drift between reviews. Add a scope question to design reviews and change tickets: does this service call the vault, log a new field or open a new connection? Run a card-number detector over logs and data stores so accidental PAN storage shows up in days, not at the next assessment.

• Search logs, data stores and support tooling for card numbers before drawing any boundary; a PAN in an unexpected place changes the plan.
• Agree on one data-flow diagram with product, platform and security, and treat it as the source of truth for scope.
• Make the vault the only place a PAN rests and the processor connector the only caller of detokenize; everything else holds tokens.
• Ask your acquirer or the brands which validation route applies before choosing between SAQ D for Service Providers and an on-site assessment.
• Put the six-month scope confirmation and segmentation test on the calendar now; they recur, they are not one-off fixes.