PCI DSS v4.0 & v4.0.1: Everything That Changed and What You Must Do by 2026

PCI DSS v4.0 is now fully in effect and as of March 31, 2025, every requirement is mandatory. The 51 "future-dated" requirements that were optional best practices when v4.0 was first published in March 2022 are now enforceable across all PCI DSS assessments.

If your organisation is still operating as if PCI DSS v3.2.1 requirements are sufficient, you are non-compliant. If you validated compliance under PCI DSS v4.0 in 2024 but treated the future-dated requirements as optional, your next assessment in 2026 will fail unless you have implemented those controls.

This guide explains exactly what changed between PCI DSS v3.2.1 and v4.0, what the minor v4.0.1 update clarified, which of the 64 new or updated requirements are now mandatory, and how to verify that your environment meets the current standard in 2026.

1. The PCI DSS v4.0 Timeline: What Happened and When
2. The Core Shift: From Checkbox Compliance to Continuous Security
3. PCI DSS v4.0.1 — What Actually Changed (Spoiler: Almost Nothing)
4. The 64 New or Updated Requirements (Categorised by Impact)
5. The 51 Future-Dated Requirements That Became Mandatory on March 31, 2025
6. The New E-Commerce Skimming Requirements (6.4.3, 11.6.1) — Biggest Impact
7. Expanded MFA Requirements — Everyone in the CDE, Not Just Admins
8. The Customised Approach — What It Is and Who Should Use It
9. Penetration Testing Changes (Requirement 11.4)
10. What to Do Next: Verifying Your Environment Is v4.0.1 Compliant

The PCI DSS v4.0 Timeline: What Happened and When

PCI DSS v4.0 was published in March 2022 as the first major update to the standard in over a decade. The PCI Security Standards Council (PCI SSC) provided a multi-year transition period to allow organisations to understand the new requirements, assess their impact, and implement the necessary controls.

Here is the complete timeline:

March 2022 — PCI DSS v4.0 published. It introduced 64 new or updated requirements, 51 of which were designated as "future-dated" (best practices until March 31, 2025) and 13 of which became effective immediately.

March 31, 2024 — PCI DSS v3.2.1 officially retired. From this date forward, all assessments and validations must be conducted against PCI DSS v4.0 or v4.0.1. Organisations could no longer validate compliance using the v3.2.1 standard.

June 2024 — PCI DSS v4.0.1 published as a limited revision to v4.0. This update corrected typographical and formatting errors, clarified the intent and applicability of certain requirements, and improved guidance. Crucially, v4.0.1 introduced no new requirements and no deleted requirements. It was purely a clarification release.

December 31, 2024 — PCI DSS v4.0 retired. After this date, PCI DSS v4.0.1 became the only active version of the standard supported by the PCI SSC.

March 31, 2025 — The 51 future-dated requirements from PCI DSS v4.0 became mandatory. From this point forward, all 64 new or updated requirements must be validated during PCI DSS assessments.

2026 and beyond — All assessments conducted in 2026 are against PCI DSS v4.0.1, and every requirement is in scope. The transition period has ended.

The Core Shift: From Checkbox Compliance to Continuous Security

The most significant change in PCI DSS v4.0 is not a single requirement it is a shift in philosophy. PCI DSS v3.2.1 was often implemented as an annual compliance event: organisations would conduct assessments, remediate findings, submit their Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ), and then return to business as usual until the next assessment cycle.

PCI DSS v4.0 explicitly rejects this model. The standard now emphasises security as a continuous, business-as-usual process not a yearly obligation.

This shift is operationalised through several mechanisms:

Continuous monitoring requirements — The standard now requires automated detection of security control failures, continuous log review mechanisms, and real-time alerting rather than periodic reviews.

Roles and responsibilities documentation — Many requirements now include an explicit obligation to document and assign roles and responsibilities for security functions. This is designed to embed security accountability into the organisational structure, not leave it as an IT department task.

Targeted Risk Analysis (TRA) — For certain requirements that provide flexibility in how frequently a control is performed, organisations must now conduct a formal Targeted Risk Analysis to justify the frequency. This replaces the previous implicit assumption that annual was sufficient.

Evidence accumulation over time — The standard expects organisations to demonstrate that controls are operating consistently throughout the year, not just at the moment of assessment. This is assessed through continuous evidence such as logs, change records, access review outputs, and incident response testing.

