PCI DSS SAQ D for service providers: what it adds

Which PCI DSS SAQ does a service provider use?

SAQ D for Service Providers is the only self-assessment questionnaire a service provider can use. Every other SAQ is written for merchants, so a provider that hosts, processes or manages payment environments for others cannot choose a merchant SAQ based on how it accepts cards. The PCI SSC FAQ on multiple SAQs sets out this split. Customers who ask for proof of compliance will expect the provider to have validated against the service provider questionnaire or a Report on Compliance, depending on what the compliance-accepting entity requires.

The validation route is not chosen by the provider alone. The compliance-accepting entity, typically a payment brand, acquirer or other organization that relies on the provider's status, decides whether SAQ D for Service Providers or a ROC is required. That decision moves with the provider's transaction volume, the services it sells, and its role in the cardholder data environment. A provider that only supports storage, processing or transmission indirectly still has to meet every requirement that applies to that service and its supporting systems. Ask the compliance-accepting entity in writing which route it accepts, and confirm whether internal or enterprise service providers in your group follow the same rule.

The organization owns its controls and the answer to the validation question. DeployOpen can plan the scope, prepare systems, configure controls and assemble the evidence an assessor will examine, under a written, fixed scope. DeployOpen does not issue reports, attestations or certificates. Only a Qualified Security Assessor or the assessor the compliance-accepting entity names can complete a ROC, and the provider signs its own Attestation of Compliance for an SAQ. Plan that handoff early, since the assessor's evidence needs shape the way the environment is built.

SAQ D for service providers or a ROC: which path fits

This table compares SAQ D for Service Providers with a Report on Compliance by who completes the work, who signs the attestation, who typically directs the path and what each asks of the provider's team. Read each row against the directive from your compliance-accepting entities, because the path is set by them, not by the provider alone.

Factor	SAQ D for Service Providers	Report on Compliance (ROC)
Who completes it	The service provider's own team, working through the SAQ's requirements and responses	A Qualified Security Assessor (QSA) performs the assessment and writes the ROC
Who issues the attestation	The service provider signs the Attestation of Compliance (AOC) for the SAQ	The QSA's company issues the ROC and the AOC, and the provider signs the AOC
Typical direction	Directed by the compliance-accepting entity, often for Visa Level 2 service providers	Directed by the compliance-accepting entity, often for Visa Level 1 service providers
Visa annual validation	Level 2: annual SAQ, as the supplied Visa guidance states	Level 1: annual ROC by a QSA, for providers handling over 300,000 transactions a year
Quarterly ASV scans	Required, as Visa applies quarterly ASV scans at both levels	Required, as Visa applies quarterly ASV scans at both levels
Documentation asked of the team	Section 2a documentation plus a Describe Results section for each requirement	Evidence gathered and presented to the QSA for each requirement in the ROC template
Internal staffing demand	Staff must answer every requirement accurately and keep evidence ready for review	Staff must support the QSA's interviews, sampling and evidence requests
Confirm before starting	Ask each acquirer, brand or entity in writing which path it accepts and the reporting date	Ask each acquirer, brand or entity in writing which path it accepts and the reporting date

What SAQ D for service providers adds over merchant SAQs

SAQ D for Service Providers is the only self-assessment questionnaire a service provider can use, and it is heavier than any merchant SAQ. The cards below cover the structural additions and the service-provider-only requirements that drive most of the work, along with the controls that keep that work manageable.

Every requirement is in scope

SAQ D for Service Providers covers all PCI DSS requirements, and a service provider cannot use a merchant SAQ's eligibility criteria to drop any of them. Scoping starts from the full list, then you mark applicability with a documented reason. Ask your compliance-accepting entity to confirm which requirements it expects you to address. A limited service still carries obligations for every system that supports it.

Section 2a documentation

Section 2a adds a list of documentation the service provider must supply as part of the questionnaire, which merchant SAQs do not carry. Much of this material, such as architecture diagrams, policies and inventories, must exist and be current before you start answering. Assign an owner to each document and set a review date so the evidence is not assembled under pressure at submission time.

Describe Results for each requirement

A Describe Results section sits under each requirement, and it asks you to explain how the requirement was met in your environment rather than simply selecting a response. Write each description so that a reviewer can trace it to a named system, process or record. Vague descriptions invite follow-up questions from your acquirer or assessor, so draft them against the evidence you hold, not from memory.

Documented cryptographic architecture

