Skip to main content
Commerce Security Authority
Category: PCI DSS Compliance

Scope of Assessment

Also known as: Assessment Scope, Scope Definition
Simply put

The scope of assessment sets the boundaries for what will be reviewed during a compliance evaluation, identifying which areas, controls, requirements, and processes are included. In a payment security context, defining scope determines which parts of an organization's people, processes, and systems must be examined to confirm that applicable requirements are met. A clearly defined scope helps make an assessment more focused and efficient by concentrating effort where it is needed.

Formal definition

The scope of assessment defines the boundaries of what is evaluated in a compliance or security review, specifying the areas, controls, requirements, and processes that fall within the assessment. Scope definition is a foundational planning step that establishes the goals and boundaries of the evaluation, and it may benefit from meaningful stakeholder engagement to ensure the relevant systems and processes are correctly identified. In practice, the accuracy and defensibility of an assessment depend heavily on correct scoping, since anything excluded is not evaluated; practitioners should confirm scoping expectations against the current published standard governing the assessment rather than assuming a fixed set of boundaries, as requirement wording and scoping guidance can differ between versions.

Why it matters

In a payment security assessment, scope is the single decision that shapes everything that follows. Because anything excluded from scope is not evaluated, an inaccurate or overly narrow scope can leave systems that store, process, or transmit cardholder data unexamined, producing a compliance result that does not reflect the organization's actual risk. Conversely, an unnecessarily broad scope wastes effort by concentrating review on areas that do not need it. Getting scope right is therefore foundational to whether an assessment is both accurate and defensible.

Scope also determines which requirements and controls apply to which parts of the environment. Where data-reduction techniques such as tokenization, encryption, truncation, or masking are used, their effect on what falls inside or outside scope depends on how they are implemented and validated, not on the label alone. For that reason, scoping decisions should be documented and justified rather than assumed, so that reviewers and stakeholders can confirm the boundaries reflect where sensitive data actually flows.

Because scoping expectations and the wording of scoping guidance can differ between versions of a governing standard, practitioners should confirm current requirements against the published standard rather than relying on a fixed set of boundaries carried over from a prior assessment. Treating scope as a static artifact can cause an environment to drift out of alignment with the standard as systems, data flows, and requirements change over time.

Who it's relevant to

Compliance officers
They rely on a clearly defined and documented scope to ensure the assessment concentrates effort where it is needed and that no in-scope area is inadvertently excluded. Because anything left out of scope is not evaluated, compliance officers must be able to justify scoping decisions and confirm them against the current published standard rather than assuming boundaries carried over from a prior assessment.
Security engineers
They map how people, processes, and systems handle payment data so that the relevant environment is correctly identified during scope definition. Where techniques such as tokenization, encryption, truncation, or masking are used, engineers help determine how those implementations affect what falls inside or outside scope, since the effect depends on implementation and validation rather than the label.
Payment processors and acquirers
They need assessments whose boundaries accurately reflect where cardholder data is stored, processed, or transmitted so that the compliance result is meaningful. A defensible scope supports confidence that the applicable requirements were actually evaluated across the relevant systems and processes.
Assessors and reviewers
They depend on a well-documented scope as the foundational planning step that establishes the goals and boundaries of the evaluation. Stakeholder engagement helps them confirm the relevant systems and processes are identified, and they should verify scoping expectations against the current published standard, as requirement wording and scoping guidance can differ between versions.

Inside Scope of Assessment

Cardholder Data Environment (CDE)
The people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, along with system components directly connected to or that could affect the security of that environment. The CDE forms the core of what an assessment must cover.
Connected-to and Security-Impacting Systems
Systems that connect to the CDE or that could impact the security of cardholder data, such as authentication servers, administrative workstations, and shared services. These are in scope even when they do not directly store, process, or transmit cardholder data.
Cardholder Data vs. Sensitive Authentication Data
Scoping distinguishes cardholder data (PAN, cardholder name, expiration date, service code) from sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks). Sensitive authentication data must not be stored after authorization, even when encrypted, while some cardholder data may be stored under defined controls.
Segmentation
The use of controls to isolate the CDE from out-of-scope systems. Effective segmentation can reduce the scope of an assessment, but systems remain in scope unless segmentation is validated as effective rather than merely asserted.
Scope Reduction Techniques
Approaches such as tokenization, encryption, truncation, and masking may reduce the systems in scope. Their effect on scope depends on the specific implementation and how it is validated, not on the label applied to the technique.
Third Parties and Service Providers
Outsourced functions and service providers that could affect the security of cardholder data are part of scope considerations, including how responsibilities are allocated and validated between the entity and its providers.
Scope Confirmation and Documentation
The activity of identifying all locations and flows of cardholder data, documenting the boundaries of the assessment, and confirming that no in-scope systems have been overlooked before assessment activities begin.

