Updated 18/8/26

PCI DSS has undergone its biggest transformation in more than a decade.

PCI DSS v4.0 introduced significant changes to how organisations protect payment account data, assess risk and demonstrate compliance. It was followed by PCI DSS v4.0.1, a limited revision designed to clarify and improve the standard without introducing new or removing existing requirements.

By 2026, the transition period is over. The future-dated requirements introduced under PCI DSS v4.x became effective on 31 March 2025, which means organisations should now be operating fully against the requirements of PCI DSS v4.0.1.

So, what changed, which requirements matter most and what should organisations be focusing on now?

• What is PCI DSS 4.0.1?

  PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard, the global security standard designed to protect payment account data.

  PCI DSS applies to organisations that store, process or transmit cardholder data or sensitive authentication data, as well as organisations whose systems or services could affect the security of the Cardholder Data Environment (CDE).

  PCI DSS v4.0 was originally published in March 2022 and represented the first major revision of the standard in more than a decade.

  PCI DSS v4.0.1 followed in June 2024.

  Importantly, PCI DSS v4.0.1 was a limited revision. It did not introduce new requirements or remove existing ones. Instead, it clarified wording, corrected formatting and addressed questions raised since the introduction of v4.0.

  For organisations assessing their compliance in 2026, PCI DSS v4.0.1 should therefore be the version around which their PCI DSS programme is built.

  Is PCI DSS 4.0 still valid?

  PCI DSS v4.0 was retired on 31 December 2024.

  PCI DSS v4.0.1 is now the active version of the standard.

  Organisations should therefore ensure that their assessments, documentation, policies, controls and compliance programmes reflect the requirements and supporting documentation associated with v4.0.1.

  What changed with PCI DSS 4.0?

  PCI DSS v4.0 introduced 64 new requirements compared with PCI DSS v3.2.1.

  Thirteen became effective when v4.0 came into force, while the remaining 51 were initially treated as best practices before becoming mandatory on 31 March 2025.

  For organisations in 2026, those requirements are no longer future considerations.

  They are part of the standard.

  The most significant changes include stronger authentication requirements, greater emphasis on continuous security, targeted risk analyses, enhanced e-commerce protections, increased flexibility in how organisations meet requirements and more detailed expectations around third-party service providers.

  1. Greater emphasis on continuous compliance

  One of the most important changes introduced by PCI DSS v4.x is the move away from treating compliance as a once-a-year exercise.

  PCI DSS has always required controls to be maintained throughout the year, but v4.x reinforces the need for security to operate as an ongoing process rather than something prepared specifically for an annual assessment.

  This means organisations need to think beyond passing an audit.

  Controls should remain operational, monitored and evidenced throughout the year. Processes need to survive staff changes, infrastructure changes, cloud migrations and new suppliers without falling out of compliance.

  The question is no longer simply:

  “Can we pass our PCI DSS assessment?”

  It should be:

  “Can we demonstrate that these controls are operating effectively throughout the year?”

  2. Multi-factor authentication requirements have expanded

  PCI DSS v4.x significantly strengthened authentication requirements.

  Multi-factor authentication is required for access into the Cardholder Data Environment and for remote access that could lead to the CDE.

  This reflects the increasing importance of identity as an attack vector.

  Passwords alone provide limited protection when credentials can be stolen through phishing, infostealer malware, credential stuffing or other techniques.

  Organisations should therefore review exactly who can access the CDE, from where and using which authentication mechanisms.

  That includes employees, administrators, developers, contractors and third-party service providers.

  3. Password requirements are stronger

  PCI DSS v4.x also strengthened password controls.

  Where passwords or passphrases are used as authentication factors, organisations are expected to implement stronger password requirements and ensure credentials are managed securely.

  The standard places greater emphasis on protecting authentication credentials throughout their lifecycle rather than relying solely on frequent password changes.

  In practice, this means organisations should examine password strength, account management, inactive accounts, credential storage and authentication processes as part of their wider identity security controls.

  4. Targeted Risk Analyses are now an important part of PCI DSS

  PCI DSS v4.x introduced the concept of the Targeted Risk Analysis, often shortened to TRA.

  A Targeted Risk Analysis allows an organisation to assess the risks associated with particular activities or controls and, in certain cases, use that analysis to determine how frequently an activity should be performed.

  For example, where PCI DSS allows an organisation to define the frequency of a particular control, that decision should be supported by a documented risk analysis rather than an arbitrary schedule.

  The PCI Security Standards Council describes two forms of Targeted Risk Analysis within PCI DSS v4.x, including analyses used to determine control frequencies and analyses supporting use of the Customised Approach.

  The important point is that PCI DSS increasingly expects organisations to understand and justify their security decisions.

  Simply saying, “We do this every six months because we always have” is not a risk-based approach.

  The organisation needs to demonstrate why that frequency is appropriate.

  5. Defined Approach vs Customised Approach

  One of the biggest structural changes introduced by PCI DSS v4.0 was the addition of the Customised Approach.

  Under the traditional Defined Approach, organisations implement controls that meet the requirements and testing procedures prescribed by PCI DSS.

  The Customised Approach provides greater flexibility.

  Instead of implementing a control exactly as described by the Defined Approach, organisations may be able to use alternative controls that achieve the same security objective.

  That does not necessarily make compliance easier.

  In many cases, it makes the assessment more demanding because the organisation must clearly define the control, explain how it meets the requirement's objective, perform a Targeted Risk Analysis and provide sufficient evidence to demonstrate its effectiveness.

  For organisations with mature cybersecurity, engineering and risk management capabilities, this can provide valuable flexibility.

  For others, the Defined Approach may remain considerably simpler.

  6. Stronger e-commerce security requirements

  E-commerce security is one of the most significant areas of PCI DSS v4.x.

  Requirements 6.4.3 and 11.6.1 became effective on 31 March 2025 and are specifically designed to address threats such as e-skimming and payment-page attacks.

  Modern e-commerce environments frequently rely on JavaScript and other browser-executed scripts provided by multiple internal and external sources.

  Those scripts can become an attractive target.

  Attackers who successfully manipulate a payment-page script may be able to capture cardholder information directly from the customer's browser.

  PCI DSS therefore introduces stronger requirements around identifying, authorising and managing payment-page scripts.

  Organisations need to know which scripts are present, why they are necessary and whether their integrity can be trusted.

  PCI DSS also requires mechanisms capable of detecting unauthorised modification of payment pages and security-impacting HTTP headers.

  For e-commerce organisations, these requirements should now be treated as core controls rather than projects still awaiting a compliance deadline.

  7. Greater focus on phishing and security awareness

  PCI DSS v4.x strengthened the requirements around security awareness.

  Employees need to understand the social engineering threats that could lead to the compromise of payment systems or account data.

  That includes threats such as:

  • Phishing
  • Business email compromise
  • Social engineering
  • Malicious links
  • Suspicious authentication requests
  • Impersonation attacks

  Training should reflect the organisation's actual threat environment rather than simply providing generic annual cybersecurity training.

  Security awareness needs to be relevant, measurable and reinforced over time.

  8. Increased focus on vulnerability and malware management

  PCI DSS v4.x also modernised the way organisations are expected to think about vulnerability management and malware.

  Organisations should identify security vulnerabilities using reputable external sources and assess the risk they present to the environment.

  Patch management needs to be prioritised according to risk, while systems that are not traditionally considered susceptible to malware should not simply be assumed to be permanently safe.

  Periodic evaluation is required to determine whether those systems continue to be considered not at risk from malware.

  This is another example of the standard moving towards continuous evaluation rather than static assumptions.

  9. Stronger controls around account management

  Dormant, shared and poorly controlled accounts can provide attackers with opportunities to access payment environments.

  PCI DSS v4.x strengthened expectations around user accounts, privileges and access reviews.

  Organisations should ensure access is granted according to business need and the principle of least privilege.

  Accounts should be reviewed periodically, unnecessary access removed and terminated-user access revoked promptly.

  This is particularly important where privileged accounts provide access to systems within the CDE.

  10. Scope must be confirmed regularly

  PCI DSS scope has always mattered, but v4.x places greater emphasis on organisations understanding and validating their scope.

  Organisations should identify all people, processes, technologies and third parties that store, process or transmit account data, or which could impact the security of the CDE.

  PCI DSS scope should not simply be copied from the previous year's assessment.

  Networks change.

  Applications change.

  Cloud environments change.

  Suppliers change.

  Payment journeys change.

  Organisations therefore need processes that identify those changes and determine whether they alter the PCI DSS scope.

  Reducing unnecessary scope can significantly simplify compliance, but scope reduction must be technically defensible rather than simply convenient.

  11. Third-party service providers remain your responsibility

  Using a PCI DSS compliant third-party provider does not automatically remove your organisation's PCI DSS responsibilities.

  Organisations need to identify third parties that store, process or transmit account data or could affect its security.

  They should understand which controls are:

  • Managed by the provider
  • Managed by the organisation
  • Shared between both parties

  An Attestation of Compliance should also be reviewed carefully.

  It is not enough to establish that a supplier describes itself as “PCI compliant”.

  Organisations need to verify that the assessment actually covers the service, legal entity and environment they use and that the provider's validation remains current.

  Third-party PCI DSS compliance therefore needs to form part of procurement, supplier management and ongoing compliance rather than being checked only shortly before an assessment.

  12. PCI DSS requires more documentation and evidence

  PCI DSS v4.x is also more evidence-driven.

  Policies existing on paper are not enough.

  Assessors increasingly need to see evidence demonstrating that controls are actually operating.

  That can include:

  • Configuration evidence
  • Access reviews
  • Vulnerability scans
  • Penetration test results
  • Logs
  • Targeted Risk Analyses
  • Security awareness records
  • Change-management documentation
  • Third-party compliance evidence
  • Incident response testing
  • Payment-page monitoring evidence

  This is one reason organisations that treat PCI DSS as an annual project can struggle.

  Trying to reconstruct 12 months of evidence shortly before an assessment is considerably harder than collecting it continuously.

  
  
  

  What should organisations focus on for PCI DSS compliance in 2026?

  The migration period has finished.

  For most organisations, 2026 should therefore be less about preparing for PCI DSS v4.x and more about demonstrating that the new controls are working effectively.

  Priority areas should include understanding scope, verifying that the future-dated requirements have been fully implemented, reviewing Targeted Risk Analyses, checking e-commerce controls, validating third-party responsibilities and ensuring sufficient evidence exists to support the assessment.

  Organisations should also look carefully at controls implemented quickly ahead of the March 2025 deadline.

  A control being technically present does not necessarily mean it is operating effectively.

  2026 provides an opportunity to move from initial implementation towards mature, sustainable compliance.

  Is PCI DSS compliance required every year?

  Yes.

  PCI DSS validation is performed on a recurring basis, generally annually, with the exact validation method depending on factors such as the organisation's role, transaction volumes and requirements set by payment brands or acquiring institutions.

  Some organisations can validate using a Self-Assessment Questionnaire, while others require a formal Report on Compliance conducted with a Qualified Security Assessor.

  PCI DSS also contains requirements that must be performed more frequently than annually, including various monitoring, testing, scanning and review activities.

  PCI DSS compliance should therefore be considered a continuous programme supported by an annual validation exercise.

  How do you prepare for a PCI DSS 4.0.1 assessment?

  Preparation should begin with scope.

  Identify where account data enters the organisation, where it travels, where it is stored and which systems, people and third parties can affect its security.

  From there, perform a gap assessment against PCI DSS v4.0.1.

  Particular attention should be given to controls introduced or changed under v4.x, especially those that became mandatory in March 2025.

  Any deficiencies should then be prioritised through a remediation programme before formal validation begins.

  Evidence should be collected as controls operate rather than assembled retrospectively at assessment time.

