Today’s digitally-fuelled economy sees tens of millions of online credit card transactions and debit card payments per day. Visa alone processes 29 million online transactions per day, with companies like Mastercard and American Express recording similar figures. Aside from e-commerce websites and other online businesses, the card-processing ecosystem also includes hundreds of millions of transactions at point-of-sale systems on physical premises.
Whether payment card data gets stored in point-of-sale devices; mobile devices, personal computers, servers, or web apps, it’s at risk of theft both in storage systems and when transmitted to service providers. In response to the need to protect cardholder data against theft or loss, the Payment Card Industry Data Security Standard (PCI DSS) sets out the baseline essential technical and operational requirements for achieving adequate data protection. Here is a comprehensive guide to PCI DSS to assist with compliance.
What is PCI DSS and Why is it Important for Information Security?
- PCI DSS is a global information security standard that applies to any organization that accepts, transmits, or stores cardholder data. The standard contains 12 key security requirements to adhere to.
- The most recently published version of the standard is v4.0, which was released on March 31, 2022. However, there is a two-year transition period that lasts through March 31, 2024, in which version v3.2.1 remains active.
- The Payment Card Industry Security Standards Council (PCI SSC) published the first version of the standard in 2004, unifying the approaches and recommendations from the security programs of five major card brands. The five members of PCI SSC are American Express, Discover, JCB, MasterCard, and Visa.
- PCI DSS requirements apply to both merchants and service providers. A merchant, as defined by the PCI Security Standards Council, is any entity that accepts card payments for goods or services, where the credit or debit card bears the logo of any of the Council’s five members. A service provider is any entity (other than the five payment brand members of PCI SSC) that has direct involvement in the processing, storage, or transmission of cardholder data.
- Compliance with PCI DSS is mandated when merchants and service providers enter a contract with one of the five-card brands. In other words, as soon as you start accepting payments via any of these five payment brands, you’re contractually obliged to adhere to PCI DSS requirements.
- Failing to maintain the standards that PCI DSS aims to uphold can result in significant penalties. These non-compliance penalties are typically written into the contract you sign with a payment processor when accepting card payments.
Understanding why PCI DSS is so important comes down to the sensitivity of credit card and debit card information. The primary account number (the long number embossed on the front of payment cards), the expiration date, the cardholder’s name, and the security code all require protection against unauthorized access.
Cybercriminals prize this cardholder data and they relentlessly seek to exploit vulnerabilities in companies’ IT defenses in order to access and exfiltrate it. A thriving underground cybercrime economy sees millions of stolen credit card details up for sale on the dark web. Often, the stolen credit card data for sale comes from previous data breaches that exploited lax security controls.
When an unauthorized party gets access to someone’s card details, they can make fraudulent purchases or even clean the victim’s bank account out. The requirements of PCI DSS put in place minimum cybersecurity defenses and processes for reducing the probability of security breaches that result in people having their card details stolen.
While being PCI DSS compliant doesn’t guarantee you won’t get breached by hackers, it at least achieves baseline security standards.
4 Levels of PCI Compliance
The routes to validating compliance with the PCI standards depend primarily on the volume of card transactions that a merchant handles each year. There are four merchant levels in total (and there are two separate levels with distinct requirements for service providers).
The other factor that determines your compliance level is whether your company has been previously hit by a data breach or other cyber attack that compromised cardholder data; if this factor is not at play then the level comes down to the volume of transactions.
The payment card brand members of the PCI SSC use transaction volume as a proxy for risk. In other words, the more transactions a merchant processes, the higher the perceived risks, and the more stringent the route to validating compliance.
It’s worth noting that all card companies have their own compliance programs and corresponding merchant levels. This distinction can cause confusion. However, simplifying matters is the fact that Visa, MasterCard, and Discover use the same criteria for all compliance levels. Furthermore, while American Express has different criteria and JCB only has 3 levels, it’s a general rule that if you are at a given merchant level for one card brand, the same compliance level applies across the board for all five brands.
Starting from the lowest level set by the card companies and working upwards, here are the four levels of PCI compliance:
Level 4
This is your compliance level if your company processes fewer than 20,000 Visa or Mastercard e-commerce transactions per year or a total of up to 1 million annual Visa or Mastercard credit card transactions through all channels. You must:
- Complete a self-assessment questionnaire (SAQ) each year
- Get a quarterly network scan by an approved scanning vendor (ASV).
- Complete an attestation of compliance (AoC) form
Level 3
Level 3 applies if your company processes between 20,000 and one million annual Visa, Mastercard, or Maestro e-commerce transactions. To validate compliance, the same procedures apply as Level 4.
Level 2
Level 2 compliance kicks in for companies that process one to six million Visa, MasterCard, or Discover transactions, 50,000 to two and a half million American Express transactions, or less than one million JCB transactions. The validation procedures are:
- Complete an annual SAQ
- Perform a quarterly network scan using an ASV
- Complete an AOC form
Level 1
Level 1 applies if you process more than 6 million Visa, Mastercard, and Discover card transactions per year, 2.5 million American Express transactions, or 1 million JCB transactions. You must also achieve Level 1 compliance if you’ve previously had a breach in which cardholder data was compromised. Validating Level 1 compliance entails:
- Submitting an Annual Compliance Report (ROC) by a Qualified Security Assessor (QSA) or Internal Security Assessor
- Quarterly ASV network scans
How Does PCI DSS Protect Cardholder Data?
PCI DSS protects cardholder data by:
- Forbidding the storage of sensitive authentication data (SAD) after authorization, including card magnetic stripe data, card validation codes (CAV2/CVC2/CVV2/CID), and PIN codes.
- Requiring any electronically stored SAD (prior to authorization) to be protected with encryption based on strong cryptography.
- Requiring the unique id (PAN) of any card to be made unreadable anywhere you store it (e.g. backup devices, removable media, servers). Similarly, other account data, including cardholder name, expiration dates, and service codes must also be made unreadable if stored alongside the PAN.
- Only allowing the storage of cardholder data where there is a legitimate business need.
12 Requirements of PCI DSS Compliance
Below is an overview of the 12 PCI DSS requirements, updated to include any changes in version 4.0. These 12 compliance requirements slot neatly into six different categories.
Build and Maintain a Secure Network and Systems
Requirement 1: Install and Maintain Network Security Controls – this could include firewalls, cloud access controls, software-defined networking tools, and any other system that examines network traffic.
Requirement 2: Apply Secure Configurations to All System Components – avoid using vendor-supplied default passwords, remove unnecessary accounts, and disable unneeded services.
Protect Account Data
Requirement 3: Protect Stored Account Data – put in place safeguards for protecting both cardholder data and sensitive authentication data while in storage.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks – when PAN data is transmitted over a public network like the Internet or wireless technologies (Wi-Fi), encrypt it either before transmission, encrypt the session, or for maximum protection, do both.
Maintain a Vulnerability Management Program
Requirement 5: Protect All Systems and Networks from Malicious Software – this requires putting in place a range of controls that protect against all types of malware. So, if your anti-virus software doesn’t protect against other forms of malware, such as trojans, rootkits, and ransomware, look for anti-malware tools that give comprehensive coverage.
Requirement 6: Develop and Maintain Secure Systems and Software – tools and apps that get used in your IT ecosystem, run vulnerability scans, perform code reviews, apply security patches, and follow best practices in secure software development.
Implement Strong Access Control Measures
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know – for interactive accounts associated with a particular user and accessed by employees, applications, and system accounts, ensure you assign least privilege access and periodically review accounts for unnecessary access.
Requirement 8: Identify Users and Authenticate Access to System Components – put in place processes and systems that enable you to able to identify users and what they’re doing. Effective authentication ensures you can verify that users are who they claim to be.
Requirement 9: Restrict Physical Access to Cardholder Data – put in place physical barriers and controls such as locks and security badges that restrict unauthorized access to systems in the cardholder data environment.
Regularly Monitor and Test Networks
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data – the ability to log and track activity helps proactively identify suspicious patterns while also facilitating easier post-incident investigations.
Requirement 11: Test Security of Systems and Networks Regularly – this means running periodic wireless network scans, vulnerability scans on payment applications and other apps, penetration tests, and more to bolster security.
Maintain an Information Security Policy
Requirement 12: Support Information Security with Organizational Policies and Programs – support the protection of data with policies and programs, including incident response plans, establishing a designated role that assumes assume information security responsibilities, running security awareness programs, and conducting targeted risk analysis.
PCI DSS Incident Response Plan
Each of the 12 PCI DSS requirements has several sub-requirements associated with them. For the 12th requirement, one critical element of an information security policy is to implement an incident response plan. In other words, the policy is not just about preventing security breaches, but it also requires putting processes in place to limit the damage from intrusions.
Some pointers for the plan are:
- Establish an incident response team with designated roles and responsibilities
- Ensure that each party involved in incident response sees the plan and understands their responsibilities
- Procure tools and set in place processes to limit data exposure and minimize data loss while preserving evidence for later forensic investigations.
- Test the plan often (ideally at least once per year) to ensure it works smoothly
Fines & Penalties
Since PCI DSS is enforced through contracts, the same also applies to the penalties for non-compliance. The contracts are typically between merchants, companies that process payment card transactions, and the payment brands. In the event of non-compliance, the card brand fines the payment processor, and this gets passed ultimately down to the merchant.
Fines have a wide range of between $5,000 and $100,000 per month of non-compliance.
There are further possible penalties payable for having to reissue payment cards or payable for each customer affected by a breach.
Repeated compliance breaches can result in your company no longer being able to accept card payments by one or all of the five payment card brands.
How Endpoint Protector Helps You Become Compliant with PCI DSS
Endpoint Protector is a data loss prevention (DLP) solution that provides multi-OS support across macOS, Windows, and Linux systems. Endpoint Protector helps you become PCI DSS compliant by:
- Discovering, monitoring, and controlling the movement of cardholder data in your environment.
- Monitoring data use by different users to help meet the PCI DSS monitoring and logging requirements.
- Blocking unauthorized transfers to stop data theft or loss of cardholder data.
- Automatically encrypting data transferred to removable media such as USB storage devices.
Frequently Asked Questions
The 12 key requirements of PCI DSS are:
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
12. Support Information Security with Organizational Policies and Programs
Download our free ebook on
Data Loss Prevention Best Practices
Helping IT Managers, IT Administrators and data security staff understand the concept and purpose of DLP and how to easily implement it.