How to Comply with PCI DSS 4.0.1 (2024 Guide)

Risk Score

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.

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:

Requirements detail changes:

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.

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.

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

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).

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.

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

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:

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

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.

UpGuard's custom labeling feature allows you to include PCI DSS attributes in vendor metadata for tracking and reporting purposes.

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

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:

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:

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:

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:

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:

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.

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:

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.