How to Comply with PCI DSS 4.0.1 (2024 Guide)

If you process credit card data, you only have until 31 March 202, when all the requirements in PCI DSS v4.0.1 become officially mandatory.

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 version 4.0.1?

Before you panic, understand that version 4.0.1 isn't a complete overhaul of version 4.0. The changes are minor, primarily focused on addressing formatting issues, typographical errors and improving the clarity of requirment details. Thankfully, the primary requirements and have not been changed. They remain the same as in version 3.2.1.

Version 4.0.1 does not remove, modify, or add any new requirements to PCI DSS.

PCI DSS version 4.0.1 (which is basically identical in scope to version 4.0) will remain a best practice standard, and it's requirements officially become mandatory on March 31, 2025. Organizations yet to align with the version 4 framework should begin preparing immediately to avoid last-minute botchy compliance efforts that could result in fines of up to $100 000 per month.

For additional compliance guidance, download this free whitepaper offering a clear and concise explanation for how to align with the PCI DSS version 4.0.1 (and version 4) standard.

The changes in version 4.0.1 of PCI DSS are outlined below.

General changes:

• Correction of typographical and formatting errors.
• Better alignment with subsequent publications, such as the v4.0 Quick Reference Guide and recently published FAQs.
• Additional glossary references
• Enhanced clarity in guidance, including reference updates to the Glossary for terms defined therein.
• Standardizes the terminology to consistently use “impact the security of cardholder data and/or sensitive authentication data” in place of “impact the security of the CDE.”

Requirements detail changes:

• Requirement 3: Clarifications around the storage of sensitive authentication data (SAD) and the use of keyed cryptographic hashes.
• Requirement 6: Reverted to v3.2.1 language regarding critical vulnerabilities and clarified applicability notes for managing payment page scripts.
• Requirement 8: Clarified multi-factor authentication applicability, especially for phishing-resistant authentication factors.
• Requirement 12: Updated guidance for relationships between customers and third-party service providers (TPSPs).

Appendices: Removal of Customized Approach sample templates from Appendix E, with references to the PCI SSC website for these resources, and the addition of new definitions in Appendix G.

What was new in PCI DSS 4.0?

Because version 4.0.1 is just a minor touchup of the significant changes brought about in version 4.0 of PCI DSS, compliance guidance will primarily map to the changes introduced in version 4.0, which were as follows:

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 did 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 >

4 compliance tips: PCI DSS version 4.0.1

The strategies will help streamline your Payment Card Industry Data Security Standard compliance journey, ensuring you address all of the data security standards outlined in versions 4.0 and 4.0.1 of PCI DSS.

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 have been 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.0.1 or version 4.0, so current control strategies mapping to these standards don’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:

Requirement 1: Install and Maintain Network Security Controls

Install and maintain a firewall and router configuration to protect cardholder data. Properly functioning firewalls and correctly configured routers comprise the critical first layers of network defense of an organization’s IT infrastructure. 

Compliance with this item will require a demonstration of the above, with appropriate testing and validation measures in place to ensure expected operations are indeed functioning. 

How UpGuard can help:
UpGuard can scan and validate that firewalls and routers are configured correctly through comprehensive change monitoring and policy-driven testing.

Requirement 2: Apply Secure Configurations to All System Components

Do not use vendor-supplied defaults for system passwords and other security parameters. Many intrusions and data breaches result from unchanged default passwords or system software settings in payment card systems or architectures. 

Since most default administrator passwords, application service passwords, and system monitoring passwords for leading products are widely known and accessible, changing or removing factory-set credentials is an integral preliminary step when deploying applications or devices. Furthermore, controls should be instituted to verify that default logins do not exist in the environment. 

How UpGuard can help:
UpGuard can automatically scan and monitor for the existence of vendor-supplied defaults.

Requirement 3: Protect Stored Account Data

Protect stored cardholder data. Any cardholder data stored in the systems must be encrypted. In this case, the shortest path to compliance is determining where credit card data is stored and encrypting it before saving. 

PCI DSS stipulates that cardholder data must be rendered unreadable before saving to disk, so these encryption requirements apply to any type of storage media.

As Requirement 3 only applies to organizations that store cardholder data on their systems, many merchants have circumvented this by opting not to save credit card data at all. PCI DSS actually prefers this since not storing cardholder data by default translates to stronger protection.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Encrypt transmission of cardholder data across open, public networks. When credit card information is transmitted over public networks like the Internet (e.g., submitting a web form with payment details), encryption methods such as SSL must be used to protect the data. 

Additionally, wireless networks using the WEP encryption standard are no longer allowed to transmit credit card data of any type.

