PCI DSS 4.0: What Changed and Why You Should Care

PCI DSS 4.0: What Changed and Why You Should Care (Even If You Weren't Ready)

PCI DSS 4.0 went into effect on March 31, 2025. If you haven't updated your compliance controls, your business is now out of compliance—and if your annual assessment cycle is coming up, you'll need to demonstrate compliance with the new requirements. The new standard tightened requirements significantly, and many travel tech companies are working to understand what's required.

Here's what changed, why it matters, and what it means for your infrastructure.

The March 31, 2025 deadline (it's past)

PCI DSS 4.0 introduced 64 new requirements in total, of which 51 were designated as "future-dated"—provisions that weren't mandatory immediately but had a sunset date. On March 31, 2025, that deadline passed. Those 51 future-dated requirements are now mandatory alongside the 13 requirements that were mandatory from day one.

If your last PCI compliance assessment was in 2024 under PCI DSS 3.2.1, you may not have implemented all of these controls yet. If your assessment is happening now or in the coming months, you will be audited against PCI DSS 4.0—including these newly mandatory requirements. Non-compliance will be documented in your assessment report.

These requirements are now mandatory for all merchants and service providers within the PCI compliance framework. If your systems are in scope, these controls must be implemented as part of your compliance program.

What actually changed?

1. Multi-factor authentication (MFA) for all CDE access

What it is: Anyone accessing the Cardholder Data Environment (CDE)—the systems, networks, and people who handle payment card data—must use MFA. This includes:

• System administrators
• Database users
• Application developers (when they access production systems)
• Anyone on your security team

What changed: In PCI 3.2.1, MFA was required for remote access to the CDE. PCI 4.0 expanded it: MFA is now required for all access to the CDE, whether remote or on-site.

What this means: If you have a developer who walks into your office and logs into a server in the CDE without MFA, that's now non-compliant. If a database administrator accesses your payment database without MFA, that's non-compliant. MFA is no longer optional for convenience—it's mandatory for all access points.

Implementation cost: For most travel tech companies, this means deploying an enterprise MFA solution (Okta, Azure AD, Duo, etc.), integrating it with your CDE systems, and training your team. Budget: 40-80 hours of engineering time, plus licensing.

2. Payment page script integrity monitoring

What it is: Every script running on your payment page must be monitored for unauthorized changes.

If a customer logs into their booking system and a malicious script is injected into the payment form (Magecart-style attack), the attacker can capture card data directly from the form before tokenisation. PCI DSS 4.0 requires you to detect when scripts on your payment page change unexpectedly.

What changed: This wasn't in PCI 3.2.1 at all. It's entirely new.

What this means: You need:

• A way to establish a baseline of all scripts on your payment page
• Continuous monitoring to detect when new scripts are added or existing scripts are modified
• Alerting when unauthorized changes occur

Implementation cost: You can use Content Security Policy (CSP) headers, Subresource Integrity (SRI) attributes, and endpoint detection tools. You can also use specialized third-party script integrity monitoring services. Budget: 20-60 hours of engineering time, plus potential SaaS licensing.

3. Disk-level encryption alone is no longer sufficient

What it is: In PCI 3.2.1, encrypting entire hard drives or storage volumes was often used as a primary control for protecting cardholder data at rest.

What changed: PCI DSS v4.x clarified that disk or partition encryption alone is not sufficient — it must be accompanied by the other encryption and key management controls in the standard. Implementations that relied solely on full-disk encryption (BitLocker, FileVault, etc.) need to be reviewed and likely augmented.

What this means: Cardholder data at rest needs to be protected by encryption that operates at the database or file level, with proper key management. If you were relying on disk-level encryption as your sole control, that gap needs to be addressed.

The architectural advantage: This is one of the easiest requirements to satisfy by eliminating the problem entirely. If you don't store card data in your environment—if you use tokenisation—disk-level encryption becomes irrelevant because there's no card data to encrypt.

Implementation cost: If you continue storing card data, budget 40-120 hours for implementing application-level encryption. If you use tokenisation, this requirement disappears.

4. Annual scope validation and documentation

What it is: You must formally validate your PCI scope every year and document it.

What changed: In PCI 3.2.1, scope validation was part of the annual assessment, but not explicitly required as a separate exercise. PCI 4.0 made it mandatory: you must create a written, detailed scope statement that identifies all systems in and out of scope, and you must validate it annually.

What this means:

• You need a clear document listing every system, application, database, and network segment
• You must identify which of these systems touch, store, process, or transmit card data
• You must audit this document annually
• You must document how you validated it
• Your QSA (Qualified Security Assessor) will ask to see this documentation

Implementation cost: For most companies, this is 20-40 hours of documentation and process work annually.

5. Targeted risk analysis (TRA) requirements

What it is: PCI 4.0 expanded the use of Targeted Risk Analysis (TRA) beyond compensating controls. TRA is now required in multiple contexts where you need to document that a security decision mitigates risk appropriately. This formalization reflects PCI's move toward risk-based compliance rather than prescriptive checkbox compliance.

What changed: In PCI 3.2.1, TRA was primarily associated with compensating controls. PCI 4.0 extends TRA requirements to broader scenarios, including:

• Compensating controls (alternative controls that achieve the same security objective when you can't meet the original requirement)
• Risk-based authentication decisions
• Multi-factor authentication variances or exceptions (in limited circumstances, where justified by documented business or technical constraints)

When TRA is required, it must be a formal, structured document that explains:

• The business or technical constraint that prevents implementing the standard requirement
• How your chosen control or alternative approach mitigates the intended risk
• What the residual risk is and how it's managed
• Why your approach is appropriate and justified for your environment

What this means: Risk-based decisions require documented evidence, not informal judgment. If your compliance approach relies on exceptions or alternative controls, expect your QSA to ask for the TRA supporting that decision.

Implementation cost: For each risk decision requiring TRA, budget 10-20 hours of analysis and documentation work.

The bigger picture: What assessors are expecting

This is the first full assessment cycle under PCI 4.0, and QSAs are evaluating compliance against the full set of requirements. Non-compliance findings are being documented according to PCI's standard assessment procedures. Companies that identify gaps during this cycle need to remediate before their next assessment.

If your assessment is scheduled for later in 2025 or beyond, understand that you will be audited against all PCI 4.0 requirements, including the ones that became mandatory on March 31, 2025. Plan remediation accordingly.

The architectural advantage: Minimize card data in scope

Here's the insight that simplifies compliance: The most efficient way to meet PCI DSS 4.0 requirements is to minimize the volume of card data your systems must secure.

Most of these new requirements exist to protect cardholder data when it exists in your infrastructure. They require MFA, encryption, monitoring, documentation, and risk analysis. The burden is proportional to the amount of card data you store and process.

But what if you minimized card data storage entirely?

If you tokenise your card data with Vaultera Vault:

• Your systems never hold the real card number
• You don't need to encrypt card data at rest (no card data exists to encrypt)
• Your scope shrinks dramatically
• Some of these requirements become irrelevant

A company that stores no card data and uses tokenisation for all card operations has a significantly smaller PCI scope—sometimes moving from a full Level 1 assessment to a Level 3 or Level 4 assessment (lighter, cheaper, faster).

MFA requirement: Still applies if you have any cardholder data environment.

Script integrity monitoring: Still applies if you collect card data on payment pages.

Disk encryption: Irrelevant if there's no card data to encrypt.

Scope validation: Simpler and faster if your scope is minimal.

Risk analysis: Easier because the risk profile is lower.

What travel tech companies should do right now

1. Get clarity on your scope. If you haven't done a formal scope validation document under PCI 4.0, do it now. You need to know exactly what's in and out of scope.
2. Assess your current state. Are you meeting all the newly mandatory requirements? If not, document what's missing and prioritize the gaps.
3. Plan your remediation. If you're out of compliance on MFA, script monitoring, encryption, or other controls, create a timeline to fix it before your assessment.
4. Consider tokenisation. If you're struggling to meet these new requirements while storing card data, tokenisation is worth evaluating. It can substantially reduce the scope of your compliance obligations and simplify the controls you need to implement.
5. Schedule your assessment. If you haven't had an assessment under PCI 4.0 yet, schedule it soon. The sooner you understand your compliance posture, the sooner you can identify and fix gaps.

The Vaultera advantage in a PCI 4.0 world

Vaultera Vault is built from the ground up for PCI DSS compliance. Our vault is certified at PCI DSS Level 1 v4.0.1—the highest standard. We manage:

• MFA for all vault access
• Encryption at every layer (data at rest, data in transit, key management)
• Script integrity monitoring on our side
• Annual scope validation
• Comprehensive risk analyses
• Continuous compliance monitoring

When you use Vaultera to tokenise card data, your company's scope shrinks because the sensitive data lives in our vault—not yours. You get the security and compliance benefits of PCI DSS 4.0 without bearing the full operational burden.

Your development team can focus on building great travel tech products. Your compliance team can manage a smaller scope and lighter annual assessments. Your customers' card data is protected by a system that specializes in nothing but security and compliance.

That's the Vaultera approach to PCI DSS 4.0 and beyond.