How to Comply with PCI DSS 4.0 (2024 Guide)

If you process credit card data, you only have until 1 April 2024 to become completely compliant with PCI DSS 4.0. Failure to comply by this deadline could result in monthly fines until full compliance is finally met.

This post will help you get familiar with the compliance requirements of the latest version of the data security standard and aim to help you achieve compliance across all the standard’s requirements as efficiently as possible.

Learn how UpGuard streamlines Vendor Risk Management >

What’s New In PCI DSS 4.0?

Before you panic, understand that version 4 isn’t a complete overall of previous PCI DSS compliance. This new version is an adaptation to payment technology advancements that have occurred since version 3.2.1 - the tech landscape has significantly changed since this version was released in 2018!

The changes in version 4 (ordered by degreasing significance) are listed below.

1. Customized Approach to Implementation

Perhaps the most dramatic shift in version 4 is that organizations can now choose how to implement technology to achieve compliance. Custom implementation means companies now have the freedom to innovate their custom control strategy to achieve their own custom complaint pathway. This new requirement offers greater flexibility in adhering to the strict cybersecurity standards of PCI DSS.

Custom controls should not be confused with compensating controls - supportive security measures put in place when a company cannot achieve compliance for acceptable reasons.

This new customized approach to PCI DSS compliance is particularly beneficial to large organizations with well-developed internal compliance strategies. With the customized approach, you can still demonstrate compliance without having to prescriptively align  with PCI DSS standards.

The customized approach allows organizations to determine the security controls used to meet a stated objective in PCI DSS.

2. Increased Focus on Vulnerability Management

PCI DSS version 4.0 broadens the scope of security vulnerabilities that need to be remediated in version 3.2.1, which only requires critical and high-risk vulnerabilities to be addressed. In version 4, all vulnerabilities must be fixed, regardless of their severity level, with the most critical being prioritized. This is because every vulnerability if exploited, can potentially facilitate a data breach impacting cardholder data.

3. Malware and Phishing Controls

To mitigate the threat of ransomware attacks and other malware-related cyberattacks, overcoming isolation strategies like air gaps, PCI DSSv4.0 requires all removable media devices, such as USBs and external hard drives, to be scanned with malware detection software - either when the device is connected, or on a continues system scanning level while the device is connected.

This security control isn’t a new standard. It essentially describes the process of an endpoint protection solution, which should already be a component of your network security program.

4. Improved Cybersecurity Awareness Training

Version 4 offers more defined specifications for staff training. Staff now need to be trained at least every 12 months, with the training material reviewed annually to ensure it reflects the latest threat landscape developments.

PCI DSS 4.0 is also more specific about which topics staff should be trained on. These include social engineering and phishing attacks - the most common initial attack vector leading to data breaches.

Get your free data breach prevention guide >

5. More Secure User Authentication

A new access control requirement in PCI DSS v4.0 is implementing Multi-Factor Authentication (MFA) to secure access to Cardholder Data Environments (CDE).

User validation methods, like MFA and Zero Trust, are among the most effective measures for protecting payment data.

This new PCI DSS requirement will also minimize the risk of account data compromise, supporting the objective of the regulation’s social engineering training expectations.

Learn about common MFA bypass methods >

There are 60 new requirements introduced in PCI DSS v4.0. In addition to those listed above, some other new security requirements include:

• Keeping an inventory of all cryptography
• Mitigating eCommerce skimming attacks.
• Automated access log reviews

For a more comprehensive explanation of what PCI requirements have changed in version 4, refer to this document by the PCI Security Standards Council (PCI SSC).

Learn how to choose a PCI DSS 4.0 compliance product >

When Does PCI DSS 4.0 Go into Effect?

On 31 March 2024, PCI DSS version 3.2.1 officially retired. The next day, on 1 April 2024, compliance with PCI DSS version 4.0 becomes mandatory.

However, best practice requirements - standards requiring special technology to achieve alignment, aren’t expected to be completely complied with until 31 March 2025. The Summary of Changes document by PCI SSC highlights these special requirements with the following statement:

"This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment."

