PCI DSS Scope and Segmentation: What Is Actually in Scope for Payment Companies?

A payment flow can be small while its security dependencies are not. A processor might keep card numbers in one tightly controlled service, yet use separate identity, logging, cloud-administration, and deployment systems that can affect that service. Leaving those dependencies off a PCI DSS scope diagram can create an unpleasant surprise later in an assessment.

The right starting point is not a list of servers. It is the path of payment account data and the systems and people that can affect its security. This article explains how to map that path, distinguish systems in the cardholder data environment (CDE) from other in-scope systems, and support any claim that segmentation has reduced scope.

What enters and leaves in this example?

PCI DSS distinguishes cardholder data (CHD) from sensitive authentication data (SAD). PAN is the defining element of CHD; cardholder name, expiration date, and service code are other CHD elements when present with PAN. The printed card verification code, commonly called CVV2 or CVC2, is SAD, not CHD. Full track data and PIN/PIN block are other SAD elements, although they are not part of this card-not-present example. PCI SSC account-data definitions

In the illustrated flow, the Cardholder enters PAN, expiration date, and CVV/CVC. All three go to the Payment API and then to the Processor for authorization. The Processor represents an external authorization path that may include a card network and issuer. The response to the Payment API contains an authorization result and reference, not the CVV/CVC. The Payment API does not retain CVV/CVC after authorization. A real deployment must confirm the Processor's downstream path and exact response fields.

In this example, CVV/CVC crosses flows 1 and 2, then is absent from flows 3 through 6. It does not enter the Token vault, Security event logging, Analytics, or support tickets. For merchants and non-issuing service providers, SAD cannot be retained after authorization, even if encrypted. It must be rendered unrecoverable upon completion of authorization. A customer's consent or a recurring-payment use case does not create an exception. PCI SSC card-verification-code FAQ

There are two narrower situations worth separating from that rule. Before authorization, PCI DSS does not set a universal storage duration for SAD, but any retention must be minimized and protected, electronically stored SAD must be encrypted with strong cryptography, and payment-brand rules may prohibit storage altogether. After authorization, only issuers and companies supporting issuing services may retain SAD when they have a legitimate, documented issuing business need; they must protect it and encrypt it with strong cryptography under Requirement 3.3.3. Being a Processor or a general service provider does not by itself qualify. Neither situation changes the no-retention rule for the merchant-side flow illustrated above. PCI SSC pre-authorization FAQ · PCI DSS Requirement 3.3.3

Start with the payment account data flow

Identify every point where cardholder data or sensitive authentication data enters, moves through, or leaves your environment. Trace the flow through customer interfaces, APIs, gateways, message queues, databases, logs, support tools, cloud services, and third parties. Ask where a primary account number (PAN) can be seen or recovered, not merely where the team intends to store it.

The CDE includes the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. PCI DSS scope can extend beyond the CDE to systems that connect to it or can affect its security. The PCI Security Standards Council (PCI SSC) describes this distinction in its scoping and segmentation guidance. That guidance is supplemental; use the current PCI DSS standard and applicable assessment documents for the actual requirements.

For a payment platform, the initial map should answer:

• Which application or service first receives the card data?
• Can the data enter logs, error reports, queues, test environments, or support tickets?
• Where is it tokenized, encrypted, or sent to a payment provider?
• Which administrators and vendors can change the systems handling it?
• What services provide identity, deployment, monitoring, time synchronization, or network protection for those systems?
• Which third parties perform a PCI DSS control on your behalf, and what does their responsibility documentation actually cover?

Do not mark a system out of scope just because its database contains no PAN. Its access or security role may still make it relevant.

Three useful categories for the first scope map

1. CDE systems

These are systems that store, process, or transmit cardholder data or sensitive authentication data. In the illustration, the Payment API that receives a PAN and the Token vault are straightforward CDE candidates. The precise boundary depends on their actual deployment and data flows.

2. Connected-to or security-impacting systems

A system may be in scope even if it never holds a card number. Examples can include an administrator workstation with access to the CDE, an identity platform that authenticates CDE administrators, a cloud control plane that can change CDE configuration, a logging service that supports PCI DSS controls, or a firewall that maintains the segmentation boundary. The applicable requirements differ by function, but these dependencies cannot simply be omitted from the analysis. PCI SSC scoping guidance describes these categories.

