PCI DSS Compliance and Cybersecurity

The Payment Card Industry Data Security Standard (PCI DSS) was developed by world leading credit card
brands to prevent payment card fraud, by introducing cybersecurity and data protection
requirements for all of their merchants worldwide.

What is PCI DSS?

The first version of the Payment Card Industry Data Security Standard (PCI DSS) was jointly developed in 2004 by Visa, MasterCard, American Express, JCB International and Discover to combat growing credit card theft, misuse and fraud.

ImmuniWeb can help you comply with PCI DSS cybersecurity requirements. How We Help

The standard is administered by the PCI Security Standards Council (PCI SSC) and applies to all entities that store or process payment card data (irrespective of the number of processed transactions), including merchants, processors, acquirers, issuers and service providers. The standard has the following overall objectives for covered entities:

• Build and Maintain a Secure Network and Systems
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

These overall objectives are broken down into 12 specific requirements which we will explain in the section below entitled “What is the PCI DSS compliance checklist?”.

In contrast to the EU GDPR or US state laws such as the SHIELD Act or CCPA, which are enacted and enforced by governmental entities in their respective jurisdictions, the PCI DSS and its underlying data protection duties are imposed by virtue of contract law. If a merchant (company) wishes to accept payments by credit or debit cards, it will be required to adhere to PCI DSS requirements by a contractual agreement involving its bank or processing center and credit card brands such as Visa.

Interestingly, some states in the US have incorporated the PCI DSS into their state legislation; Nevada mandates compliance by any merchants doing business in the state, while companies which adhere to the standard in Washington are shielded from liability.

What are the penalties for PCI DSS violations?

Violations of PCI DSS may be costly, with fines of up to 100,000 USD/month, until compliance is met. Continued non-compliance can result in the termination of card processing contracts which will eventually leave merchants unable to accept card payments, preventing- a e-commerce and digital businesses from trading.

Non-compliance with PCI DSS can provide evidence of negligence in the case of a data breach, potentially leading to costly individual and class action lawsuits by aggrieved individuals whose cards were compromised by hackers. Frequently, merchant banks also file lawsuits against merchants which have suffered a breach, claiming damages, such as costs associated with reissuing stolen credit cards.

In contrast to the Singaporean PDPA or Brazilian LGPD personal data protection laws, there are no criminal penalties or sanctions associated with PCI DSS violations. Nevertheless, it’s important to be aware of any other relevant national legislation. Data breaches may trigger regulatory scrutiny from the FTC or state Attorney Generals in the US, and from the national Data Protection Authorities (DPA) in Europe and other countries, potentially leading to severe monetary penalties, injunctions and even criminal prosecution.

What is PCI PA-DSS and PCI PTS compliance?

The PCI Payment Application Data Security Standard (PA-DSS) applies to software vendors that develop and commercialize card payment applications for third parties. The PCI SSC maintains a list of PA-DSS tested and validated payment applications that can be used in accordance with the PCI DSS standard. PA-DSS contains 14 requirements that include, among other things, prohibition to store card verification code (CAV2, CID, CVC2 or CVV2) and PIN block data, protection of stored cardholder data and its wireless transmission, implementation of strong authentication, and robust security testing of the applications to be performed in a continuous manner, including regular penetration testing.

PCI SSC maintains a list of PA DSS approved payment applications on its website. PCI PIN Transaction Security (PTS) covers the security of hardware devices that process card payments, such as portable devices or fixed terminals for payment with cards. Merchants that accept payments by credit cards, via a physical contact with the card, must use only the approved PCI PTS devices that were successfully tested and certified by the PCI SSC for PTS compliance. The PTS standard encompasses PIN security requirements, Point of Interaction (POI) modular security requirements and Hardware Security Module (HSM) security requirements. PCI SSC maintains a list of PCI PTS approved payment devices on its website.

Who is covered by PCI DSS compliance?

