You're the security lead at a SaaS company that processes payments for enterprise merchants. Your acquirer has asked for a Level 1 service provider Report on Compliance, but the security vendor you already use only performs an annual penetration test. The sales team says the company is secure. The assessor asks for current scans, segmentation evidence, responsibility documentation, and artifacts that map to specific PCI DSS requirements.
That gap is where many PCI DSS engagements go wrong. A penetration test is important, but it isn't a ROC. An ASV scan isn't a penetration test. A compliance dashboard doesn't prove that segmentation works. PCI DSS service providers may bundle these activities under one statement of work, yet each produces different evidence, follows a different cadence, and carries a different responsibility.
Table of Contents
- When You Realize You Need a PCI DSS Service Provider
- What a PCI DSS Service Provider Actually Is
- Service Provider Levels and Required Evidence
- Recurring Technical Controls That Prove Compliance
- The Four Services Often Sold as One
- How to Assess and Choose the Right Provider
- Why Service Provider Selection Is Now a Continuous Decision
- Bringing It All Together
When You Realize You Need a PCI DSS Service Provider
The first warning usually arrives in an email from an acquirer, enterprise customer, or payment partner. The message asks for an Attestation of Compliance, a current Report on Compliance, or confirmation that a provider handling payment infrastructure is compliant. Your team searches the security folder and finds a penetration-test report, a SOC 2 report, and a collection of vulnerability tickets. None of those documents answers the request completely.
That situation is common for mid-market MSSPs, cloud platforms, hosted commerce providers, and SaaS vendors. They may operate firewalls, identity systems, hosting platforms, payment integrations, or software that can affect a customer's cardholder data environment. They often perform sound security work, but they haven't built an evidence process around PCI DSS service-provider validation.
Practical rule: A security activity only satisfies an audit when its scope, method, timing, and attestation match the applicable PCI DSS requirement.
The distinction matters because a service provider can be in scope even when it doesn't store cardholder data directly. A managed firewall provider, hosting company, web application provider, or software vendor may still influence the security of another organization's payment environment. Once that relationship exists, customers may ask for evidence that the provider understands its responsibilities and can produce documentation on demand.
This article focuses on the operational questions that determine whether a provider is useful in practice:
- What qualifies as a PCI DSS service provider, including providers that can affect cardholder-data security without handling the data.
- Which validation tier applies, and whether the expected output is a ROC or SAQ D for Service Providers.
- What technical evidence recurs, including ASV scanning, vulnerability testing, penetration testing, and segmentation validation.
- What bundled services include, because assessment, scanning, managed compliance, and remediation aren't interchangeable.
- How to test a provider's operating model, especially when your environment changes between assessment windows.
The right engagement leaves an assessor with a defensible audit trail, not just a polished security presentation.
What a PCI DSS Service Provider Actually Is
PCI DSS treats a service provider as a business entity that isn't a payment brand and that processes, stores, or transmits cardholder data for another organization, or provides services that control or could impact the security of that data. That definition reaches beyond payment gateways and processors. It can include hosting companies, managed firewall providers, data-center operators, tokenization platforms, and technology vendors whose access or controls affect a customer's cardholder data environment.
The practical test is influence. Ask whether the provider can change, expose, restrict, monitor, authenticate, or otherwise affect systems that protect payment data. If the answer is yes, the provider may be relevant to the customer's PCI DSS scope even if the provider never sees a primary account number.
Why the classification changes the engagement
Merchants usually assess the environment supporting their own payment acceptance. Service providers may support several customers, each with different architectures, integrations, and responsibility boundaries. A weakness in a shared management plane, authentication system, network control, or hosting layer can therefore affect more than one merchant.
PCI DSS gives service providers additional scrutiny because the provider's controls may influence multiple cardholder-data environments. Customers commonly request an AOC, a responsibility statement, and a clear explanation of which PCI DSS requirements the provider manages. A responsibility matrix is especially useful when a cloud platform, MSSP, or hosting provider controls only part of the customer's environment.
The classification also interacts with the merchant's own risk profile. A payment business serving a high-risk merchant PCI DSS customer may need tighter documentation around outsourced systems, payment flows, and third-party responsibilities, even where the provider doesn't directly process card data.
Common classification mistakes
A SOC 2 report doesn't automatically establish PCI DSS compliance. It may provide useful evidence about security controls, but PCI DSS uses its own requirements, validation forms, and payment-brand or acquirer expectations. The same applies to an MSSP contract. A provider that manages security tools for a merchant may still need to document its PCI responsibilities.
Internal IT teams aren't normally service providers to their own company. They are part of the organization's internal control structure. The classification is about an external business entity providing services to another entity, or about a provider whose services can affect the other entity's cardholder-data security.
Start with data flows, administrative access, shared infrastructure, and control ownership. Don't begin with the vendor's marketing category.
Service Provider Levels and Required Evidence
Service-provider validation generally follows a two-tier model. Organizations processing more than 300,000 annual transactions are typically treated as Level 1 service providers, although payment brands or acquirers can designate a provider differently. Organizations below that operational threshold are generally treated as Level 2 service providers. The threshold and governance context are summarized in the history of PCI compliance, which also explains how the framework developed across the founding card brands.
The tier determines the usual validation route, but it doesn't eliminate the need to confirm requirements with the relevant acquirer and brands. A Level 2 provider may be allowed to self-assess, while a customer or acquirer may still require a QSA-led ROC. Buyers should treat the tier as a starting point, not as a substitute for written validation requirements.
Comparing the evidence package
| Requirement | Level 1 Service Provider | Level 2 Service Provider |
|---|---|---|
| Assessment approach | Annual assessment performed by a PCI SSC-qualified QSA | Typically self-assessment using SAQ D for Service Providers |
| Primary report | Report on Compliance, or ROC | SAQ D for Service Providers |
| Attestation | Attestation of Compliance, or AOC | AOC supporting the applicable SAQ |
| External testing | Quarterly ASV scans, with documented results | Quarterly ASV scans where applicable to the environment and validation requirements |
| Penetration testing | Annual internal and external penetration testing, plus change-triggered testing | Required controls still apply where relevant, with the validation method confirmed by the provider's assessor or acquirer |
| Segmentation evidence | Validation at least every six months when segmentation is used to isolate the CDE | The same service-provider segmentation obligation applies when segmentation is used |
| Buyer-facing material | Current AOC, ROC availability or relevant excerpts, responsibility statement, and responsibility matrix | Current AOC, SAQ-related evidence, responsibility statement, and responsibility matrix |
A Level 1 provider should be prepared to show an annual ROC attested by a QSA, along with its AOC and supporting evidence. A Level 2 provider may use SAQ D for Service Providers, but the buyer should still ask for the completed attestation, scope description, exceptions, remediation status, and evidence supporting recurring controls.
The PCI DSS compliance testing guidance is useful when translating these validation paths into a testing plan. The key question isn't whether a vendor says “PCI compliant.” Ask which entity performed the assessment, which environment was assessed, which version of the standard applied, and what evidence remains available after the engagement closes.
Recurring Technical Controls That Prove Compliance
Annual paperwork does not replace technical evidence collected throughout the year. A PCI DSS service provider needs records showing what was tested, when it was tested, what failed, how it was remediated, and whether the retest passed. This evidence separates an operating control from a compliance statement.
External ASV scans are performed by an approved scanning vendor and generally run quarterly. Results should identify covered assets, scan dates, failures, exceptions, remediation actions, and passing status. A dashboard screenshot without asset coverage or scan history gives an assessor little to verify.
Internal vulnerability scanning should connect to the organization's change process. Significant system modifications should trigger scanning, remediation, and rescanning until relevant findings are resolved or formally addressed. The QSA will usually examine how the team identifies changes and links them to testing records.
PCI DSS v4.0.1 Requirement 11.4.2 and Requirement 11.4.3 require internal and external penetration testing at least once every 12 months, and again after a significant infrastructure or application upgrade or change, as described in this PCI DSS penetration-testing guidance. For service-provider testing cadence and evidence expectations, see this PCI DSS penetration testing resource. Change management therefore forms part of the penetration-testing control, rather than remaining only an engineering workflow.
Segmentation needs its own proof
A provider's claim that segmentation reduces scope has value only when testing demonstrates that the boundary works. For service providers, segmentation validation is required at least every six months when segmentation isolates the cardholder data environment, and it must be repeated after relevant network or segmentation changes. Segmentation testing guidance explains why this service-provider-specific cadence matters in shared and multi-tenant environments.
A useful evidence folder contains network diagrams, test methodology, source and destination coverage, observed paths, failed controls, remediation tickets, retest results, and approval records. Missing dates or vague scope statements create audit doubt even when the technical control is sound.
The Four Services Often Sold as One
A provider may place four distinct services under one commercial package. That can be convenient, but it can also hide gaps. The buyer should identify the deliverable behind each line item before comparing prices.
| Service | Deliverable | Cadence | Who Delivers It |
|---|---|---|---|
| QSA assessment | ROC or SAQ D for Service Providers, plus AOC support | Usually annual, with updates after material changes where required | An individually qualified QSA conducts or attests the assessment |
| ASV scanning | Approved external vulnerability scans and passing results | Quarterly and when applicable after relevant changes | A PCI SSC-approved ASV |
| Managed continuous compliance | Evidence collection, policy monitoring, control dashboards, change tracking, and reporting | Ongoing, with refresh frequency defined in the contract | Compliance platform team, MSSP, or managed service provider |
| Remediation and penetration-test support | Vulnerability validation, exploitation testing, remediation guidance, retesting, and technical reports | Annual minimum for required penetration testing, plus change-triggered work | Qualified penetration testers and remediation specialists |
A QSA assessment produces an attestation artifact. It doesn't automatically perform every scan, fix every finding, or continuously monitor your cloud environment. The individual QSA's role and qualification should be clear, especially when a consultancy sells the assessment as part of a broader managed package.
ASV scanning is narrower. It evaluates external exposure against the applicable PCI scanning requirements. It won't replace internal vulnerability scanning, application testing, cloud configuration review, or a penetration test designed to validate attack paths.
Managed compliance services fill the operational gap between formal reviews. They can collect evidence from ticketing systems, cloud platforms, identity providers, logging systems, and testing tools. They're valuable only when the underlying evidence is complete and the dashboard preserves dates, ownership, exceptions, and approvals.
Remediation support is where technical judgment matters most. A provider should explain exploitability, business impact, compensating controls, and retest conditions rather than export a list of scanner findings. Teams responsible for online payments may also need adjacent controls, such as e-commerce fraud detection techniques, but fraud monitoring and PCI validation remain separate disciplines.
How to Assess and Choose the Right Provider
Start with the scope decision, not the vendor shortlist. Write down whether you need Level 1 ROC support, Level 2 SAQ D for Service Providers support, a penetration test, ASV scanning, segmentation validation, remediation, or a managed evidence service. If the provider can't map its proposal to those needs, the engagement will likely produce a confusing collection of reports.
Questions that expose the operating model
- Who performs the assessment? Confirm the QSA's individual qualification and role. A company may employ qualified assessors, but the named assessor should be identifiable.
- Who performs the ASV work? Verify that external scanning is delivered through a PCI SSC-approved ASV, not merely through a general vulnerability scanner.
- What will we receive? Request sample redacted reports, AOCs, scope statements, remediation registers, segmentation-test outputs, and responsibility matrices.
- How are changes handled? Ask what triggers a new scan, penetration test, segmentation validation, or attestation update after a cloud, network, or application change.
- Can the evidence travel? Machine-readable exports are useful when evidence must feed a GRC or continuous-compliance platform. PDF-only delivery can become a manual bottleneck.
- Does the team understand cloud segmentation? Require practical detail about shared services, identity paths, administrative planes, tenant boundaries, and inherited cloud controls.
A provider's sample deliverable tells you more than a sales deck. Look for asset inventories, test dates, methodology, finding identifiers, screenshots, retest outcomes, scope limitations, and explicit responsibility assignments. “Compliant” without those details isn't enough to support an audit or defend a customer review.
Test the remediation depth
Ask who owns a finding after the report is delivered. Strong providers explain severity, attack path, affected assets, compensating controls, deadline logic, and retest criteria. Weak providers treat remediation as the customer's problem and return only when the next annual assessment begins.
For MSSPs and consultancies that need recurring penetration-test capacity, ThreatExploit AI is one option to evaluate. It supports web applications, APIs, networks, and cloud infrastructure, and produces compliance-mapped reports in PDF and JSON formats. Its role is technical testing and evidence production, not QSA attestation, ASV authorization, or replacement of the customer's PCI governance process. A broader third-party risk assessment resource can help structure the vendor review around control ownership and residual risk.
Why Service Provider Selection Is Now a Continuous Decision
Choosing a provider once a year is a poor fit for an environment that changes every week. New cloud services, deployments, integrations, access paths, and network rules can alter the cardholder data environment long before the next ROC window.
The practical standard is continuous evidence management. Teams need current scan results, penetration-test records, segmentation validation, log and file-integrity monitoring, change records, and remediation approvals. A provider that appears only during the annual assessment leaves the customer responsible for proving what happened during the rest of the year.
Use the service relationship as a control
Review the provider against the environment it supports, not against the contract signed in the previous cycle. Ask how often its dashboard refreshes, how it detects segmentation drift, how it identifies significant changes, and who approves closure of remediation tickets.
A quarterly review should examine more than whether the provider is still contracted. It should test whether the scope remains accurate, the evidence is complete, the responsible people are still assigned, and the provider's controls match the current architecture.
Cloud expansion makes this more important. AWS broadened its PCI DSS scope in 2025 by adding services and a new Asia Pacific region, showing that certified cloud footprints can change as providers expand their offerings. Mastercard's registered service-provider list also continues to update by region and assessor date. Those changes reinforce a simple operational point: provider status and cloud dependencies need active review.
The following video provides another perspective on the technical testing context:
Select a provider that can support evidence between assessments, explain changes clearly, and coordinate with your engineering and compliance teams. Continuous compliance isn't a dashboard subscription. It's a repeatable operating process with named owners and verifiable outputs.
Bringing It All Together
A PCI DSS service provider is defined by its scope, validation tier, and evidence, not by the language in its sales deck. Map each outsourced function to the relevant service-provider obligations. Confirm whether the engagement requires a Level 1 ROC, a Level 2 SAQ D for Service Providers, or focused technical consulting.
Before signing, require a current AOC, the applicable ROC or SAQ evidence, a responsibility statement, and a clear cadence for ASV scans, penetration tests, vulnerability testing, and segmentation validation. Treat bundled offerings carefully. QSA assessment, ASV scanning, managed compliance, and remediation are separate deliverables, even when one vendor sells them together.
Cloud architecture makes stale documentation especially dangerous. Your provider should be able to explain shared responsibility, segmentation boundaries, change-triggered testing, evidence retention, and how findings move from discovery to verified closure. The cheapest quote rarely creates the strongest audit trail.
ThreatExploit AI helps security service providers run recurring penetration tests across web applications, networks, APIs, and cloud environments, then produce evidence-backed reports mapped to PCI DSS controls. Review the platform at ThreatExploit AI and evaluate whether its automated testing and structured reporting fit your next service-provider compliance engagement.