PCI DSS for service providers: validation and duties

Does PCI DSS for service providers apply if you never store card data?

Yes, PCI DSS can apply to a service provider that never stores, processes or transmits account data. The standard covers entities that could affect the security of the cardholder data environment (CDE), and PCI SSC FAQ 1579 names two common cases: a provider with access to a customer's CDE, and a provider that meets a PCI DSS requirement on a customer's behalf. A managed security firm with administrative access to a customer's firewalls, or a hosting company that runs the servers beneath a payment application, falls into the first case even if card data never touches its own systems. The useful question is not where the data is kept but whether your access or your duties could weaken the customer's protection. Check your administrative access, remote support paths and any task you perform on a customer's behalf before you conclude you are out of scope.

Once you are in scope, the assessment boundary is wider than most providers expect. PCI SSC FAQ 1580 places all people, processes and technology used to deliver the service inside the assessment, so the support desk, change process, jump hosts, ticketing tools and staff who hold privileged access all count, not only the production servers. You then validate in one of two ways: with SAQ D for Service Providers or with a Report on Compliance (ROC), as directed by the compliance-accepting entity that relies on your results. Ask that entity in writing which route it requires before you scope the work, because the answer determines the effort. Your organization owns its controls and evidence. An implementation partner can prepare systems and documentation, but only the Qualified Security Assessor (QSA) issues the ROC, and the Attestation of Compliance (AOC) is the document customers receive.

Four variables decide how your situation plays out. The first is service type: a payment gateway, a managed firewall operator and a SaaS scheduling tool with no payment role carry very different duties. The second is access to customer CDEs, including whether your staff can reach cardholder data, log in to customer systems or change their configurations. The third is multi-tenancy, because shared infrastructure brings in the additional requirements of Appendix A1. The fourth is the payment brand's level for your organization, which sets whether an annual ROC by a QSA is mandatory. Visa, for example, requires a ROC for Level 1 providers. Confirm your level and validation route with each brand and acquirer you serve before you commit to a plan.

SAQ D or ROC: which validation path a service provider uses

This table compares the SAQ D for Service Providers with a Report on Compliance completed by a QSA across who directs the choice, what the organization must produce, who signs, and when a ROC is expected. Read each row against your customers' and payment brands' instructions, because the compliance-accepting entity usually sets the path.

Question	SAQ D for Service Providers	Report on Compliance (ROC)
Who usually directs the choice	The compliance-accepting entity, such as a customer or acquirer, directs which validation applies	The compliance-accepting entity or payment brand directs a ROC, often for larger providers
Applies to internal or enterprise providers	Yes, internal service providers validate the same way as external ones	Yes, internal service providers can be directed to a ROC
What the organization produces	Self-completed questionnaire answers with supporting evidence for each requirement	A detailed report written by a QSA after examining people, processes and technology in scope
Who signs the Attestation of Compliance	The organization's authorized officer signs the AOC with the SAQ D	The QSA company and the organization's authorized officer sign the AOC with the ROC
Scope of the assessment	All people, processes and technology involved in providing the services, documented by the organization	All people, processes and technology involved in providing the services, examined by the QSA
When a ROC is expected	Usually for lower transaction volumes where the directing entity accepts a self-assessment	Visa requires an annual ROC by a QSA for Level 1 service providers handling over 300,000 transactions a year
Certificates	Certificates are not recognized as validation; the SAQ D and AOC are the evidence	Certificates are not recognized as validation; the ROC and AOC are the evidence
Action for the reader	Confirm the exact path in writing with each customer and each payment brand before starting	Confirm the exact path in writing with each customer and each payment brand before starting

Which extra requirements apply only to service providers

Service providers that can affect a customer's cardholder data environment carry several requirements that merchants do not. These cards cover the five that assessors test most often, each with the evidence that proves it. The organization owns every control, while an implementation partner can prepare systems and evidence for the assessor to review.

Documented cryptographic architecture

Requirement 3.6.1.1 asks the provider to document how cryptography protects account data, including the algorithms, key lengths, key types and where each key lives. Assessors will ask for a current architecture document that names every cryptographic function in the service and the systems that run it. Evidence includes key inventories, configuration exports from key management systems and records showing the document was reviewed when the environment changed. Check that the document matches what is deployed, not what was planned.

Quarterly review of security personnel

Requirement 12.4.2 requires a service provider to review, at least every three months, that people performing security tasks still do them as their role requires. Assessors look for signed review records, the task list each person is responsible for and proof that gaps were corrected. Evidence includes access reviews, training records and the review log itself. Confirm the reviews are performed by someone independent of the person being reviewed.

