PCI DSS 4.0.1: What do merchants need to know?

Protecting money matters. And Data Security Standard version 4.0.1 is helping to do this. Also known as PCI DSS 4.0.1, it’s a set of industrywide guidance to safeguard payments against cyber attacks. Published in June 2024, PCI 4.0.1 became the sole active version in January 2025.

PCI 4.0.1 has 12 requirements to maintain a secure payment environment, which this article will briefly outline. Checkout.com is fully compliant with PCI DSS Level 1, which is the highest possible standard. That means you can trust us to protect your customers’ card data when we process payments for you.

What is PCI 4.0.1?

PCI 4.0.1 is the current version of PCI DSS: a set of security standards all merchants accepting credit and debit card payments must adhere to. It provides a framework for businesses to safeguard sensitive cardholder data. As such, it helps protect your customers from all kinds of payment fraud. 

It contains 12 requirements, explaining exactly how to maintain secure card payment transactions. Some examples of its provisions include guidance on encryption, maintaining sufficient documentation, and restricting access to sensitive data.

It’s maintained by Payment Card Industry Security Standards Council (PCI SSC) – a private consortium in charge of setting security standards for account data protection – formed by American Express, Discover, JCB International, Mastercard and Visa.

What’s new in PCI 4.0.1 compared with 4.0?

While 4.0.1 did not introduce new requirements nor remove any existing ones from PCI DSS 4.0, the previous version. Instead, it clarified several points. 

One such clarification was that the requirement for multi-factor authentication for non-administrative access into the cardholder data environment (Requirement 8.4.2) does not apply to accounts that authenticate exclusively using phishing-resistant factors. For organizations deploying hardware security keys or passkeys, this distinction affects how to scope and document MFA controls.

Another such clarification was to rectify a misunderstanding of PCI DSS 4.0's wording on vulnerability patching, which was widely read as extending the 30-day installation window to a broader set of vulnerabilities than intended. PCI DSS 4.0.1 corrected this, confirming the 30-day requirement applies to critical vulnerabilities, specifically. 

Who needs to comply with PCI DSS 4.0.1?

Any entity that processes, stores or transmits payment card data must meet PCI security standards. There are different levels of standards to meet, depending on what role you play in accepting or sending payments. Your exact responsibilities depend on your business size, your volume of transactions, and how much access you have to cardholders’ payment data. 

What must you do to achieve PCI compliance?

You must review and validate your PCI DSS certification once a year. We recommend you seek independent, professionally-certified advice to check the status of your own business’s PCI compliance. This article provides a general overview for informational purposes, only.

Qualified Security Assessors (QSAs) are independent individuals and organizations approved by the PCI Security Standards Council that validate your PCI DSS compliance, help you choose the right self-assessment questionnaire (SAQ) for your business, and support you through the entire process.

At Checkout.com, we partner with SecurityMetrics, a QSA company, to help merchants with PCI DSS compliance. SecurityMetrics will contact you annually for review and validation if you’ve chosen to use them during your application.

SecurityMetrics is best equipped to answer specific questions about your scope of compliance. For the best way to contact SecurityMetrics, visit their website.

An overview of PCI DSS 4.0.1 and its 12 Requirements

As mentioned, PCI DSS 4.0.1 was a minor revision of version 4.0. As such, almost all of the provisions in v4.0 apply in v4.0.1. These replace the last significant version update of PCI DSS 3.2.1. 

One of the main updates between PCI DSS versions 3.2.1 and 4.0 is the introduction of two new requirements – 6.4.3 and 11.6.1 – to counter web-skimming attacks, where malicious JavaScript captures the payment details customers enter on the page. These two requirements are among the most demanding in v4.0.1 for ecommerce operators, and they are the ones most likely to require new tooling and process investment.

Below, we lay out a summary of PCI DSS 4.0.1’s requirements – but it is not exhaustive. If you need more information, we recommend visiting the PCI SSC website to access further resources.

PCI 4.0.1 Requirement 1: Establish and maintain network security controls

The first Requirement recommends the proper use of firewalls to monitor and control incoming and outgoing network traffic. You need to establish sufficient segmentation of your Cardholder Data Environment (CDE) and other business networks, and carefully control communication to or from the CDE. Such security rules safeguard your CDE from unauthorized access. 

Between PCI DSS 3.2.1 and PCI DSS 4.0 there was a shift away from the language of “firewalls” and “routers” towards “network security controls”. Ultimately, today you are likely to still need to use strong firewalls to protect your CDE, though you may decide to use additional software and hardware to assist.

PCI 4.0.1 Requirement 2: Securely configure all system components

There are two main themes here: ensuring you have secure account access settings, and proactively maintaining system security on an ongoing basis. You’ll need to carry out system hardening for all applications, drivers, and services. This aims to remove the number of possible points of access a cyber criminal could use to steal data from your systems. For example, you should uninstall any scripts or services that you don’t need.