Requirement 3.6.1.1 asks service providers to document their cryptographic architecture, including the algorithms, key uses and the systems that rely on them. This inventory must be kept current as key management changes. Start by mapping every place cardholder data is encrypted, hashed or tokenized, then record which keys protect each store. Gaps here usually surface when a key is rotated or a new service is added.

Quarterly personnel security reviews

Requirement 12.4.2 requires service providers to review, on a quarterly basis, that personnel performing security tasks are still following the security policies and daily procedures. Each review should leave a dated record listing the people checked, the tasks they perform and any exceptions raised. Plan the reviews as a recurring calendar item with a named reviewer, because a missed quarter is visible to the assessor.

Six-monthly scope and segmentation checks

Requirement 12.5.2.1 asks service providers to confirm PCI DSS scope every six months, and Requirement 11.4.6 requires segmentation testing on the same six-month cycle. Scope confirmation depends on current network and data-flow diagrams, while segmentation testing needs a documented method that proves isolation between the cardholder data environment and other customer or internal systems. Ask any tester to show that the method reaches the boundaries you claim to enforce.

How Visa's Level 2 threshold changes the service provider's validation

Visa sorts service providers into levels by transaction volume, and the level sets how the provider validates PCI DSS with that brand. Level 1 providers handle over 300,000 transactions a year and must complete an annual Report on Compliance (ROC) led by a Qualified Security Assessor (QSA). A Level 2 provider handles fewer transactions and completes an annual self-assessment instead, using SAQ D for Service Providers, together with quarterly scans by an Approved Scanning Vendor (ASV). Quarterly ASV scans apply at both levels, so the difference between them is mainly the depth of the annual validation. The exact Level 2 threshold is not set out in the facts behind this page, so confirm it on Visa's compliance validation page and with your acquirer before you plan the year.

A provider's volume with one brand does not settle its obligations with another. Each payment brand sets its own levels and validation rules, so a provider processing for Visa and Mastercard may fall into different tiers with each. Ask Visa and every acquirer or compliance-accepting entity you serve which level applies to your organization, whether volume is counted per brand or across brands, and how the count is measured and reported. Record each answer in writing, because the figure used for the level decides whether you need a ROC or a self-assessment for that brand.

Whatever the level, the SAQ D for Service Providers you complete must cover all applicable requirements, including the service-provider-only requirements. Treat the level decision as a planning input, not as a reason to narrow the scope of the assessment. A practical step is to write down the brand-by-brand level determination, the date of the next validation for each, and the ASV scan schedule, then assign an owner to each. Reassess the level whenever volumes change materially, and reconfirm it with each compliance-accepting entity when you add a new customer or brand.

Why a merchant SAQ or AOC does not prove a service provider's compliance

A service provider cannot use a merchant SAQ, or hand a customer a merchant AOC, as evidence of its own compliance. PCI SSC FAQ 1578 is explicit that a service provider must not borrow a merchant SAQ's eligibility criteria to decide which requirements apply to it. SAQ D for Service Providers is the only correct questionnaire, and every requirement must be considered when scoping. The practical consequence is that the provider's scope starts from its own platform, staff and supporting systems, not from a merchant profile that excludes the controls it runs for others. Consider an illustrative hosting provider that runs customer storefronts on shared infrastructure. Its team completes a merchant-style questionnaire, reasons that it never stores card data itself, and marks the requirements for its own administrative access, log review and change control as not applicable. The customer receives a merchant AOC and assumes the hosting layer was assessed. It was not. The questionnaire skipped the controls that protect the environment where the payment data actually sits. Before the provider signs any attestation, it should list each system it operates that could affect the cardholder data environment and confirm that every requirement applicable to those systems has been answered on SAQ D for Service Providers, with evidence behind each answer. The limited-service case catches providers that assume a narrow role lowers the bar. PCI SSC FAQ 1578 states that a provider offering a limited service, such as one that only indirectly supports storage, processing or transmission of payment data, must still comply with all requirements applicable to that service and its supporting systems. Ask the compliance-accepting entity which services it expects covered, document the boundary, and confirm with the assessor or the entity whether the indirect role changes the validation route. PCI SSC FAQ 1578 sets out the scoping rule in full.

How a service provider completes SAQ D for service providers

The sequence moves from confirming the validation path with the compliance-accepting entity to a signed Attestation of Compliance, with each phase producing a named artifact that a customer or acquirer can check. The organization owns every control and signs the AOC, while DeployOpen can prepare systems and evidence and an independent assessor reviews the result where required.

