PCI DSS : What SaaS Platforms Owe Their Customers Under v4.0.1
A common misconception in the B2B software world is that if you never see, process, or store a Primary Account Number (PAN), PCI DSS does not apply to you.
Under PCI DSS v4.0.1, custody is only half the equation. The standard explicitly pulls in any entity that could affect the security of a customer's cardholder data environment (CDE). If your SaaS delivers a script, manages an API gateway, hosts an iframe wrapper, or provides infrastructure connected to an e-commerce checkout page, you are a Third-Party Service Provider (TPSP).
That classification brings a specific operational cadence, contractual obligations, and specialized testing requirements that standard merchant assessments never encounter.
Core Service-Provider-Only Rules at a Glance
PCI DSS v4.0.1 contains 11 core clauses explicitly tagged "Additional requirement for service providers only" across Requirements 1 through 12, flanked by the dedicated Section 12.9, a multi-tenant clause at 11.4.7, and Appendix A1.
The service provider clauses that set your calendar
Seven requirements in PCI DSS v4.0.1 that apply to service providers rather than to their customers, grouped by how often each one comes due.
| Requirement | Cadence or focus | What it demands |
|---|---|---|
| 10.7.1 to 10.7.3 | Immediate | Detect, alert, respond to, and document failures of critical security controls promptly. |
| 11.4.6 | Every 6 months and after change | Penetration test all segmentation controls isolating the CDE from out-of-scope systems. |
| 11.4.7 | Multi-tenant | Support and provide access for multi-tenant customer-initiated external penetration tests. |
| 12.4.2 | Quarterly | Confirm operational security procedures are followed, reviewed by personnel independent of the task. |
| 12.5.2.1 | Every 6 months and after change | Document and confirm overall PCI DSS scope, identifying all connection points and dependencies. |
| 12.9.1 | Master services agreement | Provide written acknowledgment to customers accepting responsibility for account data security. |
| 12.9.2 | On request | Provide compliance status and a granular requirement-by-requirement responsibility matrix. |
Source: PCI DSS Requirements and Testing Procedures, v4.0.1
The Reach of Security Influence: How SaaS Lands in Scope
Under Requirement 6.4.3 and Requirement 11.6.1, merchants must inventory, authorize, and verify the integrity of all scripts running in the consumer’s browser on payment pages.
If an e-commerce brand drops your SaaS tag, live-chat widget, or analytics script onto their checkout flow, your infrastructure has the technical capability to modify the DOM, alter script execution, or redirect sensitive data. Even though you never intended to touch card numbers, your code runs in an environment that handles them. You affect their security posture, which establishes your status as a service provider under PCI DSS rules.
A SaaS provider cannot rely on a generic disclaimer. Every product, integration method, and hosted feature must be cataloged based on whether it touches data or could impact the security boundary around it.
The Service Provider Operating Rhythm
The requirements specific to service providers transform compliance from an annual audit exercise into an active operational calendar.
1. The Six-Month Testing Windows (11.4.6 & 12.5.2.1)
Merchants typically validate their network segmentation once a year under Requirement 11.4.5. Service providers do not get that runway. Requirement 11.4.6 requires penetration testing on segmentation controls every six months and after any significant change to verify that out-of-scope networks cannot reach customer environments. Requirement 12.5.2.1 requires an official scope confirmation on the same six-month schedule.
2. Independent Quarterly Reviews (12.4.2)
Every three months, the platform must verify that operational personnel are adhering to documented security procedures, including firewall reviews, log reviews, and configuration checklists. The reviewer must be independent of the team that executed the actual operational task.
3. Immediate Failure Alerting (10.7.1 through 10.7.3)
If a critical security control drops offline (such as an endpoint detection agent failing, a firewall rule dropping, or logging halting), service providers must have automated mechanisms to detect the issue, sound operational alerts, and execute restoration protocols immediately.
Why an Attestation of Compliance (AOC) Is Not Enough
Enterprise procurement teams often request an AOC and consider the check complete. Requirement 12.9.1 makes that approach invalid for both sides.
Requirement 12.9.1 Applicability Note: An Attestation of Compliance (AOC), a general marketing statement, or a website terms-of-service link does not satisfy the written acknowledgment requirement.
Requirement 12.9.1 mandates that service providers supply customers with a formal, written agreement explicitly confirming responsibility for the security of account data they store, process, transmit, or could otherwise impact. This belongs directly in the Master Services Agreement (MSA) or a signed Security Addendum.
Requirement 12.9.2 then requires providers to deliver two assets upon request:
Written confirmation of current PCI DSS compliance status.
A customer responsibility matrix (CRM) indicating precisely which PCI DSS requirements are the provider's responsibility, which belong to the customer, and which are shared.
Pre-building this matrix avoids contract delays and ensures customer security teams can complete their own vendor reviews under Requirements 12.8.4 and 12.8.5.
Multi-Tenant Architectures and Appendix A1
Most SaaS environments run multi-tenant architectures where client data resides on shared database clusters or containerized infrastructure.
Appendix A1 applies directly to multi-tenant service providers. Under A1.1.4, you must run penetration testing every six months to confirm logical separation between tenants holds under hostile conditions. Under A1.2.3, you must maintain isolated, secure channels for customers to report suspected security incidents.
A carve-out exists for providers selling solely unmanaged physical data center space, power, and raw transit lines on a rental basis. Cloud-native software running containers, serverless functions, or shared application logic does not qualify for that carve-out.
Who Sets Your Validation Route?
A frequent point of confusion is looking to an acquiring bank for validation tier guidance. Most B2B SaaS platforms have no merchant accounts and no acquirers.
Your validation route (completing an on-site Report on Compliance via a Qualified Security Assessor versus completing SAQ D for Service Providers) is determined by two factors:
Payment Brand Direct Programs: Programs like Visa’s Global Third-Party Beneficiary/Agent Program and Mastercard’s Site Data Protection (SDP) define volume thresholds and categorization for Level 1 and Level 2 service providers.
Customer Contractual Mandates: Large enterprise merchants often require their critical SaaS vendors to produce a QSA-signed ROC and AOC, regardless of whether the card brands classify them as Level 2.
Where self-assessment is permitted, SAQ D for Service Providers is the only SAQ available. There is no shortened questionnaire for service providers; every applicable clause in the standard must be evaluated.
Action Plan for SaaS Product and Compliance Teams
Map security influence, not just card flows: Review all client-facing libraries, APIs, and client-side JavaScript tags. If code runs on or talks to a payment surface, scope it.
Embed 12.9.1 in standard legal terms: Update standard MSA or Data Processing Addendum templates to include the specific PCI DSS acknowledgment language.
Build the Customer Responsibility Matrix: Document the division of controls for every service tier before enterprise procurement requests it under 12.9.2.
Set calendar cadences: Lock in three-month intervals for independent procedure reviews (12.4.2) and six-month intervals for segmentation penetration testing (11.4.6) and scope re-verification (12.5.2.1).
Sources and Regulatory References
PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1, June 2024. pcisecuritystandards.org
PCI Security Standards Council, PCI DSS v4.0.1 Self-Assessment Questionnaire D for Service Providers, June 2024. pcisecuritystandards.org
PCI Security Standards Council, PCI DSS v4.0.1 Report on Compliance and Attestation of Compliance for Service Providers, June 2024. pcisecuritystandards.org
Regulatory Disclaimer: This article summarizes publicly available PCI Security Standards Council documentation for educational purposes. It does not constitute formal assessment findings, legal counsel, or an official scoping determination. Compliance obligations are governed by individual payment brand rules, enterprise customer agreements, and designated Qualified Security Assessors.
Frequently asked
PCI DSS service provider requirements, answered
PCI DSS service provider requirements are the fifteen clauses in Requirements 1 through 12 of PCI DSS v4.0.1 labeled as applying to service providers only, covering cryptographic architecture, remote access, personnel reviews, scope confirmation and customer acknowledgments. A sixteenth clause, 11.4.7, applies to multi-tenant providers, and Appendix A2 adds two more for legacy SSL and early TLS connection points.
PCI DSS applies to SaaS companies that could impact the security of cardholder data, even when they never store, process or transmit it. The standard lists software as a service among the vendor types to which PCI DSS may apply. A platform whose script loads on a payment page, or whose staff hold remote access into a customer environment, meets that test.
An Attestation of Compliance does not satisfy PCI DSS Requirement 12.9.1, which calls for a written agreement in which the service provider acknowledges responsibility for the security of customer account data. The applicability note names an AOC, a website declaration, a policy statement and a responsibility matrix as evidence that falls short of that written acknowledgment.
Requirement 12.9.2 requires a service provider to give customers, on request, its PCI DSS compliance status and a statement of which PCI DSS requirements are the provider's responsibility, which are the customer's, and which are shared. Those two items let the customer satisfy its own obligations under Requirements 12.8.4 and 12.8.5.
SAQ D for Service Providers is the only Self-Assessment Questionnaire available to service providers under PCI DSS, and it applies to every service provider a payment brand has deemed eligible to self-assess. Providers outside that eligibility complete a Report on Compliance and the service provider Attestation of Compliance instead.
Source: PCI DSS Requirements and Testing Procedures, v4.0.1
