The short answer
A PCI DSS service provider is a business that stores, processes or transmits cardholder data for another business, or can affect its security. Under Visa and Mastercard rules, providers handling more than 300,000 transactions a year are Level 1 and need an annual Report on Compliance from a QSA. Smaller providers can usually use SAQ D for Service Providers.
On this page
- What is a PCI compliance service provider?
- What are the PCI DSS service provider levels?
- PCI DSS requirements for service providers: what applies only to you
- ROC or SAQ D: what do service providers submit?
- Do payment facilitators and ISOs need PCI DSS?
- What is a responsibility matrix, and why do customers ask for one?
- How does a PCI compliance assessment for a service provider run?
- Why Sovereign Secure
- Get your service provider route confirmed
PCI compliance for a service provider means meeting every applicable PCI DSS v4.0.1 requirement, plus a set of requirements that apply only to service providers, and proving it to the card brands, your acquirer and your customers every year. Level 1 service providers validate with a Report on Compliance (ROC) from a Qualified Security Assessor (QSA); smaller providers can usually use SAQ D for Service Providers. Either way, the document your customers will ask for is the Attestation of Compliance (AOC) for Service Providers.
Sovereign Secure is a PCI SSC-approved QSA company that assesses service providers and signs the AOC for Service Providers their customers rely on. Looking for a company that provides PCI compliance services rather than the rules for service providers? See our PCI compliance services.
What is a PCI compliance service provider?
A PCI compliance service provider, in PCI DSS terms a third-party service provider (TPSP), is a business that is not a payment brand and that stores, processes or transmits account data on behalf of another entity, or provides services that control or could affect the security of that data. You can be a service provider without ever seeing a card number. A business that provides only public network access, such as a telecoms link, is not a service provider for that service. TPSP is the term PCI DSS v4.0.1 uses in Requirement 12.8, where it sets out how the merchants and other businesses that rely on you must manage you.
| Business | Why PCI DSS treats it as a service provider |
|---|---|
| Payment gateway or processor | Transmits or processes card data for merchants |
| Payment facilitator | Processes payments on behalf of its sub-merchants |
| Hosting, cloud or colocation provider | Hosts systems in a customer’s cardholder data environment (CDE); see PCI compliant hosting |
| Managed security or IT provider | Manages firewalls, logging or access that protect a customer’s CDE |
| Outsourced contact centre | Takes card payments by phone for its clients |
| SaaS platform with embedded payments | Handles, or controls the pages that collect, its customers’ card data |
Many businesses are both. A SaaS company is a merchant for its own subscription billing and a service provider for the payments its platform handles, and each role is validated separately. Our guide to PCI DSS for SaaS companies works through that split. Processors and payment firms connected to the Swift network have a separate annual obligation; our SWIFT CSP assessment guide shows where PCI DSS evidence overlaps.
What are the PCI DSS service provider levels?
There are two service provider levels, set by the card brands, not by the PCI SSC. Visa places all VisaNet processors, and Mastercard several provider types, at Level 1 whatever their volume. Our PCI Level 1 guide explains what a Level 1 service provider must prepare for.
| Level | Visa | Mastercard | How you validate |
|---|---|---|---|
| Level 1 | VisaNet processors, and any service provider that stores, processes or transmits more than 300,000 Visa transactions a year | All Third-Party Processors, Staged Digital Wallet Operators, Digital Activity Service Providers, Business Payment Service Providers, Token Service Providers, 3-D Secure Service Providers, Installment Service Providers and Merchant Payment Gateways; plus AML/Sanctions Service Providers, Data Storage Entities and Payment Facilitators with more than 300,000 combined Mastercard and Maestro transactions a year | Annual ROC by a QSA, AOC for Service Providers, quarterly ASV scans |
| Level 2 | Any service provider with fewer than 300,000 Visa transactions a year | AML/Sanctions Service Providers, Data Storage Entities and Payment Facilitators with 300,000 or fewer combined Mastercard and Maestro transactions a year, and all Terminal Servicers | Annual SAQ D for Service Providers, AOC for Service Providers, quarterly ASV scans |
Both brands’ levels are as published on their compliance pages, checked on 13 October 2026. Mastercard also recommends that Level 1 and 2 providers validate against the Designated Entities Supplemental Validation (Appendix A3), and lets a qualifying Level 2 Data Storage Entity submit a PCI PIN AOC from a Qualified PIN Assessor every two years instead. Confirm your level with your acquirer. Merchant levels are in our guide to PCI compliance levels.
PCI DSS requirements for service providers: what applies only to you
PCI DSS v4.0.1 marks a number of requirements “additional requirement for service providers only”. These PCI requirements for service providers sit on top of everything a merchant must do. Several were future-dated in v4.0 and have been mandatory since 31 March 2025, so any assessment now includes them.
| Requirement | What it asks | Mandatory since 31 March 2025? |
|---|---|---|
| 3.6.1.1 | A documented description of the cryptographic architecture protecting stored account data: algorithms, keys, key usage and an inventory of HSMs and other key management devices | Partly: the bullet preventing the same keys being used in production and test |
| 8.2.3 | Unique authentication factors for each customer premises you can access remotely | No, already required |
| 8.3.10.1 | Where passwords are the only factor for customer users, change them at least every 90 days or assess account security dynamically | Yes |
| 11.4.6 | Penetration test segmentation controls at least every six months and after any change to them | No, already required |
| 11.4.7 | Multi-tenant providers support customers’ external penetration testing | Yes |
| 11.5.1.1 | Detect, alert on or prevent, and address covert malware communication channels | Yes |
| 12.4.1 | Executive management takes responsibility for protecting card data and for a PCI DSS compliance programme with a charter | No, already required |
| 12.4.2 and 12.4.2.1 | At least every three months, someone other than the task owner checks that security procedures are followed, and the review is documented | No, already required |
| 12.5.2.1 | Confirm PCI DSS scope at least every six months and after significant change | Yes |
| 12.5.3 | Review the effect on scope of significant changes to organisational structure | Yes |
| 12.9.1 | Acknowledge in writing to customers your responsibility for the account data you handle | No, already required |
| 12.9.2 | Give customers, on request, your compliance status and which requirements are yours, theirs or shared | No, required since v4.0 |
Requirement 10.7.1, detecting failures of critical security controls, was a service-provider-only requirement until 31 March 2025, when 10.7.2 extended it to every entity. If you are a multi-tenant provider, Appendix A1 also applies: logical separation between customers, confirmed by penetration testing every six months, plus per-customer logging, forensic support and incident handling. Our PCI DSS penetration testing covers the six-monthly segmentation and separation tests.
ROC or SAQ D: what do service providers submit?
Level 1 providers submit a ROC from a PCI QSA; Level 2 providers may use SAQ D for Service Providers, the only questionnaire open to service providers. It covers every applicable requirement, including the service-provider-only ones, so self-assessing does not shrink the workload. The customised approach is only available through a ROC. For a quick first view of your gaps, our free PCI compliance check has a service provider option.
Both routes end in an AOC for Service Providers, a separate PCI SSC template from the merchant version. It names the services assessed and any you provide that were not, so customers can check it covers what they buy. Our guide to the Report on Compliance and AOC explains what each document contains, and our guide to PCI SAQ D covers the merchant version.
Many Level 2 providers involve a QSA anyway. Visa requires QSA validation before it lists a provider on its Global Registry of Service Providers, the public list merchants use to check PCI compliant service providers, and banks and large merchants often write a QSA-signed AOC into their contracts.
Do payment facilitators and ISOs need PCI DSS?
Payment facilitators do. A payment facilitator processes payments on behalf of its sub-merchants under an acquirer’s sponsorship, so it validates as a service provider. Mastercard places them at Level 1 above 300,000 combined Mastercard and Maestro transactions a year. Your acquirer will also expect you to manage your sub-merchants’ compliance, so the programme has two halves: your own validation and a sub-merchant programme.
Independent sales organisations (ISOs) depend on what they do. An ISO that only signs up merchants, and never handles card data or affects its security, must still be registered (Visa runs a Third Party Agent registration programme) but may not need to validate as a service provider. An ISO that runs a gateway, hosts payment pages or manages terminals is a service provider. Your sponsoring acquirer confirms what applies. Our page on fintech cyber security covers the wider picture for payments firms.
What is a responsibility matrix, and why do customers ask for one?
Customers ask because PCI DSS requires them to. Requirement 12.8.4 makes them monitor your compliance status at least every 12 months, and 12.8.5 makes them record which requirements you manage, which they manage and which are shared. Requirement 12.9.2 obliges you to provide that information on request, and a responsibility matrix is the usual format. An illustrative extract for a managed hosting provider (yours will depend on your contracts and architecture):
| PCI DSS requirement | Provider | Customer |
|---|---|---|
| 1: Network security controls | Platform perimeter and shared network | Customer-configured rules and security groups |
| 8: Identification and authentication | Provider administrators | Customer users and application accounts |
| 9: Physical access | Data centres and media | Customer’s own premises, where in scope |
| 10: Logging and monitoring | Platform and infrastructure logs | Application and customer system logs |
How does a PCI compliance assessment for a service provider run?
- Discovery. Your services, card brands, level and what major customers ask for.
- Scoping. Which services the AOC will cover, data flows, multi-tenancy and segmentation, documented to meet Requirement 12.5.2.1.
- Readiness (optional). A gap analysis through our PCI DSS consultancy. Where we both advise and assess, advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company, and consultancy never buys an easier assessment.
- Testing. Penetration and segmentation testing, and quarterly external scans through our PCI SSC Approved Scanning Vendor partner (Sovereign Secure is not itself an ASV).
- Assessment. Interviews, configuration review, sampling and observation across every in-scope requirement.
- Reporting. The ROC passes our internal quality review, then our QSA signs the AOC for Service Providers.
Fieldwork follows our PCI compliance audit method. Processors that also handle PINs or keys can have the PCI PIN work planned alongside, because we are also a Qualified PIN Assessor.
Why Sovereign Secure
- Five PCI SSC approvals. Sovereign Secure Ltd (Companies House 08334453, incorporated 2012, Accrington, Lancashire) is a QSA company, Qualified PIN Assessor, Card Production Security Assessor, P2PE Assessor (Europe and USA) and 3DS Assessor, so providers that also run P2PE or 3DS services can be assessed by one team. Our entry on the Qualified Security Assessor list covers Europe, CEMEA, Asia Pacific, the USA and Canada (checked 13 October 2026).
- Part of the assessor community. We are a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026-2028.
- Testing alongside the assessment. We carry out the penetration and segmentation testing, with ASV scans through our PCI SSC Approved Scanning Vendor partner.
- Payments clients. Clients shown on our site include Fiserv, Cashplus and Liquid Pay. We are also ISO 27001 certified.
Get your service provider route confirmed
Tell us what services you provide, which card brands you handle and what your customers are asking for. We will confirm your level, whether a ROC or SAQ D applies, and send a fixed quote. Contact our PCI team or call +44 161 523 5276.
Last reviewed October 2026 by the Sovereign Secure assessment team.
