Reassess Your PCI Scope: Virtual Terminals

At the annual PCI Community Meeting in September, the PCI Security Standards Council (SSC) made it clear that interpretation of the standard and requirements has not been performed in the same manner throughout the industry. Some of the goals of the new standard are to improve verbiage in order to clarify the intent of individual requirements and understanding how to scope your cardholder data environment. From my review of the Payment Card Industry (PCI) Data Security Standard (DSS) version 2.0, things are definitely clearing up.

That said, a couple of weeks ago the PCI SSC released the latest versions of the Self-Assessment Questionnaires (SAQs) in alignment with version 2.0 of the PCI DSS. Not a big deal; of course, the SSC would need to update the SAQs to ensure they have the same clarifications and additional guidance that PCI DSS 2.0 has been updated with. However, a new SAQ has now been thrown into the mix: SAQ C–VT. SAQ C-VT has been specifically developed for merchants that are using secure web-browser based connections to manually enter and submit payment information to a service provider or processor. Like all the other SAQs, it provides a subset of requirements that apply to a specific process that is being performed.

What’s the issue? Well, it seems there has been some confusion in the PCI community in determining which PCI requirements actually applied to web-based virtual terminals. Doing a search on virtual terminals brings up a lot of links to various service providers that provide ‘virtual terminal’ services for merchants. Some of these providers are putting information out that states you would only need to complete SAQ A if you use these services. Well, we have some pretty definitive new guidance that increases compliance requirements around using a virtual terminal type of service to process credit card transactions.

If you are going from SAQ A to SAQ C-VT, you could have some work ahead of you to ensure that you are still compliant. SAQ A revolved around some physical security and policy requirements. You basically just needed to ensure you were using a compliant service provider. At a high level with SAQ C-VT, you’ll need to isolate those virtual terminal systems, do some system hardening, use anti-virus, and perform patch management on top of the SAQ A requirements.

I’ve heard arguments that this is just like someone making a payment online at home, so why is it in scope? Because those people making purchases through you are entrusting their card data to your organization. By processing and transmitting credit card information on behalf of a consumer, you need to ensure those systems are secure. For example, what if someone chose to put some malicious code containing a key logger on the PC that is using a virtual terminal? Without proper firewall access control rules, patch management, and anti-virus, that type of breach would go undetected. Even though the data is encrypted in the secure virtual terminal session, it’s not as it is entered from the keyboard.

This is not a change to the PCI DSS, just an effort by the SSC to clarify what the intent of the DSS always was. In my opinion, it makes scoping these types of processes during an on-site assessment much more black and white. Remember, PCI DSS 2.0 explicitly states that you must reassess the scope of your cardholder data environment at least annually, so make sure you identify processes that use virtual terminals for credit payments and include those in your scope.

By Konrad Fellmann