According to the PCI SSC guidelines for merchants, PCI DSS applies to all entities that store, process, and/or transmit cardholder data, where “cardholder data” is broadly defined as any information printed, processed, transmitted or stored in any form on a payment card. The following equipment and data, related to payment card information, must be protected in accordance with the PCI DSS requirements:

• Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions; and
• Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes; and
• Encrypted cardholder data that is present on a system or media that also contains the decryption key; and
• Encrypted cardholder data that is present in the same environment as the decryption key; and
• Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

Therefore, all entities engaged in receiving card payments, storing or processing cardholder data, regardless of their geographical location and size of business, must abide by the PCI DSS data security requirements.

There are, however, significant variations in the requisite validation of PCI DSS compliance for merchants of different sizes, grouped into four merchant levels, described below.

What are the merchant levels used in PCI DSS?

There are four consecutive merchant levels that are defined by credit card companies to classify merchants, according to their annual number of transactions, enabling adequate reporting and validation requirements proportional to the level of risk. There is a general consistency of merchant levels among different credit card brands, though minor differences may exist. For instance, Visa has the following merchant levels classification:

• Level 1 Merchant: processing over 6 million card transactions annually.
• Level 2 Merchant: processing between 1 and 6 million card transactions annually.
• Level 3 Merchant: processing between 20,000 and 1 million card transactions annually.
• Level 4 Merchant: processing below 20,000 card transactions annually.

Regardless of their level, merchants must comply with all PCI DSS cybersecurity and data protection requirements. The levels just impose different approaches to compliance validation; Level 1 merchants must strictly adhere to the standards, while Level 4 merchants usually enjoy some flexibility.

Importantly, a merchant may be automatically re-classified as a Level 1 merchant for one or more years if they suffer a data breach caused by non-compliance with PCI DSS - regardless of the number of processed transactions.

What is a PCI DSS audit?

Level 1 merchants (see above) are required to submit an annual Report on Compliance (RoC) after performing an onsite audit by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). Additionally, network vulnerability scan reports must be performed quarterly by an Approved Scanning Vendor (ASV), and they must submit anAttestation of Compliance (AoC) forms.

Level 2 and 3 merchants are exempt from submitting ROCs but must provide annual Self-Assessment Questionnaires (SAQ), alongside AoC forms. SAQs may be filled out internally or by an external provider and answer different questions about compliance depending on the SAQ type. There are different types of SAQ depending on the particular physical and technological attributes of card processing. For example, SAQ A type is designed for the so-called “Card-Not-Present” merchants, who entirely outsource card processing to an external entity, while SAQ B-IP type is intended for merchants with standalone, PTS-approved, payment terminals with an IP connection to their payment processor. A full list of SAQs can be found on the PCI SSC website.

Identically to Level 1 merchants, Level 2 and 3 merchants are required to submit quarterly network vulnerability scanning reports performed. These reports set a high bar for network security whereby one single vulnerability, except the low-risk ones as per the Common Vulnerability Scoring System (CVSS), will result in non-compliance with PCI DSS and require undelayed remediation from the merchant to avoid penalties or even a temporary suspension of its card processing activities.

Level 4 merchants commonly enjoy some degree of flexibility from banks and card brands. They are still normally required to submitSAQs - but sometimes banks may absolve small merchants from network vulnerability scanning requirements or make these voluntary. Level 4 merchants must nevertheless implement all data protection requirements imposed by PCI DSS.

What is a PCI DSS certification and how much does it cost?

Technically speaking, there is no formal “PCI DSS certification” process by a central certification body or authority. The annual process of self-assessment with SAQ submission (for Levels 2-4 merchants) and external QSA-driven assessment with RoC submission (for the Level 1 merchants) complemented with Attestation of Compliance is oftentimes referred to as PCI certification.

