PCI Compliance - which SAQ?

Sure it will be grand

Just setting up a shop for client. We have the follwing:

- Blacknight shared hosting with SSL
- Realex Remote
- BrilliantRetail eCommerce with Realex plugin

For Realex Remote we need to be PCI Complient. I'm just not sure which SAQ to fill out.

I thought it was SAQ A, but one of the requirements is

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

We won't be storing any card numbers, but obviously we have to transmit them to Realex. We will also store the name and address for delivery.

Does this mean that SAQ A does not apply to us? None of the other SAQs seem to apply to out scenario.

lynchie

This is not a development question btw...

By using the remote method and not the redirect method you will be SAQ-C unless you decide the store the CC numbers in your own database in which case you will be SAQ-D.

Best to avoid C and D if possible and use the realex redirect method?

Sure it will be grand

lynchie wrote: »

This is not a development question btw...

By using the remote method and not the redirect method you will be SAQ-C unless you decide the store the CC numbers in your own database in which case you will be SAQ-D.

Best to avoid C and D if possible and use the realex redirect method?

Thanks for the response.

It's related to Web Development, where else should I have put it?

SAQ C seems to assume that I transmit card details from my own internet hardware in the office., whereas it is all done by third parties (Blacknight/Realex). I'd just be answeing N/A to most of the questions. Would that be right?

I'll probably go for Redirect for the moment as the site won't be pulling in many orders, though it would be nice to know the easiest way to be PCI complient for future clients.

Thanks.

IRLConor

It's been a while since I looked at PCI compliance stuff, but from memory you'd almost certainly be SAQ C.

It's a ginormous pain in the hole to be properly PCI compliant, so if you can avoid it I would advise you do so.

mneylon

Your bank's merchant team should be able to advise you on what they need in terms of compliance

Just bear in mind that Visa et al are taking PCI compliance a lot more seriously these days, though on the plus side some of the banks will cover or share the costs with you

NetLink

I'm afraid it's going to have to be SAQ-D. This applies if ANY cardholder data is stored anywhere that's your responsibility. This includes the server, even if you're only renting space from Blacknight. Cardholder data includes ANY identifiable personal information associated with a payment card, including name, address, CC number, expiry date, etc.

It will be practically impossible to complete SAQ-D on a shared server. Also, it's almost impossible to complete SAQ-D unless you have a professional who's familiar PCI compliance to help.

Your web host and your ecommerce software will also need to be PCI compliant. For example, physical access to your server needs to be logged and restricted, for example by multi-factor authentication (this could be a combination of password and biometric sensor, fingerprint scanner, smart card, access token, key fob, etc). If your ecommerce software stores cardholder data, this would then probably also require two-factor authentication to get into the back-end. Every login must be logged, along with an audit trail.

There's really a lot to it. Best to consult a QSA (Qualified Security Assessor). You'll also need an ASV (Approved Scanning Vendor) - this is a requirement. The ASV will externally scan your server (and other devices related to transactions) for vulnerabilities (on a quarterly basis, I forgot to add).

Sure it will be grand

Thanks very much!

Fart

I work for a QSA company and I work with merchants Monday - Friday.

If your website is contained on your own network, then it will usually be a SAQ C.
If you're storing any credit card data electronically, then it'll be SAQ D.
It's ok to store credit card data in hard copy format once it is locked and secure.

If you're using a payment gateway service where all the transaction information (such as card numbers) is inserted online through a third party service provider, then it's usually a SAQ A.
It's fine to store customer names and addresses. If you're not physically storing credit card information on your systems, then that's fine, it's the responsibility of the third party service (usually written in contractual agreement).

Sure it will be grand

Thanks for the info.

Fart wrote: »

If you're using a payment gateway service where all the transaction information (such as card numbers) is inserted online through a third party service provider, then it's usually a SAQ A.

Wouldn't that be like Realex Redirect? In that case you don't need to be PCI compliant as Realex handle it, correct?

NetLink

Give this free, interactive wizard a try. If you answer these couple of questions, it will tell you which SAQ to fill out.

http://www.hackerguardian.com/hackerguardian/qa_sa_wizard.html

If you're using Realex Redirect, you would probably need to complete SAQ-B.

Sure it will be grand

Thanks for the link, I'll check that out.

NetLink wrote: »

If you're using Realex Redirect, you would probably need to complete SAQ-B.

Are you sure about that? I've done several Redirect integrations and never had to be PCI Compliant. All CC details are handled and stored by Realex so PCI Compliance is their responsibly.

jma

I'm pretty sure if you have a merchant account, you need to be PCI compliant, but SAQ A might be sufficient. Hosted payment pages mean that most of the compliance is taken care of by the processor, but your merchant agreement might still require you to be compliant also, ie submit SAQ.