SAQ-A vs SAQ-D Scope

Question

I've received notice from our risk management group that they believe our website falls in scope for SAQ-D.

We utilize third party vendors for all of our payment processing - and on the website essentially just provide static links (href="ourcompany.someprocessor.com") to direct them to the payment processing sites. There are no forms on our site where any customer data is collected, we do not post any information over to the vendor (100% of the process takes place there) - nor do we receive any callbacks about any transaction that takes place there.

So my read on it is that we fall under SAQ-A. We have explicitly tried to take steps NOT to fall in scope of SAQ-D/etc.

The argument that the risk management group is making is that the potential exists that someone could hack our site - and change the link from the valid link to some nefarious CC processor. While a legit concern - I do not believe that it changes our status as requiring SAQ-A.

Am I off base on that?

Answer 1

You seem to fall under SAQ A. Let's review the list of criteria that determine a SAQ A merchant:

SAQ A merchants confirm that, for this payment channel:

• Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;

You don't say this explicitly, but it's implied.

• All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;

You state this explicitly.

• Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;

You state this is the case.

• Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;

This is implied by what you've said.

• Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and

This is what you've said.

• Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

It's highly unlikely a processor would give you receipts with cardholder data.

Additionally, for e-commerce channels:

• The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).

And this is what you say you're doing.

I agree with you, it sounds like a SAQ A environment. I would push back and ask the risk management group to explain which criteria of SAQ D they feel you fall under. The chance that someone could hack your website and change the link is not something that triggers a SAQ D categorization; if that was the case there would be no SAQ A at all.

Answer 2

I would just add to @gowenfar's accurate and correct answer that at the end of the day you are answerable for your PCI DSS compliance to your acquiring bank, not your risk department ;-)

PCI DSS is one part of payment ecosystem risk management. If your website was hacked and your customer redirected to a nefarious payment page where the customer's card data was taken, you would notice very quickly as you would stop receiving transactions! So although this is an attack that criminals use, it is much less common than the "magecart" class of attacks that skim card data from payment pages because it is typically detected very quickly by the merchant and stopped - so the criminal's ROI is small.

Remember PCI DSS is a baseline set of controls, there's nothing to stop you using an external website monitoring service (many companies offer such services) that would alert you if that link destination changed. Or, depending how your system is configured, the addition of file integrity monitoring may also alert you that type of attack.