Version 4.0 includes 13 new requirements that are now valid and relevant in an Attestation of Compliance (AOC), with the remaining 50 not expected to be adhered to until March 31, 2025.

But don’t wait. Begin your compliance journey today. There are hundreds of sub-requirements in this latest version of PCI DSS, with many highly complex tasks requiring a significant implementation timeline.

PCI DSS 4.0 is in effect today. But compliance won’t officially begin to be mandated until 1 April 2024

To help companies expedite compliance with PCI DSS version 4.0, UpGuard offers risk assessments and security questionnaire templates mapping to the standards of PCI DSS, helping you track compliance internally and for each service provider.

Request a free trial of UpGuard >

Watch this video for an overview of UpGuard’s compliance tracking features:

4 Compliance Tips: PCI DSS Version 4.0

The strategies will help streamline your Payment Card Industry Data Security Standard compliance journey, ensuring you address all of version four’s security needs across all system components interacting with card data.

1. Define Your PCI DSS Scope

A new requirement within PCI DSS 4.0 (12.5.2) scoping involves identifying all system components and people involved in cardholder data's transmission, storage, and processing phases.

Scoping is different from a gap analysis. The overall objective of scoping is to discover opportunities for reducing implementation costs, both upfront and ongoing. With PCI DSS 4.0 approving a customized approach to compliance, there should now be more opportunities for compressing your PCI DSS scope and reducing compliance costs.

PCI DSS requirements 12.5.2 require this scoping process to be documented, with compliance confirmed by a Qualified Security Assessor (QSA). To simplify the scoping process, divide the effort into mapping cardholder data flows and scoping cloud service providers. Third-party vendors with access to cardholder data environments directly impact your level of PCI DSS compliance, so their security controls should be included in the scoping process.

Scoping Your Cardholder Data Lifecycle

Use these questions and action items to scope your cardholder data lifecycle.

• What types of credit card data are collected (expiration date, CVV, PAN, etc.)
• Which payment card brands are accepted (Mastercard, Visa, American Express, etc.)?
• At what point is cardholder data collected, and which systems collect this data?
• Where is cardholder data stored and transmitted immediately after collection?
• Which business functions depend on cardholder data access for continuity?
• List applicable regulations impacting your cardholder data storage standards (HIPAA, GDPR, etc.).
• List all applications, systems, and services involved during credit card data transmission.
• List all individuals with access to cardholder data at each stage of its journey.
• List all security controls for protecting cardholder data at each stage of its flow. (include information security and physical access controls).
• How long is cardholder data stored?
• How do you ensure cardholder data is securely disposed of?

Scoping Your Service Providers

Use these questions and action items to scope the security controls of all service providers processing cardholder data.

• What security controls do you have in place to ensure the integrity and security of cardholder data?
• Describe your security patch management process. How do you ensure cardholder data environments are patched promptly?
• Describe your software lifecycle development process. Does it map to an industry-standard cybersecurity framework? If so, which one?
• Describe your cyber risk analysis processes for detecting security risks in cardholder data environments.
• Do you perform vulnerability scans to detect emerging cardholder data vulnerabilities?
• Do you have user authentication protocols to protect accounts that access cardholder data environments?

Important: Scoping isn’t a complete-once-and-forget process. Scoping docs should be regularly reviewed and updated when significant changes occur.

PCI DSS 4.0 expects scoping documents to be reviewed at least every 12 months to ensure their accuracy, especially when significant to the in-scope environment occurs.

The following activities constitute a “significant change” and should, therefore, trigger a scoping review:

• Upgrades to cardholder data environments
• New hardware additions or replacements in cardholder data environments
• Network changes in cardholder data environments
• Changes to continuous process monitoring within cardholder data environments
• User access changes in cardholder data environments
• Changes to cardholder data flow
• Changes to third-party vendor services supporting cardholder data environments

2. Identify Scope Reduction Opportunities

Look for opportunities to reduce your PCI DSS scope and, therefore, implementation costs. These could include:

• Masking or Tokenization of cardholder data.

• Data loss and protection strategies across all three cardholder data states - at rest, in use, and in transit.
• More secure firewall configuration management
• Improving information security policies
• Avoiding cardholder data transfer across public networks
• Requesting patch verifications from service providers.