How UpGuard can help: Through policy-driven testing, UpGuard can monitor and verify that encryption mechanisms are working as expected.

Requirement 5: Protect All Systems and Networks from Malicious Software

Use and regularly update antivirus software or programs. Malicious software such as malware and viruses are standard tools in a hacker’s arsenal, often enabling advanced persistent threats (APT) and multi-pronged attacks to be orchestrated later. 

Antivirus software is, therefore, a critical component of IT security, but like all applications, it must be regularly updated and patched to maintain its effectiveness. 

How UpGuard can help:
UpGuard ensures that antivirus programs are regularly accounted for in patch management initiatives.

Requirement 6: Develop and Maintain Secure Systems and Software

Develop and maintain secure systems and applications. In an increasingly complex and integrated world of applications and services, maintaining a comprehensive view of security is a major challenge. Review the alerts of all the software vendors used in your systems and apply their patches methodically. 

If the application has been customized, patching can be very difficult as the extended code may be affected by the patch. In this situation, the application needs to be adequately tested to see whether it is vulnerable, and then a plan must be put in place to address any issues. In addition, organizations with customized applications should consider conducting a vulnerability assessment.

How UpGuard can help:
UpGuard offers policy-driven testing and OVAL-backed vulnerability scanning and monitoring.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Restrict access to cardholder data by business need-to-know. All access to critical cardholder data should be restricted and recorded. For example, access should only be given to staff explicitly requiring credit/debit card details. 

Remember— encryption and directory access control allow administrators and support staff appropriate access to the services they need without revealing sensitive data. Additionally, all access should be documented and regularly audited. 

How UpGuard can help:
UpGuard can track all access to files and applications to ensure that only authorized access is permitted.

Requirement 8: Identify Users and Authenticate Access to System Components

Assign a unique ID to each person with computer access. It’s a well-known fact that most data breaches originate from inside the corporate network. Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by—and can be traced to—known and authorized users. 

All remote users should access corporate data and applications via two-factor authentication (e.g., tokens or smartcards). Devices should be logged off after a period of inactivity. Passwords should be routinely tested to prove they are unreadable during transmission and storage. 

How UpGuard can help:
UpGuard’s detailed reporting gives organizations the answers to questions like “who accessed the application or network and when?”

Requirement 9: Restrict Physical Access to Cardholder Data

Restrict physical access to cardholder data. Physical access to any building must be via a reception area, where all visitors and contractors must sign in. All devices that store or could store credit card details must be in a secure environment. Server rooms need to be locked with CCTV installed. Access to the wireless and wired network components must be restricted.

How UpGuard can help:
UpGuard can test and monitor physical security devices such as IP cameras to ensure they are correctly configured.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Track and monitor all access to network resources and cardholder data. The logs of all network and device activity need to be recorded and analysed for anomalies. They need to be stored in a manner that provides tracking of legitimate access, intrusions, and attempted intrusions. The logs must be available as material evidence in the event of a breach. 

How UpGuard can help:
UpGuard can integrate with leading log analysis and SIEM solutions to satisfy this requirement

Requirement 11: Test Security of Systems and Networks Regularly

Regularly test security systems and processes. Organizations affected by PCI DSS should conduct regular vulnerability scans for possible exploitable weaknesses in their environments. When significant changes are made to the network, device operating systems, or applications, organizations should run internal and external vulnerability scans to check for exploitable security flaws. 

How UpGuard can help:
UpGuard satisfies this requirement by automatically scanning the entire infrastructure for vulnerabilities through comprehensive OVAL-backed testing. The platform’s continuous monitoring capabilities ensure that all systems and applications are free from security flaws on an ongoing basis.

Requirement 12: Support Information Security with Organizational Policies and Programs

Maintain a policy that addresses information security for all personnel. Virtually all businesses transact digitally these days. For this reason, organizations need to include IT security in their overall policies and risk management strategies. 

Ownership of these initiatives must be assigned to a person or group within the organization. A strong security policy sets the tone for the entire company and informs employees of what is expected of them. 

Some of the areas addressed include remote access technologies, wireless technologies, removable electronic media, email usage, internet usage, laptops, and mobile devices. Additionally, service providers should be monitored and managed. 

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.

PCI DSS v4.0.1

Released in June 2024, PCI DSS v4.0.1 is a limited revision of PCI DSS v4.0, addressing stakeholder feedback with corrections and clarifications. Key updates include fixing typographical errors, aligning guidance with the version 4.0 Quick Reference Guide and FAQs, and standardizing terminology regarding cardholder data security.