Some cybersecurity vendors readily provide privately issued certificates of PCI DSS compliance, following an onsite audit of the merchant. Usually, such certification may have value only if the vendor is QSA-certified by the PCI SSC, but there is no such legal requirement except for RoC reports that are accepted only from QSA vendors. The cost of PCI DSS audits greatly varies by sector, country and vendor. Small merchants may spend from 10 to 12 thousand USD per year, while international conglomerates, with complex Cardholder Data Environments (CDE) - discussed below - and branch offices around the globe, should be prepared to spend a seven-digit amount on annual auditing and compliance.

How to comply with PCI DSS

PCI DSS compliance is not as complicated and burdensome as may appear at first glance. According to the latest SSC’s Quick Reference Guide, the entire compliance process is composed of four foundational steps:

1. the merchant, or external QSA vendor, performs regular assessment for compliance with PCI DSS requirements of the Cardholder Data Environment (CDE).
2. Remediation: this phase identifies vulnerabilities through methods such as penetration testing, and addresses any deficiencies or non-conformities with PCI DSS.
3. the merchant or external auditor completes an SAQ or RoC and the underlying technical documentation validating conformity with PCI DSS.
4. Monitoring and maintenance: this is essentially the ongoing checking of systems for any vulnerabilities, through regular penetration testing.

It is important to highlight here that PCI DSS compliance is not an ad hoc exercise but rather an ongoing process. It’s aim is to continuously improve cybersecurity resilience and swiftly adjust security controls to shield organizations from the rapidly evolving cyber threat landscape.

How to determine the PCI DSS Cardholder Data Environment

The Cardholder Data Environment (CDE) is probably the most determinative and impactful part of the PCI DSS compliance process. It may either increase the burden or significantly alleviate the entire process.

The PCI DSS defines CDE broadly as: people, processes and technologies that store, process or transmit cardholder data or associated sensitive authentication data. The PCI DSS data protection and cybersecurity requirements apply to all system components within the CDE scope. The system components include network devices, servers, computing devices and applications – virtually all electronic devices and computer systems. The CDE must be assessed, scoped and documented at least annually or after any significant change in the IT environment.

The concept of CDE scoping is essential for PCI DSS compliance. An overestimation of the scope of the CDE may trigger unnecessary costs and considerably protract the auditing process. On the other hand, missed or forgotten systems and applications that process cardholder data, will make the CDE incomplete and could lead to a major data breach and/or non-compliance with PCI DSS.

Under the PCI DSS, covered entities are not obliged to secure their entire IT infrastructure and networks – just the parts where cardholder data is present or processed. Proper network segmentation and segregation, and the use of of VLANs to isolate the CDE from all other corporate networks and systems, can minimize the costs of PCI DSS compliance and auditing.

While determining your CDE scope, it is important to bear in mind modern technologies such as cloud backups. If an engineer connects to a CDE environment remotely to access cardholder data while their machine is being backed up to the cloud, the cloud and all interconnected networks could potentially fall into the CDE scope and create a compliance disaster.

What is the PCI DSS compliance checklist?

The PCI DSS contains 12 interrelated requirements that provide a comprehensive framework for regular risk assessment, asset inventory, implementation of risk-based security controls to adequately mitigate identified or reasonably foreseeable cyber threats, and ongoing security testing (eg penetration testing) accompanied with timely remediation:

1. Install and Maintain Network Security Controls.
2. Apply Secure Configurations to All System Components.
3. Protect Stored Account Data.
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.
5. Protect All Systems and Networks from Malicious Software.
6. Develop and Maintain Secure Systems and Software.
7. Restrict Access to System Components and Cardholder Data by Business Need to Know.
8. Identify Users and Authenticate Access to System Components
9. Restrict physical access to cardholder data.
10. Log and Monitor All Access to System Components and Cardholder Data.
11. Test Security of Systems and Networks Regularly (eg through methods such as penetration testing).
12. Support Information Security with Organizational Policies and Programs.