Confirm the validation path with your compliance-accepting entity
Before any questionnaire work starts, ask the payment brand, acquirer or other entity that accepts your compliance to confirm in writing whether it expects SAQ D for Service Providers or a Report on Compliance. Service providers validate through one of those two routes as directed by that entity, and internal or enterprise service providers follow the same rule. Visa's published levels also distinguish annual ROC work from annual SAQ work for service providers, so confirm the level that applies to you. The output is a short written direction naming the validation type, the entity that issued it, and the reporting period. You know this step is done when that direction is filed with the project scope and nobody is relying on a verbal assumption.
Scope every requirement against services and supporting systems
Work through all PCI DSS requirements, not only the ones a merchant questionnaire would have covered, and decide for each one how it applies to your services, your cardholder data environment and the systems that support them. Service providers cannot use a merchant SAQ's eligibility criteria to narrow the requirements, and a provider offering a limited service still has to meet every requirement that applies to that service and its supporting systems. The output is a scope statement listing the services, the account data flows, the in-scope systems and the connected systems that could affect security, with a rationale for each exclusion. You know this step is done when every requirement has a documented applicability decision that the assessor can trace back to the scope statement.
Assemble the Section 2a documentation
Section 2a of SAQ D for Service Providers asks for the documentation that supports the answers, so collect it before writing responses. Typical items include the data flow and network diagrams, the inventory of in-scope components, the cryptographic architecture documentation that service providers must maintain, the policies and procedures each requirement references, and the responsibility matrix you give customers. DeployOpen can prepare the technical diagrams, configuration baselines and inventories for systems it implements or hardens, but the policies and the decisions in them belong to your organization. The output is a documentation register that maps each artifact to the requirement it supports, with an owner and a last-reviewed date. You know this step is done when every document cited in the questionnaire exists, is approved by a named owner, and matches the current environment.
Build the requirement-by-requirement evidence register
Create one register row per requirement, listing the response you intend to give, the evidence that backs it, the system or person that produces that evidence, and the date it was last collected. Service-provider-only requirements need specific attention, including quarterly reviews of personnel who perform security tasks, six-monthly confirmation of scope, six-monthly segmentation testing and the documented cryptographic architecture. Where you rely on a customized approach, record the stated objective and the evidence showing the objective is met. The output is the evidence register itself, which becomes the working file for the Describe Results text. You know this step is done when each row points to evidence that can be produced on request and no requirement is answered from memory.
Write Describe Results for each requirement
For each requirement, write the Describe Results text in your own words, explaining what your environment does, which systems and people the control covers, and how the evidence in the register shows it. Keep the description specific enough that someone reading only the questionnaire could find the control in the environment, and avoid generic statements that could describe any provider. Where a requirement does not apply, record the reason in the same language you use elsewhere so the decision is auditable. The output is a completed set of Describe Results entries cross-checked against the evidence register. You know this step is done when a second reviewer can follow each description to a specific artifact without asking the author what was meant.
Perform and record the Expected Testing
For each requirement, carry out the Expected Testing described in the questionnaire, which is the set of checks that show the control works as described, such as inspecting configurations, reviewing samples, observing processes or interviewing staff. Run the tests against the live environment or a representative sample, record who performed each test, when, and what they observed, and log any gap as a finding with an owner. The output is a testing log linked to the evidence register and an updated list of open remediation items. You know this step is done when every requirement has a recorded test result, and every failed test has either been fixed and retested or carries an approved compensating control or customized approach record.
Review the completed questionnaire with an independent assessor where required
If your compliance-accepting entity asks for independent help, or if your own review is not sufficient for your risk, engage a Qualified Security Assessor or Internal Security Assessor to review the questionnaire, the evidence register and the testing log before submission. Their role is to test and advise on whether the evidence supports the answers, and only an independent assessor or certification body issues validation reports, so their review does not replace your own responsibility for the answers. DeployOpen can support preparation and remediation but does not issue or sign the AOC. The output is a reviewed questionnaire with any reviewer comments resolved and recorded. You know this step is done when the review comments are closed or documented and the assessor's role is stated in the file.
Sign the Attestation of Compliance and submit it
Complete the Attestation of Compliance that accompanies SAQ D for Service Providers, confirm the status it states, and have an authorized officer of your organization sign it, because the attestation is the organization's own statement. Submit the signed questionnaire and AOC to the compliance-accepting entity that directed the validation, and keep the signed copy, the evidence register and the testing log together for the assessment period. Certificates are not accepted as validation evidence, so the AOC is the document to present. The output is a signed AOC, a submission record and an archived evidence package. You know this step is done when the entity confirms receipt and the archived package can be retrieved for the next assessment cycle.