Modern cloud environments make this harder to see. A deployment pipeline, ephemeral workload, or shared identity service can change a payment environment without sitting on the same traditional network segment. PCI SSC's modern-network scoping supplement specifically addresses cloud, microsegmentation, and dynamic inventories.

3. Candidate out-of-scope systems

Consider Analytics in the illustration: it receives a token rather than a PAN and has no path to administer or access the CDE. It may be possible to exclude Analytics, but “token-only” is not proof by itself. You must understand whether PAN can be retrieved, where tokenization and key-management functions sit, whether Analytics can affect the payment flow, and whether isolation is effective. PCI SSC's tokenization guidance treats the tokenization system as in scope and says an adequately isolated token-only system may be out of scope. The conclusion depends on the actual implementation.

Treat “out of scope” as a conclusion supported by architecture and evidence, not a label assigned at the beginning of the project.

Segmentation can reduce scope, but only when it works

Segmentation separates in-scope systems from other systems through controls such as network restrictions or other effective isolation mechanisms. It is not mandatory for every environment, but it can substantially reduce the number of systems to which PCI DSS controls apply. A firewall rule in a diagram is not sufficient evidence. The organization needs to understand the permitted paths, verify that prohibited paths are blocked, and maintain that state as the environment changes. PCI SSC scoping and segmentation guidance

A useful review asks:

1. Can a user or workload in the proposed out-of-scope environment reach the CDE directly or through a jump host, management service, shared credential, or cloud control plane?
2. Could it change the checkout page, payment API, DNS, identity configuration, or deployment artifact that the CDE depends on?
3. Do network and access-control configurations match the diagram?
4. Has the boundary been tested from the relevant locations, and were exceptions investigated?
5. Is there a process to revisit the boundary after a new integration, provider, network route, or administrative role is added?

If the answer to any of these is unclear, the scope claim needs more work. PCI SSC's workstation FAQ emphasizes that an assessor must verify segmentation controls used to exclude systems.

Outsourcing does not make responsibility disappear

Using a payment gateway or cloud provider may change your scope, but it does not automatically remove your PCI DSS obligations. Document which services the provider supplies, which PCI DSS requirements it meets on your behalf, and which responsibilities remain with your team. Request current evidence that covers the specific service you use, not merely the provider's brand. PCI SSC says customers must manage third-party service-provider relationships and identify the requirements each party meets. PCI SSC third-party FAQ

This matters for payment companies in both directions. A merchant may depend on a gateway. A processor or software provider may itself be a third-party service provider capable of affecting a customer's payment account data, even without directly storing that data. Scope then depends on the services and access provided. PCI SSC service-provider scoping FAQ

What evidence should support the scope decision?

A defensible scope package normally includes a current payment-data-flow diagram, network and cloud architecture diagrams, an inventory of in-scope components, administrative and third-party access paths, segmentation configurations and test results, and a responsibility matrix for providers. It should state why each excluded area cannot access or affect the CDE. The goal is to let another reviewer follow your reasoning rather than accept a line drawn around a few servers.

Do not wait for the formal assessment to discover that the diagrams do not match production. Revisit the scope after significant changes to payment-data flows, CDE boundaries, infrastructure, or relevant providers. PCI SSC lists those among changes that can affect a CDE. PCI SSC significant-change FAQ

Where a gap assessment fits

Scoping is the foundation of a useful PCI DSS gap assessment. Once the boundary and validation route are understood, the team can compare applicable requirements with actual controls and evidence, then prioritize remediation. A gap assessment can expose an overly broad environment that will be expensive to secure, or an overly narrow one that misses critical security dependencies. It is preparation, not a Report on Compliance or Attestation of Compliance.

If you are building a new payment flow, expanding into enterprise customers, or preparing for a requested PCI assessment, ControlSolid's PCI DSS gap assessment can help map the environment, validate the working scope, and turn the findings into an actionable plan.

This article is general guidance, not a determination of scope or validation requirements for a particular organization.