PCI DSS service provider levels and what SaaS owes
By Sam Rivera, Founder, SentinelPanda · February 9, 2026 · 3 min read · PCI DSS
If your software handles card data on behalf of your customers, you are a service provider in the PCI DSS sense. The customer-facing AOC you owe is one of the most common compliance artifacts you will be asked for.
Who counts as a service provider
Service providers under PCI DSS are not just payment gateways and acquirers — the definition covers any company that stores, processes, or transmits cardholder data on behalf of another entity. That includes managed hosting providers handling CDE systems, fraud prevention services that see transaction data, tokenisation vendors, payment-page widget providers, and most SaaS companies whose customers configure card-data-touching workflows on top of them.
The definition extends further: any service that could impact the security of cardholder data, even without directly handling it (a managed firewall service for a CDE, for example) is a service provider for PCI purposes.
Level 1 service providers
Most card brands define Level 1 service providers as those storing, processing, or transmitting more than 300,000 transactions per brand per year, with brand-specific variations. Level 1 service providers must validate annually with a ROC issued by a QSA, plus quarterly ASV scans, an annual internal vulnerability scan, and an annual penetration test (including segmentation testing every six months for service providers, more frequent than the annual cadence required of merchants).
A specific designation by a card brand can elevate any service provider to Level 1 regardless of transaction volume — this is common after a breach or for service providers handling particularly sensitive data flows.
Level 2 service providers
Service providers below the Level 1 threshold can typically validate with SAQ D-Service Provider — a long-form self-assessment that walks every PCI DSS requirement applicable to service providers. Customers, however, often prefer a ROC-issued AOC because it carries an external assessor's name, so many growth-stage service providers move to a ROC ahead of the strict Level 1 threshold.
A Level 2 service provider with even a handful of enterprise customers usually ends up doing the ROC anyway. The economics tilt fast.
What service providers owe customers
PCI DSS requires service providers to maintain a list of their PCI DSS responsibilities and to share that list with customers in writing. The classic artefact is the AOC plus a "responsibility matrix" — a per-requirement table identifying which controls the service provider owns, which the customer owns, and which are shared.
For SaaS companies serving merchants, the AOC is also a sales asset. Procurement teams treat its absence as a deal-blocker; treat its presence as a baseline expectation.
The Section 12.8 / 12.9 chain
Merchants are required (Req 12.8) to maintain a list of their service providers, perform due diligence before engagement, and monitor their compliance status annually. Service providers are required (Req 12.9) to acknowledge in writing their responsibility for the cardholder data they handle and to maintain PCI DSS compliance.
In practice this means: as a service provider, you will receive recurring compliance evidence requests from every merchant customer at their annual revalidation, and you need a defensible process for responding without losing a person-week to each one.
Additional service-provider requirements
- Internal vulnerability scans at least once every three months (Req 11.3.1.1) — quarterly, not annually.
- Segmentation testing every six months (Req 11.4.5) — twice the merchant cadence.
- A documented Targeted Risk Analysis for any control where the standard allows entity-defined frequency.
- Service-provider-specific responsibilities in Section 12 around customer responsibility documentation.