3. Perform a Gap Analysis

Within the compliance boundaries set by your scoping document, perform a gap analysis to determine the effort involved to determine the discrepancy between your current compliance baseline and complete alignment with the standard of PCI DSS 4.0.

To make your compliance pathway as efficient as possible, the requirements in PCI DSS 4.0 that need to be adhered to by 1 April 2024 should be prioritized over those that won’t be mandatory until a year later. For this, two separate gap analyses should be performed:

• One for the list of requirements that need to be complied with by 1 April 2024.
• Another for the list of requirements that need to be complied with by 1st April 2025.

Filing compliance gaps identified in your first analysis should be a relatively simple process, primarily consisting of minor security processes and policy changes. The gaps identified in the second assessment will take the longest to fill as they will involve large changes to your technology landscape. Performing a gap analysis for these changes early will allow you to start planning for significant changes well ahead of time to minimize disturbances that may trigger scoping revisions.

Examples of requirements that should be implemented before 1 April 2024 include:

• Documentation of PCI DSS scope
• Definition of PCI DSS roles and responsibilities
• Documentation of requirements and security standards expected of third-party service providers
• Implement security measures for files establishing network architecture, such as Terraform scripts, PowerShell scripts., Juniper Config Files, etc.

Examples of requirements that don’t need to be completed implemented until 1 April 2025 include:

• MFA protocols for all accounts accessing cardholder environments
• Automated user access log review
• Internal vulnerability scanning and management
• Periodic review of systems and application accounts to mitigate unauthorized access (may require implementing a Privileged Access Management solution).
• Hardware and software inventory reviews

4. Plan Your Vulnerability Scanning Process

Though not a mandatory requirement until 1 April 2025, you should start planning your vulnerability management program early, as settling on an optimized strategy could require significant effort, especially if you’re a large organization.

The vulnerability scanning details of PCI DSS 4.0 are listed under requirement 11.3.1.2:

Internal vulnerability scans are performed via authenticated scanning as follows:

• Systems that are unable to accept credentials for authenticated scanning are documented.

• Sufficient privileges are used for those systems that accept credentials for scanning.

• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.

- PCI DSS 4.0 (Requrement 11.3.1.2)

Authenticated vs. Unauthenticated Scanning

Authenticated scans log into a target system using user credentials to perform vulnerability scans from inside a system. This differs from unauthenticated scans, which search for security vulnerabilities from an outside perspective without logging in.

There are advantages and disadvantages to both scanning methodologies.

The benefit of authentication scans is that they’re more intrusive and so can gather more detailed vulnerability insights about a target system, such as:

• Open ports
• System patches
• Registry key configurations
• Non-running kernels
• Firewall configurations
• Antivirus versions

And much more.

The main disadvantage of authenticated scans is that they’re resource-depleting and take longer.

The benefit of unauthenticated scans is that they’re much faster and demand significantly less resource bandwidth. The disadvantage of unauthenticated (or uncredentialed) scans is that their insights aren’t as detailed as authenticated scans.

The greater depth of cardholder data vulnerability information that authenticated scans produce is likely why it’s preferred in PCI DSS 4.0. But this doesn’t mean unauthenticated scans should be excluded. By analyzing security measures from an outsider’s perspective, unauthenticated scans are, in some ways, more suitable for discovering external-facing attack vectors a hacker would exploit when targeting cardholder data.

Combining both scanning methodologies will provide the most comprehensive protection against cyber-attacks threatening the integrity of cardholder data. Finding the perfect balance between the two methods will require a well-strategized plan, so you should start considering options as early as possible.

To help organizations adhere to the two most competitive metrics for PCI DSS compliance - speed and insight depth, UpGuard combines a security ratings feature with point-in-time assessments.

With its security ratings engine, UpGuard tracks security posture degradations that could indicate emerging security risks. These events can then be further investigated with UpGuard’s PCI DSS security questionnaires and risk assessments to gather deeper insights into the specific vulnerabilities causing PCI DSS compliance gaps.

Get a free trial of UpGuard >

Complying with the 12 Foundational Requirements of PCI DSS

