PCI DSS for SaaS Companies and Payment-Enabled Platforms

For SaaS and Platform Operators

• Classify your role: merchant-only, service provider, or both
• Scope multi-tenant boundaries and collect isolation evidence
• Provide customers clear responsibility matrices (Requirement 12.9.2)
• Expect Describe Results and deeper documentation on SAQ D for Service Providers

For Merchants Using SaaS Checkout

• Prefer fully outsourced payment page elements (SAQ A) versus merchant-delivered scripts (SAQ A-EP)
• Confirm TPSP compliance for services used; monitor per Requirement 12.8
• Remember ASV obligations on redirect/iframe hosts under SAQ A

How CyberSilo Helps

• Multi-tenant logging and monitoring patterns in ThreatHawk
• CSA for service-provider assessments
• Merchant SAQ path workshops for platforms and their customers

Frequently Asked Questions

We never see raw PAN - only tokens from a processor. Are we out of scope?

Maybe reduced, not automatically out. Connected systems, admin access, scripts, and whether you can impact payment security still matter. Confirm with your QSA.

Can we give customers our AOC and call them compliant?

No. PCI DSS is explicit: a compliant TPSP does not make the customer compliant.

Is a major payment SaaS "PCI compliant" enough for us?

Their validation helps your TPSP file; you still choose the correct SAQ or ROC path for your role and architecture.

Related PCI Resources

SAQ A · SAQ A-EP · SAQ D · Merchants vs service providers · PCI on AWS · PCI on Azure · ROC and AOC