PCI DSS is an acronym for the “Payment Card Industry Data Security Standard”. PCI DSS is a security standard setup in 2004 by Visa, Mastercard, Discover, JCB, and American Express. It details requirements for protecting cardholder data, which any organisation that stores, processes, or transmits cardholder data must adhere to. The latest version of PCI DSS is version 4.0, which was released on March 2022, however it is still possible to use PCI DSS version 3.2.1 until March 2024.

PCI DSS covers all aspects of security relating to card data, with 12 requirements including areas such as firewalls, physical security, development standards, monitoring and security testing.

Any organisation that takes card payments or handles cardholder data will need to comply to the requirements of PCI DSS, based on how the card data is stored, processed, or transmitted. The number of applicable requirements can vary significantly depending on how the cardholder data is stored, processed, or transmitted. For example, a company that fully outsources their payments to a PCI DSS compliant third-party service provider would have relatively few requirements, whereas a company that receives payments through their own networks and systems is likely to need to comply with most PCI DSS requirements.

This is an annual requirement, and merchants and service providers need to attest their compliance by firstly doing a Self-Assessment Questionnaire (SAQ), or Report on Compliance (ROC), and then if compliant, produce and Attestation of Compliance (AOC). There may be other circumstances where you need to attest, for example after a significant change to your PCI DSS environment or payment channels. Also, your acquirer may have additional requirements, depending on your status as an organization. Additionally, if you are the subject of a breach of cardholder data, you may need to engage with a QSA to confirm your compliance status after completing a forensic investigation.

At the very minimum, cardholder data consists of the Primary Account Number (PAN) which is the 16-digit number on the front of your card. In addition to this, it can also include the cardholder’s name, the expiration date of the card and the card validation code. Sensitive Authentication Data includes more security related information, for example the card service code, PIN number or PIN blocks and the data from the chip or magnetic stripe.

Although not storing card details will certainly reduce the number of applicable compliance requirements and also reduce your risk, you would still need to comply with PCI DSS if you are a merchant or service provider that processes or transmits cardholder data through your networks and systems. Even if you fully outsource all card payments to a third party, there are still requirements from PCI DSS that would apply.

This is something that is often confused. There are no ‘levels’ of compliance, an organization is either compliant or non-compliant to the requirements of PCI DSS. The ‘levels’ are based on the number of transactions an organization processes annually, and these levels vary depending on the card brand, and whether you are a merchant, service provider, or both. So, a ‘Level 1 Compliant’ merchant is simply a merchant that has been assessed to be compliant by a QSA that has a large number of transactions. For example, Visa defines a Level 1 merchant as processing over 6 million Visa transactions, across all channels, and a Level 1 Service provider as storing, processing, or transmitting over 300,000 transactions per year.

Complying with PCI DSS will hopefully reduce the risk of a security incident involving the loss of cardholder data, but if it does happen, you must report the compromise immediately to the relevant card brands. At this point, fines are normally levied against the merchant, and there may be a requirement to engage with a PCI Forensic Investigator to understand what happened, the scale of the compromise, and to remediate any immediate security holes. From there, your compliance may need to be verified by a QSA, in the form of a Report on Compliance (ROC).

A merchant is defined as “an entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard, or Visa) as a payment for goods and/or services.”. A Service Provider is defined as a “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data.”. So, if you take card payments for any goods or services, you would be a merchant. If you don’t take card payments, but store, process or transmit cardholder data on behalf of a merchant or other party, you would be a service provider. It is not uncommon for an entity to be a service provider to merchants, while being a merchant themselves.

QSA stands for Qualified Security Auditor. A QSA is someone who has undergone training in and around PCI standards and is qualified by the PCI SSC to advise organizations on how to achieve compliance and to perform Reports on Compliance (ROCs).

This question is best directed to your acquiring bank, as they will clearly set out their requirements for you to attest your compliance to PCI DSS. However, the basis for needing a ROC completed by a QSA is normally defined by the number of annual transactions you take per card brand. Each card brand has slightly different levels and requirements for merchants and service providers, so the requirements of each brand you accept should be consulted. Typically, though, Level 1 (and sometimes level 2) merchants, and Level 1 Service Providers, would need a Report on Compliance. Below that, merchants and service providers can usually self-assess.

That said, many organizations use a QSA to assist with SAQ.

This purely comes down to exactly how you are storing, processing, or transmitting cardholder data. By default, you would need to complete SAQ D, which includes the full set of PCI DSS requirements. However, many merchants store, process or transmit cards via specific methods (for example only using a third party to take payments, or only taking payments only via P2PE payment terminals). For these situations, you can potentially use one of the alternative SAQs, which only list the relevant requirements. These SAQs include SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ C-VT, SAQ C, SAQ P2PE, SAQ D. Service providers would always have to complete SAQ D for Service providers.

This question is best directed to your acquiring bank, as they will have full details of your transactions, and which level you are defined as. However, merchant levels are based on the number of annual transactions that are taken through your merchant account. These range from a Level 1 merchant to a Level 4 merchant. Each card brand has its own definition of levels for the number of transactions for their card brand, with specific compliance requirements for each level, so best to check each of the card brands you accept individually.

For Service providers, there are just two levels: level 1 and level 2. This is based on the number of transactions the service provider stores, processes, or transmits annually.

Firstly, don’t panic. This is something that happens to a lot of people. It is also relatively common for an organization to be asked about PCI DSS compliance for the first time, and to not really know where to start, or have internal expertise.

The most important thing at this point is to establish exactly what your organization is doing with card data. Dionach can help you with this with an initial conversation with a QSA around your understanding of your scope, and also help out with demystifying some of the terminology related to PCI DSS. Typically, at this point, we would recommend some form of scope review by a QSA, followed by a gap assessment to work out exactly where you are on your compliance journey. The output of these exercises would ensure that the scope of your compliance is correct and give a list of actions needed achieve compliance. The scope review would also highlight any existing processes that could make compliance difficult, or pose an unnecessary risk, with recommendations on alternatives. From that point, Dionach can support you through your compliance journey with as little or as much help as you need, with various services to help with working towards compliance and completing your annual attestation.

Your PCI DSS scope is the foundation for all of your future compliance efforts. Any errors in your determination of the scope can introduce unnecessary risk and also lead to a false sense of security, or incorrect attestation of compliance. Over many years, Dionach have performed numerous scope reviews for our clients, and it is very common for us to find additional cardholder data flows or discover that the wrong SAQ is being completed. Also, becoming compliant with a large scope can be very difficult and create a number of inherent risks. As part of the scope review, Dionach look for any opportunity to reduce your scope, or suggest alternative processes that could reduce your compliance burden and risk.

Many suppliers of QSA services will provide a certificate confirming that a Report on Compliance assessment has taken place and detail the result. These certificates can be useful to show clients or interested parties that you have undergone a successful assessment. Dionach can issue you with a certificate if you need one. However, these certificates are not official PCI SSC certificates, as there is no official certificate authorized by the PCI SSC. The official method of showing your compliance is by using your Attestation of Compliance (AOC) document, which would be signed off by both your organization and also by a QSA. When following up with your Service Providers to ascertain their compliance, you should always ask for their AOC, if you are presented only with a certificate of compliance.