Who owns the controls, who prepares evidence, and who validates

The service provider owns its PCI DSS environment, its controls and the statements made in SAQ D for Service Providers. Its leadership decides the scope, accepts the risk of each requirement and signs the Attestation of Compliance. The signatory is accountable for every answer in the AOC, including answers prepared by consultants or engineers.

Scope and data flows: Maintain the list of systems that store, process or transmit account data or could affect that environment, and confirm it at least every six months as the service-provider-only requirement 12.5.2.1 expects.
Controls: Operate the security controls day to day, including the cryptographic architecture documented under 3.6.1.1 and the quarterly reviews of personnel performing security tasks under 12.4.2.
Evidence: Keep records that show each control operates over time, such as logs, review sign-offs, change records and test results.
Sign-off: Assign a named signatory who understands each answer and who has authority to commit the organization to the AOC.

Confirm that your internal owners can name, for every requirement, the person who runs the control and the person who reviews its evidence.

What usually delays a service provider's SAQ D

Most delays on a service provider's SAQ D trace back to a few gaps that surface late: scoping done with the wrong criteria, missing records for requirements that only service providers carry, and unclear lines of responsibility with customers. Each card below names one of these gaps and the check that prevents it, so the work is finished before the directing entity or assessor asks for it.

Scoping with merchant criteria

Teams often start from a merchant SAQ's eligibility questions and mark requirements not applicable on that basis. Service providers may not do this. Every requirement must be considered against the service and its supporting systems, including indirect support roles. Before answering anything, write a scoping memo that lists each requirement and the reason it applies or does not. Ask your compliance-accepting entity to review it.

Undocumented cryptographic architecture

Requirement 3.6.1.1 asks service providers to document their cryptographic architecture, and many teams have keys and algorithms spread across applications, cloud services and vendor tools with no single record. Assessors then have to reconstruct it from interviews. Build an inventory of every cryptographic key, its owner, storage location, rotation method and the systems that use it, and keep it current as the environment changes.

Missing six-monthly scope and segmentation records

Service providers must confirm scope every six months under Requirement 12.5.2.1 and test segmentation every six months under Requirement 11.4.6. Teams that run these once during the assessment year cannot show the earlier cycles. Put both tasks on a recurring calendar with named owners, and keep dated results, the diagrams used, and any remediation tickets as evidence.

Responsibility matrices that do not match contracts

Customers rely on the service provider's responsibility matrix to know which PCI DSS requirements the provider covers. When the matrix conflicts with contract language, support runbooks or what the platform actually does, customers and assessors both question it. Reconcile the matrix against each contract and service description, assign an owner to every line, and review it whenever a service or hosting location changes.

Unconfirmed validation path

Service providers validate with SAQ D for Service Providers or a ROC, as directed by the compliance-accepting entity, and this includes internal service providers. Teams that assume an answer often discover late that a customer or acquirer expects a ROC. Ask each compliance-accepting entity in writing which validation path it requires, the due date, and the form of evidence it accepts before the assessment year starts.

Evidence gathered too late

Most evidence is easy to produce when the control runs and hard to rebuild months later. Logs rotate, tickets get closed without reasons, and access reviews are not signed. Assign each Section 2a document and each Describe Results item to an owner, collect samples on a set schedule, and store them in one repository so the self-assessment can be completed from evidence rather than memory.

Questions service providers ask about SAQ D

Can a service provider use a merchant SAQ for PCI DSS?

No. SAQ D for Service Providers is the only self-assessment questionnaire a service provider can use, because every other SAQ is written for merchants. Service providers must not use a merchant SAQ's eligibility criteria to decide which requirements apply. A merchant SAQ or merchant Attestation of Compliance given to a customer is not sufficient evidence of the provider's own compliance. The provider has to consider all requirements when scoping, including those that apply to the services it runs for customers. The PCI SSC FAQ on SAQ eligibility for service providers sets out this position.

What makes SAQ D for service providers heavier than merchant SAQs?

