Merchant & Retailer PCI DSS Basics
Almost everyone accepts credit or debit cards for transactions these days. And more and more stores are either moving online or supplementing their bricks and mortar store with an ecommerce site. We often think that PCI only applies to one or the other of these, but the reality is that whether your store is physical or virtual, you will have certain PCI requirements that will apply to you. And the requirement to comply with PCI DSS is something you agreed to when you signed up with your bank.
As a merchant, protecting your customers data has always been important, but it’s becoming even more important as the way that we shop changes and evolves. On this page, we cover some of the key things for PCI that merchants need to be aware of.
What’s the Difference Between a Merchant and a Service Provider?
When it comes to PCI, the distinction is not always clear cut. An organisation can be both a merchant and a service provider. And an organisation may decide to only be assessed as a merchant but not as a service provider. That’s why it’s important for both merchants and service providers to understand what the difference is between these and why you might want to (or need to) be assessed as both.
At the heart of it, a merchant is anyone who directly accepts payments via credit or debit cards that have the logos of one of the five card brands that are members of the PCI SSC (American Express, Discover, JCB, MasterCard, or Visa).
A service provider is anyone who is not a payment brand that is directly involved in either:
- The storage, processing, or transmission of cardholder data on behalf of another entity OR
- Providing services that control or could impact the security of cardholder data.
Read more about the differences between merchants and service providers when it comes to PCI compliance and PCI assessments.
What’s Covered On This Page
- What is your PCI scope?
- What are your reporting requirements?
- How do you secure your EFTPOS terminals?
- Why you should have a responsibility matrix that outlines your responsibilities and those of your service provider(s).
- What happens if your service provider isn’t PCI compliant?
- Common questions from merchants
Merchant PCI Basics
At the very start of your PCI journey, your biggest questions are probably focused on understanding what you need to be concerned about as part of your compliance and what it is that you need to do to report on your compliance.
What’s My Scope?
One of the key things that you need to understand for PCI is what your scope is. Scope means all of the systems, people, and processes that are governed by PCI DSS. Your scope will depend on a number of different things, including how you accept payments. But it will also depend on how you have made sure that your “in-scope” systems have been secured so that they cannot have their security negatively affected by “out-of-scope” systems.
The PCI Information Supplement “Guidance for PCI DSS Scoping and Segmentation” sets out three different categories for scope:
- Cardholder Data Environment (In-scope)
- Security Impacting or Connected-To (In-scope)
If you accept payments, you will never be able to reduce your scope to zero and you’ll still have a minimum amount of PCI compliance that you will need to do. However, understanding these categories will make it easier to understand how you can ring fence your compliance.
Read more about what each of these means for your compliance and learn about what you need to do to take systems out-of-scope.
What Are my Reporting Requirements?
The PCI Standards have a number of different reporting options for merchants depending on:
- How many transactions you have per year
- How you accept payments (e.g. online, over the phone, in person)
If you have more than 6 million transactions per year, you will need to do a Report on Compliance. If you have fewer than 6 million transactions, in most situations you will be able to use a “Self-Assessment Questionnaire” or SAQ. There are 7 different SAQs that might apply to your environment, each with different sets of requirements and applicability criteria that have to be met in order to use them.
Read more about what each of these options means for your compliance reporting.
Protecting Your Customers’ Data
You want to make sure that you protect your customers’ payment card data. There’s nothing more devastating than finding out that you’ve been a point of compromise. Depending on how you accept customer payments, there are different things that you need to do to ensure that the transaction is secure.
Secure Your Terminals
Merchants with EFTPOS terminals have a specific set of requirements that apply to making sure that card-present transactions are secured. That’s because card-skimming can happen anywhere, and it even happens in New Zealand. The key requirements here can be summarised as:
- Know your devices
- Check your devices
- Train your staff
If you’re already doing these things, you’re probably off to a good start.
Read more about how you can make sure that your customers’ payment information is secure when they shop in your store.
Secure Your Phone Payments
It’s not uncommon to take payments over the phone. But if you do, you need to make sure that your doing the right things to secure your environment. This means making sure:
- Your computers are secure (keep them patched)
- Your phone calls are secure (understand if you are recording calls)
- Your staff understand how to protect payment information
While this doesn’t cover everything you need if you’re taking payments over the phone, it’s a good place to start.
Read more about how you can make sure that your customers’ payment information is secure when they shop in your store.
Managing Your Service Providers
Almost every organisation, large or small, uses service providers. Whether they are your data centre providers, your website host, managing your firewalls, or writing code for your website, you need to be aware of how what they could do could affect your PCI compliance and how to manage your vendors in a PCI compliant manner.
Why You Need a Responsibility Matrix
One of the worst things you can hear during your PCI assessment (aside from maybe finding out that you’re storing unprotected cardholder data) is your service provider saying “that’s not my responsibility”. Suddenly you find yourself pushing your service provider to do things differently, facing unforeseen costs, and a potentially long remediation period.
Regardless of whether you are using an SAQ or doing a full Report on Compliance (RoC), you need to ensure that you have a process for managing your service providers that includes understanding which requirements they are responsible for, and which you are responsible for.
There are two ways that you can understand which requirements your service provider is responsible for:
- They might provide you with a copy of their Attestation of Compliance (AoC) which details which requirements were in-scope for their assessment
- They might provide you with a responsibility matrix
The reality is that both of these items need to be looked at together to be able to understand exactly which parts of each requirement your service provider is responsible for. Without all the information you might find that your service provider is compliant with a requirement, but that it is wholly the responsibility of you (the customer) to look after it in your environment.
Read more about responsibility matrixes and how they can make your PCI compliance easier for both you and a QSA.
My Service Provider Isn’t Compliant, Now What?
Currently there is no requirement to use a PCI compliant service provider. However, if you have a service provider that is in-scope as part of your PCI requirements, then you need to be aware of how this affects you. If the service that they provide is not done in a PCI compliant way, then this could cause you to become non-compliant. As a result, if your service provider can’t provide an Attestation of Compliance (AoC) for the service they are providing, they may need o be included within your compliance and be able to show how they are meeting that requirement for you.
Read more about how service provider compliance can affect your PCI compliance and how you can take steps to minimise your risk.
Back to Basics
If you want to learn more about some of the specific requirements and go into more depth, head back to our PCI Basics page and read about some of the requirements that apply whether you are a service provider or a merchant.
And if you need some help with your PCI, Confide is here to help you.
Common Merchant Questions
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?