SAQ-D Service Provider without a CDE

Question

We provide a shopping cart service with integrations to multiple third party payment processors (PayPal, Authorize.net, etc.) where all payment processing happens on their networks (i.e., no CC data enters our networks). Some of our prospects have said that we're a Service Provider in their eyes since we control the redirect to the payment processors.

Since we have no CDE, can we response "N/A" to all SAQ-D SP requirements that reference the CDE?

I'm trying to narrow down our scope which I think is just the server that performs the redirect. However since it neither stores, processes nor transmits CC data, I'm having trouble figuring how we fit within SAQ-D SP.

I'm sure we'll need a QSA at some point but I'd like to figure out as much as possible so I can at least have an intelligent conversation and a list of questions before contracting with them.

Answer 1

This depends how you do the integration with the payment processor. Let's pretend for a minute you are a merchant - then the correct SAQs would most probably be SAQ A or SAQ A-EP depending on the integration / re-direct / IFRAME / JScript.

As a service provider you can't complete A or A-EP but you must complete D or undertake a full Report on Compliance. What you need to do is follow the guidance contained in these FAQs about basing an full PCI DSS assessment on a reduced set of requirements contained in one of the other SAQs.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-a-partial-PCI-DSS-assessment-be-documented-in-a-Report-on-Compliance-ROC

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-SAQ-eligibility-criteria-be-used-for-determining-applicability-of-PCI-DSS-requirements-for-onsite-assessments

I know you asked about SAQ D and not an onsite assessment but the principles outlined in these FAQs are the same for a Service Provider SAQ D.

To answer the question about what the CDE is for SAQ A and SAQ A-EP there's another FAQ you might find helpful.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-PCI-DSS-Requirements-2-and-8-apply-to-SAQ-A-merchants

It's basically anything that can directly affect the integrity of the redirection.

Answer 2

I talked with a QSA a while ago about this, we were looking at using an iframe or redirect to reduce our scope. As a service provider you pretty much have to do the lot, I argued we should do what was applicable for SAQ A but he disagreed. It took me awhile to come around but now I agree.

Pragmatically you need to protect that server (or any dealing with sensitive data) with best practice security anyway, so might as well let PCI guide you. It’s not going to be hard to change that redirect if you’ve got security flaws. Annoying that merchants don’t have to do it to the same level in some respects, but ultimately it’s to protect your business.

A quick google and I came across this article saying roughly the same, that redirection servers are apart of the CDE. On the other hand I’ve seen in a couple of places the suggestion to follow the SAQ A sections for this situation, so might just depend on the QSA.

As you say, talk to QSA. It’d be great to hear what you end up doing, if you feel like sharing.