Common questions

Answers to the questions practitioners most commonly ask about Scope of Assessment.

Does using tokenization or encryption automatically take a system out of PCI DSS scope?
No. Applying a label like tokenization or encryption does not by itself remove a system from scope. The effect on scope depends on the specific implementation and how it is validated, not on the terminology used. Tokenization, encryption, truncation, masking, and hashing transform data differently, and whether any of them reduce scope must be assessed against how the solution is deployed, what data remains accessible, and how key or token mappings are controlled. Confirm scope-reduction claims through validation rather than assuming them from the label.
If systems are separated on the network, are they always out of scope?
Not necessarily. Network segmentation may reduce scope, but only when it effectively isolates in-scope systems from those that store, process, or transmit cardholder data, and from systems that could affect the security of that data. Segmentation that is incomplete or that leaves connectivity or shared services in place may not remove systems from scope. Segmentation effectiveness should be verified rather than assumed, and connected-to and security-impacting systems can remain in scope even when logically separated.
What data determines whether a system is in scope?
Scope is driven by systems that store, process, or transmit cardholder data (such as PAN, cardholder name, expiration date, and service code) or sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks), as well as systems connected to or that could affect the security of those environments. Note that sensitive authentication data must not be stored after authorization, even if encrypted, while some cardholder data may be stored under defined controls. Identifying where each data type flows is a starting point for defining scope.
How should we begin identifying our scope for an assessment?
A common approach is to map cardholder data flows to identify where cardholder data and sensitive authentication data are stored, processed, or transmitted, then trace the systems, people, and processes involved. From there, identify connected-to and security-impacting systems. Because requirement wording and expectations differ between PCI DSS versions, confirm scoping guidance against the current published standard rather than relying on a fixed prior version.
How can segmentation be used to help reduce assessment scope?
Segmentation is intended to isolate the cardholder data environment from other systems so that out-of-scope systems cannot access or affect it. To rely on segmentation for scope reduction, the isolation must be effective and verifiable. Consider what connectivity, shared services, and management paths cross segmentation boundaries, since these may bring additional systems back into scope. Segmentation should be validated rather than presumed effective.
How often should scope be reviewed?
Scope should be reviewed periodically and whenever changes occur that could affect it, such as changes to data flows, network architecture, connected systems, or business processes. Because environments and cardholder data flows evolve, a scope defined at one point may no longer be accurate later. Confirm the current expectations for scope confirmation frequency and documentation against the current published PCI DSS version.

Common misconceptions

Encrypting cardholder data automatically removes a system from assessment scope.
Encryption may reduce scope in some cases, but the effect depends on the implementation and how key management and access are handled and validated. Systems that can decrypt the data, or that hold keys, generally remain in scope. Encryption also does not permit storing sensitive authentication data after authorization.
Segmentation is presumed effective simply because network zones are defined.
Systems are considered in scope unless segmentation is validated as effective. Declaring a segment out of scope without testing the controls that isolate it does not remove those systems from the assessment.
Only systems that directly store, process, or transmit cardholder data are in scope.
Systems connected to the CDE or that could impact the security of cardholder data are also in scope, even if they never touch cardholder data themselves, such as authentication and administrative systems.

Best practices

Identify and document all locations and flows where cardholder data and sensitive authentication data are stored, processed, or transmitted before defining assessment boundaries.
Validate segmentation with testing rather than assuming isolation, and treat any system not proven to be segmented as in scope.
Confirm that sensitive authentication data is not retained after authorization anywhere in the environment, even in encrypted form.
Evaluate scope-reduction techniques such as tokenization, encryption, truncation, and masking based on how they are implemented and validated, not on the label alone.
Include connected-to and security-impacting systems, third parties, and service providers in scope analysis, and clearly allocate responsibilities where functions are outsourced.
Confirm scope against the current published version of the applicable standard, since requirement wording and scoping guidance differ between versions.