The result: organisations that approach PCI DSS v4.0 as a checklist to be completed once a year will struggle to demonstrate compliance during assessments. The standard now expects that security is embedded into day-to-day operations and can be demonstrated as an ongoing practice.

PCI DSS v4.0.1 — What Actually Changed (Spoiler: Almost Nothing)

When PCI DSS v4.0.1 was published in June 2024, it caused confusion in the market. Many organisations assumed it was a new version with additional requirements and began planning for another compliance uplift.

It was not. PCI DSS v4.0.1 is a limited revision with zero new requirements and zero deleted requirements. The PCI SSC's own FAQ explicitly states: "There are no new or deleted requirements in this revision."

So what changed?

Typographical and formatting corrections — Minor errors in v4.0 were corrected.

Improved alignment with supporting documentation — The language in the standard was aligned with other PCI SSC publications such as the Quick Reference Guide, FAQs, and Glossary.

Clarification of ambiguous language — Several requirements that had been subject to interpretation by assessors were reworded for clarity.

The most significant clarifications in v4.0.1 include:

Requirement 3 — Storage of Sensitive Authentication Data (SAD) — Clarified applicability for issuers and companies that support issuing services. Added guidance on the use of keyed cryptographic hashes to render Primary Account Numbers (PAN) unreadable.

Requirement 6.2.4 — Critical Vulnerabilities — Reverted to PCI DSS v3.2.1 language specifying that the requirement to install patches/updates within 30 days applies only to "critical vulnerabilities," not all high-severity patches. This reduced the burden on organisations that were interpreting v4.0 as requiring 30-day patching for all high-risk findings.

Requirement 6.4.3 — Payment Page Scripts — Added Applicability Notes to clarify how the requirement for managing payment page scripts applies, particularly for merchants using third-party payment service providers (PSPs) with embedded iframes.

Requirement 8.4.2 — Multi-Factor Authentication (MFA) — Added an Applicability Note clarifying that MFA for all (non-console) access into the CDE does not apply to user accounts that are authenticated only with phishing-resistant authentication factors (such as FIDO2/WebAuthn hardware tokens). This was one of the most requested clarifications from the market.

Requirement 12.8.4 — Third-Party Service Provider (TPSP) Relationships — Updated and clarified Applicability Notes regarding relationships between customers and TPSPs, including which party is responsible for which aspects of compliance when using hosted payment pages or embedded iframes.

New Definitions in Appendix G — Added definitions for "Legal Exception," "Phishing Resistant Authentication," and "Visitor" to reduce ambiguity.

Critical point: The March 31, 2025 deadline for future-dated requirements was not affected by v4.0.1. Those requirements became mandatory on schedule, and v4.0.1 did not introduce any delay.

The 64 New or Updated Requirements (Categorised by Impact)

PCI DSS v4.0 introduced 64 new or updated requirements compared to v3.2.1. These fall into three categories based on when they became effective and the level of implementation effort required.

Category 1: Immediately Effective (Effective from First v4.0 Assessment)

Thirteen requirements became effective as soon as organisations began validating against PCI DSS v4.0. These were considered foundational changes that could be implemented quickly. Most involve documentation, governance, and formalising existing practices.

Requirement 3.3.1.3 — Disk-level or partition-level encryption no longer qualifies as an acceptable method to render PAN unreadable (except for removable electronic media). File-level, column-level, or field-level encryption is now required.

Requirement 12.3.1 — Perform a Targeted Risk Analysis (TRA) for each PCI DSS requirement where the organisation has flexibility in how frequently the requirement is performed (such as log review frequency, vulnerability scan frequency, or penetration testing triggers). The TRA must be documented and approved annually.

Requirement 12.5.2 — Conduct an annual scoping exercise to confirm the systems, people, and processes that are in scope for PCI DSS. This was previously guidance but is now a mandatory, documented requirement.

Requirement 12.5.2.1 — Service providers must perform the scoping exercise at least every six months (rather than annually) and after any significant change to the organisational structure, technology, or business objectives.

Requirement 6.3.3 — Bespoke and custom software must be reviewed prior to release to production to ensure it is developed in accordance with PCI DSS requirements.

Requirements 1.2.5, 1.2.6, 1.2.7, 1.2.8 — Network security controls (firewalls and other boundary protections) must be reviewed at least every six months to ensure configurations remain appropriate.

Requirement 8.3.6 — User accounts that have been inactive for 90 days must be removed or disabled.

