PCI Compliance for SaaS Companies: Scope, Cloud and Customer Evidence

PCI compliance for SaaS starts with your role, and a SaaS company can have two. For its own subscription billing it is a merchant, which with a processor’s hosted checkout often means a short SAQ A. If its platform stores, processes or transmits card data for customers, or could affect the security of that data, it is also a service provider, and that role usually drives the effort: the payment-facing platform comes into scope, extra PCI DSS v4.0.1 requirements apply, and larger providers need an annual Report on Compliance (ROC) from a Qualified Security Assessor (QSA).

This guide explains how a SaaS business works out its role, keeps cloud scope small, handles multi-tenant rules and prepares the evidence customers will ask for.

Key takeaways

• If you handle or can affect card data for other businesses, you are a service provider, even if you never see a card number.
• Many SaaS companies are both a merchant (for their own subscriptions) and a service provider (for their customers).
• Level 1 service providers (over 300,000 Visa or Mastercard transactions a year) need a ROC from a QSA.
• Service providers have extra requirements, including six-monthly scope confirmation and segmentation testing.
• Customers will ask for your Attestation of Compliance and a responsibility matrix.

Is a SaaS company a merchant or a service provider?

It depends on whose payments your platform touches. You can be one, the other, or both. Under the PCI SSC definition, a service provider stores, processes or transmits account data for another business, or provides services that could affect its security, so a SaaS platform can qualify without ever seeing a card number. Our guide to PCI DSS for service providers covers the full definition and who else it catches.

Use this decision table to find your role, what you validate and what your customers will expect to see.

The service provider role almost always drives the effort, because it brings your whole payment-facing platform into scope. For your merchant billing, our guide to PCI SAQ A and SAQ A-EP explains how checkout design sets your questionnaire, and our free PCI compliance check suggests the likely one for each role.

What does the service provider role add for a SaaS platform?

Two things: a validation level and a set of extra requirements. Under Visa and Mastercard rules, a SaaS platform handling more than 300,000 transactions a year on either brand for its customers is a Level 1 service provider and needs an annual ROC from a QSA, while smaller platforms may use SAQ D for Service Providers; PCI DSS v4.0.1 then adds service-provider-only requirements such as six-monthly scope confirmation and segmentation testing every six months. Our guide to PCI DSS for service providers sets out the levels by card brand and the full list of extra requirements, and a ROC is delivered through a PCI compliance audit.

What extra rules apply to multi-tenant and cloud providers?

If customers share your infrastructure, Appendix A1 applies. It requires logical separation between customer environments, confirmed by penetration testing at least every six months, logging and audit trails for each customer, processes to support forensic investigation, and suspected incident handling for each customer. Requirement 11.4.7 adds that you must support customers who need to penetration test their part of your service.

If you build on AWS, Azure or Google Cloud, their Attestations of Compliance cover the infrastructure and managed services they operate. They do not cover your IAM, security groups, encryption, logging or code. A responsibility matrix showing which requirements the cloud provider meets, which you meet and which are shared is essential evidence. Our guide to AWS PCI compliance shows where that line falls on AWS.

How do you keep a SaaS platform’s PCI scope small?

Scope covers every system component that stores, processes or transmits account data, plus anything connected to it or able to affect its security. In the cloud, that spreads quickly into CI/CD pipelines, identity providers, logging platforms and administrator devices. The most effective limits are:

• Tokenisation, so a compliant provider holds the card data and your platform only stores tokens.
• Separate accounts or subscriptions for the CDE, with their own identity boundary.
• Network segmentation using VPCs, security groups and private endpoints, with no shared admin accounts across zones.
• Keeping card data out of logs, support tools and analytics.

Our PCI DSS scoping guide covers the method. Whatever you choose, segmentation must be proved by PCI DSS penetration testing every six months.

What will your customers ask for?

Your customers have their own obligations under Requirement 12.8 to manage their providers, so expect to be asked for:

• Your current Attestation of Compliance, covering the services they use.
• A responsibility matrix showing which requirements you manage for them, which they manage and which are shared (12.8.5 and 12.9.2).
• A written acknowledgement of your responsibility for the account data you handle (12.9.1).
• Notice of changes to your compliance status.

Enterprise customers often expect a QSA-signed ROC even where SAQ D would be allowed. Plan for that if you sell upmarket.

PCI compliance for SaaS in seven steps

1. Define your role and scope. Map card data flows for your own billing and every customer-facing payment feature.
2. Reduce scope. Tokenise, use hosted payment components and isolate the CDE.
3. Run a gap analysis against the applicable requirements, including the service-provider-only ones. Our guide to a PCI DSS gap analysis explains what it involves.
4. Remediate, starting with controls that need a track record, such as quarterly scans, quarterly staff reviews and log review.
5. Test. Commission web application penetration testing and cloud penetration testing alongside the segmentation tests. Our guide to SaaS penetration testing explains the tenant isolation testing that enterprise customers also ask about.
6. Validate with SAQ D for Service Providers or a ROC, and publish your AOC to customers.
7. Maintain compliance with named owners for every six-monthly and quarterly task.

A PCI DSS consultant can shorten steps 1 to 4 considerably, particularly for a first ROC.

Working with a QSA company

Sovereign Secure is a PCI SSC-approved Qualified Security Assessor company and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026-2028. We help SaaS companies with every stage of PCI compliance: confirming their role and scope, preparing for validation and completing their ROC, so the AOC is ready when customers ask for it. Advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company.

If you are not yet sure which role applies, our free PCI compliance check takes about five minutes. When you are ready to plan a ROC or SAQ D for Service Providers, contact us for a scoping call, or see our PCI DSS compliance services for the full range.