2 Big PCI 4.0 Requirements You Need to Understand Before the Deadline

If you haven’t moved to PCI DSS 4.0 yet, it’s time to start the transition. Time is quickly slipping by, and you’ll need to be up and running with version 4.0 by the end of March.

It won’t be easy to get your arms around PCI 4.0 — there are a lot of new requirements and significant changes to old requirements, and they can be confusing. Let’s take a look at two of those requirements and break them down for you.

Get TCT’s complete guide to PCI DSS Certification

Payment Page Scripts — Requirement 6.4.3

If you outsource your online payments to a third party payment processor, you have a new requirement to adhere to. PCI DSS 4.0 now requires that you verify your page scripts.

What are the payment page script requirements in PCI DSS 4.0?

According to PCI 4.0, payment page scripts that are loaded and executed in a web browser must have methods to verify that the scripts are authorized and that you’ve ensured the integrity of each script. You must also maintain an inventory of any scripts you have, and provide justification about why each script is necessary.

An example of this requirement would be if your website passes customers along to a third party page for payment processing.

To initiate this kind of process, when your customers go to pay, your platform instructs the user’s web browser to pull up the payment page from your chosen third party site. That third party runs the payment processing and then redirects the customer back to your website once the transaction is complete.

In PCI 4.0, your ecommerce platform must have a way to confirm that the scripts are authorized and that the integrity of the scripts has been verified.

In other words, you need to be able to verify that your platform intended to send customers to that specific third party page, and that the users were successfully sent to the correct page. If for some reason either of those checks fails, it is inferred that you need some form of appropriate response action — such as a redirect back to your platform or a pop-up warning message is displayed.

Why this requirement exists

The purpose of this new requirement is to protect from the bad actor that redirects or hijacks the payment process, sending your customer to their own unauthorized lookalike site.

This kind of scheme allows bad actors to collect a slew of credit card information. The customer is none the wiser, enters all of their credit card information, and passes it to the bad guy. The payment is submitted to the credit card company as normal and the customer has no idea their information was stolen until they start to see unauthorized purchases on their account.

In addition, PCI requires an inventory of the scripts that are called for the third party processing. Maintain an accurate list of the scripts that are called, with a suitable justification for each script that explains why it’s necessary.

How to meet this PCI requirement

PCI DSS doesn’t prescribe a specific tool or process for validation, but it generally involves using an encrypted two-way communication between your system and the user’s browser — a handshake that confirms that the customer was sent to, and arrived at, the right destination.

To meet this requirement, leverage your PCI Consultant or Assessor to walk you through acceptable options. Anything you choose to do will need to pass muster with your Assessor, so be sure to work with them as you figure out how to implement this PCI requirement.

If you don’t have an Assessor or a Consultant who can help you with this requirement, TCT can provide you with some directional guidance.

Shouldn’t your payment vendor be the responsible party?

It’s your responsibility to adhere to PCI requirements, but you certainly ought to work with the vendor to agree on the details of mutual responsibilities. You should also ask them about code snippets that you’ll need to implement on your end. Every vendor is different, so it’s important to collaborate with them for a successful approach.

Even if you already have payment page script verification, you may need to make changes to comply with the new PCI requirement.

Web Application Firewall — Requirement 6.4.2

This requirement isn’t a new one, but a modification of an existing requirement. I’m mentioning it here, because it will be a big deal for some organizations.

It is important to keep in mind that this approach is not mandated until 3/31/2025. However, as you’re about to see, it will take some time to get this one in place. I am continually attempting to get organizations to take this one seriously in enough time to appropriately get it implemented in advance of the deadline.

PCI 4.0 requires that you implement an automated technical solution that continually detects and prevents web-based attacks. This is known as a web application firewall (WAF).

Until 3/31/2025, you could choose to do a manual code review or an automated code review, or you could leverage a WAF. In version 4.0, a WAF is mandatory as of 3/31/2025.

If you weren’t already implementing a WAF under PCI DSS 3.2.1, you’ll need to start planning an update to your approach.

Related: Your Approach to PCI Compliance Could Put You Out of Business

What is a web application firewall?

A web application firewall is a system that sits in front of a web application and reviews the incoming traffic. The WAF allows expected traffic to pass through to the application and blocks suspicious traffic. The system also generates logs and alerts personnel of key events.

A WAF can operate in three different modes:

Training mode

In this mode, the WAF observes all of the traffic that enters your web-based system. It collects information so that it can learn how to identify expected web traffic. For example, a user enters their username and password, then clicks on the login button. Once they’re in your environment, there are typical expected behaviors — they might click on their dashboard or update their account settings.

The WAF will also observe and collect information on any attempts to break into your web server.

When training the WAF, you’ll typically leave it on for several months so it can collect plenty of data about all kinds of user behaviors. Eventually, you’ll look at the information it collected and designate the expected versus unexpected traffic.

Warning mode

After training the WAF, switch to Warning mode. In Warning mode, the WAF sends an alert any time it observes what it thinks is unexpected behavior. When you receive a warning, review it and either confirm it or correct your WAF ruleset as appropriate. Once the WAF is alerting appropriately all of the time, switch to Blocking mode.

Blocking mode

In this mode, the WAF is trained well enough that it can independently block any traffic that is unexpected behavior. This is where you want your WAF to be under normal operations, because you want to block nefarious traffic before it has the chance to hit your website.

Important WAF tips!

It’s crucial to ensure that you exercise all of the functionality of the site during Training mode. Otherwise, when the WAF eventually enters Blocking mode, you’ll have legitimate traffic that gets blocked. When you enter Training mode, do a full regression test of the entire application — all features, all functions.

Don’t forget about things that are rarely used, or used on a configurable basis for some users. For example, don’t forget your web-based API that’s only used by a handful of clients or a configurable element of functionality that’s only turned on for a handful of clients.

When you update your application with new functionality or new pages, you’ll need to update the WAF’s ruleset. Anytime you do a functional release, back your WAF to Warning mode and run through a full regression test until you’ve captured all the traffic patterns from the new functionality before turning it back to Blocking mode.

Related: How to Train Your Organization to Follow PCI DSS

Don’t Wait to Implement These PCI DSS Requirements

Both of these PCI requirements must be implemented by March 31, 2025. That sounds like you have plenty of time, but each one of them can’t simply be flipped on. Remember that it takes several months to train your WAF, and several more months to get through Warning mode.

Likewise, you will need time to implement and appropriately validate Requirement 6.4.3 as appropriately implemented.

Plan wisely, and make sure you give yourself plenty of time to meet the PCI deadlines. The last thing you want is to tell your customers that you’ve lost PCI compliance because you weren’t proactive.