When it comes to the vendor-supplied default usernames and passwords – be they for network devices, applications, servers, firewalls, routers, or any software your business relies on – PCI 4.0.1 guidelines dictate that you should always change these to your own, stronger, passwords.

Why? These products tend to come with weak, easily guessable passwords as standard – often published online for all to access – and that includes bad actors.

On top of this, you must maintain an inventory of all hardware and software relevant to your CDE, document your procedures, and dedicate responsible persons to manage upkeep.

PCI 4.0.1 Requirement 3: Protect stored account and cardholder data

Requirement 3 centers around how you safeguard any account or cardholder data in your possession. This is to prevent unintended data leaks. So, the main actions are to find out exactly where your payment data is stored, create a map of data flows, confirm whether you are allowed to store each data type, and check whether you should be encrypting the data types.

To give a silly example with a serious message: you can’t keep lists of credit card numbers in a spreadsheet on your office computer. It’s just not secure enough to sufficiently protect customer’s accounts. There are too many possible ways that a bad actor could access it, and misuse what they find.

If you process credit and debit card transactions through a payment service provider such as Checkout.com, we’ll safely store that data for you – easing your compliance burden.

But if you do store account and cardholder data, such as the PAN (primary account number), PCI 4.0.1 mandates that you render it unreadable, and regularly check that it remains secure. There are several effective strategies – such as tokenization, which replaces the PAN with a random alphanumeric chain – to help you achieve this.

PCI 4.0.1 Requirement 4: Encrypt cardholder data in transit

Just as Requirement 3 requires you to safeguard cardholder data when it’s in storage, Requirement 4 mandates this data’s encryption when it’s in transit, too. You must carefully consider where your networks are sending sensitive payment data, because each time data moves, there is a possibility of it being intercepted. That’s why PCI 4.0.1 calls for “strong cryptography” of transmitted data over open, public networks such as the internet.

For instance, when you’re using saved PANs to bill a customer for a recurring service, like a subscription or membership, then you could use payment tokenization to help ensure cardholder data stays safe when it’s transferred. You should also ensure you are using the approved, up-to-date internet encryption standards for payments via your website.

PCI 4.0.1 Requirement 5: Update your malware protection

The fifth PCI 4.0.1 Requirement is all about protecting the systems and networks in your business within the PCI DSS assessment scope from malicious software, known as malware. Your organization should consider adopting advanced technologies such as artificial intelligence and machine learning to help you combat emerging threats.

In addition to installing reputable anti-malware software, PCI 4.0.1 mandates that you also keep it regularly updated and maintained to a high standard.

PCI 4.0.1 Requirement 6: Keep your apps updated and maintained

The sixth PCI 4.0.1 mandate requires you to keep the security settings of all your software and hardware regularly updated with the latest patches and fixes, and document change control procedures. You must install critical patches within a month of release – you may set up a manual or automatic schedule for this.

Requirement 6 now covers not only your business’s applications but all software involved in the payments process, including some of the software your consumers are using.

Part of this includes:

• Keeping and maintaining an inventory of any bespoke or custom software you use
• Using web application firewalls to detect and prevent web-based attacks
• Managing scripts loaded and executed on the payment page of the customer’s internet browser

Requirement 6.4.3 

Requirement 6.4.3 mandates that merchants maintain an inventory of every script executing on their payment pages, authorize each one, and protect the integrity of all of them. In v4.0.1, script ownership for embedded payment forms is split: the merchant is responsible for scripts and headers outside the third-party service provider's iframe, and the provider is responsible for those inside it. This is a direct response to the Magecart and web-skimming attack patterns that have caused large-scale card data breaches at retailers. For many merchants, meeting this requirement means deploying a content security policy, a script monitoring solution, or both.

PCI 4.0.1 Requirement 7: Limit who has access to cardholder data

Your business must allow or deny access to payment data based on strict permissions. The basic principle of Requirement 7 is to only allow data access to those who need it – and no one else.

Essentially, it states that cardholder data can only be accessed on a ‘need-to-know’ basis – not by every employee who feels like taking a peek. 

What’s more, you need an ongoing account and access review process, so you should evaluate (and, if necessary, update) user roles and permissions every six months, and grant access only on a ‘least privilege’ basis. This ensures that users with access to cardholder data have only the minimum amount of access required to do their job, and no more. Of course, you must document who has access to what, as well.

PCI 4.0.1 Requirement 8: Identify and authenticate users

The eighth PCI 4.0.1 stipulation requires strong, unique passwords and usernames to access data systems. This serves a dual purpose: safeguarding this data from external hackers, while making it possible to trace any activity back to the user who accessed it – knowledge which is vital for the audit trail in the case of a breach.

