PCI DSS: Which Self-Assessment Questionnaire?

For many small and medium size organisations it can be a difficult to know where to start with PCI DSS. There is quite a lot of PCI DSS documentation to get your head around, and some of the terminology is difficult to understand initially. Furthermore, your bank (or acquirer) may be telling you to become compliant, may charge additional fees until you are compliant to PCI DSS, and may give you a deadline to achieve compliance or face further fees.

Risks and Fines

For many organisations, the first question shouldn’t necessarily be “which self-assessment questionnaire”, but “how do we outsource all card payments.” The reason is two-fold: processing cardholder data yourself increases the risk of a breach, and the costs of achieving compliance and then maintaining compliance can be significant. The risk of a breach in terms of likelihood and impact is serious: many credit card breaches on SMEs are not made public, unlike the larger breaches, and SMEs are a target for card fraud just like large retailers. If an organisation is breached, they can expect a large fine from the card brands and have to pay for a forensic investigation and also a follow up report on compliance (RoC). Altogether this can run into tens of thousands of pounds or euros. If you can’t outsource all card payments, then try and limit how you handle cardholder data as much as possible, as this will still reduce the risk and reduce the compliance burden. Before launching into working on compliance to PCI DSS, it is worth reviewing the help available on the PCI SSC website. The guide for self-assessment questionnaires (SAQs) can be found here: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf You can find this and other documents including the SAQs themselves and PCI DSS itself in the PCI SSC documents library: https://www.pcisecuritystandards.org/security_standards/documents.php

Self-Assessment Questionnaires

The following table shows a summary for each SAQ for PCI DSS v3:

If possible aim for SAQ A, which is common for ecommerce merchants where you redirect to a payment gateway. This means that you will outsource all card payments. SAQ A has the lowest number of requirements that you need to meet. If you can reduce processes so you only take payments on stand-alone payment terminals and outsource everything else then you can aim for SAQ B, again with a low number of requirements. If you take payments over the telephone and enter them into a payment service provider’s website on a stand-alone PC, then you may be able to aim for SAQ C-VT, but there are caveats, as you will read below. Any mix and match of transmitting or processing card-holder data usually means SAQ D, although some sections may not apply.

Storing Credit Card Numbers

If you store cardholder data at all, specifically the credit card number or PAN (primary account number) you need to complete SAQ D. However for most merchants there is very little reason to store cardholder data electronically. If you think you need to store card details for recurring payments, then most payment service providers can provide recurring payments based on tokens. PCI DSS prohibits storing 3 digit card security codes at all, so it makes sense to let the payment service provider take care of recurring payments. Whether for subscription services or ecommerce payments, storage should be unnecessary. As well as the additional requirements necessary in SAQ D for compliance and the significant overhead of those, you have the risk of storing cardholder data; even with the required encryption controls, the risk of a breach and the number of card holders that could be breached is significantly higher when storing cardholder data.

eCommerce Payment Gateways

If your organisation only takes payments through a website then getting to SAQ A should be straightforward: make sure you either redirect to your payment gateway or use an iframe that shows your payment gateway. Ensure that no card details actually pass through your web site or servers (if you use the payment service provider’s web service APIs for example), as if they do you may fall into SAQ D. To avoid SAQ A-EP you need to carefully consider how your website interacts with the payment gateway. Use the Visa Europe guide to check this for your site:
https://www.visa.co.uk/dam/VCOM/regional/ve/unitedkingdom/PDF/risk/processing-e-commerce-payments-guide-73-17337.pdf

Taking Telephone Payments and Entering Them on Web Terminals

If you are taking telephone calls for payments and the agent is using a VoIP phone, then it is very likely that you are SAQ D and can’t do SAQ C-VT, as cardholder details are transmitted over IP on your network. If the agent is then entering the card details onto a payment service provider’s website and the computer used for that data entry is also used for other applications and is on your network, then again it is very likely that you are SAQ D and can’t do SAQ C-VT. If you look at the detail of SAQ C-VT, it is far stricter than the SAQ guide suggests; one of the requirements indicates that the virtual terminal needs to be the equivalent of a standalone payment terminal: “Your company accesses the virtual payment terminal via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment.” There are several options for reducing the scope. For VoIP, you can move to analogue phones for agents that take payments or even outsource the part of the call where payments are made: there are service providers that will take card details via the customer’s telephone keypad and then switch the call back to the agent. The agent can then check if the payment is verified through the service provider’s website. This may not suit all merchants and customers however, and an analogue phone line to call the customer back on could be a good backup solution. If you want to use VoIP then SAQ D may be the only option, however you could still reduce scope by isolating the VoIP network. If you need to record calls for compliance reasons, then there are solutions to allow the card number and 3-digit security code to be blanked, through automatic or manual agent methods. Some of these can be challenging to implement and may not be suitable for some merchants. If your agents enter payments through the payment service provider’s website on their PC, then it is likely that they use the same PC for other applications such as the main customer application and email. This means it is very difficult to isolate the PC from the rest of the network. Options here include the following:

• Switch to using physical, standalone dial-out payment terminals. This may only be suitable for a low frequency of payments within a small team.
• Have a separate PC or laptop that is isolated on its own network. Again, this is probably only suitable for a low frequency of payments within a small team.
• Have agents use isolated PCs, but that can connect to other web services via the internet on that PC. This option should be carefully designed and verified with your acquirer, and may require compensating controls. Even if the rest of the organisations network cannot connect to the isolated PCs, there may be increased risk if the agent connects to more than just the payment service provider’s website.

Networked Payment Terminals

If you are only using physical payment terminals you can aim for SAQ B. However, there are some payment terminals that connect to the payment provider over your own network and out through your internet connection. If these are not a validated P2PE solution from end-to-end then you may be bringing your entire network into scope and SAQ D. The best option is to check with the provider of your payment terminal about a validated solution and if that a validated solution is not possible, switch to standalone, dial-up payment terminals. Alternatively you could isolate the payment terminals on their own network, but this would still need SAQ D, although some requirements would not apply, such as cardholder data storage.

Road to Compliance

It may be the case that you are unable to reduce scope sufficiently and are unable to change how you process cards, so that you can satisfy the requirements of the SAQs with the least number of requirements (SAQ A, SAQ B or SAQ C-VT). It may be worth reviewing options again at this stage just to really make sure that you can’t outsource everything or reduce scope more. If you can, it will be worth it in the long run. Make sure that you map out the cardholder data flows, as not only is this is a requirement of PCI DSS, whichever SAQ you end up completing, but a diagram can really help you understand what is going on and how you may be able to change processes and systems. If you are left with SAQ D or with one of the SAQs with more requirements, then the PCI SSC have a very useful compliance tracking tool called the Prioritized Approach Tool, which is a spread sheet which prioritizes controls in terms of risk. PCI DSS Prioritized Approach Tool: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_v3.xlsx The banks (acquirers) also understand the Prioritized Approach Tool, so if they ask you for progress on compliance you can provide them with the spread sheet, which shows percentage progress in compliance and estimated completion dates. For many organisations with more complex systems achieving compliance to PCI DSS can take a year or more. Organizations could depend on legacy systems and may have legal requirements around voice recording, all of which may require significant changes and investment. Compensating controls could be an option in some cases, but should not be a long term goal. You should be mindful of the intent of the PC I DSS requirements when you are working towards compliance. Look at the testing procedures and guidance to determine the intent. Here are some examples of where organisations may miss the intent of requirements:

• When using network segmentation to reduce scope, the standard requires isolation of the cardholder data environment, not just separation where traffic is still allowed between networks (page 11 of PCI DSS v3). Any network segmentation needs careful consideration of which networks may allow access to cardholder data, and it can help to think about the cardholder data environment and what other components may be in scope.
• Critical security patches need to be applied within a month of release for all applications in scope, not just Microsoft software. This may include Java and Adobe software if in use.
• Access control requirements apply to all system components in scope, not just the payment application and its server.
• Audit logs need to be formally reviewed every day, and what needs to be logged is specified in detail. Just taking default logs and storing them is not enough.
• The penetration test as required by section 11.3 is a full, manual penetration test, and is not just an automated vulnerability scan.

Summary

A good step-by-step approach to PCI DSS compliance is as follows:

• Document how you process, store or transmit cardholder details. Tracking the PAN and the 3 digit card security codes are key to this. A data flow diagram is ideal. Be aware that staff may not handle cardholder data as you expect, so observation of processes and using discovery tools is important.
• Try and outsource or take out as much of the payment process as possible, whether redirecting to a payment gateway, removing card storage, using tokenization, or switching to analogue phones. If you think you have done enough to meet the requirements for one of the smaller SAQs then carefully check the requirements list on the SAQ document itself.
• When you have reduced your scope but still need to do significant work on compliance, use the Prioritized Approach Tool.

By removing storage of cardholder data and removing or reducing transmission and processing of card payments, you will not only reduce your ongoing compliance burden but you will also significantly reduce the risk of a breach.

Epilogue

Although the aim here has been how to achieve compliance with PCI DSS, PCI DSS is seen as a baseline for card security. You may wish to consider reviewing security controls in a wider context to protect intellectual property, personal data and reputation. A good example is an ecommerce website which redirects to a payment gateway for payments. If this met the requirements for SAQ A, the ecommerce website itself would not be in scope, and so not be subject to compliance requirements such as penetration testing, vulnerability scanning and timely application of security patches. However, these examples are common practice for any website which an organisation relies on for revenue. Ideally, PCI DSS compliance requirements should be included in your organisation’s wider information security programme, which could be an information security management system based on ISO 27001.