On Page 8 of the PCI DSS Self-Assessment Instructions and Guidelines, v1.1, it says:
SAQ Validation Type 1 / SAQ A: Card-not-present, All Cardholder Data Functions Outsourced
SAQ A has been developed to address requirements applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their premises. Merchants in Validation Type 1 do not store cardholder data in electronic format and do not process or transmit any cardholder data on their premises, and must validate compliance by completing SAQ A and the associated Attestation of Compliance, confirming that:
Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;
Your company does not store, process, or transmit any cardholder data on your premises, but relies entirely on a third party to handle these functions;
Your company has confirmed that the third party handling storage, processing, and/or transmission of cardholder data is PCI DSS compliant;
Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and
Your company does not store any cardholder data in electronic format.
If mail/telephone order is an accepted criteria for SAQ A, then how can they also say “Your company does not store, process, or transmit any cardholder data on your premises, but relies entirely on a third party to handle these functions”
In other words, if I get a credit card mail via phone or in the snail mail, I will log in to my authorize.net virtual terminal and input the cardholder data. So aren’t I transmitting cardholder data from my computer to authorize.net?
Am I missing something here? How can I take mail or telephone orders without transmitting the cardholder data in the virtual terminal?
If you enter it directly into authorize.net then you are not transmitting the information via any functionality on your own web site. Your computer is directly accessing authorize.net without going through any web page on the site that you are getting the PCI compliance for. So your site isn’t transmitting anything in that instance since it isn’t even accessed.
I agree with you on all of that, but I’ve been advised by the ASV’s that they have to conduct their “network scan” on any outward facing IP address. I think the notion is that there could be some kind of keylogger or something living on the system used to input cardholder data even if it is on the authorize.net terminal. But if no one is getting gigged for that, I’m not going to go nuts over it. Authorize.net SIM seems to be the way to go!
Ohh… Well if that’s the case, how can anyone on a shared host pass the network scan? Shouldn’t shared hosts by their very nature not pass because of all the different domains on it?
It is more difficult to pass when you’re on shared hosting but it really depends on the shared hosting. Since with proper security in place the web sites don’t have any access to other accounts on the shared hosting server what is in those other accounts doesn’t matter.
The difficulty with shared hosting is usually the facilities that the provider installs that everyone on the server has access to use but where you need to have it disabled for your account in order to pass. Not using the option or turning it off may not be considered sufficient and you may not have access to do more than that.
It’s more than I want to deal with. I will just use a PCI compliant hosted payment page such as authorize.net or Paypal. That way if these regulations start to become heavily enforced by the card brands, I’ll be safe.
It’s virtually impossible to meet the PCI standards on a shared host. You, as a normal customer, don’t have the ability to guarantee all the access control and logging requirements, for starters. If you don’t have your own servers, then stick to 3rd party payment pages like SIM.