PCI Scope, the SAQ – Self Assessment Questionnaire and ASV’s
Part 2 in a series on What is PCI Compliance? for credit card processing merchants from XBS Global. Our series of articles is directed toward level 3 and 4 merchants, their obligations for PCI compliance as mandated by the card brands and how best to achieve and maintain it.
PCI Compliance – Now mature, but still emerging
PCI compliance is required of all merchants, no matter the size or the number of transactions they process. We strongly recommend that PCI compliance and cybersecurity be an organizational undertaking, with an identified individual or - based on company size - a collaborative interdepartmental group responsible for the assignment. Meeting Pci Dss (Payment Card Industry Data Security Standards) is an ongoing, dynamic and evolving task.
To recap, PCI DSS 3.2 is the most current version of requirements and guidelines, suggested as “best practices” as of October 2016, and required by merchants officially by February of 2018.
The industry standards typically do not engage in the requirement of specific technologies such as tokenization, an excellent fraud protection tool that eliminates the need for merchant storage of sensitive cardholder data. Instead, the PCI SSC (Payment Card Industry Security Standards Council) uses phrases like “strong encryption”, to leave room for new and emerging technologies. One of the foremost changes noted recently by the council with this latest release, is that PCI DSS is now considered mature. Major upgrades, on a timed cyclical basis - as has been done since guideline inception - will no longer be made, but will instead arise with new and evolving cyber threats.
The path to PCI Compliance -
Step 1 - PCI Scope
Does your company use a credit card terminal over a phone line or internet to process payment? Are you strictly ecommerce? How is your checkout page hosted? Do you use an API for connectivity of payment processing with back office functions or an ERP? Do you store cardholder data electronically?
Do you, or any of your employees, access payment processing functions or view transaction data, remotely, from a home computer or on your smartphone? How many hardware devices have access to process payments or access payment data?
Determining the extent, range and scale of your responsibility for security of sensitive cardholder data necessitates a thorough assessment of your company’s cardholder data environment or CDE. This environment is defined by the PCI SSC as:
“The people, processes, and technology that touch or handle cardholder data, or sensitive authentication data.”
PCI DSS applies to ALL system components included or connected to the CDE, as well as those used in managing the security of other in-scope systems – all servers, 3rd party software, etc.
Cardholder data is defined as:
- PAN (primary account number)
- cardholder names
- and service codes.
Examples of sensitive authentication data would be:
- CVV2 or CVC2 data
- full magnetic stripe data
- or pin codes/blocks.
XBS Global does not recommend the storage of cardholder data, typically utilized for recurring billing. There are a variety of payment gateways (XBS for example, often uses Paytrace for our B2B payments clients), that can offload this need which serves to reduce the merchant’s PCI scope.
A quick diagram of your network, hardware components, and the routes traveled by cardholder data once accepted by (or entrusted to) your company, will give you and your cybersecurity team a better understanding of your CDE, possible vulnerabilities, and prepare you for completing the SAQ, or self- assessment questionnaire. Check out the great infographic below on PCI Scope from SecurityMetrics. PCI scope reduction should be a fundamental function of the PCI team.
Part 2 - The SAQ – Self-Assessment Questionnaire
At the heart of merchant PCI compliance is the SAQ. Every merchant must complete this questionnaire to be validated as PCI-compliant. With the new PCI DSS 3.2 version (updated from PCI DSS 3.1) there are NO new SAQ’s, and the eligibility criteria for which SAQ a merchant is to complete also remains unchanged.
However, requirements for some merchants will become more stringent and MFA or multi-factor authentication will come into play. While MFA has long been a component of the guidelines for remote access to the CDE, it will now be required for non-console administrative access, defined by the PCI SSC as –
“logical administrative access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console administrative access includes access from within local/internal networks as well as access from external, or remote, networks.”
The writing is on the wall - a password alone will no longer be enough – nor should it be..
Good news for merchants who invested in PCI SSC-approved P2PE (point to point encryption) hardware solutions. These merchants will find fewer questions on their SAQ in this new PCI DSS release, as these technologies are now understood to considerably reduce payment processing risk.
For ecommerce merchants who redirect customers to 3rd party payment pages, requirements are tightening and the SAQ becomes more involved. We’ve covered the concerns of increased ecommerce and online fraud (CNP, “Card Not Present”) as a result of the US migration to EMV in our blog post – B2B Payments – Where’s the Risk? – now realized in the upgraded PCI DSS requirements for such merchants.
You can take a look at the various SAQ’s and merchant classification criteria here. Merchants should be prompted to complete the SAQ by the merchant account provider or Acquiring Bank, and directed to which questionnaire they need to complete. Completion of the SAQ is an annual obligation (see our blog post, The SAQ, is it Costing You? )
Part 3 - ASV – Approved Scanning Vendor
Depending on the merchants SAQ criteria, a quarterly external scan of the merchant’s internet-facing systems and components is required. The purpose of the scan is to detect vulnerabilities in the system that would give hackers access. Merchants must use a vendor approved by the PCI SSC for external scanning compliance.
It may come as a huge surprise to merchants, but the PCI SSC also requires quarterly internal scans. Threats introduced via an employee download, or through a USB stick, for example – can be identified this way. The difference between these two requirements is that the internal scan does not require using an approved vendor.
In their recent blog post - "More Understanding PCI DSS Scanning Requirements" Tenable provides an in depth look at the difference between internal and external scan requirements that are outlined in the PCI DSS 11.2 - the most notable being what constitutes a passing scan and the rank and urgency of threats to be remediated.
In the simplest terms then, the merchant must:
- Assess PCI Scope
- Fill out the correct SAQ
- Pass any required scans
Scanning, if required, will be implemented by the ASV. Merchants will be notified and be given remediation recommendations by the ASV, if the scan is not passed.
Hopefully this clarifies to some degree, the fees or costs for PCI Compliance and non-compliance that are cropping up on your merchant statements. PCI DSS 3.2 is 139 pages long and provides the guiding framework for merchants and service providers alike as to the complex security requirements put in place and mandated by the card brands to protect sensitive cardholder data. It is the Acquiring Bank that provides the merchant account that brings the merchant the guidance, resources, and tools needed to attain PCI compliance. It's a huge task. Still, the fees being passed on to the merchant are fairly nominal. Non- compliant merchants (and possibly the acquiring bank) are legally responsible for a data breach. If you are not being charged a fee for PCI compliance you have to wonder... are you and your customer protected? Are you compliant?
Our last blogs in the series will cover some of the newer updates regarding PCI DSS that have a major impact, such as multi-factor authentication, the elimination of SSL and early version TSL as acceptable ecommerce cryptography protocols, and lastly, what you should be able to expect from your payments processing partner. Stick around!
