PCI Scope, Tokens, and Processor APIs

Question

A merchant receives a processor provided payment token in response to an authorization from an online order (for the sake of this question assume this part of the process has all its PCI t-s crossed and i-s dotted). Next the order is processed by an Order Management System (OMS), which is in a non-PCI network segment. The OMS will reach out to the processor directly through internet-accessible APIs to perform captures, auth-reversals, etc. according to its business process flows. These API calls are using the token received from the processor in the original auth. Is the OMS system and its network in PCI scope because it is reaching out directly (no proxies) to the processor's APIs?

Answer 1

Is the OMS system and its network in PCI scope because it is reaching out directly (no proxies) to the processor's APIs?

No, it is not in scope. The processor will be using a combination of network firewalls, application security firewalls, and restricted APIs to provide segmentation between their PCI-scoped network and you, the consumer of their services. Segmentation is what limits the spread of PCI scope.

That is, of course, assuming the processor is PCI compliant... Page 12 and section 12.8 of PCI DSS 3.1 lays out that you are responsible for vetting the compliance of providers that process on your behalf:

A service provider or merchant may use a third-party service provider to store, process, or transmit cardholder data on their behalf, or to manage components such as routers, firewalls, databases, physical security, and/or servers. If so, there may be an impact on the security of the cardholder data environment.

...

Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated third-party service providers with access to cardholder data. Refer to Requirement 12.8 in this document for details.

Validating your processor - In general, the flow in PCI is documentation upwards, certification downwards. Assuming your processor is a Level 1 Service Provider*, they must be listed at Visa's Service Provider listing or MasterCard Compliant Service Provider list. Looking the provider up is the preferred method of validating their compliance, as it goes to the gated central authority which makes timely updates (e.g., revocation). They will also provide you with a copy of their AoC upon request, which is a short document from the auditor saying "We came, we audited, we found them compliant (and that finding is point in time only!)". No details in the AoC.

They will effectively never share their RoC with you - they are not required to, and it contains information they don't want disseminated. I believe I have seen ASV scans shared with a merchant on an exceptional basis, but that's certainly not normal practice, and I would expect most processors to decline to do so under ordinary circumstances.

On the other hand, everything the merchant has - ROC/SAQ, ASV scans, AOC - must be made available to the processor (and the acquiring bank, and the card brands...) upon request. It's an asymmetric relationship.

If you read through the subsections of 18.2, you'll see that it basically says "You must know who you're in a relationship with, what PCI-related data is exchanged in the relationship, and verify that their validation is up-to-date." You are not expected (...or allowed...) to see the data used to conclude that they are validated.

So - circling back to your specific question - you are not expected to receive data from your processor which proves that their configuration properly limits PCI scope. The fact that they were validated (by an audit, for Level 1s) is proof that they are properly containing the flow of cardholder data.

(Actually, it's more nuanced than that. They may have two service offerings - one that uses tokenization and other magic to limit your scope, and another in which you transmit and store CHD yourself. Both can be provided in a PCI-compliant manner... it's your responsibility to know the difference. If you choose the offering where you get to see the CHD, it's your SAQ or RoC which must reflect that fact. If you say you're using tokenization but use the other offering, you're out of compliance. Your auditor or whoever reads your SAQ is, in part, going to review your assertions and ask for evidence - show them you have tokens; show them you don't have cards.)

.* A Level 2 Service Provider may SAQ and therefore not be listed. I've no idea how they prove their compliance to merchants, unless they share their SAQ, even if only to your auditor. The QSAs I've talked to tend to dismiss Level 2 Service Providers and I'm sure being in a relationship with one would open your organization to more audit scrutiny than might otherwise be the case.