thePCI Portal

Who is a service provider for a SAQ A ecommerce only Merchant?

The Scenario:

Low volume ecommerce only merchant.  Website does a full redirect to a PCI compliant provider payment page so payment processing is fully outsourced.  The payment provider page is actually the Merchant’s acquirer (not a middleman).

All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service provider (the acquirer!).
Merchant 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.
Merchant has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant (no one but acquirer).

SAQ A eligible?  Sounds like it.

Scenario variation A:Website hosted and maintained by the Merchant

SAQ A has no requirements specific to the webserver security controls.

The physical media controls aren’t applicable as cardholder data (CHD) is not on paper in any form.

The service provider requirements aren’t really applicable either as the Merchant does not have to worry about their acquirer’s compliance.  The acquirer is the one calling the Merchant and asking!

So really, maybe an ASV scan and this merchant is compliant.

Scenario variation B:  Website hosted and maintained by a small website hoster

Website hoster is small, is totally uninvolved with payment data processing and has certainly not completed a PCI DSS compliance assessment.

Is the webhoster now a service provider and subject to the controls of 12.8.x (which are in SAQ A)?

The website hoster certainly does NOT store, process or transmit CHD.

Can they impact the security of cardholder data?    Sure, they could facilitate a website redirection attack.  Or they could implement poor security controls on the host or webserver allowing anyone on the internet to implement a website redirection attack.  The attack could involve altering the website to redirect users to instead of the correct payment site allowing them to scoop up payment data.

If the merchant hosted the site internally, PCI DSS SAQ-A doesn’t provide any guidance on which controls to apply to a webserver, so what changes when the webserver is outsourced?  Nothing.  Current thinking is that the website redirection attack on a fully redirected payment page is a lower risk than the other e-commerce options where the webserver handles the data.   The web hoster is not a service provider and PCI DSS does not prescribe controls for the merchant web page totally uninvolved with payment data.

BUT, please don’t stop there.

The Risk Based Approach

If you wanted to apply some controls to the webserver (say you were taking a risk based approach!) you might just use the controls from SAQ A-EP.  Those would serve you well in both the internal and outsourced webserver scenario.  You are paying for webhosting, so why not pay for good webhosting where you know the provider has controls in place and is willing to commit to them in the contract.

Even if the website is not an e-commerce site, its not a good idea to put a webserver out on the internet without at least some basic controls in place (SAQ A-EP again?).  Please don’t do it. 🙂

Ad below this line:




Leave a Reply