PCI DSS v4.0: What Changed and What It Means for Cloud Environments

What PCI DSS v4.0 Changes Mean and Why Cloud Teams Cannot Ignore Them

PCI DSS v3.2.1 retired in March 2024, and organisations handling cardholder data moved into the PCI DSS v4.x era. PCI DSS v4.0.1 is now the current version of the standard, refining v4.0 without adding new requirements.

For cloud teams, the change is not cosmetic. The v4.x updates affect authentication, software security, monitoring, risk analysis and how organisations demonstrate compliance.

The version that most organisations spent years building controls around is now retired. Any assessment conducted from April 2024 onwards is measured against PCI DSS v4.0. Organisations that continued operating against v3.2.1 controls through the transition period without updating their programmes will discover the gaps during their next assessment, not before.

Understanding what changed, and where cloud environments are most affected, is the starting point for closing those gaps before an auditor finds them.

For a broader comparison of how HIPAA, PCI DSS and SOC 2 differ in cloud environments, read HIPAA, PCI DSS and SOC 2: Key Differences for Cloud Teams.

What Are the Most Significant Changes in PCI DSS v4.0?

The changes in PCI DSS v4.0 cluster around four areas: authentication, software security, monitoring and a new implementation pathway called customised implementation.

Multi-factor authentication requirements have expanded significantly. Under v3.2.1, MFA was required for remote access to the cardholder data environment. Under v4.0, MFA is required for all access into the CDE, including access from within an organisation’s internal network.

Requirement 8.4.2 makes this explicit: MFA applies to all personnel with non-console access to system components in the CDE, regardless of whether that access originates externally or internally.

For cloud environments where internal and external access boundaries are often fluid, this is a meaningful operational change.

Targeted risk analysis is another structural shift. PCI DSS v4.0 introduces the concept of requiring organisations to perform a targeted risk analysis to justify the frequency of certain activities, including penetration testing schedules, log review intervals and vulnerability scans.

Rather than setting a single mandatory frequency for all organisations, the standard now expects organisations to document their reasoning for the schedule they choose, based on the specific risks relevant to their environment.

This gives organisations more flexibility, but it also creates a documentation obligation that did not previously exist.

PCI DSS v4.x introduced several new and updated requirements, including future-dated requirements that became effective on 31 March 2025. Organisations that passed an early v4.x assessment but have not revisited their programme since may now find that these requirements are fully in scope and outstanding.

What Is Customised Implementation and When Does It Apply?

Customised implementation is a new pathway in PCI DSS v4.0 that allows organisations to meet the intent of a PCI DSS requirement through controls that differ from the standard’s defined approach, provided those controls achieve the same security objective and the organisation can demonstrate that equivalence to a Qualified Security Assessor.

This matters for cloud-native organisations whose architectures do not map neatly onto the defined requirements written with traditional on-premises environments in mind.

A containerised microservices environment, for example, may not have firewalls in the conventional sense. However, it may have network policies, security groups and service mesh controls that achieve equivalent network segmentation.

Customised implementation allows that equivalence to be formally assessed rather than forcing organisations to implement controls that do not fit their architecture.

The trade-off is documentation and assessor engagement. Customised implementation requires a defined approach document, a targeted risk analysis, testing procedures agreed with the assessor and ongoing evidence that the alternative control continues to meet the objective.

It is not a lighter path. It is a different path that suits specific architectural contexts.

How PCI DSS v4.0 Affects Cloud Scope Definition

Scope definition remains the area where most organisations create unnecessary compliance burden, or leave themselves exposed.

The cardholder data environment includes all system components that store, process, or transmit cardholder data, plus all system components that are connected to or could impact the security of the CDE.

In cloud environments, that scope expands quickly. A compute instance that never directly handles card data but shares a network segment with one that does is in scope. A logging system that receives output from a CDE component is in scope. A developer workstation with access to a CDE system is in scope.

PCI DSS v4.0 does not narrow this. Its expanded monitoring and authentication requirements make the boundaries of the CDE more consequential, because more controls now depend on those boundaries being accurate.

Segmentation testing, required under PCI DSS v4.0 at least once every six months for organisations using segmentation to reduce scope, is the mechanism by which organisations verify that their CDE boundaries are holding.

For cloud environments using VPCs, security groups and network access control lists to create segmentation, those controls need to be tested, not assumed.

