PCI Compliance Requirements for SaaS Products Handling Payments

PCI DSS v4.0 replaced the 3.2.1 standard that governed card payment security for over a decade, and it changed the basic contract for SaaS companies handling transactions. The old version got retired March 31, 2024. Every assessment now runs against v4.0 (clarified slightly by v4.0.1 in 2024, which fixed wording but didn't touch requirements), and the standard added 64 new requirements, 51 of which became mandatory on March 31, 2025. A second wave of future-dated requirements is set to follow. This piece maps what actually applies to SaaS engineering teams, where scope hides, and what the infrastructure layer needs to do to keep up.

The bigger shift is philosophical. PCI DSS was never a certification you earn once and frame on a wall, the way SOC 2 or ISO 27001 sometimes get treated. It's a continuous state: documented controls, ongoing monitoring, evidence you can produce on demand. v4.0 just made that explicit and harder to fake.

Which SaaS teams are in scope and how transaction volume determines compliance obligations

Scope in v4.0 covers more than companies that store, process, or transmit cardholder data directly. Any organization that could affect the security of the cardholder data environment is in scope now, even if it never touches a card number. A billing dashboard that reads transaction metadata, a webhook processor that fires after a charge clears, an analytics tool that logs payment status: all of it counts. Indirect involvement isn't an exemption.

Using Stripe or Braintree cuts down what you have to worry about, but it doesn't hand off the obligation entirely. The processor secures its own systems. What happens on your side, how your app talks to the processor, where tokens land, who can reach that code, stays your problem.

Merchant level, based on annual transaction count, sets the specific paperwork:

• Level 1: more than 6 million transactions a year. Requires an annual Report on Compliance (ROC) done by a Qualified Security Assessor, plus quarterly external vulnerability scans by an Approved Scanning Vendor.
• Level 2: 1 million to 6 million transactions. Requires Self-Assessment Questionnaire D (SAQ D) plus the same quarterly ASV scans. Worldpay for Platforms recommends bringing in a QSA the first time a company completes SAQ D, even though it's technically self-assessed.
• Level 3: 20,000 to 1 million transactions. SAQ appropriate to the payment setup, plus quarterly scans.
• Level 4: fewer than 20,000 transactions. Compliance requirements apply at a reduced scope appropriate to the lower volume.

Which SAQ applies (A, A-EP, B, C, and so on) depends entirely on how card data physically moves through the system, not on the company's size or funding stage.

There's a commercial angle too. A compliant vendor assessment reduces what merchant customers have to independently validate on their end, which means PCI status becomes a sales asset, not just a checkbox for legal. A QSA-attested assessment can support listing on compliant service provider registries, and that kind of recognized status is a real trust signal when competing for enterprise deals where the buyer's security team is doing diligence.

Why SaaS data flows make scoping harder than it looks

The cardholder data environment, or CDE, is every system, database, service, and workflow that stores, processes, or transmits cardholder data, plus anything that could affect the security of those systems. That second clause is where most SaaS teams get surprised.

In a microservices setup, card data might pass through an authentication service, a billing engine, a webhook processor, and a reporting API, sometimes all within the same request cycle. Teams that haven't mapped this out tend to discover the real scope is much bigger than assumed, usually during an audit, or worse, after an incident. Per VISTA InfoSec's 2024-2025 fintech audit data, 70% of Level 1 findings traced back to API and webhook scope leakage, meaning systems the team assumed were out of scope, not weaknesses in the core payment stack itself.

Handling only tokens instead of raw card numbers still creates obligations under v4.0. Tokens aren't magic; they carry transaction context, and systems that process them are still part of the compliance picture, just a smaller part.

CI/CD pipelines count too. Staging environments count. Analytics tools that ingest payment events count. If any of these touch cardholder data, even briefly, they're in the CDE. The fix is simple to state and hard to enforce: pipelines must never store or transmit plain cardholder data, full stop.

Multi-tenant SaaS adds another wrinkle. If one tenant's data can somehow affect another tenant's CDE, whatever mechanism enforces that isolation, the tenancy model itself, becomes part of the audit. So the real first step, before any control gets implemented, is mapping every place card data flows. That mapping isn't prep work for the compliance exercise. It is the compliance exercise.

The new technical requirements in v4.0 that directly hit SaaS engineering teams

Several new rules land directly on engineering, not just policy documents.

MFA is now required for all access to the CDE, not just admin accounts. VPNs, cloud consoles, internal dashboards, CI/CD pipelines: all of it needs multi-factor authentication, which is a bigger lift than it sounds for teams that only ever locked down the production database.

Fixed-schedule checks are giving way to targeted risk analysis for many controls, meaning teams now have to document why they chose a given frequency for a given check, not just run it on a calendar and call it done.

Anti-phishing controls are mandatory: DMARC, SPF, and DKIM all need to be configured and verified as part of the assessment. TLS 1.2 or higher is required for cardholder data in transit, and HSTS has to be in place to stop downgrade attacks.

E-skimming protection is new and specific. Requirements 6.4.3 and 11.6.1 call for a mechanism that detects and alerts on unauthorized changes to HTTP headers and payment page content, as it actually renders in the consumer's browser. Scripts on payment pages need explicit authorization. This is aimed squarely at Magecart-style attacks, where a compromised third-party script quietly skims card data off a checkout page.

Log review can no longer be manual. Automated audit log review is required for all CDE components, which effectively means SIEM-class tooling is expected, not optional. Authenticated scanning became mandatory in March 2025 under Requirement 11.3.1.2, so scans now need credentials to get real visibility into a system, not just probe it from outside.

Penetration testing under Requirement 11.4 has to happen at least annually and after any significant environment change, following an accepted methodology like NIST SP 800-115. It has to cover the whole CDE, internal and external, network and application layers both. Password complexity rules got stricter too, and some of the access control changes will genuinely disrupt existing workflows for teams that haven't planned around them.

What cloud providers cover under shared responsibility and what they leave to the SaaS team

AWS, GCP, and Azure are responsible for the physical data centers, the core network fabric, and hypervisor integrity: the foundational layer nobody above them can touch anyway. Everything configured on top of that, application security, data handling, access controls, encryption settings, logging setup, belongs to the customer.

A provider's own PCI certification only covers the piece of infrastructure the provider manages. It says nothing about how the SaaS team configured its VPC, its IAM roles, or its logging pipeline. Security features like encryption, logging, monitoring, and access controls exist in these platforms, but they don't turn themselves on. Someone has to configure them, and that someone is the customer.

That gap is where most breaches actually happen. Per the Thales 2024 Cloud Security Study, 44% of organizations reported a cloud data breach, and the leading root cause wasn't a sophisticated attack. It was human error and misconfiguration, responsible for 31% of all cloud breaches.

Major cloud providers offer tools that surface compliance artifacts and generate raw telemetry. But centralizing that data, setting retention policies, and triaging alerts, none of that happens automatically. That's customer work.

Vercel offers both a SAQ-D AOC for service providers and a SAQ-A AOC for merchants under v4.0, and its shared responsibility model puts payment data isolation squarely on the customer, recommending an iframe integration so cardholder data flows straight to the payment gateway and never touches application infrastructure. Heroku gets assessed annually by a third-party QSA and issues its own Attestation of Compliance, but that AOC covers Heroku's assessed infrastructure components, not whatever the customer built on top of them.

No PaaS or IaaS provider's AOC substitutes for the customer's own compliance work. Auditors care about what the team configured. What the provider certified is a separate conversation.

Tokenization and network segmentation as the primary levers for reducing CDE scope

The smaller the CDE, the fewer systems have to carry the full weight of PCI DSS controls. That's the entire game, and two mechanisms do most of the work.

Tokenization replaces the actual cardholder data, principally the PAN, with a randomly generated token. The real data sits in the payment processor's token vault, never in the SaaS system at all. For subscription SaaS specifically, this is close to ideal: recurring billing runs on tokens, and raw card data never touches the platform after the initial capture. Systems that only ever see tokens fall out of scope for most PCI DSS controls, and that reduction is direct and auditable, not a judgment call.

Network segmentation isolates CDE components using VLANs, firewalls, and access control lists, so cardholder data only moves through defined, secured paths. In cloud-native environments, microsegmentation extends the same idea down to service-to-service traffic inside a microservices architecture.

Hosted payment pages and iframe integrations push this further. Card data entered into a processor-hosted iframe goes directly to the processor and never touches the SaaS application layer at all, which in many configurations drops the merchant's own scope down to SAQ A, the lightest form.

Least-privilege access, enforced through IAM roles, RBAC, and policy-based controls, limits which services and people can reach CDE systems in the first place, shrinking both the human attack surface and the service-account attack surface.

None of this counts unless it's documented. A segmentation claim that can't be demonstrated during an assessment doesn't reduce scope. It just becomes a finding.

What the infrastructure layer must deliver to stay continuously compliant

Quarterly vulnerability scans, internal and external, are required, and as of March 2025, authenticated scanning under Requirement 6 is mandatory, meaning scans need credentials to get past the surface. Scans also have to repeat after any significant network change, and in a SaaS environment running continuous deployment, that trigger fires constantly.

Containers and cloud images need regular scanning too, and the right response to a discovered vulnerability is rebuilding the image, not patching it in place after the fact.

Log aggregation and review has to be automated across every CDE component. Raw telemetry from cloud logging services needs to land somewhere centralized, get retained under a documented policy, and go through actual alert triage, not just sit in a bucket.

Annual penetration testing has to cover the entire CDE, internal and external, network and application layers, and repeat after significant changes. An annual risk assessment is required as well, and its findings need to get tracked and remediated, not just written down and filed.

Vendor management is part of the obligation too. Every third party that touches the CDE has to comply with v4.0 itself, which means contracts, ongoing monitoring, and real due diligence before signing anyone new.

The stakes for skipping any of this are concrete. Non-compliance can mean monthly fines between $5,000 and $10,000, a payment processing ban, placement on the MATCH or TMF list, loss of card-brand contracts, and higher exposure if a breach actually happens.

Infrastructure platforms that automate cluster management, CVE patching, network configuration, and compliance artifact generation cut down the operational load on teams without a dedicated security or DevOps function, which describes a large share of SaaS companies at Level 3 and Level 4.

And March 2025 wasn't the finish line. Another set of future-dated requirements is due to become mandatory in 2026, so teams that just cleared the last deadline should already be mapping which upcoming requirements actually touch their environment. Compliance here doesn't pause between deadlines. It just moves to the next one.