Six-monthly scope confirmation

Requirement 12.5.2.1 asks the provider to confirm, every six months and after significant change, that the PCI DSS scope is still accurate. Assessors expect a dated scope statement backed by network diagrams, data-flow diagrams, system inventories and a search for stray account data. Evidence includes the signed confirmation, the discovery results and the list of changes reviewed. A confirmation that repeats last cycle's document without checking the environment will not satisfy the assessor.

Six-monthly segmentation testing

Requirement 11.4.6 requires a service provider that relies on segmentation to isolate the cardholder data environment to test that segmentation every six months and after significant change. Assessors will ask for the test scope, the method used, the tester's qualifications and the results showing that out-of-scope systems cannot reach the CDE. Evidence includes test reports, the list of attempted connections and remediation records for any path that succeeded. Confirm whether the test is internal, external or both, and who performs it.

Written acknowledgment of customer responsibility

Requirement 12.9 requires a service provider to acknowledge in writing to its customers that it is responsible for the security of the account data it stores, processes or transmits, or that could affect that data. It also requires the provider to give customers the information they need about its compliance status and responsibilities. Assessors will check the contract or responsibility matrix for this statement and for the process used to answer customer requests. Evidence includes the signed agreement template, the responsibility matrix and a log of customer requests.

How multi-tenant rules in PCI DSS for service providers change the assessment

Multi-tenant rules apply when a service provider's customers share resources such as servers, infrastructure, applications (including SaaS) or databases. PCI DSS Appendix A1 adds requirements for this model, and the shared platform is what triggers them, not the fact that a provider offers services to several customers. A provider running one dedicated environment per customer is in a different position from one hosting many customers on the same cluster, database or application instance. Before scoping the assessment, list each service you offer and record whether tenants share any component in the payment path. That list is the first piece of evidence your QSA will ask for.

In a shared environment, the assessor will expect evidence that one customer's cardholder data cannot be reached by another customer. That means showing how tenant boundaries are enforced at each layer you control, how administrative and support access into tenant data is granted, logged and reviewed, and how changes to shared components are tested before they affect every customer. Each of these needs documented design decisions and records that show the controls operate over time, not only a diagram. Ask your QSA which of these layers fall under Appendix A1 for each service, because the answer changes the evidence you must produce.

Single-tenant managed services usually carry a smaller evidence burden for the isolation question, since each customer's environment is separate. The provider's own duties still apply, particularly around its staff access, its responsibility matrix and its written acknowledgment of responsibility for customer account data under Requirement 12.9. Confirm the tenancy model for each service with your QSA in writing before the assessment begins, and note any service that mixes models, such as a dedicated database instance on shared hosting. Mixed models are where scope disputes most often start.

What to give customers under PCI DSS for service providers

Customers that rely on your service need to know what you have validated and what remains their responsibility. Under PCI DSS, a service provider with an Attestation of Compliance is expected to provide it on request, and customers may also ask for the relevant sections of the Report on Compliance or the SAQ D for Service Providers. Requirement 12.9 expects you to acknowledge in writing that you are responsible for the account data you handle for customers, and to explain your compliance status and responsibility split when asked.

Attestation of Compliance: Provide the current AOC on request, with its validation date and scope statement. Confirm the AOC covers the service actually sold to that customer.
Relevant ROC or SAQ D sections: Share only the sections that describe the services, scope and responsibilities the customer needs. Do not send internal findings beyond what the customer is entitled to see.
Responsibility matrix: Set out which requirements you meet, which the customer must meet, and which are shared, service by service.
Written acknowledgment: Keep the Requirement 12.9 statement of responsibility signed and current.
Certificates and logos: Do not offer vendor certificates or compliance badges as validation.

Before sending anything, check that the document is current and that its scope matches the contract with that customer.

Visa service provider levels and what each one submits

This table compares Visa's two service provider levels on transaction volume, annual validation method, scanning and where the provider is listed. Read it as a starting point for your own assessment: confirm your level with Visa and your payment brand contacts before you plan a validation.

