As no doubt many of you will know, becoming PCI compliant can be a daunting task. I usually leave it to our head Information Security guru (Jason) to cover this subject; however I’ve noticed a lack of digestible information on the internet at large covering the initial questions one might ask when stepping into the world of PCI DSS. With this in mind, I’ve collaborated with Jason to bring you an FAQ that covers some of the basics.
So what is PCI DSS?
PCI DSS, short for Payment Card Industry Data Security Standard, is a set of standards designed by the Payment Card Industry Security Standards Council (PCI SSC) to ensure that anyone processing, storing or transmitting credit card details are doing so as securely as possible. SSC is backed by the likes of Visa and Mastercard.
Does PCI DSS apply to my business?
If you’re involved with processing, storing or transmitting any credit card information, then you need to ensure that your business is PCI compliant. This applies to all businesses, regardless of how big or small they are. Don’t believe us? Just ask your enquiring bank, or look here.
How do I become compliant?
This is the biggest question of all. Bigger than anything we can fit into one blog post, but a good start is to find out which ‘merchant level’ your business falls into. These levels are laid out and defined by the PCI SSC, based on the number of transactions your business is completing each year:
|Merchant Level||Transactions per year|
|2||1,000,000 to 6,000,000|
|3||20,000 to 1,000,000|
|4||Up to 20,000|
What’s the practical difference?
The higher level merchant you are, the more of a risk your business is at and so the controls and requirements are stricter. Level 1 merchants are the highest risk (without saying that other merchant levels are not attractive to cyber crooks) and require on-site audits to make sure that controls are in place and effective. Interesting fact: If Visa deems your business as high risk, they may insist you meet level 1 requirements even if you’re processing less than 6 million transactions per year.
Merchants in the Level 2 category do not require an on-site audit but one is often suggested by your acquiring bank and the PCI council. After you conduct a risk assessment, you might decide you want to validate the effectiveness of your controls by voluntarily having an on-site audit. Volunteering for the ‘extra work’ of an audit is not so strange: remember this is to protect you and your customers.
Level 3 & Level 4 merchants are required to fill in the Self-Assessment Questionnaires (SAQs - see below) that’s applicable to your environment. It doesn’t mean you’re immune or not at risk – cyber crooks often go after small and medium-size concerns as they know they under-invest in their security. If such businesses are affected by a breach, it could knock them out of the market for good.
What if I’m a service provider?
What if you’re providing a service that processes, transmits or stores cardholder data on behalf of a merchant then? Think about managed services or a website/app developers. There are three levels you can adhere to:
|Service Provider Level||Transactions per year|
|1||All payment gateways. Unlimited transactions|
|3||Up to 1,000,000|
What is the PCI DSS Self-Assessment Questionnaire (SAQ)?
The SAQs are a set of questionnaires designed by the PCI SSC to help merchants and service providers alike through their self-assessment. The requirements laid out in these questionnaires are there to ensure the necessary controls required to minimise the risk of a security breach are in place. There are currently 8 different SAQs, each applicable to different ways of transacting as merchants. There’s also one specifically for those who are looking to become a PCI-compliant Service Providers (like us) which requires a special audit.
So which SAQ do I need to complete?
Your best bet is to have a chat with your acquiring bank, as they’ll know exactly which SAQ they expect you to fill in, or take a look at the official definitions. But as a guide, the areas are broken down as follows:
|A||This SAQ is aimed at ‘card-not-present’ merchants: namely traders that have outsourced the transmission, processing and/or storage of all card data. To fit into this category, you basically have to ensure that you have nothing to do with the payment information your business takes.|
|A-EP||This is only for e-commerce traders that use a 3rd party for payment processor such as SagePay or PayPal. You’re still not permitted to store, process or transmit any card information yourself, but the link to a 3rd party does put you into a different category and leaves you slightly more at risk.|
|B||SAQ B applies to Merchants using only card imprint machines or dial-out payment terminals. If that all sounds a bit retro, that’s because it is. Note that this one doesn’t apply to e-commerce traders or those who store cardholder data.|
|B-IP||Almost exactly the same as SAQ B, except your payment terminals make use of a permanent connection. This also doesn’t apply to e-commerce traders or those who store cardholder data.|
|C-VT||Similar to B-IP, but applicable if you’re instead manually entering transaction details into an internet-based solution provided by a 3rd party, generally via a web browser. Again, this doesn’t apply to e-commerce traders or those who store cardholder data.|
|C||The original SAQ C is for companies that run integrated point of sale (POS) systems on a network that only connects to the Internet for authorisation. Once more: not for e-commerce traders or those who store cardholder data.|
|P2PE-HW||As the name suggests, if you are taking payments using hardware that is validated for Point to Point Encryption by PCI SSC, then you fall into this SAQ. And you guessed it – this isn’t for e-commerce traders or those who store cardholder data.|
|D||This is the one for if you store cardholder data. It’s also a catch-all for any organisations who don’t fit into above categories.|
Do I need PCI compliance if only take card details over the telephone?
You do indeed. The SAQ you’ll need to complete is a bit of a grey area as what you do with the details thereafter defines what category you’ll fall into, but your bank can help.
Does an SSL certificate make me PCI compliant?
No, but it’s definitely great start. SSL is designed to provide a secure connection between a website and a customer's browser. Any data transmitted to/from your website will usually be unencrypted, but SSL-certified pages will transmit the data encrypted. On its own, it doesn’t make you compliant.
What is a Vulnerability Scan?
A vulnerability scan is the process of identifying any vulnerabilities your systems may have that a hacker could take advantage of to steal data. A vulnerability scan generally makes use of a vast database of known issues and scans your environment to see if any of those flaws are present.
Can I choose to ignore PCI compliance?
You could, however you wouldn’t want to. Different payment providers can (and do) fine the acquiring banks for PCI violations. The acquiring banks will in turn pass this penalty down to you, the merchant. Thereafter, you’ll need to jump through various hoops to bring your business up to compliance. This is a long and expensive process. If you don’t, you risk the relationship with your bank being severed and your business being blacklisted so you can’t then take card payments. Scary stuff.
What if my Service Provider is not PCI DSS compliant?
In short: get a new service provider. If you’re using a service provider that is not PCI compliant then you are also not compliant, no matter how much work you put in.
If you’re looking to host your website and trade online securely, then might I humbly suggest ourselves? We're a a PCI DSS v3.0 Level 1 service provider. Get in touch with us today for a free PCI health check.