Frequently asked questions about PCI DSS 4.0.1

What is the current version of PCI DSS in 2026?

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard.

It was published in June 2024 as a limited revision of PCI DSS v4.0.

What is the difference between PCI DSS 4.0 and 4.0.1?

PCI DSS v4.0.1 introduced clarifications and corrections to PCI DSS v4.0 but did not introduce new requirements or remove existing ones.

Organisations should now use v4.0.1 for current PCI DSS assessments.

When did the PCI DSS 4.0 future-dated requirements become mandatory?

The future-dated PCI DSS v4.x requirements became effective on 31 March 2025.

They are therefore mandatory requirements in 2026 rather than recommended best practices.

How many new requirements did PCI DSS 4.0 introduce?

PCI DSS v4.0 introduced 64 new requirements compared with PCI DSS v3.2.1.

Of these, 51 were initially future-dated requirements before becoming effective on 31 March 2025.

What are PCI DSS Requirements 6.4.3 and 11.6.1?

Requirements 6.4.3 and 11.6.1 are designed to strengthen the security of e-commerce payment pages.

They address areas including payment-page script management, script authorisation and integrity, and mechanisms capable of detecting unauthorised changes to payment pages and security-impacting HTTP headers.

Does PCI DSS 4.0.1 require multi-factor authentication?

