.svg)
.svg)
.svg)
.svg)
.svg)
The unified orchestration layer for wallets and alternative payments
.svg)
The secure repository for all your payment methods
.svg)
Workflow-driven payments intelligence for smarter routing and higher auth rates
.svg)
A flexible fraud and authentication layer. Instantly add advanced fraud tools and 3DS
One integration to sell inside ChatGPT, Gemini, and every agentic platform
The visual workflow builder that ties fraud, identity, and payment routing together in one place
The unified orchestration layer for wallets and alternative payments
The secure repository for all your payment methods
Workflow-driven payments intelligence for smarter routing and higher auth rates
A flexible fraud and authentication layer. Instantly add advanced fraud tools and 3DS
One integration to sell inside ChatGPT, Gemini, and every agentic platform
The visual workflow builder that ties fraud, identity, and payment routing together in one place
De-scoping
De-scoping is the practice of designing payment systems and data flows so that cardholder data never enters certain systems or processes, thereby removing those components from PCI Scope and the associated compliance requirements. The goal of de-scoping is to reduce the number of systems that must be assessed, secured, and maintained to PCI DSS standards, shrinking compliance overhead while improving the security posture by limiting cardholder data exposure.
The most effective de-scoping strategies create a clean boundary: cardholder data is handled only by PCI Level 1 Service Providers and never touches the merchant's own servers, application code, or databases. Tokenization is the primary de-scoping tool for stored payment data, by replacing the Primary Account Number (PAN) with a token before it reaches merchant systems, those systems handle only tokens (which are out of scope) rather than PANs (which are in scope). Hosted Payment Pages and iFrame-based card collection de-scope the data capture process, because cardholder data is entered directly on the payment provider's infrastructure, the merchant's servers never receive it.
De-scoping is not the same as compliance avoidance. Even a fully de-scoped merchant retains compliance obligations in respect of how their website and systems interact with in-scope components, under PCI DSS v4.0.1, even merchants using SAQ A must ensure their e-commerce pages are not susceptible to script attacks that could affect the security of the payment form. De-scoping reduces scope; it does not eliminate it.
Frequently Asked Questions
What are the limits of de-scoping?
The most common limit is incomplete data flow analysis. Cardholder data that enters a merchant's environment through unexpected paths, log files that capture card numbers from failed transaction data, analytics platforms that record form inputs, browser extensions on staff machines, can quietly expand scope beyond the intended boundary. Effective de-scoping requires thorough data flow mapping and ongoing vigilance to prevent cardholder data from entering systems intended to be out of scope.
Does de-scoping save money on PCI compliance?
Yes, significantly. The cost of PCI compliance, QSA fees, security controls, staff time, remediation, scales with scope. A merchant with a large, poorly bounded CDE faces a much more expensive and time-consuming compliance program than a merchant who has successfully de-scoped to SAQ A or SAQ B.
Can a merchant de-scope their entire environment?
Not entirely, there is always a residual scope representing the merchant's relationship with in-scope systems. But the residual scope can be made very small. A merchant that uses Spreedly's iFrame to collect card data (which goes directly to the Spreedly vault without touching the merchant's servers), processes all transactions through the Spreedly API (tokens only, no PANs), and maintains proper network security on their own systems may qualify for SAQ A, one of the most minimal compliance validation requirements available.
Related Terms
