PCI compliance for SaaS platforms under PCI DSS v4.0.1

PCI compliance for SaaS: who PCI DSS applies to

PCI DSS, the Payment Card Industry Data Security Standard, applies to any business that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the environment where that data lives. The PCI Security Standards Council (PCI SSC) names merchants, processors, acquirers, issuers and service providers, and service providers can include payment gateways and SaaS platforms.

For a software platform, that usually means two layers. Your customers, the merchants who take card payments in your software, validate their own compliance. Your platform can also be in scope as a service provider if it handles card data for them, or if it could affect the security of the page where their customers pay.

No payment provider makes your platform compliant for you. A validated provider can shrink the part of your system that is in scope, but your own systems still have to meet the requirements that apply to them. Ask any gateway provider which network registrations and PCI DSS validation it holds.

The current version: PCI DSS v4.0.1

As of October 2026, PCI DSS v4.0.1 is the only active version of the standard. PCI SSC published it on June 11, 2024, with no requirements added or deleted. Version 4.0 was retired on December 31, 2024. The requirements that v4.0 marked as future-dated took effect on March 31, 2025, so they now apply like any other requirement.

From June 3 to July 20, 2026, PCI SSC ran a request for comments on v4.0.1, describing it as the start of the next iteration of the standard and inviting feedback on supporting future technology and AI innovation. It has announced no successor version and no timeline since, so build against v4.0.1 and watch the PCI SSC blog for news.

Validation levels are set by the card brands, not PCI SSC

PCI DSS is one standard, but how a business proves it complies depends on its validation level, and the card brands set those levels. Visa bases a merchant’s level on its total Visa transactions over 12 months. Visa’s own page does not list the thresholds, so the figures below are the typical ones given in widely used secondary summaries. Mastercard’s levels differ slightly, and acquirers can set stricter requirements.

As of October 2026, the typical Visa merchant levels are:

• Level 1. More than 6 million Visa transactions a year.
• Level 2. 1 million to 6 million Visa transactions a year.
• Level 3. 20,000 to 1 million Visa e-commerce transactions a year.
• Level 4. Fewer than 20,000 Visa e-commerce transactions a year, plus all other merchants with up to 1 million Visa transactions a year.

Service providers, which can include your platform, are typically Level 1 above 300,000 transactions a year. Level 1 means an annual on-site assessment that ends in a Report on Compliance (ROC). Level 2 service providers, below that line, are allowed to self-assess. Confirm the level that applies to your platform, and to your customers, with the acquirer involved.

Which SAQ applies

Businesses that are allowed to self-assess fill in a Self-Assessment Questionnaire (SAQ). Four SAQs matter most to platforms and their merchants. SAQ D for Service Providers is the only SAQ a service provider can use, and a service provider that is not eligible to self-assess needs a Report on Compliance instead.

Which SAQ your customers can use depends largely on how the payment page is built: whether card data ever reaches a server you run, and who controls the page that holds the payment form. Their acquirers make the final call.

The 2025 SAQ A change

PCI SSC revised SAQ A in January 2025. From March 31, 2025, it no longer includes Requirements 6.4.3 and 11.6.1, the controls on scripts in payment pages, or Requirement 12.3.1.

In their place is an eligibility criterion. As of October 2026, a merchant that uses SAQ A must confirm that its site is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

A PCI SSC FAQ from February 2025 explains how to meet it. A merchant that embeds a provider’s payment iframe can confirm eligibility in one of two ways: by using script-protection techniques like those in Requirements 6.4.3 and 11.6.1, or by getting confirmation from its PCI DSS compliant provider that the provider’s solution, used as the provider instructs, protects the page from script attacks. The criterion does not apply to full redirects (an HTTP 30x, meta or JavaScript redirect) or to merchants that fully outsource their payment functions to the provider.

For a platform, this matters most when your software builds the page that holds the payment iframe. You control the scripts on that page, so plan how your customers will answer the script criterion each time they validate.

Hosted fields, iframes and redirects reduce scope but do not remove it

Payment providers commonly offer three ways to keep card data away from your servers. A redirect sends the payer to a payment page the provider hosts. An iframe places the provider’s payment form inside your page. Hosted fields put individual card-entry fields, served by the provider, into a form you design.

Each one shrinks scope, because card numbers go to the provider instead of passing through your systems. None of them removes the obligation to validate. Your customers still validate, at least with SAQ A, and your platform still answers for the pages, scripts and systems it controls. The more of the payment page you build yourself, the more of it sits in scope.