PCI DSS v4.x expanded requirements for multi-factor authentication, including access into the Cardholder Data Environment and certain remote-access scenarios.

Organisations should review all authentication paths into systems within or connected to the CDE.

What is a PCI DSS Targeted Risk Analysis?

A Targeted Risk Analysis is a documented risk assessment used in particular PCI DSS circumstances to justify decisions such as how frequently a control should operate or to support controls implemented using the Customised Approach.

What is the PCI DSS Customised Approach?

The Customised Approach allows eligible organisations to meet the security objective of a PCI DSS requirement using an alternative control rather than following the Defined Approach exactly.

The organisation must demonstrate that the alternative control meets the requirement's intent and provides appropriate protection.

Is PCI DSS compliance a legal requirement?

PCI DSS is an industry security standard rather than legislation.

However, compliance requirements are imposed through the payment card ecosystem and contractual relationships with acquiring banks, payment brands and other parties.

Organisations that fail to meet their obligations can face financial, commercial and reputational consequences.

Does using a PCI compliant payment provider make my organisation compliant?

No.

Using a compliant service provider can reduce scope and transfer responsibility for particular controls, but your organisation remains responsible for understanding its own PCI DSS obligations and confirming which requirements are handled by each party.

How Integrity360 can help with PCI DSS 4.0.1

PCI DSS compliance has become more complex, but it should not become an annual scramble.

Integrity360 provides end-to-end Payments Compliance services designed to help organisations understand their scope, identify gaps and build sustainable PCI DSS compliance programmes.

Our services include:

• PCI DSS scope and gap assessments
• Compliance validation
• QSA services
• Remediation support
• Penetration testing
• Vulnerability scanning and PCI ASV services
• Control testing
• Targeted Risk Analysis support
• Third-party compliance reviews
• Audit preparation
• Continuous compliance support

Whether you are preparing for your next PCI DSS v4.0.1 assessment, reviewing controls implemented for the March 2025 deadline or trying to reduce the complexity of your payment environment, Integrity360 can help.

Speak to our Payments Compliance specialists to review your PCI DSS 4.0.1 readiness and build a more sustainable approach to compliance.