PCI DSS stands for the “Payment Card Industry Data Security Standard”. It is a set of requirements that all organisations who store, process, transmit cardholder data must comply with. It also applies to organisations who have the ability to affect the security of the storage, processing, or transmission of cardholder data.
At a high level, there are 12 main requirements in PCI DSS which include over 200 individual requirements each with their own testing processes within them.
For more about the basics of PCI DSS, see What is PCI DSS?
If you’ve ever heard the term SAQ (sometimes pronounced like “sack”), they are referring to a Self-Assessment Questionnaire.
PCI allows merchants who only process a certain number of transactions annually to complete a SAQ.
If you are a service provider and are able to self-assess, the only SAQ you are allowed to use is SAQ D (Service Provider).
Merchants are required to submit one or more SAQs based on the payment channel or channels that you support. You should always get confirmation from your acquiring bank on which SAQ or SAQs they need you to submit. Especially if you have multiple payment channels.
Each SAQ has a set of criteria that you must meet in order to use that SAQ. If you do not meet these criteria, you will need to use a different SAQ. If you aren’t sure, please contact your bank. For every SAQ except D, you must confirm that you do not store any cardholder data. A data discovery tool (for example, card scanning) can be used to demonstrate that you do not store cardholder data.
The table below provides a quick summary of each of the SAQs.
|SAQ||Summary of Payment Channels|
|A||Card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers. No storage, processing, or transmission of cardholder data on the merchant systems or premises.|
|A-EP||E-commerce merchants who outsource all payment processing to PCI DSS validated third parties and who have one or more websites that don't directly receive cardholder data but can impact the security of the payment transaction. No storage, processing, or transmission of cardholder data on the merchant systems or premises.|
|B||Merchants using either imprint machines and/or standalone, dial out terminals. No electronic storage of cardholder data. No e-commerce.|
|B-IP||Merchants using standalone PTS-approved payment terminals with an IP connection to the payment processor. No electronic storage of cardholder data. No e-commerce.|
|C||Merchants with payment application systems connected to the internet. No electronic storage of cardholder data. No e-commerce.|
|C-VT||Merchants who manually enter a single transaction at a time via a keyboard into an internet-based virtual terminal solution provided and hosted by a PCI compliant third party service provider. No electronic storage of cardholder data. No e-commerce.|
|P2PE||Merchants using only hardware payment terminals included in and managed via a PCI SSC listed P2PE solution. No electronic storage of cardholder data. No e-commerce.|
|D (Merchant)||All other merchants not included in the descriptions above. Merchants with multiple payment channels. Merchants that store cardholder data.|
|D (Service Provider)||All service providers who are eligible to complete a SAQ.|
A Report on Compliance (or RoC) is the report that is completed by your Qualified Security Assessor (QSA) documenting the outcome of your onsite assessment. A RoC is required for all Level 1 merchants and service providers. It may also be required for lower Level merchants and service providers if requested by your bank or by another entity.
You can find the reporting template used for assessments on the PCI SSC Website (search for Reporting Template). This document will help you understand each of the testing processes and types of documents and interviews that are required to be completed during the assessment. We will help you understand the material, but the easiest way to make your assessment as smooth as possible is to ensure that you’ve reviewed not only the PCI Standard, but also the testing procedures.
PCI DSS has different requirements for how you have to assess your compliance depending on the number of transactions that you store, process, or transmit on an annual basis. However, there may be other considerations, such as:
- The value of your transactions
- Whether you have had a breach
- The type of transactions (for example, higher risk transactions)
Typically though, your level will focus on the number of transactions you store, process, or transmit yourself or on behalf of your customers.
|Merchant Level||Number of Transactions (Annual)||Payment Channel||Assessment Requirements|
|Level 1||6+ Million||All Channels||Report on Compliance (RoC)|
|Level 2||1 - 6 Million||All Channels||Self-Assessment Questionnaire (SAQ)|
|Level 3||20,000 - 1 Million||E-Commerce||Self-Assessment Questionnaire (SAQ)|
|Level 4||Up to 1 Million||All Channels||Self-Assessment Questionnaire (SAQ)|
|Fewer than 20,000||E-Commerce||Self-Assessment Questionnaire (SAQ)|
Service Provider Levels
|Service Provider Levels||Transaction Volume (Annually)||Assessment Type|
|Level 1||More than 300,000 transactions||Report on Compliance (RoC)|
|Level 2||Fewer than 300,000 transactions||Self-Assessment Questionnaire (SAQ)|
The simple answer is “no”. Vulnerability scans and penetration tests are two different things, both of which may need to be performed as part of your PCI requirements.
PCI defines the difference between penetration tests and vulnerability scans in their Information Supplement on Penetration Testing.
While penetration testing may include vulnerability scanning in the initial phases or as part of their testing, the primary difference is that vulnerability scans are primarily automated while penetration testing is primarily a manual task.