It covers every PCI DSS requirement and adds elements that merchant questionnaires leave out. It includes a Section 2a for required documentation and a Describe Results section for each requirement, so the provider must explain how each control works, not only confirm it exists. It also carries service-provider-only requirements, such as a documented cryptographic architecture, quarterly reviews of personnel who perform security tasks, six-monthly scope confirmation and six-monthly segmentation testing. The extra work comes from the documentation and the explanations that each answer needs, which assessors check against evidence.

When does a service provider need a ROC instead of an SAQ?

The compliance-accepting entity decides. Service providers validate with either SAQ D for Service Providers or a Report on Compliance, as that entity directs, and this also applies to internal or enterprise service providers. For Visa, a Level 1 service provider handles over 300,000 transactions a year and must file an annual ROC completed by a Qualified Security Assessor. Level 2 providers handle fewer transactions and complete an annual SAQ. Both levels run quarterly ASV scans. Confirm the level and the required format with each acquirer, card brand or customer that receives your evidence, because the requirement comes from them.

What does the internal team need to provide for an SAQ D?

The internal team owns the controls, so it must supply the evidence behind every answer. In practice this means current network and data-flow diagrams, an inventory of system components and people with access, the cryptographic architecture, written policies and procedures, records of scans, penetration tests, access reviews and log reviews, and a clear responsibility matrix showing which controls the provider runs and which the customer runs. Someone with authority must also confirm the scope and sign the Attestation of Compliance. The effort scales with how many systems, customers and shared environments the provider runs.

Can a service provider complete SAQ D without outside help?

Yes, if the organization has staff who understand the standard, the evidence and the environment. Nothing in the standard requires an outside firm for a self-assessment, but the provider must still get the answers right, and a mistaken scope or missing control undermines the whole attestation. Many providers bring in outside help for gap analysis, remediation, or a second review before submission. An independent assessor's involvement depends on what the directing entity accepts. Ask that entity whether it requires a QSA or ISA, and ask the assessor what it will test before any work starts.

How long does a PCI DSS SAQ D for service providers take?

No researched timeline applies to every provider, so this depends on the scope, the number of customer environments, how much evidence already exists and how quickly the directing entity and assessor respond. The main drivers are the size of the cardholder data environment, the maturity of documentation and monitoring, and the number of remediation cycles. Ask the compliance-accepting entity for its submission deadline, then ask your assessor and any implementation partner for a schedule built from a written scope and an evidence inventory.

How do DeployOpen and an independent assessor divide the work?

The provider owns its controls and its attestation. DeployOpen plans, implements and hardens the self-hosted open-source platforms inside the client's own infrastructure, then prepares the systems, controls and evidence the questionnaire needs. Security testing is a separate scoped task. DeployOpen does not issue reports, attestations or certifications. The independent QSA, ISA or assessor, where required, tests the evidence and the provider's responses, and the directing entity accepts the result. Agree this split in writing before work starts, so each party knows what it delivers and what it does not.

How DeployOpen prepares service provider evidence before validation

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the systems, controls and documentation that a service provider needs for SAQ D for Service Providers. We do not issue attestations; your compliance-accepting entity and assessor decide what evidence is acceptable.

How we scope

Each engagement starts with a written scope covering every PCI DSS requirement that applies to your service and supporting systems.
We map which in-scope systems support the customer cardholder data environment, including those that only indirectly support payment data.
We identify the service-provider-only duties your compliance-accepting entity expects, such as the cryptographic architecture and six-monthly scope confirmation.

How we build

We implement and harden the open-source platforms in your cloud accounts, data centers or air-gapped networks to meet the technical requirements in scope.
We configure logging, access control, segmentation and change management so that the evidence is produced by the systems themselves.
We test segmentation and security controls in the environment and record results for the Describe Results sections of the questionnaire.

How we hand over

We deliver the required documentation, including network and data-flow diagrams, policies, responsibility matrices and control inventories, in a form your team can maintain.
We provide an evidence index that links each SAQ D response to the artifact, configuration or test record that supports it.
Your organization owns the controls, signs the Attestation of Compliance where applicable, and submits it through the channel your compliance-accepting entity specifies.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so evidence stays current between validation cycles.
We can help your team prepare for the independent assessor, but we do not perform or certify the assessment.
Ask any provider, including us, to confirm in writing which SAQ or ROC your compliance-accepting entity requires before work begins.

PCI DSS SAQ D for service providers