Complying with PCI DSS requirements by 2025

Version 4.0.1 of the Payment Card Industry Data Security Standard (PCI DSS), which came into effect back in April, incorporates a few important changes to make it fit for the modern digital world, addressing how technologies, the threat landscape and payment processes have changed.

For example, it includes a new customized approach for a more flexible and tailored implementation of security controls, through to a new focus on vulnerability management and authentication.

However, some of the requirements will force entities to make substantial changes. Due to their complexity, cost, and potential impact, these requirements have been given an extended implementation timeline. Many require specialized expertise and potentially significant technological investments.

There are 64 requirements in all: 13 are now in effect and mandatory, but the remaining (51) won’t come into effect until 1 April 2025. Until then, they are classified as best practice requirements.

Below, we consider some notable examples of these complex future-dated requirements that organizations need to carefully evaluate and plan for.

Encryption and MFA

An important change is the requirement to replace disk-level or partition-level encryption with another protection mechanism (3.5.1.2).

This states that these encryption methods should only be used to render the Primary Account Number (PAN) unreadable on removable electronic media or, if used for non-removable electronic media, the PAN should also be rendered unreadable via a mechanism that meets Requirement 3.5.1.

The requirement stems from the fact that disk-level or partition-level encryption, as opposed to file-, column-, or field-level database encryption, is only an effective way to encrypt PAN when systems are powered down. When the system is running, the data on the disk is accessible to anyone with system level access, thus not meeting the requirements for granular, need-to-know, or the default-deny-all principles of PCI DSS. This will require substantial changes to be made to the way encryption is applied within these contexts.