Each of these requirements is composed of numerous sub-requirements, elaborated over 360 pages of the PCI DSS standard (version 4.0). It’s worth noting that these 12 requirements have been updated since the previous version (3.2.1), but organizations can still rely on the previous version during the transition period (see “Transition to PCI DSS 4.0” below).

All merchants must comply with all of these 12 requirements, regardless of their identified level. Common sense scoping exceptions apply, eg if there are no wireless networks in the CDE scope, then wireless security requirements are obviously inapplicable.

What are the application security requirements of PCI DSS?

PCI DSS places significant importance on the ongoing application security aimed at ensuring resilience to multiplying web attacks of growing complexity and amplitude.

The most important application security requirements come from Requirements 6 and 11, applicable to all on-premises and cloud systems within the CDE scope:

• Requirement 6.3.1 directs entities to identify security vulnerabilities and assign “a risk ranking based on industry best practices and consideration of potential impact.”
• Requirement 6.4 says: “For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks” and goes on to outline specific methods.
• Requirement 11.4 instructs that “A penetration testing methodology is defined, documented, and implemented by the entity”, which includes, amongst other things: industry-accepted penetration testing approaches; coverage for the entire CDE perimeter and critical systems; testing from both inside and outside the Network ; testing to validate any segmentation and scopereduction controls; application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.”

The PCI Software Security Framework provides supplementary guidance including regular security testing of software for external and open-sourced components, implementation of a Secure Software Development Lifecycle (S-SDLC) to ensure security-by-design, and mitigation of the detected security flaws and misconfigurations in a risk-based manner.

In a nutshell, all web applications from the CDE scope must either be protected with a Web Application Firewall (WAF) or scanned for the OWASP Top 10 vulnerabilities in a continuous manner. The automated efforts should be enhanced with penetration testing that must be performed at least annually or after any major update.

ImmuniWeb can help you comply with PCI DSS cybersecurity requirements. How We Help

What are the third party risk management requirements of PCI DSS?

The PCI DSS standard makes it clear that covered merchants should and will likely be held accountable for any omissions, carelessness or negligence of their vendors and suppliers. The standard says that covered organizations which outsource their CDE or payment operations management to third parties remain responsible for ensuring that cardholder data is sufficiently protected by the third party, as per the relevant PCI DSS requirements.

Moreover, when outsourcing activities that require PCI DSS compliance, such as processing or storage of cardholder data, the merchant is eventually responsible for verifying that the service provider is compliant with the PCI DSS data protection requirements. Finally, an up to date inventory of all third parties that have access to the CDE environment or cardholder data must be maintained by the covered entity. Such documentation may be requested as a part of a PCI DSS audit.

PCI SSC Guidance on Responding to a Cardholder Data Breach suggests implementing contractual clauses that will require trusted third parties to immediately notify the merchant about any security incidents or data breaches when cardholder data is affected. Likewise, contracts may allow merchants to perform regular audits, request relevant security documentation or otherwise ascertain third party compliance with the standard.

The PCI Software Security Framework provides vendors with a set of security standards to help “assure that Payment Software is developed with security to protect the integrity of the software and the confidentiality of sensitive data it captures, stores, processes, and transmits.”.

Transition to PCI DSS 4.0

Although PCI DSS 4.0 was released in 2022, and organizations are encouraged to follow its standards as soon as possible, it will not take full effect until 31 March 2024, at which point the previous version (3.2.1) will be retired. In addition to this transition period, organizations will have until 31 March 2025 to phase in new requirements that are initially identified as best practices in version 4.0.

A full summary of changes from PCI DSS Version 3.2.1 to 4.0 is available on the PCI SSC website. But the key change is an updating of the 12 requirements (see “What is the PCI DSS compliance checklist?” above), to take account of new threats and modern security measures. There will also be a greater possibility of more customized approaches.

Share on LinkedIn
Share on Twitter
Share on WhatsApp
Share on Telegram Share on Facebook