PCI DSS 4.0.1: Are Your Future-Dated Requirements Covered?

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard. It applies to organisations that store, process or transmit cardholder data. When version 4 was introduced, many new requirements were marked as future-dated, giving organisations time to prepare. Those future-dated requirements became mandatory on 31 March 2025.

That date has passed. The question now is not whether the requirements apply, but whether your programme has actually caught up. This guide offers a practical self-check in general terms. Use it to prepare for a conversation with your assessor, not as a replacement for the standard itself.

1. What the future-dated requirements were about

The future-dated requirements were not a single theme. They touched many parts of the standard. In general terms, they pushed organisations towards stronger authentication, better protection of payment pages, more risk-based decisions and more regular, documented reviews.

Some asked for wider use of multi-factor authentication. Some focused on managing the scripts that run on payment pages, an area attackers have targeted. Others introduced targeted risk analyses, where an organisation decides how often to perform certain activities based on its own risk, and records the reasoning. Several asked for clearer roles, documentation and periodic reviews.

It also helps to remember why these requirements exist. Attacks on card data have moved towards payment web pages, stolen credentials and weak spots in third-party code. The future-dated requirements respond to those patterns, so meeting them well lowers real risk, not just audit risk.

The exact list and wording sit in the standard. Read the requirements that apply to your environment and your validation method, because the details matter for your assessment.

2. A practical self-check

Work through the questions below with the people who run your cardholder data environment. Honest answers show where to focus.

• Do you know your scope? Can you show an up-to-date picture of where cardholder data flows and which systems are in scope?
• Is multi-factor authentication where it needs to be? Check that it covers the access the standard now expects, not only remote access.
• Are payment page scripts managed? Do you know which scripts run on your payment pages, who approved them and how changes are detected?
• Are targeted risk analyses documented? Where the standard lets you set the frequency of an activity, have you recorded how you decided?
• Do reviews actually happen? Are periodic reviews of access, configurations and other controls carried out and recorded?
• Are roles and responsibilities clear? Does each requirement have an owner who knows what is expected?
• Is evidence ready? Could you show your assessor records from across the year, not just from the week before?

If several answers are "not sure", that is useful information. It tells you where to look before your next assessment.

3. Closing the gaps

Start by confirming scope. Many PCI DSS programmes become easier when scope is reduced. Segmentation, tokenisation and outsourcing card handling to a compliant provider can reduce how much of your environment is in scope. Less scope means fewer systems to secure and fewer controls to evidence.

Next, prioritise the gaps by risk. Payment page script management and authentication often deserve early attention, because they address real attack paths. Documentation gaps, such as missing targeted risk analyses, are usually quicker to close once the decisions are made.

Assign owners and dates, and track progress in a simple register. Each gap should have a clear action, an owner and a target date. Review the register regularly with the people involved.

Talk to your assessor early. A Qualified Security Assessor or your acquiring bank can clarify how they interpret requirements in your situation. A short conversation before the assessment avoids surprises during it.

Service providers deserve a look as well. If a third party handles card data for you, or can affect its security, check what their own assessment covers and how responsibilities are split between you. A clear responsibility matrix avoids gaps where each side assumes the other is in charge.

Finally, keep the programme running between assessments. PCI DSS expects controls to operate all year. Build reviews and evidence collection into normal work, so that each assessment confirms what you already know.

If your environment includes web applications or APIs that handle payments, regular testing helps too. Our VAPT services cover that side. For help with the self-check and a plan to close any gaps, our PCI DSS team would be happy to talk.