Category 2: Future-Dated Requirements (Became Mandatory March 31, 2025)

Fifty-one requirements were designated as future-dated when v4.0 was published, giving organisations three years to implement them. All of these became mandatory on March 31, 2025.

These requirements address modern threat vectors, improve authentication and access controls, strengthen vulnerability management, and enhance logging and monitoring capabilities. The full list is provided in the next section.

Category 3: Minor Updates and Clarifications

The remaining changes were updates to existing requirements rewording for clarity, reorganisation of sub-requirements, or expansions of applicability. These did not introduce entirely new controls but clarified expectations or extended existing controls to additional scenarios.

For example, several requirements now explicitly state that roles and responsibilities must be documented and assigned. This was always an expectation under v3.2.1, but v4.0 makes it explicit and testable.

The 51 Future-Dated Requirements That Became Mandatory on March 31, 2025

Below is a categorised list of the 51 future-dated requirements from PCI DSS v4.0 that were best practices until March 31, 2025 and are now mandatory for all assessments conducted in 2026.

These are not listed in numerical order they are grouped by the domain or control family they impact, so organisations can assess implementation gaps by area.

Authentication and Access Control

Requirement 8.3.1 — All user access to system components must use multi-factor authentication (MFA). Previously, MFA was required only for administrative access and remote access. Under v4.0, MFA is required for all access into the Cardholder Data Environment (CDE), including non-administrative users.

Requirement 8.3.10.1 — User accounts that are authenticated with phishing-resistant authentication factors (such as FIDO2/WebAuthn hardware tokens or certificate-based authentication) do not require MFA as an additional layer, because the phishing-resistant factor satisfies the intent of MFA.

Requirement 8.3.11 — Service providers supporting customer user accounts (such as hosted payment gateways or SaaS platforms) must ensure that customers change their passwords at least once every 90 days if passwords are the only authentication factor (i.e., MFA is not used).

Requirement 8.4.2 — MFA must be used for all access into the CDE, not just for remote access or privileged users.

Requirement 8.4.3 — MFA systems themselves must be secured and configured to prevent bypass.

Requirement 8.5.1 — Multi-factor authentication mechanisms must resist replay attacks and man-in-the-middle attacks.

Requirement 8.6.1 — Minimum password length is now 12 characters (previously 7 characters). If systems cannot support 12-character passwords, they must support a minimum of 8 characters until those systems can be upgraded, and this exception must be documented.

Requirement 8.6.2 — Password history must be maintained to prevent reuse of any of the last four passwords.

Requirement 8.6.3 — Passwords must not be changed more than once per day to prevent users from cycling through the password history and returning to their original password.

Vulnerability Management and Patching

Requirement 6.3.2 — Software development practices must include manual code reviews or automated security testing to identify security vulnerabilities.

Requirement 6.3.4 — Accounts used by payment applications to connect to databases must have the minimum privileges required for the application to function.

Requirement 11.3.1.2 — Internal vulnerability scans must be authenticated (credentialed) scans that can detect vulnerabilities only visible when credentials are provided. Previously, unauthenticated scans were acceptable.

Requirement 11.3.1.3 — Internal authenticated vulnerability scans must be performed after any significant infrastructure or application change.

Requirement 11.4.6 — Penetration testing must be performed using both network-layer and application-layer tests.

Requirement 11.4.7 — Penetration testing must cover segmentation and scope-reduction controls to validate that network segmentation is effective in isolating the CDE from out-of-scope systems.

Logging, Monitoring, and Incident Response

Requirement 10.4.1.1 — Automated mechanisms must be implemented to perform log reviews.

Requirement 10.4.2.1 — Automated mechanisms must be used to detect failures of critical security control systems (such as intrusion detection, anti-malware, physical access controls, and segmentation controls).

Requirement 10.4.3 — Failures of critical security controls must be responded to promptly, and the security team must be alerted.

Requirement 10.7.2 — Failure of any critical security control must generate an alert.

Requirement 10.7.3 — Responses to critical security control failures must be performed in a timely manner and in accordance with documented procedures.

E-Commerce Payment Page Security (The Most Impactful Changes for Online Merchants)

Requirement 6.4.3 — All payment page scripts that are loaded and executed in the consumer's browser must be managed. This includes:

• A method to confirm that each script is authorised
• A method to ensure the integrity of each script
• An inventory of all scripts with a business or technical justification for why each is necessary