The good news is that the 12 foundational requirements of PCI DSS haven’t changed in version 4. So, a current control strategy mapping to these standards doesn’t need to be completely overhauled.

The 12 operational and technical requirements of PCI DSS are broken down into six adjacent groups called "control objectives" that require businesses to:

• Build and maintain a secure network;
• Protect cardholder data;
• Maintain a vulnerability management program;
• Implement strong access control measures;
• Monitor and test networks regularly;
• Maintain an information security policy.

Additionally, the requirements are separately elaborated into three segments for better clarification:

• Requirement declaration - The main description of the requirement.
• Testing processes - The proper methodologies the specified assessor uses to confirm the requirement is properly followed and implemented.
• Guidance - Further explains the main goal and purpose of the requirement and gives context that can assist businesses in properly defining the requirement.

Although each of the PCI DSS versions has its separate model of the six requirements and different sub-requirements, the twelve requirements have not significantly changed since the standard was implemented:

1. Implement and Maintain Network Security Controls

As the first step of PCI compliance, businesses are required to mandate a strong and secure network for improved data protection via the use of firewalls, as well as improving network security controls to avoid unauthorized access.

2. Implement Secure Configuration

Businesses must have a secure configuration for all of their system components.

Third-party products like modems, routers, and POS (point of sale) systems usually have very vulnerable, predictable passwords and weak security measures.

Instead of using the vendor’s default passwords and security parameters, businesses need to have uniquely tailored and customized security measures.

Inventory management and regularly changing passwords as additional safety measures are equally important.

3. Safeguard Stored Account and Cardholder Data

This is the most important requirement of the PCI DSS scope.

PCI DSS Requirement 3 ensures that cardholder data is protected from breaches by requiring businesses to implement two-fold protection of cardholder data and to improve storage methodologies.

For PCI compliance, businesses must protect cardholder data like PANs (primary account numbers) in two ways:

• encrypting stored cardholder data with strong algorithms that are put into place with encryption keys,
• regularly scanning them to prevent any potential unencrypted data.

Businesses can ensure strong PAN encryption by using truncation and redaction methodologies, as well as one-way hashing, which makes PAN impossible to read when stored.

PCI compliance Requirement #3 also includes data retention and storage policies, requiring businesses to decrease how long and frequently they store cardholder data.

While all stored cardholder data must be encrypted, encryption is not enough to comply with Requirement #3 of PCI DSS. Businesses must also hide card verification codes (CVCs; not to be confused with CVSs) and personal identification numbers (PINs) once the authorization code is complete.

4. Have Improved Cryptography During Transmission of Cardholder Data

This requirement enables businesses to protect card data while at rest (storage) and moving (during transmission) across open, public networks.

Cardholder data travels through multiple channels like payment processors and homes, and it must be appropriately encrypted, while account numbers must never be shared.

5. Improve and Maintain Protection Against Malware

Hackers can use many malware types and other malicious methods to reach protected data.

Businesses must be constantly vigilant by improving, updating, and maintaining their antivirus software on all PAN devices.

Many POS providers have anti-malware and antivirus software that may prevent direct installations for further protection.

6. Update and Maintain Systems and Apps

Businesses must always update their firewalls, antivirus software, and other software. The newest patches protect against recently discovered vulnerabilities and virus databases.

7. Limiting Digital Access to Cardholder Data

Companies must limit access to cardholder data and have it exclusively on a need-to-know basis. This is one of the most critical steps for maintaining strong security for financial data and records.

Entities and personnel without prioritized access to this information must not have access. If they don’t need access to sensitive data, they mustn’t and shouldn’t have it.

Moreover, instances where employees and entities with authorized access use and access the data should be well monitored and recorded.

8. Limiting Physical Access to Cardholder Data

Hackers aren’t the only reason for data theft — it can also get stolen “offline.” Therefore, all types of cardholder data must be stored appropriately and safeguarded in a protected location. This means both physical and digital data.

To comply with this control, businesses should deploy appropriate security measures, such as CCTV-protected perimeters and security personnel.

9. Assign a Unique ID for Each Authenticated User

Individuals with access to cardholder data and system components should have credentials and an authenticated identification, namely a unique ID.

