What’s in PCI Scope vs. Out of Scope?

What is PCI-DSS and what does it mean to be in 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 - which, because they do not pose a risk to consumer data, do not have to comply 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-DSS compliance.

In scope vs. out of scope: it’s not quite binary

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 that the interfaces between provider and merchant, were fully PCI compliant.

Limiting PCI scope within the broader payments system

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 resident on the same physical server and one of them is part of the CDE, then so is the other - because access to one could create a vector for access 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 remove any chance of it having 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 maintain out-of-scope status

Although using a full-service PSP, or aggregator, can result in implicit PCI compliance and only require the annual filing of a prefilled SAQ A form, it also limits the options that a merchant has on how they develop their business. A single PSP means a single point of failure, a single rate card, and a single location to store all customer credit cards that is not controlled at all by the merchant, 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 like Basis Theory. 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.