Another new requirement is for the secure implementation of multi- factor authentication (MFA systems (8.5.1). Under PCI DSS version 3.2.1, MFA was only used selectively, such as for remote network access from outside the network or for non-console administrative access into the cardholder environment (CDE).

However, version 4.0 changes that, making MFA applicable in numerous other contexts. It must be used to secure all access to the CDE (not just by administrators) and may be required multiple times, for example, so it could be required once to connect remotely via a VPN into the organization’s network and then again into the CDE or CDE systems and applications, necessitating at least two uses of MFA.

This also means that MFA will need to be implemented in more places, such as across the cloud, on prem, security devices and endpoints, as well as on any mechanisms that seek to provide direct access to the entity’s CDE (including but not limited to network components, systems and applications). Consequently, implementing MFA will likely be onerous for many entities.

Automating detection and response

Implementing automated audit log reviews (10.4.1.1) is another new requirement that aims to allow the entity to review audit logs for events that are suspicious or malicious. To comply, entities will need to look at their current capabilities with respect to log management and analysis and the generation of and response to alerts. While a logging solution such as a SIEM may already be in place, the entity could, for instance, need to expand its capabilities to handle higher log volumes, thus necessitating the addition of more tools and technologies or the outsourcing of this function.

The ability to detect, alert and promptly respond to failures in critical security control systems (10.7.2) will also necessitate the implementation of automated detection and response mechanisms.

Critical security control systems is an extensive term that refers to network security controls (a deliberately far broader term than “firewalls”), IDS/IPS, change detection mechanisms, anti-malware solutions, physical access controls, logical access controls, audit logging mechanisms, segmentation controls, audit log review mechanisms and automated security testing tools. Applicable only to service providers under v3.2.1, from next April it will also apply to merchants, bringing them in scope for the first time.

Another new requirement is to perform authenticated internal vulnerability scans (11.3.1.2). Authenticated scanning sees the scan log-on to systems using account credentials, enabling the scan to gain access to internal resources and detect vulnerabilities across these.

Unlike unauthenticated scanning, it does not rely on ports being open nor is it limited to just scanning the network. It’s therefore much more thorough but entities can expect the number of vulnerabilities they detect and the need to remediate to increase, putting pressure on resources. Systems that cannot accept credentials for scanning will also need to be documented.

Addressing web-based skimming

Perhaps one of the most significant changes in terms of preventing e-commerce fraud is the requirement to deploy change-and-tamper-detection mechanisms to alert for unauthorized modifications to the HTTP headers and the contents of payment pages as received by the consumer browser (11.6.1).

Most e-commerce-related cardholder data (CHD) theft comes from the abuse of JavaScript used within online stores (otherwise known as web-based skimming). Recent research has shown that most website payment pages have 100 different scripts, some of which come from the merchant itself and some from third parties, and any one of these scripts can potentially be altered to harvest cardholder data. Equally, this could be the payment page of a payment service provider (PSP) which a merchant redirects to, or uses a PSP generated inline frame (iframe), making this an issue that is also relevant to PSPs.

The ideal scenario is to reduce this risk by knowing what is in use, what is authorized and has not been altered, which is the principle aim of requirement 6.4.3. This mandates the inventory of scripts, their authorization, evidence that they are necessary and have been validated. But even then, the merchant payment pages whose scripts redirect to or invoke the payment service provider’s iframe can be compromised when an authorized script is illegally modified – which is where 11.6.1 comes in.

The new requirement means it’s no longer possible for entities to delegate the problem away by using a payment service provider to move the payment form into an iframe or redirect to the PSP. Delegating the problem fails because by compromising the merchant’s payment pages that invoke the iframe or redirect scripts, criminals can harvest CHD, even when a compliant and validated PSP is used by the merchant.

Issues such as iframe overlay and iframe hijacking have revealed the problem behind this approach, effectively allowing an attacker to exfiltrate payment account information. Therefore, under 11.6.1, the requirement demands a change and tamper detection mechanism must be deployed to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.

The mechanism should be configured to evaluate the received HTTP header/s and payment page scripts (not just third-party but also in-house created scripts) and these functions should be performed periodically, but no less than every seven days.

Where to begin to reduce complexity

Each of these requirements makes substantial demands upon the entity and will require significant changes to be made in terms of people, processes and technologies.

Assessing and deploying these controls will take time, which means entities must not delay until nearer the deadline of 1 April 2025. Where should they start? Some might suggest with a gap analysis of PCI DSS 4.0.1 against version 3.2.1, however, this is in fact one of the last stages the business should take. A far more effective approach is to perform a scope analysis first.

A scope analysis and review should be used to check the perimeter within the entity to verify whether the current scope is accurately documented and whether it can be further optimized and reduced.

Questions that should be asked include:

• Can I further reduce my PCI DSS scope, especially considering all the new requirements?
• Do I really need all the cardholder data I process, transmit or store?
• Can I redesign my CDE to reduce the people, processes and technology that are in scope?
• Can I leverage technologies such as tokenization, hashing, point-to-point encryption, etc. to reduce my and scope?
• Does it make sense to outsource non-core business processes, activities and technologies to specialized service providers?

It’s also advisable to look at any common ground PCI DSS 4.0 shares with standards the entity is already complying with, such as ISO 27001, DORA, and GDPR, all of which have overlapping requirements.

Security controls that fulfil the requirements of multiple standards, for example, access control, encryption, logging, and monitoring, are common requirements across these frameworks. By aligning these overlapping areas, it’s possible to avoid duplicating efforts and reduce the resources required for compliance. Streamlining processes and reducing redundancy can also lead to cost savings in terms of manpower, technology investment, and audit preparation.

Where possible, it’s therefore advisable to coordinate audits and assessments to cover multiple frameworks at once. To help facilitate this, integrate technology solutions and consider how technology solutions will support compliance with multiple standards when looking to invest. From a people perspective, develop a single training and awareness program that covers the essential elements of all applicable standards.

Only after this should the entity conduct a gap analysis and then remediate based on those findings. As mentioned, time is of the essence, so it’s important that the gap assessment is carried out in sufficient time before the audit.

Choosing the right path to compliance

The new requirements under PCI DSS 4.0.1, such as the authenticated scans, automated log reviews, and SAD encryption, will vary in terms of their demands and complexity from entity to entity, as will the time and resources required. Whether a company is undergoing certification for first time or is already certified under a previous version of the standard, they should seek to meet the standard well in advance of the April 2025 deadline to avoid any surprises.

Entities must critically assess whether these technical security requirements align with their core business activities and internal capabilities. For many, particularly smaller or non-tech-focused entities, outsourcing these complex security measures to specialized service providers might be a more efficient and effective approach.

Such a decision should seek to achieve a balance between the activities, processes and requirements to be outsourced, versus those to be kept in-house, considering factors such as internal expertise, budget constraints, and the organisation’s overall risk management strategy. The entity can then make the right choice for the business that ensures it is able to meet the requirements on a continuous basis.