Authorized users must have their own access IDs. Under no circumstances should a single login be used by different staff members. This allows security systems to properly identify and monitor authorized users and improve protection against unauthorized access.

This can also help forensics determine if the user has mishandled or compromised data.

10. Monitor and Report When Network Resources and Cardholder Data Are Accessed

As an overlooked and continuously violated requirement, companies must seriously consider the process of logging and monitoring network resources and cardholder data.

Businesses must create and maintain logs every time cardholder data is accessed, along with log entries from PAN activity.

For better organization, protection, and overview, all data within a company should be precisely documented — how and why it’s handled, where it’s stored, and where it moves.

11. Conduct Frequent Tests for Security Systems, Processes, Networks, and Devices

Businesses must regularly conduct scans and vulnerability tests for networks, processes, and security systems to prevent malfunctions, data mishandling, workplace errors, and employee misconduct.

12. Create, Implement, and Maintain Information Security Policies for Information Security

Businesses must establish, support, disseminate, and annually maintain information security addressed by organizational policies and programs. This is to be done according to the changing risk environment.

A comprehensive information security policy should include the following:

1. Purpose
2. Audience
3. Information Security Objectives
4. Authority and Access Control Policy
5. Data Classification
6. Data Support and Operations
7. Security Awareness Training
8. Responsibilities and Duties of Employees

Learn how to create an effective information security policy.

PCI DSS Compliance Levels (Merchant Levels)

Before they set up their compliance, businesses must first determine their merchant levels.

Credit card companies adhere to their own validation levels of PCI compliance. The levels are based on how many card transactions and payments the business processes annually.

They are divided into four merchant levels:

• Merchant Level 1: Processing over 6 million transactions
• Merchant Level 2: Processing between 1-6 million transactions
• Merchant Level 3: Processing between 20,000-1 million transactions
• Merchant Level 4: Processing less than 20,000 transactions

To find a suitable list of 12 PCI requirements and PCI questionnaires, businesses need to be sorted into compliance levels first.

Generally, the criteria applied will be based on those set by Visa and Mastercard, the predominant payment card brands.

The current PCI DSS documents can be found on the PCI Security Standards Council website.

More details about PCI compliance and which requirements and questionnaires suit your business can be found on the PCI Council Merchants website, their Getting Started Guide, and their Quick Reference Guide.

PCI DSS Compliance Auditing

Each of the five major credit card members of the PCI SSC have their own data security standards. To achieve PCI DSS compliance, organizations must also complete a CDE (cardholder data environment) audit.

A cardholder data environment is the segment of a business that handles cardholder data. By auditing their CDEs, companies can demonstrate their PCI security standard and adherence to the 12 compliance requirements.

CDE auditing can be done via:

SAQ (Self-Assessment Questionnaire)

Businesses must submit an SAQ, or self-assessment questionnaire, to their payment brand or acquirer (merchant bank).

These questionnaires serve as a checklist for PCI compliance, and they help reveal any vulnerabilities and inconsistencies in the organization’s credit card infrastructure, as well as requirements that are not yet met.

They come in nine uniquely tailored types. For example, “Questionnaire type A” is for companies that process transactions solely through third-party entities, while “Questionnaire type B” is for standalone online payment terminals.

Merchants should consult with their bank or payment brand to determine if they’re obliged or allowed to fill out.

Businesses can either complete their own Self-Assessment Questionnaire (SAQ) or file it via a certified QSA (Quality Security Assessor).

Picking a suitable questionnaire for the business depends on the business environment and the merchant’s level. 

External Vulnerability Scan

Businesses must go through an external, non-intrusive vulnerability scan conducted by an ASV (Approved Scanning Vendor) once every 90 days.

Vulnerability scanning is used to review businesses’ networks and web applications. It also checks the device and software configuration for vulnerabilities via IP addresses, ports, services, GUI interfaces, and open-source technologies.

RoC (Report on Compliance)

All Level 1 Visa merchants (and some Level 2 merchants) undergoing a PCI audit must complete a RoC or report on compliance to verify their compliance.

The report can be completed by a QSA (Qualified Security Assessor) or by an ISA (Internal Security Assessor).

