In PCI DSS, the cardholder data environment (CDE) is the people, processes, and system components that store, process, or transmit cardholder data or sensitive authentication data, plus system components with unrestricted connectivity to those systems. It is the center of PCI DSS scoping, but it is not always the full assessment boundary.
The broader PCI DSS scope can also include connected-to systems and components that could affect the security of cardholder data or the CDE. An identity platform, SIEM, DNS service, jump host, code repository, cloud control plane, or administration workstation can therefore matter even when it never stores a card number.
PCI SSC defines CDE and related terms in its official glossary. The practical scoping question is not only "Where is card data?" but also "Which systems can reach, administer, secure, change, or otherwise affect the environment where that data is handled?"
The table separates the CDE itself from the wider assessment scope. This distinction helps prevent teams from treating every in-scope component as though it directly handles cardholder data.
| Category | What it includes | Typical examples |
| CDE core | People, processes, and system components that store, process, or transmit cardholder data or sensitive authentication data. | Payment applications, payment databases, authorization systems, payment middleware, point-of-interaction systems. |
| CDE through unrestricted connectivity | Components that do not handle CHD/SAD themselves but have unrestricted connectivity to systems that do. | Flat-network workstations, servers, or administrative systems with unrestricted paths into CDE components. |
| Other in-scope connected or security-impacting systems | Components included in or connected to the CDE, or able to affect the security of CHD/SAD. | Identity systems, SIEM, DNS, firewalls, jump hosts, CI/CD systems, code repositories, cloud administration, vulnerability-management tools. |
| Potentially out of scope | Systems that do not handle CHD/SAD and are effectively isolated so they cannot connect to or affect CDE security. | Corporate systems behind validated segmentation with no permitted path or security dependency into the CDE. |
CDE stands for Cardholder Data Environment. PCI SSC's current glossary defines it around two conditions: direct handling of cardholder data or sensitive authentication data and unrestricted connectivity to components that perform that handling.
That makes the CDE a functional boundary rather than a list of server names. People and processes belong in the definition because card data can be handled through customer-support workflows, call centers, manual procedures, exports, paper records, or administrative tasks as well as through applications and databases.
A payment service can also span several technologies. A checkout page may redirect to a payment provider, an application may receive tokens rather than PAN, and administrators may manage the environment through separate identity and cloud systems. The CDE definition is the starting point for deciding how those relationships affect PCI DSS scope.
For the regulation-level view of scope, validation, and all 12 requirement groups, use our PCI DSS requirements guide.
No. The CDE is central to PCI DSS scope, but the assessment boundary can be wider. PCI SSC defines "system components" to include network devices, servers, computing devices, virtual components, and software that are included in or connected to the CDE or that could affect the security of cardholder data or sensitive authentication data.
This is the point where many scope discussions become difficult. A system can be in scope because it supports security, administration, connectivity, deployment, or access to the CDE even if it never receives payment account data itself.
The safest working model is to separate three questions: does the component handle account data, can it connect to the CDE, and can compromise of the component affect CDE security? A "no" to the first question does not settle the other two.
Security and administration dependencies are frequent examples. The exact answer depends on architecture and access, but the following system types deserve explicit review during scoping rather than automatic exclusion.
PCI SSC's SAQ D service-provider material gives examples of in-scope system types such as authentication servers, SIEM, segmentation controls, cloud components, code repositories, and systems that could affect the security of account data. The current PCI DSS v4.0.1 standard remains the controlling source for an assessment.
When logging systems fall into scope, the detailed control and evidence questions belong in our PCI DSS Requirement 10 guide.
Cardholder data is anchored on the full Primary Account Number (PAN). PCI SSC states that cardholder data consists at minimum of the full PAN and may also include the cardholder name, expiration date, or service code when those elements appear with the PAN. Sensitive authentication data includes items such as card verification codes, full track data, PINs, and PIN blocks.
The distinction matters because sensitive authentication data has stricter post-authorization storage rules, while stored PAN has protection requirements of its own. A scoping exercise should therefore map both where account data exists and what form the data takes at each stage of the payment process.
For current terminology, use the PCI SSC glossary rather than relying on older diagrams or vendor-specific definitions.
A reliable scope starts with payment flows rather than with the network diagram alone. Teams need to trace where account data enters, how it moves, where it is processed, where it is stored, where it leaves the organization, and which people or services can access or alter those paths.
A useful flow review follows the transaction from entry to exit. For an e-commerce company, that may include the browser, payment page, gateway integration, application logic, API calls, fraud controls, databases, support tools, exports, logs, and downstream service providers. For a call center, it may include telephony, agent workflows, recordings, payment terminals, and manual fallback procedures.
For a wider security view of that transaction path, our payment processing security guide follows the payment flow from checkout through gateways, APIs, stored account data, supporting systems, and third-party providers.
The resulting data-flow diagram should agree with the asset inventory, network and cloud architecture, third-party list, and assessment scope. If one source shows a payment path or administration dependency that the others omit, the scope is not ready to be treated as settled.
Segmentation can reduce the number of systems included in a PCI DSS assessment when it effectively isolates the CDE from systems that do not need access. Segmentation itself is not a general PCI DSS requirement, but PCI SSC recognizes it as a way to reduce assessment scope when the isolation is adequate and can be verified.
The boundary has to work in practice, not only on a diagram. Firewall rules, access-control lists, routing, cloud network policy, administrative paths, remote access, shared services, and management interfaces all need to support the claimed isolation. A hidden path from a corporate workstation or shared service into the CDE can pull more of the environment back into scope.
PCI SSC's FAQ on network segmentation explains that properly configured technologies such as internal firewalls, routers with strong access controls, VLANs, or other isolation methods can reduce assessment scope when they effectively isolate card-data systems.
Segmentation also creates an evidence obligation. If the organization relies on segmentation to reduce scope, the assessment must verify that the controls are effective. Penetration testing has a dedicated role here under Requirement 11.4.
Test whether the CDE boundary holds under attack
Use the Q-Sec playbook to define Requirement 11.4 scope, prepare segmentation evidence, plan internal and external testing, and document the results for PCI DSS assessment work.
Get the PCI DSS Penetration Testing PlaybookFor the testing requirements themselves, read our PCI DSS penetration testing requirements guide.
Sometimes they can reduce scope, but none should be treated as an automatic exclusion rule. The effect depends on where clear-text account data exists, who can reverse a transformation, which systems handle keys or tokens, what connectivity remains, and whether a provider can affect CDE security.
Encryption alone does not automatically make encrypted cardholder data out of scope for the entity that controls the encryption or decryption environment. PCI SSC reiterated this in March 2026: strong cryptography can render PAN unreadable, but encryption by itself is not enough to remove the data from the PCI DSS scope.
See PCI SSC FAQ 1086 on encrypted cardholder data and scope for the current boundary.
Outsourcing also changes the architecture rather than transferring accountability. A third-party service provider may be directly in scope because it stores, processes, or transmits payment account data, or because its service can affect CDE security. The customer still needs to understand the provider relationship, the responsibilities each party performs, and the compliance evidence the provider supplies.
PCI SSC confirms this scope principle for service providers in FAQ 1579 and gives additional assessment-scope guidance in FAQ 1580.
Cloud hosting does not create a separate scoping rule. The same questions apply: where is account data handled, what systems can connect to those components, and what services can affect their security? The answers may involve cloud identity, virtual networks, container platforms, serverless functions, secret stores, logging services, managed databases, deployment pipelines, or the provider's own controls.
Shared responsibility is therefore part of scope documentation. The organization should know which PCI DSS requirements it performs, which are supported by the cloud or SaaS provider, what evidence is available, and which controls remain dependent on customer configuration. A provider's PCI DSS status does not automatically make the customer's use of the service compliant.
If a SaaS or managed service has access to the CDE, performs a PCI DSS control on the customer's behalf, or can affect CDE security, that dependency should be visible in both scope records and the third-party responsibility model.
Scope is not a once-a-year drawing exercise. PCI DSS v4.x Requirement 12.5.2 requires the entity to document and confirm the PCI DSS scope at least annually and upon significant changes that can affect it. The review should identify payment flows, locations, systems, people, processes, third parties, segmentation, and other dependencies that belong in the assessment.
PCI SSC highlighted the annual scope-confirmation requirement in its guidance on the v4.x future-dated requirements.
Service providers have an additional requirement under 12.5.2.1 to document and confirm scope at least once every six months and upon significant change to the in-scope environment. This became required after 31 March 2025.
A practical trigger list should include new payment channels, cloud migrations, acquisitions, network redesign, provider changes, identity changes, deployment-tool changes, new integrations, tokenization or encryption changes, and any project that alters how account data moves or how the CDE is administered.
An assessor needs more than a diagram labeled "CDE." Scope evidence should show how the organization reached the boundary and how it keeps the boundary current. The exact evidence depends on the environment, but several artifacts usually work together.
For the wider assessment workflow, evidence review, SAQ/ROC paths, and AOC documentation, see our PCI DSS audit and assessment guide.
For internal and external scan scope, ASV responsibilities, remediation, and rescanning, see our PCI DSS vulnerability scanning guide.
Most scoping errors come from drawing the boundary around payment applications and databases while ignoring the systems that administer, secure, deploy, or connect to them. The following patterns deserve a specific challenge during review.
Start with a scope record that another person can challenge and reproduce. It should connect the payment flow to systems, owners, providers, network paths, security dependencies, and the reason each component is considered in scope or out of scope.
A useful working sequence is to identify CHD/SAD flows, build the system and provider inventory, map connectivity and administrative dependencies, test segmentation assumptions, reconcile the result with assessment evidence, and obtain ownership sign-off before formal testing begins. Scope should then be revisited whenever a significant change occurs rather than waiting for the next annual assessment.
The goal is a defensible boundary. If a system is excluded, the team should be able to explain why it cannot store, process, or transmit account data, cannot connect to the CDE in a way that brings it into scope, and cannot affect CDE security through a shared service or administrative path.
A useful CDE definition does more than identify where card numbers sit. It shows how payment data, connectivity, administration, security services, providers, and change paths come together around the payment environment.
That map determines where PCI DSS requirements apply, which evidence must be collected, what needs testing, and which systems can safely remain outside the assessment boundary. If the scope is wrong, every downstream assessment decision starts from the wrong environment.
Clarify scope before remediation and assessment work expands
Q-Sec supports PCI DSS readiness, scoping, evidence preparation, remediation planning, penetration testing, monitoring, and coordination around the assessment process.
Explore PCI DSS Compliance ServicesCDE stands for Cardholder Data Environment. It covers the people, processes, and system components that handle cardholder or sensitive authentication data, plus components with unrestricted connectivity to those systems.
No. PCI DSS scope can include connected-to and security-impacting systems that are not themselves part of the CDE core. Identity, security, administration, network, cloud, and deployment systems can still be in scope.
Yes, when segmentation effectively isolates the CDE, the isolation can be verified. The claimed boundary must account for network paths, administration, shared services, and other ways systems could reach or affect the CDE.
It depends on architecture and function. A SIEM can be in PCI DSS scope when it receives security data from in-scope systems or performs a security function required for the CDE, even if it does not store cardholder data.
They can be. Cloud components that handle account data, connect to the CDE, administer it, or affect its security can be in scope. The provider/customer responsibility split must also be documented.
Not automatically. PCI SSC states that encryption alone is insufficient to remove encrypted cardholder data from scope. Key access, decryption capability, connectivity, and control of the environment still matter.
Entities confirm PCI DSS scope at least annually under Requirement 12.5.2. Service providers have an additional requirement to confirm scope at least every six months and upon significant change.
The assessed entity is responsible for defining and maintaining its scope. During an assessment, the assessor evaluates whether that scope is complete and properly documented for the environment being assessed.