As a PCI Qualified Security Assessor (QSA) our primary role is to audit and validate e-commerce merchants’ compliance. We are also ideally placed to advise you on the likely overall cost and the steps you can take to minimise the time and resources associated with compliance.
Contact our Cyber Security Experts
PCI DSS stands for Payment Card Industry Data Security Standard. PCI DSS is a security standard published and maintained by the CPI Security Standards Council, an organisation established by the major credit card companies, including Visa, Mastercard, American Express, Discover, and JCB, to ensure the protection of cardholder data during payment card transactions. PCI DSS aims to prevent fraud, hacking, and other security breaches that could compromise the confidentiality and integrity of sensitive payment information.
Compliance with PCI DSS, the global Payment Card Industry Data Security Standard, is imperative if you are to minimise the risk of a data breach, avoid financial penalties – which are rising sharply – and ultimately continue to process card payments.
We provide the full breadth of QSA services from auditing, conducting a report on compliance (RoC), assisting with Self Assessment Questionnaires (SAQs) and consultancy to ensure the transmission, storage and processing of your cardholder data is fully secure and compliant with PCI DSS.
Many merchants and service providers have benefited from our expert guidance on practical ways to reduce the cost and complexity of their compliance requirements.
Dionach’s auditors can help to accurately scope your environment, defining which systems are in-scope for PCI DSS.
This is vital to ensure that the correct security controls are applied to each relevant system to achieve compliance – and not to those that are out-of-scope and would unnecessarily increase costs.
We work with you to understand and map your card payment data touchpoints – both technical and human – using detailed diagrams that allow us to confidently and accurately define the correct scope for your PCI DSS assessment.
One of the roles of our auditing team is to conduct on-site reviews in order to validate your Self-Assessment Questionnaire (SAQ) Compared to the option of simply self-assessing without the sign-off of a QSA, this provides you with added peace of mind that you are compliant and taking best practice steps to mitigate the risk of a data breach.
Following an on-site assessment, we produce a comprehensive report on compliance that assesses your cyber security resilience and adherence to the necessary PCI DSS requirements.
We are responsible for issuing your Attestation of Compliance (AOC) to demonstrate compliance to your acquirer, payment brands, customers, and relevant stakeholders.
Complying with PCI DSS is essential for businesses that store, process, or transmit cardholder data, and is usually a contractual requirement for merchants that take card payments. Here are the general steps to achieve compliance:
The first step is to determine your organisation’s merchant or service provider level of based on the number of transactions you process annually. There are four levels, ranging from Level 1 (highest) to Level 4 (lowest). The levels are determined by the card brands such as Visa, Mastercard and American Express.
Familiarise yourself with the PCI DSS requirements. There are 12 high-level requirements that include implementing firewalls, securing cardholder data, regularly monitoring and testing systems, and maintaining an information security policy, among others.
Perform a comprehensive assessment of your organisation’s current security practices and systems to identify any gaps or vulnerabilities. This assessment can be done internally or with the assistance of a Qualified Security Assessor (QSA).
Based on the assessment results, create a remediation plan to address any areas of non-compliance or security weaknesses. This plan should outline the necessary steps and timeline for achieving compliance.
Implement the necessary security controls and measures to address the PCI DSS requirements. This may involve actions such as reducing storage or cardholder data, encrypting cardholder data, implementing access controls, and regularly applying security updates.
Continuously monitor and test your systems to ensure they remain secure and compliant. This may include conducting vulnerability scans, penetration testing, and checking audit logs.
Depending on your level of compliance, complete the appropriate SAQ provided by the PCI Security Standards Council. The SAQ is a detailed questionnaire that assesses your compliance with specific requirements. Higher level merchants or service providers cannot complete an SAQ but need to have a Report on Compliance (ROC) from a QSA.
Submit the necessary documentation, including the SAQ, to your acquiring bank or payment card brands to demonstrate your compliance. Some businesses need a Report on Compliance (ROC) prepared by a QSA.
PCI DSS compliance is not a one-time effort but an ongoing process. Regularly review and update your security practices, conduct employee training, and stay informed about any changes to the PCI DSS requirements.
It’s important to note that achieving and maintaining PCI DSS compliance may require expertise and resources. Consider consulting with a Qualified Security Assessor (QSA) or engaging a reputable PCI DSS compliance service provider for guidance and support throughout the process.
PCI DSS compliance applies to any organisation that stores, processes, or transmits payment card information. This includes merchants, service providers, and any other entity involved in payment card transactions. The specific requirements and level of compliance may vary based on the number of transactions processed annually by the organisation. The PCI DSS applies to organisations of all sizes, from small businesses to large enterprises.
Here’s a breakdown of the entities typically required to comply with PCI DSS:
Any organisation that accepts payment cards as a form of payment is considered a merchant and must comply with PCI DSS. This includes retailers, e-commerce websites, hotels, restaurants, and other businesses that handle payment card transactions.
Service providers are organisations that process, store, or transmit cardholder data on behalf of merchants. This category includes payment gateways, hosting providers, payment processors, managed service providers, and other third-party vendors involved in payment processing.
Issuers refer to the financial institutions that issue payment cards to consumers, while acquirers are the financial institutions that work with merchants to enable payment card acceptance. Although issuers and acquirers are not directly required to comply with PCI DSS, they must ensure that their merchants and service providers are compliant.
It’s important to note that compliance requirements may vary based on the specific payment card brand and the number of transactions processed annually. Payment card brands have different compliance validation levels and may require additional security measures for organisations with higher transaction volumes.
Organisations are responsible for assessing their compliance requirements, determining their level of compliance, and completing the necessary validation steps outlined by the PCI Security Standards Council. They may need to complete a Self-Assessment Questionnaire (SAQ) or undergo an annual external assessment by a Qualified Security Assessor (QSA) depending on their level of compliance and specific circumstances.
We have documented frequently asked questions about our penetration test services. If you cannot find the answer to your questions, please do get in touch directly. We’ll be happy to help.
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 organisation. 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 organisation is either compliant or non-compliant to the requirements of PCI DSS. The ‘levels’ are based on the number of transactions an organisation 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).
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 authorised 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 organisation 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.
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 organisations 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 organisations 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 organisation 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 organisation 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.
We deliver the whole spectrum of cyber security services, from long-term, enterprise wide strategy and implementation projects to single penetration tests.
Our team works with you to identify and assess your organisation’s vulnerabilities, define enterprise-wide goals, and advise how best to achieve them.
Our recommendations are clear, concise, pragmatic and tailored to your organisation.
Independent, unbiased, personalised – this is how we define our services. We guide you to spend wisely and invest in change efficiently.