Turning PCI DSS Cloud Scope Into Practical Action

Understanding PCI DSS scope is one of the hardest parts of cloud compliance.

The Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud course helps cloud and security teams understand how cardholder data environments, segmentation, logging and assessor expectations apply in real cloud environments.

Explore the Course → Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud

What Cloud-Specific Controls Does PCI DSS v4.0 Require?

Cloud environments introduce compliance considerations that PCI DSS v3.2.1 addressed only partially. PCI DSS v4.0 is more explicit about several areas that directly affect cloud-native architectures.

Requirement 6 covers secure software development. PCI DSS v4.0 expands this to include requirements for web-facing applications to be protected against attacks by reviewing them at least once every twelve months through a web application firewall or an application vulnerability assessment.

For organisations deploying containerised applications or serverless functions that interact with cardholder data, this requirement applies to those components and must be built into the development and deployment pipeline, not treated as a post-deployment activity.

Requirement 10 governs logging and monitoring. PCI DSS v4.0 requires that all critical system component logs are retained for at least twelve months, with the most recent three months available for immediate analysis.

For cloud environments using managed logging services, this means verifying that log retention policies align with the v4.0 requirement and that log data is actually accessible and queryable, not just stored in a cold archive that requires days to retrieve.

Requirement 12.3 introduces the targeted risk analysis framework described earlier. Each analysis must be documented, reviewed and approved by personnel accountable for the organisation’s compliance programme, and reassessed when the relevant environment changes.

This is not an annual checkbox. It is an ongoing governance activity.

What Organisations Running Cloud Payments Should Check Right Now

The shift to PCI DSS v4.0 creates specific gaps for organisations that have not conducted a gap assessment against the new requirements.

The following areas are most likely to require action in cloud environments.

Review MFA Coverage Against the Expanded PCI DSS v4.0 Scope

MFA coverage should be reviewed against the expanded PCI DSS v4.0 scope.

If MFA is currently deployed only for external or remote access into the CDE, the configuration does not meet PCI DSS v4.0 requirements for all non-console access.

Cloud IAM policies, federated identity configurations and privileged access management tools all need to be assessed against the new scope.

Verify Log Retention and Accessibility

Log retention and accessibility should be verified.

Many cloud environments route logs to object storage with lifecycle policies that move data to cold storage after 30 or 90 days.

If those policies bring logs below the three-month immediate-access threshold required by PCI DSS v4.0, they need to be adjusted before the next assessment.

Confirm Future-Dated Requirements Are Now Implemented

Future-dated requirements that became mandatory in March 2025 should be confirmed as implemented.

These include requirements around password security, phishing-resistant authentication and additional software security controls.

Organisations that completed their first PCI DSS v4.0 assessment in 2024 may have been assessed against the 2024 requirement set. The 2025 additions are now active and will be assessed in the next cycle.

Keep Segmentation Testing Records Current

Segmentation testing records should be current.

If the CDE relies on network segmentation to limit scope, that segmentation must be tested at least every six months under PCI DSS v4.0.

Documentation of the most recent test, who conducted it, what was tested and the results should be available before any assessment begins.

If your team is working through PCI DSS v4.x requirements in a cloud environment, structured training can help clarify scope definition, MFA expectations, logging, targeted risk analysis, customised implementation and assessor preparation.

The Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud course covers PCI DSS cloud requirements in practical detail, including how to define scope, prepare evidence and manage overlapping compliance obligations.

Explore the Course → Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud

Frequently Asked Questions

What Is PCI DSS v4.0.1?

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard. It refines PCI DSS v4.0 without adding new requirements.

Why Does PCI DSS Matter for Cloud Teams?

PCI DSS matters for cloud teams because cardholder data may be stored, processed, or transmitted through cloud applications, databases, logs, APIs and infrastructure components.

What Changed in PCI DSS v4.x?

PCI DSS v4.x introduced stronger expectations around authentication, software security, monitoring, targeted risk analysis and customised implementation.

What Is Customised Implementation in PCI DSS?

Customised implementation allows an organisation to meet the intent of a requirement using a different control approach, provided it can demonstrate equivalent security to the assessor.

Who Should Learn PCI DSS Cloud Compliance?

Cloud engineers, security analysts, compliance managers, payment platform teams, DevOps teams and risk professionals should understand PCI DSS requirements if their systems handle cardholder data.