PCI DSS Basics
Confide understands that PCI can be difficult whether you’ve been working on it for one week or ten years. This is often because not only does the Standard change, but also risks change. At Confide, we work with PCI on a daily basis. We use our knowledge, skills, and information that we gain from this experience and use it to help you in your PCI journey, wherever you are at.
In our PCI Basics pages, we take a look at some of the most common areas where there are questions and confusion to help you understand and reach PCI compliance.
But let’s start with the most basic of questions, which is “What is PCI DSS”?
The Payment Card Industry Standard (or PCI DSS) is a set of twelve high-level requirements which all merchants and service providers who take card payments or who manage systems that are involved in transactions are required to follow. You can read more about the high level requirements here.
What’s Covered On This Page
- The PCI journey and how you get from asking what PCI is to being PCI compliant
- Want to know where to start? Understand why you have to be PCI compliant and whether you are a merchant or a service provider
- Next steps in your PCI journey, digging deeper into some common requirements that apply regardless of which category you fall into.
The PCI Journey
If you’re just starting out with PCI, you probably have questions about how you get from where you are to fully compliant.
When you first start out, the compliance journey might look and feel a little something like this:
You might not know what questions to ask. You might start out by focusing on what you have to report on before understanding your scope. You might try to fix gaps in your processes before really understanding what gaps PCI DSS is looking for you to fix. In short, sometimes the PCI journey is a bit of a winding road.
What usually happens if you go in unprepared is that you spend a lot of time jumping between the various parts in the journey. And quite often it means asking the same question multiple times.
At Confide, we want to help take you from the winding road of PCI compliance and help you find a smooth path to get from where you are (at whatever stage), through to PCI compliance.
In an ideal world, that journey might look a bit more like the diagram below, which follows a much straighter path through your compliance processes.
First you start by getting an understanding of what PCI is, figuring out where you fit into the PCI requirements by understanding whether you are a merchant or a service provider, and then by working through the requirements and finding out where there are gaps that you need to fix.
While you may still have to revisit certain areas, we hope that with some of the information below you’ll be able to go into your PCI journey well prepared for the steps along the way.
To start you out on this journey, we’ve put together some articles which might help with some of the basics. We won’t be able to answer every question here, but we hope it will help get you started in thinking about your own PCI journey.
Where to Start?
Next, you will probably want to figure out whether you are a merchant or a service provider.
A merchant is anyone that directly accepts payments for goods or services via credit or debit cards that have the logo of one of the five members of the PCI SSC (American Express, Discover, JCB, MasterCard, Visa)
A service provider is anyone that is not a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. It also includes companies that provide services that control or could impact the security of cardholder data.
Once you understand this first distinction and which description best fits you, we’ve put together specific pages to help you understand some of the key topics that apply to you as a merchant or service provider. We recommend reading the page that applies to you before you go further.
And if you’re wondering what the real difference in requirements is between service providers and merchants, it is only a difference of about 15 PCI sub-requirements. And there’s about 260 sub-requirements in total. So the number of additional requirements for service providers isn’t that many more. Of course, the key difference is that merchants have options to use different SAQs (depending on their payment channels and number of annual transactions) while service providers can only use one SAQ (if they meet the requirements for self-assessment rather than a full Report on Compliance).
You can read more about reporting requirements here.
Network and Data Flow Diagrams – What You Need to Know
Network and data flow diagrams are fundamental not only to you being able to understand what is in your environment and your scope, but also to be able to explain this to your QSA. As QSAs we rely heavily on your diagrams and documentation because nobody understands your environment better than you do. So even if you don’t have to have a diagram to put in your report, having a diagram you can use to document and define your scope is vital for everyone.
There are three different types of diagrams that you may need for your PCI compliance depending on which SAQ you are using (if you are using one) or whether you need to do a full RoC. These are:
- A high-level network diagram
- A detailed network diagram
- Cardholder data flow diagrams
Read more about what needs to be included in each of these types of diagrams.
Understanding Your Risks
It may be something that you do regularly, or it may be something that you only do once in a while because your board or management has asked for it. But one of the things that PCI requires is a risk assessment. Conducting a risk assessment should be looked as a way to understand potential gaps in your security controls which might lead to a breach. While the PCI DSS is aimed at helping you meet a minimum standard of compliance, there’s no reason why you shouldn’t look at the risks that are specific to your industry and your organisation to understand what additional controls might be needed to secure your environment.
Doing a risk assessment needs to be an annual process and part of any significant change. But if you don’t know how to get started with your risk assessment or what PCI requires you to document as part of your risk assessment, you can read more about it here.
What Makes a Change Significant?
One of the things that people get the most concerned over is when a change is considered significant. Just because a change is significant doesn’t mean it’s a bad thing. Some types of significant changes require out-of-schedule vulnerability scan to be carried out. Other types of significant changes require out-of-schedule penetration tests to be carried out. Other types of change are so significant that they require a whole new PCI assessment. The reality is that the last type of change, one so significant you have to do a new PCI assessment, is very rare. Most types of significant changes will only require new vulnerability scans. A few types of changes might require a new penetration test. And something so significant that you have to do a new assessment probably only happens once every five or ten years unless you are making some very significant changes regularly.
Read more about what makes a change significant and how you can make sure that you meet your requirements when you do have a significant change.
What’s the Difference Between a Penetration Test and a Vulnerability Scan?
Penetration testing and vulnerability scanning are two terms that often get confused. In fact, they get confused so often that the PCI SSC even published an information supplement that details the specific differences between them. In the simplest of terms, the main difference is that penetration testing is primarily a manual process while vulnerability scanning is an automated process. It’s not always as simple as that, but it’s a start.
Read more about the differences between penetration testing and vulnerability scans so you can make sure you’re doing what you need to do to meet your compliance requirements.
What Do I Have to Scan?
PCI talks about a lot of different types of scanning. And that’s the biggest catch usually, is that they are all different types of scans. In fact they are so different, that Requirement 6.6 calls out the fact that it is not the same as the vulnerability scans in Requirement 11.2. So, what kinds of scans might you have to do for PCI DSS?
- Req. 6.6: One option is to use web application vulnerability scans (as long as they cover a minimum of all the vulnerabilities in Req. 6.5)
- Req. 11.1: Rogue wireless access point scanning.
- Req. 11.2.1: Internal vulnerability scans.
- Req. 11.2.2: External vulnerability scans.
One of the other types of scans that you may do, but that is not required for PCI DSS is cardholder data scanning which can be used to validate that you are not storing any unsecured cardholder data.
Common PCI Questions
Service providers are limited to using SAQ D (Service Provider) or having a QSA complete a Report on Compliance.
Service providers cannot use any of the other SAQs to demonstrate PCI compliance to their customers.
Yes – if you accept credit or debit cards for the purchase of goods or services and you signed up with a merchant agreement with your bank, you are probably required to be compliant as a merchant.
If you perform a service for other businesses and you are involved in their transactional activities or look after a service that affects their PCI compliance, you’re probably required to be compliant as a service provider (or be involved in every customer’s PCI assessment who needs one).
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.
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||Annual Onsite Assessment (RoC) by a QSA|
|Level 2||1 - 6 Million||All Channels||Self-Assessment Questionnaire (SAQ) by an ISA|
Onsite assessment by a QSA (MasterCard)
|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)|
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?