Item	Level 1 service provider	Level 2 service provider
Transaction threshold	Handles over 300,000 transactions a year	Handles fewer transactions than Level 1
Annual validation method	Annual Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA)	Annual Self-Assessment Questionnaire (SAQ) with an Attestation of Compliance
Scanning requirement	Quarterly external scans by a PCI SSC Approved Scanning Vendor (ASV)	Quarterly external scans by a PCI SSC Approved Scanning Vendor (ASV)
Public listing by Visa	Listed by Visa as a Level 1 provider validated by ROC	Confirm with Visa whether and how Level 2 providers are listed
Who issues the validation	QSA company, which must be independent of the provider's own staff	Provider completes the SAQ and signs the attestation
Typical cost driver	Assessor fees, scope size, and remediation before the ROC	Questionnaire effort, scan fees, and evidence gathering
What to confirm with Visa	Current threshold, reporting deadline and submission channel	Current threshold, SAQ type required and submission channel
Other card brands	Not covered by this table; confirm each brand's levels directly	Not covered by this table; confirm each brand's levels directly
Compliant provider list	PCI SSC keeps no list of compliant service providers	PCI SSC keeps no list of compliant service providers

How a service provider validation runs from scope to AOC

The sequence turns a service provider's people, processes and technology into an assessed scope, a validated set of controls and a signed Attestation of Compliance that customers can review. Each step ends with a named output, so the assessor and the compliance-accepting entity can both see what has been proven.

Confirm compliance-accepting entities and validation path
Start by listing every customer or enterprise entity that requires your PCI DSS validation, and ask each one, in writing, whether it expects an SAQ D for Service Providers or a Report on Compliance. Your compliance-accepting entity directs the path, and that rule also applies to internal or enterprise service providers. The output is a short register of accepting entities, the template each one requires, and the payment brand programs that apply to your service. The step is done when the register is signed off by the person who owns compliance.
Define scope across people, processes and technology
Define the assessment scope to include all people, processes and technology involved in delivering the service, not only the systems that store or transmit account data. Map where your staff can reach a customer's cardholder data environment, which tools and jump hosts provide that access, and which processes (support, change, provisioning) touch it. The output is a scope document with a system inventory and a data-flow view that an assessor can trace. The step is complete when each in-scope component has a named owner and a stated reason for being in scope.
Close gaps against v4.0.1 and future-dated requirements
Compare your controls against PCI DSS v4.0.1, the only active version, and confirm that the future-dated requirements effective since 31 March 2025 are implemented rather than marked not applicable. Service-provider-only requirements, including the documented cryptographic architecture, quarterly reviews of personnel performing security tasks, six-monthly scope confirmation and six-monthly segmentation testing, need explicit owners and procedures. The output is a gap register with remediation status for each requirement. The step is done when every gap is either closed or formally tracked with an accepted plan.
Collect evidence of periodic activities
Gather dated evidence for recurring activities: quarterly external scans by an Approved Scanning Vendor, penetration tests and segmentation tests, access and personnel reviews, log reviews and change records. Assessors test whether these activities ran on schedule and whether findings were fixed and retested, so keep the raw reports alongside your tracking records. The output is an evidence library indexed by requirement. The step is complete when an assessor can pick any periodic activity and trace it from plan to result to remediation.
Document responsibilities and written acknowledgment
Prepare the material Requirement 12.9 expects: a written acknowledgment that you are responsible for the security of customers' account data, and information that explains which requirements you meet on each customer's behalf. Where you meet a requirement for a customer, you need evidence that it is met, because a claim without evidence leaves that requirement unmet for the customer. The output is a responsibility matrix and signed acknowledgment templates for customers. The step is done when each customer-facing responsibility has matching evidence.
Complete the QSA assessment and ROC or SAQ D
If the accepting entity requires a Report on Compliance, a Qualified Security Assessor tests the scope and controls and writes the ROC on official PCI SSC templates. If an SAQ D for Service Providers is accepted, you complete it, and the assessor role depends on the accepting entity's direction. Confirm the independence of anyone who helps prepare evidence, and expect the assessor to rely only on evidence it can verify. The output is a completed ROC or SAQ D that matches the scope and evidence library. The step is done when the assessor or your reviewer has checked every answer against evidence.
Sign and deliver the AOC to customers
Complete the Attestation of Compliance that matches your ROC or SAQ D and have it signed by an authorized officer and, for a ROC, the assessing QSA. Deliver the AOC to customers on request, and provide relevant ROC or SAQ D sections where they ask for them. Certificates and logos do not count as validation, so the AOC is the document to send. The output is a signed AOC and a delivery log showing which customers received it. The step is complete when each accepting entity has the document it asked for and you have recorded the date it was sent.

What usually delays service provider validation and how to avoid it

Most delays in a service provider assessment trace back to a few gaps: scope that stops short of customer-facing components, evidence that does not exist for controls met on a customer's behalf, and documents that contradict each other. The cards below name each gap, the step that prevents it, and who owns that step: the organization, its implementation partner, or the independent assessor.

Scope that stops at the back end