After a completed questionnaire, a vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV), and a submitted AOC (Attestation of Compliance) to their acquirer, the merchant finally receives a PCI compliance certificate that can be presented to business partners and customers.

PCI Compliance Scoring and CVSS

Businesses can see how they meet requirements and maintain PCI compliance according to the evaluations of a Council-certified ASV (Approved Scanning Vendors). This data security service can scan businesses for vulnerabilities on a quarterly schedule.

The scanning is based on a CVSS (Common Vulnerability Scoring System), an industry open standard, as the primary evaluation criterion. It’s a computation of base metrics that calculates the network security risk of a vulnerability.

A CVSS rates vulnerabilities on a scale of 0 to 10. The higher the score, the more severe the risk. A merchant is considered PCI-compliant if its network security components have vulnerabilities with a CVSS base score lower than 4.0.

By maintaining a good PCI compliance score, businesses can prepare for or satisfy other cybersecurity regulations, strategies, and guidelines.

FAQs about PCI DSS Compliance

The concise answers to these FAQs will fill any remaining knowledge gaps about PCI DSS compliance.

What is the PCI DSS?

The PCI DSS (Payment Card Industry Data Security Standards) is a set of information security standards and requirements for companies/merchants that process, store, or transmit cardholder data from trustworthy card schemes.

PCI DSS ensures companies prevent credit card fraud and protect credit card holders from personal data theft.

Businesses adhere to the PCI DSS to meet the minimum recommended security requirements for card payments. That helps them strengthen their card transaction security and avoid potential data infringement and non-compliance penalties.

The PCI DSS was founded in 2006 by the PCI SSC. This independent organization was created by the five biggest credit card brands and providers: MasterCard, Visa, Discover, American Express, and JCB International.

While the card brands mandate the PCI standard requirements, they’re administered by the PCI SSC (PCI Security Standards Council).

Is PCI Compliance Required by Law?

Unlike imperative cybersecurity regulations like the HIPAA Act for healthcare sectors, PCI compliance is not exclusively required by law.

To clarify, some US states (Nevada, Minnesota, and Washington have already implemented PCI DSS into their laws) mandate that businesses should make equivalent provisions for PCI.

While laws that enforce PCI compliance are not widely adopted, it’s deemed a mandatory security standard since it’s highly advised for businesses to adhere to it due to its benefits. With the first iteration of v1.0, PCI DSS compliance became mandatory in December 2004.

Compliance is mandated by the contracts that are signed by the businesses. Non-compliant businesses don’t break the law per se — states where compliance is enforced by law notwithstanding — but they'd likely be in breach of contract, due to which they can face legal action.

The business may be ultimately sanctioned by the card brands and the entity that handles their payment processing. This is what “mandatory” means in this context.

Which Businesses Should Comply With PCI?

PCI compliance applies to any organization or merchant (including international merchants/organizations) that accepts, transmits, or stores any cardholder data regardless of size or number of transactions.

Businesses must comply with PCI standards if:

• They process three or more transactions a month;
• Use third-party payment processing;
• If credit card data passes through their servers despite not storing said credit card data.

Even businesses that handle card transactions over the phone must comply with PCI, as they fall under the category of businesses that store, process, or transmit payment cardholder data.

What Are the Penalties for Non-Compliance With PCI?

Technically, a merchant isn’t directly fined for non-compliance, but their payment processors and/or card brands like Visa and MasterCard are if they are found working with a non-compliant merchant. In most cases, the payment processor automatically passes the fines to the merchant in violation.

The PCI compliance violation fines enforced by payment brands (at their discretion) to an acquiring bank may vary from $5,000 to $100,000 every month the business hasn’t yet achieved compliance.

Additionally, the business can be imposed with costs from $50 to $90 per customer affected by the data breach. For big banks, such fines are manageable, but for small businesses, it could spell bankruptcy.

Small businesses may be obliged to complete a compliance assessment (for a fee) to prove that their card security has since improved.

Major businesses may be obliged to conduct PCI assessments by third-party entities despite not having suffered a security incident.

Why is PCI DSS Compliance Important?

