PCI DSS scope must be documented and checked as accurate every three months at a minimum, and again whenever the in-scope environment changes significantly. As a minimum the scoping validation must: identify every data flow across payment stages (such as authorization, capture and settlement, plus refunds and chargebacks) and every acceptance channel (for example e-commerce, card-present and card-not-present); bring every data-flow diagram up to date under Requirement 1.2.4; locate everywhere account data is held, processed or sent, including 1) locations outside the defined CDE, 2) applications handling CHD, 3) transmissions between networks and systems, and 4) backup files; for account data found outside the CDE, the entity must 1) delete it securely, 2) relocate it into the CDE, or 3) extend the CDE so that it is covered; identify every system component in, connected to, or able to affect the security of the CDE; identify all segmentation controls and the environments segmented from the CDE, with justification for out-of-scope environments; identify all third-party connections with CDE access; and confirm all identified flows, data, components, segmentation controls and third-party connections are in scope. Linked to the PCI DSS scoping section, Requirement 12. Applies only to designated entities. Objective under the customized approach: not eligible for the customized approach; only the defined approach can be used.
PCI DSS 4.0 A3.2.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.