Teams often scope only the systems that store or transmit account data and leave out customer-facing components such as payment pages, API gateways, admin consoles and the identity provider that controls access to the CDE. PCI DSS for service providers covers all people, processes and technology involved in the service, so a scope that excludes these components will be challenged at the start of the assessment. The organization owns the scope decision and should document it with data-flow and network diagrams before the partner builds anything. The assessor confirms it independently.

Controls met for customers without evidence

When a service provider performs a requirement on a customer's behalf, such as log review, patching or key management, the assessor needs proof that the control ran for that customer. If the provider cannot show that evidence, the requirement is not in place for the customer, even if the work was done. Keep tickets, log extracts, review sign-offs and change records tied to the service, and agree in advance which records each customer may receive. The organization owns the evidence process. The partner can build collection automation, and the assessor tests samples of it.

Responsibility matrix that contradicts the AOC

The responsibility matrix tells customers which PCI DSS requirements the provider meets and which fall to the customer. If the matrix claims coverage that the Attestation of Compliance does not reflect, or the AOC covers services the matrix omits, customers and their assessors will reject both documents. Requirement 12.9 expects the provider to acknowledge responsibility in writing and provide compliance status on request. Reconcile the matrix against the final scope and the assessor's findings before release. The organization signs the matrix, and the assessor checks that it matches the report.

Shared tenant controls without isolation proof

In multi-tenant platforms, customers share servers, databases, applications and SaaS infrastructure, which brings in the Appendix A1 requirements. Assessors will ask how one customer's cardholder data cannot be read by another, and a design diagram alone rarely answers that. Prepare test results for tenant separation, access logs showing tenant-scoped administration, and configuration evidence for shared components. Confirm early whether the platform falls under Appendix A1 so the isolation tests are designed before the assessment window opens. The organization owns the design, the partner runs the tests, and the assessor validates the results.

Readiness work mistaken for the assessment

A consultant's gap analysis or readiness review shows where controls stand before an assessment, but it does not validate anything. Teams that treat a clean readiness report as a passed assessment often discover late that evidence was never collected for the full review period. Consultants who help prepare the environment cannot also act as the assessor for the same work. Agree the split in writing: the partner prepares systems, controls and evidence, and the organization decides the validation path. Only the QSA issues the Report on Compliance, and the organization submits the AOC to its compliance-accepting entity.

Who decides that your service must be validated

The PCI Security Standards Council does not enforce PCI DSS or impose penalties on anyone. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs, so your validation obligation comes from the brands and from the customers and acquirers that answer to them. Under PCI SSC FAQ 1004 and PCI SSC FAQ 1015, the consequences of non-compliance also flow through those brand programs rather than from the Council. In practice, a service provider rarely chooses its own validation path. Its compliance-accepting entity, usually a merchant or processor customer, or the acquirer that sponsors it, tells it whether to submit an SAQ D for Service Providers or a Report on Compliance, and whether the work must be done by a Qualified Security Assessor.

Because that direction shapes your cost, timeline and the documents you hand customers, ask for it in writing before scoping starts. The request should name the validation type, the assessment period, the entity that must receive your Attestation of Compliance, and whether any brand program applies to you because of your transaction volume or your role. Confirm whether the direction covers your internal or enterprise service provider functions as well, since the same SAQ D or ROC rules apply to them. If your customers operate under different brands, you may receive different instructions from each, and the stricter one usually governs your planning. Record the answers in your responsibility matrix so that later changes in a customer's requirements are traceable.

Do not treat a certificate, a badge or a vendor logo as proof that a service provider is validated. PCI DSS validation is documented only on official PCI SSC templates, meaning a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with its Attestation of Compliance, and PCI SSC FAQ 1220 states that certificates are not recognized as validation. Customers who accept a logo in procurement have not accepted evidence, and an assessor will not rely on one. Before you promise a customer that you are compliant, confirm the current AOC date, the scope it covers and whether any open remediation affects it, and make sure that what you send matches what the assessor actually signed.

Common questions about PCI DSS for service providers

Must a service provider with no direct access to card data still validate PCI DSS?

Yes, it can. PCI DSS applies to service providers that can affect the security of payment account data even if they never store, process or transmit it, such as a provider with access to a customer's cardholder data environment or one that meets a PCI DSS requirement on a customer's behalf. Whether your organization falls into that group depends on what your access and services touch, so confirm the position with the compliance-accepting entity that engages you. The PCI SSC's FAQ on service providers that can affect security explains the test in detail. Your assessment scope then covers all people, processes and technology used to deliver the service, not only the systems that hold card data.