Hackers actively search for security flaws in systems that handle customer information and exploit them to gain access to valuable financial data. Businesses must rapidly identify and remediate cybersecurity vulnerabilities in systems, devices, and networks with access to credit card and customer information to reduce the risk of a costly data breach.

Data can be stolen from many areas, including but not limited to:

• Card readers;
• Payment system databases (point-of-sale systems);
• Wireless networks in retail stores and access routers;
• Physical payment card data and paper-based records;

• Online shopping carts and payment applications.

A 2018 report by Verizon Payment Security states that 52.5% of companies and organizations have 100% PCI compliance, while a mere 39.7% of those companies are from the Americas.

The good news is that PCI compliance in businesses has grown over the years, with Verizon reporting an 11.1% increase in 2012 and a 55.4% increase in 2016. However, in 2018, only 36.7% of organizations ultimately passed the interim assessment.

PCI compliance only represents a general outline of credit card payment security regulations, and it’s not a fundamental cybersecurity framework that guarantees complete protection from cyber incidents. PCI compliance can be very complex and dependent on multiple factors, like the organization's size and the offered service provider plans.

However, PCI DSS compliance is still vital for small and big businesses. While it may be challenging to implement and maintain for some companies, it has its benefits, namely:

• avoiding the penalties of non-compliance,
• identifying security weaknesses and vulnerabilities regarding credit card information,
• maintaining their reputation and their customers’ trust.

Learn how to track PCI DSS compliance with your vendors >

What are the Different Versions of PCI DSS?

The PCS DSS standard has been evolving over the years, as cyber attackers are constantly finding new ways to breach the information systems of businesses and steal card information.

The PCI Council releases ongoing revisions to the standard in response to these increasingly sophisticated cyber threats.

PCI DSS v1.0

The first 1.0 version of the PCI DSS was a combined effort of the five card companies, ushered in December 2004 and revised and implemented in 2006. The companies had separate information security programs with similar characteristics but a clear goal for credit card security.

The first version was intended to unify a single layer of protection for card issuers to ensure that businesses meet the recommended level of security for handling cardholder data and sensitive authentication data.

PCI DSS v2.0

The second version, PCI DSS 2.0, was released in 2011 with reinforced scoping before assessment, the implementation of log management, enhanced validation requirements for assessing vulnerabilities, and several minor language adjustments intended to clarify the 12 PCI DSS requirements for credit card security.

PCI DSS v3.0

The PCI DSS v3.0 came with new updates, the biggest and most significant requirement being improving penetration testing, which changed former requirements for penetration testing. Merchants must use stricter “industry-accepted pen testing methodology,” as well as newer requirements regarding the verification of methods for segmenting the cardholder data environment (CDE) from other IT infrastructures.

Other key updates in PCI DSS 3.0 include: 

• Keeping inventories of hardware and software components in the CDE that are in the scope of PCI DSS, 
• Anti-malware detection and remediation standards
• Access control measures
• Third-party vendor PCI requirements
• Protecting the data-capture technology of payment methods, among others.

PCI DSS v3.2

The PCI DSS v3.2 was released in 2016 as a mature standard that would only require minor changes in accordance with new credit card payment methods and the changing cyber threat landscape.

It introduced new and updated clarifications to the 12 requirements regarding guidelines for vendors, updates for protection against card exploits, and implementing better security controls for new migration deadlines surrounding the removal of SSL/TLS.

Learn about the third-party requirements of PCI DSS.

PCI DSS v4.0

While PCI DSS v3.2 was the newest iteration of the PCI standard until 2016, PCI DSS 4.0 was developed, revised by the industry, and finalized in April 2022 with the following changes:

• Updated, clarified, and broadened firewall terminologies regarding NSCs (network security controls) for conducting proper analyses and policies on a per-session basis;
• Mandating the use of MFA (multi-factor authentication) for protected access into the CDE instead of just requiring a unique ID (username and password) for people with computer access privileges;
• Enhancing an organization’s flexibility so that they can better exemplify how they outline security standards and objectives for PCI compliance;
• Enabling companies to conduct targeted risk analysis which makes it easier for them to decide how regularly they perform tasks. This, in turn, allows companies to align their security posture with their business needs.