PCI DSS v4.0 for SaaS: What Changed and What You Need to Do
PCI DSS v4.0 has been mandatory since March 2024.
If you are still running your compliance program against v3.2.1 controls, you are out of date. And several new requirements that were previously future-dated became effective March 31, 2025.
This guide covers the changes that matter most for SaaS companies, what you need to do differently, and how to think about scope.
What PCI DSS v4.0 Changed
The overall structure stayed the same, 12 requirements across six goals. But v4.0 made several meaningful changes:
- More emphasis on outcomes rather than prescriptive controls
- A new "customized approach" as an alternative to the defined approach
- Stronger authentication requirements (multi-factor everywhere)
- New requirements for payment page script management (Requirement 6.4.3)
- Expanded targeted risk analysis, you must now document why your control frequencies are appropriate
- Phishing-resistant MFA required for all access to the cardholder data environment
The delayed requirements that became effective March 2025 are the ones most teams are scrambling on now.
The Requirement That Catches SaaS Teams Off Guard
Requirement 6.4.3: payment page script management
Requirement 6.4.3 is the most disruptive for SaaS companies with any kind of checkout flow. Every script loaded on a payment page must be:
- Authorized by your organization
- Justified (with a documented reason for why it is needed)
- Integrity-protected (via subresource integrity hashes or similar)
This applies to first-party scripts and third-party ones, analytics pixels, chat widgets, A/B testing tools, anything that runs on the payment page.
If you use Google Tag Manager on your checkout page, you need to enumerate every tag, document its purpose, and implement integrity controls. Tag managers are particularly complex here because they can load dynamic scripts that change without your direct action.
The simplest fix is to eliminate third-party scripts from payment pages entirely and load only what is strictly necessary.
How to Scope Down
Scope is the most important decision in a PCI DSS program. The smaller your cardholder data environment (CDE), the fewer requirements apply.
For SaaS companies, the fastest scope reduction is using a payment processor that handles the full payment flow:
| Approach | Typical SAQ | Scope Complexity |
|---|---|---|
| Stripe.js / hosted fields (no card data touches your servers) | SAQ A | Very low |
| Redirect to processor's payment page | SAQ A | Very low |
| JavaScript-based payment form you control | SAQ A-EP | Moderate |
| You collect and transmit card data directly | SAQ D | High |
SAQ A has 22 requirements. SAQ D has over 200. If you are not already using hosted fields or a full redirect, moving to one of those patterns is the highest-leverage thing you can do before your next assessment.
Multi-Factor Authentication Changes
v4.0 tightened MFA requirements significantly. MFA is now required for:
- All access into the CDE, including internal systems
- All remote access to the network
- All administrative access to systems in scope
"All access" means no exceptions for service accounts or internal tools that interact with cardholder data. If an admin tool can reach your CDE, MFA is required for it.
The new language also specifies that MFA must be implemented such that it cannot be bypassed by any user, including admins. Audit logs of authentication events are required.
Targeted Risk Analysis
One of the structural changes in v4.0 is that many controls now require a documented targeted risk analysis to support your chosen frequency or implementation approach.
For example, if you review your CDE access logs monthly instead of weekly, you need to document why monthly is appropriate given your environment and risk profile. This is not just a checkbox, assessors will review the quality of your analysis.
This adds documentation burden but also gives you more flexibility than the prescriptive v3.2.1 controls. If you can justify a different approach with evidence, v4.0 allows it.
Password and Authentication Requirements
v4.0 strengthened password requirements:
- Minimum 12-character passwords (up from 7)
- Passwords must not be the same as the previous four passwords
- MFA required for all CDE access (not just remote access)
- Phishing-resistant MFA required for all non-consumer user access to the CDE
If your systems use shared passwords, service accounts with static credentials, or password-based access for any CDE system, these need to be addressed.
What to Prioritize First
If you are updating your PCI DSS program for v4.0, the order of priority for most SaaS teams:
Confirm you are on SAQ A or SAQ A-EP if eligible; if not, plan the architecture changes to get there.
Audit every script on your payment pages, document each one, implement integrity controls.
Confirm MFA is enforced for all CDE access with no exceptions.
Identify which controls require a documented analysis and complete them.
Bring minimum length and rotation requirements to v4.0 standards.
SAQ Selection Guide
Choosing the right SAQ is critical. Using the wrong one means either over-scoping (unnecessary work) or under-scoping (compliance gaps).
| SAQ | Who It Fits |
|---|---|
| SAQ A | E-commerce merchants using hosted or iframe payment pages where no card data touches your servers |
| SAQ A-EP | E-commerce merchants with JavaScript payment forms that may affect how card data is transmitted |
| SAQ B | Physical terminal environments (rarely applies to SaaS) |
| SAQ D | Any merchant that does not qualify for a simpler SAQ |
If you are unsure which SAQ applies, start with your payment processor's documentation: Stripe, Braintree, and similar processors publish guidance on which SAQ their integration supports.
The Bottom Line
PCI DSS v4.0 is not a minor version bump. The script management requirements, expanded MFA scope, and documentation obligations are real work. But for most SaaS companies, the highest-impact action remains the same as it was under v3.2.1: minimize your scope by using hosted payment fields, stay on SAQ A, and keep card data off your servers entirely.
Start there, then address the new requirements in the order above.
Getting PCI DSS v4.0 audit-ready means mapping its controls to your environment and keeping the evidence current, the kind of program a fractional CISO runs alongside your SOC 2 or ISO work. Book a call to scope your PCI path.
Related reading
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can own your SOC 2 readiness end to end, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.