Does a service provider need an SAQ D or a ROC?

The answer is set by the entity that accepts your compliance, not by you alone. Service providers validate with either the SAQ D for Service Providers or a Report on Compliance completed by a Qualified Security Assessor, as that entity directs. This applies to internal and enterprise service providers too. Ask your customers, acquirers or payment brands which validation they require, and confirm whether your service tier triggers a higher level of validation. Your choice affects effort, because a ROC requires an assessor's testing and an SAQ D requires your own documented answers with supporting evidence.

What can a customer ask a PCI DSS service provider for?

Customers can ask for your Attestation of Compliance, and you are expected to provide it on request. They may also ask for the sections of your ROC or SAQ D that describe the services they rely on. Under Requirement 12.9, you should also be ready to acknowledge in writing your responsibility for the account data you handle and to share your compliance status and responsibility information. A responsibility matrix that maps each requirement to your side or the customer's side is the document most customers need first. Request these items in the contract so the obligation is clear before go-live.

How does multi-tenancy change the effort of PCI DSS validation?

Multi-tenancy adds work because customers share servers, infrastructure, applications or databases, and Appendix A1 sets additional requirements for that model. Your assessor will examine how tenant data is separated, how one customer's activity is prevented from reaching another, and how logging and access controls are applied per tenant. The effort grows with the number of shared components and the number of isolation mechanisms you rely on. Illustratively, a provider running one shared database for many tenants will face more isolation testing than one that dedicates an environment per customer. Confirm the Appendix A1 requirements early in design, because retrofitting tenant isolation is costly.

Can an implementation partner prepare evidence for our PCI DSS assessment?

Yes. A partner can configure systems, document architecture, build the evidence trail for technical controls and prepare your team for the assessment. The evidence and controls remain your organization's responsibility. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for compliance assessments. It does not issue reports, attestations or certificates. Only a QSA or the relevant assessor can produce the ROC, and only your organization can sign the AOC. Keep the consultant and the assessor independent so the assessor can rely on the evidence without conflict.

Can a partner issue our Attestation of Compliance?

No. The Attestation of Compliance is completed and signed by your organization on the official PCI SSC template, and a ROC is completed by a Qualified Security Assessor. An implementation partner, including DeployOpen, cannot issue an AOC, a ROC or any certificate on your behalf. Certificates are not recognized as validation, so be cautious of any vendor offering one. Your procurement team should treat any proposal that promises a certificate or attestation from a consultant as a warning sign.

What drives the cost and timeline of PCI DSS validation for a service provider?

The main drivers are the validation route (a ROC or SAQ D), the size of the scope across people, processes and technology, the number of customers sharing infrastructure, the recurring tests such as quarterly external scans and penetration testing, and the remediation needed before your first assessment. Costs split between assessor fees, implementation or consulting work, scanning and testing vendors, and internal staff time, and most of these recur each year. No official cost figure is supplied for this topic, so request a written scope from each party and compare line items. For detailed cost drivers, read the PCI DSS compliance cost guide. For timing, read the guide on how long PCI DSS compliance takes.

How DeployOpen prepares service provider systems and evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the systems and evidence behind your PCI DSS service provider scope are prepared in a controlled, written way. We prepare systems, controls and evidence for assessment, while your organization owns its controls and an independent QSA issues the Report on Compliance or Attestation of Compliance.

How we scope

We agree the written scope with you, covering the people, processes and technology involved in delivering your service to customers.
We confirm which customer CDE access and customer-facing responsibilities fall inside the assessment, and which sit with your customers.
We document the validation path you intend to use, SAQ D for Service Providers or a ROC, as your compliance-accepting entity directs.

How we build

We implement and harden the open-source platforms in your cloud accounts, data centers or air-gapped networks, against your documented configuration baseline.
We set up logging, access control, segmentation and the cryptographic architecture so the controls produce evidence your assessor can sample.
We configure the multi-tenant isolation and recurring tasks, such as quarterly reviews and six-monthly scope and segmentation checks, that the service provider requirements expect.

How we hand over

We deliver written procedures, network and data-flow diagrams, system inventories and a responsibility matrix that maps each control to its owner.
We provide evidence packs organized by requirement, with the reports, configuration exports and logs an assessor will ask to see.
We walk your team through the handover so your staff can run the recurring tasks, maintain the evidence and answer assessor questions directly.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement closes.
We help you confirm customer responsibility statements under Requirement 12.9 and prepare the status information customers request.
Ask your QSA or ASV to confirm which evidence they will accept before we finalize packs, since assessment decisions remain theirs.

PCI DSS for service providers