Passwords must be a minimum of 12 characters, including letters and numbers, and, where a password is the only authentication factor, must be changed at least once every 90 days or be subject to dynamic analysis of the account's security posture. Usernames should also be difficult to guess, i.e. do not use the administrator’s name or the company’s name. 

Organizations must implement multi-factor authentication for all users with access to cardholder data – not just administrators. PCI 4.0.1 also requires MFA systems to be attack-resistant, and for businesses to maintain strict control over administrative overrides. This does not apply to accounts that authenticate exclusively using phishing-resistant factors.

PCI 4.0.1 Requirement 9: Restrict physical access to cardholder data

PCI 4.0.1 compliance requires you to manage access to cardholder data not only on a digital basis, but on a physical one – preventing unauthorized access to paper files, work stations, or servers that store or transmit sensitive information. You can do this through an access control system in your building, and by ensuring sufficient CCTV coverage of key areas.

As part of this, you need to maintain documentation about who can access hardware that stores sensitive data, how and where devices storing sensitive data are used, as well as having a clear procedure for what happens when an employee’s access requirements need to change (because they leave the company or move to another team).

PCI 4.0.1 Requirement 10: Log and monitor all system access

The tenth Requirement requires you to log your network resources and cardholder data: keeping accurate records of each time someone at your organization accesses this information. This should raise an alert each time suspicious activity is suspected, such as an unauthorized access attempt.

Doing this properly also helps you maintain accurate documentation around sensitive data: including why and how it’s being handled, and where it’s being stored and sent to.

Under PCI 4.0.1, organizations must:

• Conduct automated log reviews (this can be done with software).
• Review log alerts daily, to quickly identify and investigate suspicious incidents.
• Detect and alert security personnel for critical control system failures, such as a loss of network connectivity, and promptly manage these failures when they occur.

PCI 4.0.1 Requirement 11: Test the security of your systems and networks regularly

Regularly testing your security systems and networks is vital. Recommended techniques include vulnerability scanning (internal and external) and penetration testing – note you should budget for potentially considerable investment, here. Larger organizations should allow for several weeks to complete penetration testing.

You’ll also need to conduct regular wireless analyzer scanning – typically on a quarterly basis – and to have a PCI-Approved Scanning Vendor (ASV) to conduct checks on your external IPs and domains. On top of identifying these vulnerabilities or leaks in your existing security setup, you’ll also be responsible for addressing them. This will help ensure your systems stay secure – and that you’re doing your bit to protect your customers’ data.

Requirement 11.6.1

Requirement 11.6.1 requires a mechanism that detects unauthorized changes to HTTP headers and payment page content, with checks running at least every seven days. Again, this is a web-skimming countermeasure, and it requires either a dedicated monitoring product or a well-engineered custom solution.

Following the revised SAQ A for v4.0.1 (published 30 January 2025, effective from 31 March 2025), Requirements 6.4.3 and 11.6.1 were removed from SAQ A, along with the Requirement 12.3.1 targeted risk analysis, and replaced with an eligibility criterion under which the merchant confirms that its site is not susceptible to script-based attacks. Requirement 11.6.1 still applies to SAQ A-EP, SAQ D for Merchants, SAQ D for Service Providers, and to onsite assessments validated by an Attestation of Compliance.

PCI 4.0.1 Requirement 12: Upkeep policies and documentation

The final PCI 4.0.1 Requirement calls for your organization to develop and maintain a comprehensive information security (infosec) policy. Review this at least once every 12 months and update it as needed. You should encourage buy-in from employees, management, and any third parties it’ll be relevant to.

Training your staff is extremely important: you should create a security awareness program to ensure your team knows how to detect, react to, and report potential cyber attacks. You’ll also need to shore up your incident response procedures to make sure your team can react quickly and correctly in case of PAN exposure. Note that you’ll also need to train your team on social engineering and phishing awareness, annually.

You’ll also need to keep a list of all third-party service providers, and document a procedure for monitoring the PCI compliance of each one.

What happens if you are not compliant with PCI DSS?

Your business can face severe consequences for non-compliance, such as:

• Heavy financial penalties (high processing fees and fines)
• Card brands will not accept payment requests from your business
• Blacklisting by payment services providers
• Increased payment fraud, which you are financially liable for
• Auditing and investigation costs in the event of a data breach
• You will likely fall short of data protection regulations and local laws, with further consequences

Although PCI DSS 4.0.1 is not a legal requirement, the cost of non-compliance is so great that it may as well be. It’s fair to say that failure to meet the appropriate PCI DSS certification could bring your business to an end.

That said, there is plenty of help and support for all businesses to keep compliant and protect their customers’ data. For more help and support on PCI DSS compliance, contact SecurityMetrics.