Tokenization vs encryption

Tokenization and encryption both protect card data, but they affect your PCI scope in different ways.

For a platform, the practical test is which of your systems could ever see a full card number, or reach a decryption key or a de-tokenization service. Those systems are in scope, however the data is labeled.

Bank account data is a different rulebook

PCI DSS covers payment card data. The bank account and routing numbers you collect for ACH bank payments fall under Nacha’s Operating Rules instead, and those rules have their own data security requirement.

Under Nacha’s Supplementing Data Security Requirements rule, large non-consumer Originators, Third-Party Service Providers and Third-Party Senders must make stored bank account numbers unreadable. As of October 2026, the rule applies to any of those parties with more than 2 million ACH entries a year. That line has applied since June 30, 2022, after a first phase in 2021 covered parties above 6 million. A party that crosses 2 million entries in a year must comply by June 30 of the following year.

Encryption, truncation, tokenization and destruction all qualify, and so does letting the bank store or tokenize the numbers. Below 2 million entries a year, handling account numbers with the same care as card numbers keeps you ready if your volume grows. Our guide to ACH authorization requirements covers what else to collect and keep before you debit an account.

What to ask your payment provider

Your provider’s paperwork shows where your own work starts. Ask for these before you design your payment screens.

• Its Attestation of Compliance (AOC), the document that records the result of its latest PCI DSS assessment, and which of its services that assessment covered.
• When its next validation is due, since Visa says issuers and acquirers must make sure their service providers demonstrate compliance at least every 12 months; an AOC older than that is worth a question.
• A written split of responsibilities, showing which PCI DSS requirements the provider meets, which stay with your platform and which fall to your customers.
• Which payment page options exist, such as redirects, iframes or hosted fields, and which SAQ each one typically leaves your customers with.
• How it handles the SAQ A script criterion, if your pages embed its payment form, including whether it will confirm that its solution protects the page.
• How tokenization works, if it is offered, including where the token vault sits and which systems can turn a token back into a card number.

Example: card numbers in clinical notes

Scope often grows by accident. Picture a practice management platform where front-desk staff can type free text into a patient’s chart. To charge a balance later, a staff member types the patient’s card number into a note.

That platform now stores cardholder data. The notes database is in scope, and so are its backups, search index, exports and logs, plus every system that can reach them. A carefully built payment screen no longer limits scope, because card data came in through a side door.

The fix is a design choice. Take card payments only through the payment step, tell staff never to record card numbers or security codes in notes, and consider screening free-text fields for patterns that look like card numbers so they can be blocked or masked. For the payment side of practice software, see patient payments by card and bank in healthcare software.

Ways platforms shrink PCI scope

Most PCI scope reduction comes from design decisions you make once and then protect as your software changes.

• Keep card numbers off your servers and out of logs, including error logs, analytics events and support tickets.
• Use provider-hosted fields, iframes or redirects where your provider offers them; ask which options exist.
• Control the scripts on payment pages, because a script on the page that holds the payment form can affect its security and your customers’ SAQ A eligibility.
• Segment systems that touch payments from the rest of your platform, so fewer of your systems sit in scope.
• Never store sensitive authentication data, such as card security codes, in any system, note or log.
• Review your scope at least once a year, and again whenever you change how payments move through your software. If your platform is a service provider, ask your assessor how often it must confirm its scope.

This guide is general information, not legal or compliance advice; see our website terms and conditions. Confirm your obligations with your acquirer, your payment provider or a qualified assessor.

Sources

1. PCI Security Standards Council, PCI DSS
2. PCI SSC blog, Just published: PCI DSS v4.0.1
3. PCI SSC blog, Request for comments on PCI DSS v4.0.1
4. PCI SSC, SAQs for PCI DSS v4.0.1 bulletin
5. PCI SSC, SAQ D for Service Providers (v4.0.1)
6. PCI SSC blog, Important updates for merchants validating to SAQ A
7. PCI SSC blog, FAQ clarifies new SAQ A eligibility criteria
8. PCI SSC FAQ, How an e-commerce merchant meets the SAQ A eligibility criteria for scripts
9. PCI SSC blog, How encrypted cardholder data affects PCI DSS scope
10. PCI SSC, Tokenization guidelines information supplement
11. Visa, Security and compliance
12. Nacha, Supplementing data security requirements