PCI DSS 12.5.2: PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon

Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.5

PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce).
• Updating all data-flow diagrams per Requirement 1.2.4.
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
• Identifying all connections from third-party entities with access to the CDE.
• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.

Summary

Work out what is in scope at least once a year, and again whenever the environment changes materially, and write down how you concluded it.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

	Procedure
12.5.2.a	Examine documented results of scope reviews and interview personnel to verify that the reviews are performed: • At least once every 12 months. • After significant changes to the in-scope environment.
12.5.2.b	Examine documented results of scope reviews performed by the entity to verify that PCI DSS scoping confirmation activity includes all elements specified in this requirement.
12.5.2	are performed: • At least once every six months, and • After significant changes

Scope decides which of the other 204 controls apply to you, which makes this the control most likely to invalidate an otherwise good assessment: everything downstream inherits it. The six bullets are a method, not a checklist to assert: data flows for every payment stage including chargebacks and refunds, diagrams updated per 1.2.4, account data locations including those outside the CDE, system components connected to or able to affect the CDE, segmentation controls with justification, and third-party connections. 12.5.2.a examines the documented result; 12.5.2.b interviews people and examines the process. Note the trigger words "and upon significant change": an annual cadence alone fails an entity that migrated a payment channel in March.

What to prepare

• The dated scoping validation, showing the method and the conclusion, not just a scope statement.
• Current data-flow diagrams covering authorisation, capture, settlement, chargebacks and refunds.
• The account data inventory, explicitly including locations outside the defined CDE, backups and file stores.
• Segmentation controls in use, and the written justification for anything held out of scope.
• The list of third parties with access to the CDE, which is the same list 12.8.1 asks for.

How to implement it

1. Start from the money, not the network. Following each payment stage end to end finds systems a network diagram misses, and chargebacks and refunds are named in the requirement precisely because they are the flows nobody maps.

2. Look outside the CDE deliberately. The bullet says "including but not limited to any locations outside the currently defined CDE". A scoping exercise that only examines what is already in scope cannot discover anything, which is the failure this bullet exists to prevent.

3. Write down what is out of scope and why. Out-of-scope is a conclusion that has to be defensible, and the segmentation controls that make it true are what an assessor tests. An unstated exclusion looks like an omission.

4. Tie the trigger to your change process. "Upon significant change" only happens if something in 6.5.1 asks whether a change affects scope. Left to memory it becomes annual by default.

5. Keep the reasoning, not only the answer. 12.5.2.b interviews personnel about the process. A scope diagram with no record of how it was derived cannot be defended by whoever inherits it.

Where this commonly fails

• Scope reviewed annually and never on change, when the requirement names both.
• Data flows drawn for the happy path, with refunds and chargebacks unmapped.
• Backups and file stores omitted from the account data locations, though they are a named sub-bullet.
• Segmentation asserted without the justification an assessor is asked to examine.
• The scope inherited from last year and re-dated, which 12.5.2.b tends to surface at interview.

Related controls

This control refers to 1.2.4.

Others in section 12.5:

Control	What it requires
12.5.1	An inventory of system components that are in scope for PCI DSS…
12.5.2.1	Service providers: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon…
12.5.3	Service providers: Significant changes to organizational structure result in a documented (internal) review…

---

← 12.5.1 · All controls · 12.5.2.1 →

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.