Requirement 11.6.1 — A change-detection and tamper-detection mechanism must be implemented to alert personnel to unauthorised modifications to the HTTP headers and the contents of payment pages as received by the consumer browser. This mechanism must be evaluated at least once every seven days (weekly).

These two requirements are designed to prevent e-skimming attacks (such as Magecart) where attackers inject malicious JavaScript into payment pages to steal cardholder data as it is entered by the customer. They apply to all e-commerce merchants and service providers that do not qualify for SAQ A (fully outsourced, no control over payment page).

Network Segmentation and Scope Reduction

Requirement 11.4.7 — Penetration testing must validate that segmentation controls are effective. This means testing whether systems outside the CDE can access systems inside the CDE, and whether the segmentation methods (VLANs, firewalls, access controls) are correctly configured and enforced.

Roles and Responsibilities (Applies to Nearly All Requirements)

Many requirements in v4.0 now include an explicit sub-requirement or applicability note stating that roles and responsibilities for that control must be documented and assigned. While this was always an implicit expectation under v3.2.1, v4.0 makes it a formal, testable obligation.

Examples include:

• Requirement 1.2.4: Roles and responsibilities for managing network security controls are documented and assigned
• Requirement 3.3.1: Roles and responsibilities for protecting stored account data are documented and assigned
• Requirement 5.2.2: Roles and responsibilities for anti-malware mechanisms are documented and assigned
• And many more across all 12 requirements

Third-Party Service Provider Management

Requirement 12.8.5 — Information must be maintained about which PCI DSS requirements are managed by each third-party service provider (TPSP) and which are managed by the entity.

Requirement 12.9.2 — TPSPs must support their customers' request for information to meet PCI DSS requirements, including providing evidence of their own PCI DSS compliance.

The New E-Commerce Skimming Requirements (6.4.3, 11.6.1) — Biggest Impact

For e-commerce merchants, the most significant changes in PCI DSS v4.0 are Requirements 6.4.3 and 11.6.1, which address e-skimming attacks (also known as Magecart attacks, web-skimming, or client-side attacks). These attacks involve injecting malicious JavaScript into a merchant's payment page to steal cardholder data as customers enter it.

E-skimming has become one of the most damaging attack vectors in payment security. Unlike server-side breaches where attackers must penetrate network defenses, e-skimming attacks occur entirely in the customer's browser and can steal card data even from merchants with otherwise strong server-side security.

Requirement 6.4.3 — Script Management

All scripts that are loaded and executed in the consumer's browser on pages that accept payment card data must be managed as follows:

1. A method is implemented to confirm that each script is authorised.

This means the merchant must have a documented list of approved scripts, and a process for verifying that only authorised scripts are present on the payment page. Scripts that appear without authorisation must be detected and blocked.

2. A method is implemented to ensure the integrity of each script.

The merchant must verify that scripts have not been tampered with or modified. This is typically achieved through Subresource Integrity (SRI) hashes or content security policies that prevent modified scripts from executing.

3. An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

The merchant must document:

• Which scripts are running on the payment page
• What each script does
• Why each script is necessary for the payment page to function or to support business operations (such as analytics or fraud prevention)

Scripts that cannot be justified must be removed.

This requirement applies to all scripts that run on the payment page including scripts from the merchant's own domain and scripts loaded from third-party domains (such as analytics providers, advertising platforms, or payment gateways).

Critical clarification from v4.0.1: If the merchant uses a third-party payment service provider (PSP) that embeds a payment page in an iframe on the merchant's website, the merchant is responsible only for the scripts on their own page (the parent page), not the scripts running inside the PSP's iframe. The PSP is responsible for securing the iframe content. However, the merchant must verify that the PSP is PCI DSS compliant and meeting this requirement for the iframe.

Requirement 11.6.1 — Change and Tamper Detection

A mechanism must be deployed to detect and alert on unauthorised modifications to the HTTP headers and the contents of payment pages as received by the consumer's browser. This mechanism must be evaluated at least once every seven days (weekly).

This requirement is designed to detect when an attacker has injected malicious code into the payment page. The detection mechanism must monitor:

• HTTP headers sent to the browser (such as Content-Security-Policy headers, which if modified could allow unauthorised scripts to execute)
• The actual content of the payment page as rendered in the browser (the HTML and JavaScript that the customer sees)

The mechanism must alert security or operations personnel if unauthorised changes are detected.

Acceptable methods include:

• File integrity monitoring (FIM) tools that detect changes to static files on the server
• Change-detection mechanisms that compare the current page content to a known-good baseline
• Content Security Policy (CSP) violation reporting, which generates alerts when scripts violate the defined CSP
• Third-party script monitoring services that detect script changes in real time

Critical point: The requirement specifies that detection must cover the content as received by the consumer's browser, not just the files stored on the server. This is because some e-skimming attacks involve injecting malicious code in transit (such as through compromised CDN accounts or man-in-the-middle attacks), which means the server-side files are clean but the customer receives a compromised page.

Who These Requirements Apply To

Requirements 6.4.3 and 11.6.1 apply to:

• All e-commerce merchants validating compliance using SAQ A-EP or SAQ D (i.e., merchants whose websites can impact the security of payment transactions)
• All service providers that operate payment pages on behalf of merchants

They do not apply to merchants using SAQ A (fully outsourced payment processing where the merchant's website only redirects to a hosted payment page and has no control over the payment form). However, as of early 2025, the PCI SSC clarified that SAQ A eligibility criteria are very strict: if the merchant's page can impact the payment transaction in any way (such as by loading JavaScript that runs on the payment form page), SAQ A does not apply.

For a detailed implementation guide to these requirements, see our dedicated article: PCI DSS Requirements 6.4.3 and 11.6.1: Payment Page Script Management Explained (coming soon).

Expanded MFA Requirements — Everyone in the CDE, Not Just Admins

Under PCI DSS v3.2.1, multi-factor authentication (MFA) was required for:

• All remote access into the organisation's network from outside the network
• All administrative access to system components within the CDE

This left a significant gap: non-administrative users who accessed the CDE locally (such as employees working on-site or users connected via VPN) were not required to use MFA unless they had administrative privileges.

PCI DSS v4.0 closes this gap. Requirement 8.4.2 now requires MFA for all access into the CDE, regardless of whether the access is remote or local, and regardless of whether the user has administrative privileges.

This means:

• Employees who log in to CDE systems from office workstations must use MFA
• Service accounts that authenticate to CDE systems must use certificate-based authentication or another MFA-equivalent mechanism
• Third-party vendor access (such as managed service providers connecting to manage infrastructure) must use MFA
• Application-to-application authentication that accesses the CDE must use cryptographic authentication methods

Phishing-Resistant Authentication

Requirement 8.3.10.1 introduces the concept of phishing-resistant authentication. If a user account is authenticated using a phishing-resistant authentication factor (such as FIDO2/WebAuthn hardware security keys or certificate-based authentication), that factor alone satisfies the MFA requirement. No additional second factor is required.

This recognises that phishing-resistant authentication is stronger than traditional MFA methods (such as SMS codes or authenticator apps) because it cannot be phished, intercepted, or replayed.

Examples of phishing-resistant authentication:

• FIDO2/WebAuthn hardware tokens (such as YubiKey)
• Certificate-based authentication using PIV/CAC smartcards
• Public key cryptographic authentication

Examples that are not phishing-resistant:

• SMS-based one-time passwords (OTP)
• Time-based one-time passwords (TOTP) generated by authenticator apps
• Push notification approvals (such as Duo Push)

These methods are still acceptable as second factors for MFA, but they do not qualify as phishing-resistant on their own.

Impact on Organisations

The expanded MFA requirement is one of the most operationally impactful changes in v4.0. Organisations that previously deployed MFA only for remote and administrative access must now extend MFA to:

• All users who access CDE systems, including read-only users
• All service accounts (through certificate-based authentication or API key rotation mechanisms)
• All third-party integrations that access CDE data

For large organisations with hundreds or thousands of users accessing CDE systems, this requires significant planning, user training, and technical deployment effort.

The Customised Approach — What It Is and Who Should Use It

One of the most innovative additions in PCI DSS v4.0 is the Customised Approach, which provides organisations with flexibility to implement alternative controls that achieve the same security objective as the defined requirements, without following the prescriptive steps outlined in the standard.

How the Customised Approach Works

Under v3.2.1, PCI DSS requirements were prescriptive: the standard specified exactly what control must be implemented, and organisations had to implement it as written. If a requirement did not fit their environment, they could use compensating controls, but those were heavily restricted and difficult to justify.

v4.0 introduces two validation approaches for each requirement:

1. Defined Approach — The traditional, prescriptive method. The requirement specifies exactly what must be done, and the organisation implements it as written. This is the default approach and remains the most common validation method.

2. Customised Approach — The organisation implements an alternative control that achieves the same security objective as the defined requirement, and demonstrates through a Targeted Risk Analysis (TRA) that the alternative control meets the intent of the requirement.

When to Use the Customised Approach

The Customised Approach is not a shortcut. It requires significantly more documentation, risk analysis, and QSA review effort than the Defined Approach. It is designed for mature organisations with advanced security programmes that have already implemented controls that achieve the same or better security outcomes as the PCI DSS requirements, but in a different way.

Examples of appropriate Customised Approach use cases:

• An organisation that uses automated configuration management (Infrastructure as Code) to enforce firewall rules and network segmentation, rather than manually reviewing firewall rules every six months
• An organisation that uses continuous behaviour-based anomaly detection instead of static rule-based log review
• An organisation that uses cryptographic key management systems and automated key rotation that exceeds the security objectives of the Defined Approach encryption requirements

The Customised Approach is not appropriate for:

• Avoiding requirements that are difficult to implement
• Reducing the scope of controls because they are expensive
• Replacing technical controls with procedural controls that do not achieve the same security outcome

Documentation Requirements

Using the Customised Approach requires:

• A documented Customised Approach Objective for each requirement where the approach is used
• A Targeted Risk Analysis (TRA) that demonstrates the alternative control achieves the security objective
• Evidence that the alternative control is operating effectively
• QSA review and validation during the ROC assessment (the Customised Approach cannot be used in Self-Assessment Questionnaires)

Most organisations will continue to use the Defined Approach for the majority of requirements and may use the Customised Approach for a small number of requirements where they have implemented advanced controls that go beyond what the standard prescribes.

Penetration Testing Changes (Requirement 11.4)

Penetration testing has always been a core requirement in PCI DSS, but v4.0 introduces several important updates to Requirement 11.4 that clarify scope, methodology, and evidence expectations.

Requirement 11.4.6 — Network-Layer and Application-Layer Testing

Penetration testing must include both network-layer testing and application-layer testing. This was always implied under v3.2.1, but many organisations interpreted penetration testing narrowly as network vulnerability scanning.

Network-layer testing covers:

• External perimeter testing (firewalls, routers, VPNs, internet-facing infrastructure)
• Internal network segmentation and lateral movement testing
• Privilege escalation and exploitation of network services

Application-layer testing covers:

• Web applications that process, store, or transmit cardholder data
• APIs that interact with payment data
• Mobile applications (if applicable)
• Custom applications and business logic vulnerabilities

Both layers must be tested during the annual penetration test.

Requirement 11.4.7 — Segmentation Testing

If network segmentation is used to reduce PCI DSS scope (i.e., the organisation claims that certain systems are out of scope because they are segmented from the CDE), penetration testing must include segmentation validation testing to confirm that the segmentation controls are effective.

This means testing whether:

• Systems in the out-of-scope network can access systems in the CDE
• The segmentation method (firewall rules, VLANs, access control lists) is correctly configured
• There are any unintended network paths that bypass the segmentation

Segmentation testing is one of the most commonly failed aspects of PCI DSS penetration testing, because organisations often assume segmentation is effective without validating it.

Authenticated vs. Unauthenticated Testing

Penetration tests must include both:

• Unauthenticated testing (testing from the perspective of an external attacker with no credentials)
• Authenticated testing (testing from the perspective of an insider or an attacker who has compromised credentials)

This ensures that the test covers both external attack vectors and insider threat scenarios.

When Penetration Testing Must Be Conducted

Penetration testing is required:

• Annually (at least once every 12 months)
• After any significant infrastructure or application change, such as:
  • New system components added to the CDE
  • Network topology changes
  • Upgrades to web applications or APIs
  • Cloud migrations
  • Firewall rule changes that affect CDE segmentation

The definition of "significant change" is at the organisation's discretion, but the organisation must document what constitutes a significant change and what triggers a new penetration test.

For a complete guide to PCI DSS penetration testing requirements and common pitfalls, see our dedicated article: PCI DSS Penetration Testing Requirements: What Assessors Check (coming soon).

What to Do Next: Verifying Your Environment Is v4.0.1 Compliant

If your organisation last validated PCI DSS compliance under v3.2.1, or if you validated under v4.0 in 2024 but did not implement the future-dated requirements, your next assessment in 2026 will fail unless you remediate the gaps.

Here is the step-by-step process to verify compliance with PCI DSS v4.0.1:

Step 1: Conduct a gap assessment

Compare your current security posture against all 64 new or updated requirements in PCI DSS v4.0/v4.0.1. This includes the 13 immediately effective requirements, the 51 future-dated requirements that are now mandatory, and the clarifications introduced in v4.0.1.

A gap assessment should produce:

• A list of requirements where your organisation is fully compliant
• A list of requirements where controls are partially in place but do not meet the full v4.0.1 expectation
• A list of requirements where no control is currently in place
• A prioritised remediation roadmap with timelines and resource requirements

Step 2: Prioritise high-impact requirements

The following requirements have the highest implementation complexity and should be addressed first:

• Requirements 6.4.3 and 11.6.1 (e-commerce script management) if you operate an e-commerce site
• Requirement 8.4.2 (MFA for all CDE access) this affects all users and service accounts
• Requirement 11.3.1.2 (authenticated internal vulnerability scans) requires credentialed scanning capability
• Requirement 8.6.1 (12-character passwords) may require application updates if legacy systems cannot support this length
• Requirement 11.4.7 (segmentation testing during penetration tests) requires specialised testing methodology

Step 3: Implement required controls

Based on the gap assessment, implement the security controls required to meet each new or updated requirement. This may include:

• Deploying new technical controls (MFA systems, script monitoring tools, authenticated scanning infrastructure)
• Updating policies and procedures to reflect new documentation requirements
• Assigning roles and responsibilities for security functions
• Conducting Targeted Risk Analyses (TRAs) for requirements that provide frequency flexibility

Step 4: Conduct penetration testing

If your last penetration test was conducted before March 31, 2025, or if your test did not cover the full scope required by v4.0 (network-layer and application-layer testing, segmentation validation), schedule a new penetration test that meets the v4.0.1 requirements.

Step 5: Update your SAQ or schedule a QSA assessment

If you validate compliance using a Self-Assessment Questionnaire (SAQ), ensure you are using the v4.0.1 SAQ published in October 2024 (or the updated versions published in early 2025). The v3.2.1 SAQs are no longer valid.

If you are a Level 1 merchant or service provider and require a QSA assessment, engage your QSA early to schedule the assessment and review the v4.0.1 requirements together.

Step 6: Submit compliance documentation

Once your controls are in place and validated, submit your completed SAQ and Attestation of Compliance (AOC) — or your QSA's Report on Compliance (ROC) and AOC — to your acquiring bank along with your quarterly ASV scan reports.

Related reading:

• What Is PCI DSS Compliance? A Plain-Language Guide for 2026
• PCI DSS Requirements 6.4.3 and 11.6.1: Payment Page Script Management Explained (coming soon)
• PCI DSS Penetration Testing Requirements: What Assessors Check (coming soon)
• How to Choose the Right PCI DSS SAQ for Your Business (coming soon)

Frequently Asked Questions

Are the v4.0 future-dated requirements now mandatory?

Yes. As of March 31, 2025, all 51 future-dated requirements from PCI DSS v4.0 are mandatory and must be validated during all PCI DSS assessments. There is no grace period.

What is the difference between PCI DSS v4.0 and v4.0.1?

v4.0.1 is a limited revision with zero new requirements and zero deleted requirements. It corrects typographical errors and clarifies the intent of certain requirements. The substantive changes to compliance obligations all come from v4.0.

Do I need to re-assess if I was compliant under v3.2.1?

Yes. v3.2.1 was retired on March 31, 2024. All assessments conducted in 2026 must be against PCI DSS v4.0.1, which includes 64 new or updated requirements compared to v3.2.1.

Do Requirements 6.4.3 and 11.6.1 apply to my business?

If you validate compliance using SAQ A-EP or SAQ D (i.e., e-commerce merchants whose websites can impact payment transactions), yes. If you validate using SAQ A (fully outsourced with no control over the payment page), no.

How long do I have to implement 12-character passwords?

The requirement became mandatory on March 31, 2025. If your systems cannot support 12-character passwords, they must support at minimum 8 characters until those systems are upgraded, and this exception must be documented with a remediation plan.

Can I use the Customised Approach to avoid difficult requirements?

No. The Customised Approach is not a method to avoid requirements — it is a method to implement alternative controls that achieve the same security objective as the defined requirement. It requires extensive documentation, risk analysis, and QSA validation.