What’s in PCI scope vs. out of scope?
PCI-DSS (the Payment Card Industry Data Security Standard) is an information security standard used by every entity that transacts business using major credit cards. It is administered by the Payment Card Industry Security Standards Council, and adherence to its regulations is at the heart of protecting the personally identifiable information (PII) of consumers, and the integrity of the broader payments ecosystem at large.
"In scope" refers to the elements of a payment system that must be compliant with the regulations contained within PCI-DSS. By contrast, "out of scope" refers to all other systems—both technological and human—that, because they do not pose a risk to consumer data, are exempt from complying with PCI-DSS standards.
For most, if not all, organizations, minimizing the share of their systems (also known as the surface area) that is in-scope is a critical element in controlling the cost and resource demands of maintaining PCI compliance.
In Scope vs. Out of Scope
Making the process of rationalizing a PCI-DSS program a little harder than it might otherwise be, the choice of in- or out-of-scope is not binary. There are, in fact, three designations for systems:
- In-scope: Any system that has direct access to collect, store, or transmit cardholder data. Any element of your payment structure that, at any time, has access to PII in plain text is unequivocally in-scope, and is known as being in the Cardholder Data Environment (CDE).
- Connected-to: Any system that connects to the CDE without being directly involved in credit card details or processing transactions.
- Out-of-scope: Any system that has no access to the CDE.
Note that each business is also responsible for the scope and compliance of its partners; for instance, storing PII on a cloud server would require the merchant to ensure that the cloud provider and the interfaces between the provider and the merchant are fully PCI-compliant. However, there are ways to reduce your PCI scope.
Limiting PCI Scope
Any system located within the CDE is necessarily in scope, even if it doesn’t technically deal with PCI-covered processes. For instance, if two applications are running on the same physical server and one of them is part of the CDE, then so is the other, because access to one could provide a vector to the other.
Similarly, anything that connects directly to the CDE is considered in-scope, because a user could reasonably be expected to have access to data in clear text. Of course, placing something in between (a VPN, say, or API middleware that disintermediates the connection) can turn that direct connection indirect, and push the system out of scope.
The best way to keep a system out of scope is to eliminate any potential access to credit card information in the first place. Full-service PSPs have been doing this for a while: they provide forms so that they actually collect credit card information, and simply provide a token back to the merchant, no credit card data, no scope (except insofar as the merchant shows that the system collecting and using the data is itself PCI-DSS compliant.)
Using Tokenization to Stay Out of Scope
Although using a full-service PSP or aggregator can result in implicit PCI compliance and require only the annual filing of a prefilled SAQ A form, it also limits merchants' options for developing their businesses. A single PSP means a single point of failure, a single rate card, and a single location to store all customer credit cards, none of which are under the merchant's control, making it difficult to transition to another provider.
An equally effective and more flexible approach to keeping PCI-DSS in-scope data out of a system is to use a third-party tokenization provider. Instead of letting a full-service PSP hold your customers’ data (and thus keep you locked into their services), a tokenization provider similarly collects credit card data for you and provides a key, but then provides the interfaces you need to transmit transactions to any payment processor you prefer.
With this flexibility, you not only keep your payment systems from being in-scope, you also give yourself opportunities to automate, to optimize your costs, and to arbitrage different rate cards for different classes of sale.