Does a PCI DSS for SaaS platform need a ROC or SAQ D?
A SaaS platform that can affect its customers' cardholder data is a service provider under PCI DSS, and it must validate with the SAQ D for Service Providers or with a Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA). Which one applies depends on its transaction volume and the payment brand's rules, not on the product's features. The platform owns its own controls and evidence, and only the QSA issues the Attestation of Compliance (AOC) that customers and card brands will ask to see. Preparing for either path is the platform's job, and the choice should be settled early because it sets the depth of testing, the assessor's role and the cost.
For a SaaS company, the decision starts with the payment brand that governs its customers. Visa's levels illustrate the logic: a Level 1 service provider, which handles over 300,000 transactions a year, needs an annual ROC from a QSA, while a Level 2 provider completes an annual SAQ. Both levels also need quarterly ASV scans. Check the thresholds, and any other brand rules, for every card brand your platform touches, because the strictest rule that applies to your volume usually decides the outcome. Confirm the current figures directly with each brand before you commit, since a platform can cross a threshold in a single year of growth.
The answer also shifts with data flow and tenancy. A platform that stores, processes or transmits account data in a shared multi-tenant environment brings Appendix A1 into scope, and it must support customers' external penetration testing. Ask your assessor early whether a SAQ D is accepted for your volume and architecture. Whichever route you take, do not hand customers a merchant SAQ or merchant AOC as proof of your compliance, because the SAQ D for Service Providers is the only correct questionnaire for this role.
Which multi-tenant requirements apply to SaaS platforms
Appendix A1 adds requirements for multi-tenant service providers whose customers share servers, databases, applications or SaaS infrastructure. The cards below cover the duties a SaaS platform most often has to evidence, from tenant separation to customer penetration testing support. Confirm how each one applies to your architecture with a QSA before you scope the assessment.
Separation between customers
Appendix A1 expects a multi-tenant provider to keep one customer's cardholder data environment logically separated from every other customer on shared infrastructure. In a SaaS platform this covers tenant identifiers in databases, encryption keys scoped per tenant, isolated storage buckets and network segmentation between tenant workloads. Ask your QSA which separation controls it will test and what evidence it expects, such as configuration exports and access test results.
Customer-specific access
Each customer's administrators and users should reach only their own tenant data and configuration. Check that application roles, API tokens and support access are bound to a tenant, and that provider staff access to a customer environment is granted by business need and logged. Shared administrative consoles are a frequent gap, so test whether one tenant's credentials can read another tenant's records.
Logging per tenant
Audit logs should show which tenant each event belongs to, so a provider can answer questions about one customer's data without searching every tenant. Confirm that log records carry a tenant identifier, that log access is restricted, and that the logs for each customer can be exported for review. Ask how the platform proves log integrity over the retention period that the logging requirements set.
Supporting customer penetration testing
Since 31 March 2025, multi-tenant providers must support customers' external penetration testing under Requirement 11.4.7. A provider may either show evidence of its own testing on the infrastructure the customer subscribes to, or give the customer prompt access to test. Decide which option fits your platform, write it into customer agreements, and confirm the exact evidence wording with your QSA.
Shared resource hardening
Shared servers, containers and databases used by several customers need the same baseline controls as the rest of the cardholder data environment. Check that tenant workloads cannot reach the host, that container orchestration is locked down, and that shared database accounts do not give cross-tenant access. Confirm with your QSA how it will sample shared components during the assessment.
SAQ D or ROC: which validation fits a SaaS platform
A SaaS company that is a service provider in its customers' payment flow completes the Self-Assessment Questionnaire D for Service Providers, the only SAQ that applies to service providers. The company's own management completes it, using evidence gathered internally, and signs the Attestation of Compliance. No external assessor issues this document, although a payment brand or acquirer may ask for further review. The questionnaire covers every requirement in scope, so eligibility criteria from merchant SAQs cannot be used to exclude requirements.
- Who completes it: Your own staff, typically security and compliance, with an officer signing the AOC.
- What it outputs: A service provider AOC, which states your compliance status to each party that receives it.
- Scope: All people, processes and technology used to deliver the service, including multi-tenant controls under Appendix A1.
- What customers typically request: The current AOC, the responsibility matrix, and evidence of external penetration testing support for their subscribed infrastructure.
- Limit to check: A merchant AOC handed to customers does not substitute for your own service provider AOC.
Confirm with your acquirer or payment brand whether they accept an SAQ D for your volume tier before you commit to this path.
A higher volume service provider, or one whose payment brand requires independent validation, must have a Report on Compliance completed by a Qualified Security Assessor. The QSA tests controls, samples evidence and documents findings in the ROC, then the company signs an AOC that references it. The QSA assesses independently; your team prepares systems, policies and evidence but does not write the report. Visa states that Level 1 service providers, which handle over 300,000 transactions a year, need an annual ROC by a QSA, and Visa lists those providers.
- Who completes it: A QSA firm conducts the assessment and writes the ROC, with your team supplying evidence.
- What it outputs: A ROC plus a service provider AOC issued by the company after the assessment.
- Listing: Visa lists Level 1 service providers validated by ROC, so listing status can be checked.
- What customers typically request: The AOC with its supporting ROC summary, and confirmation the QSA is independent of any consulting work you bought.
- Limit to check: Keep the QSA engagement separate from remediation consulting so independence holds.
Confirm your level and the reporting obligation with your payment brand, since the thresholds come from the brand, not from the PCI SSC.
A SaaS offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software if it meets the program's eligibility criteria at submission. This validates the software product rather than your company's service operations. It fits a platform whose software performs payment functions that customers deploy or rely on, and it runs alongside, not instead of, your PCI DSS assessment of the service. Listing status depends on meeting eligibility criteria when you submit, so confirm those criteria before starting.
- Who completes it: A PCI SSC-recognized assessor performs the Secure Software validation.
- What it outputs: A validation result and a listing as Validated Payment Software if accepted.
- Scope: The software and its secure development lifecycle, not the full hosting environment.
- What customers typically request: Evidence the product is listed, which tells them the software was assessed against the Secure Software Standard.
- Limit to check: A listing does not by itself show your hosting environment meets PCI DSS, so you still need an SAQ D or ROC.
Ask the assessor and the PCI SSC which eligibility criteria apply to your product before you budget for the validation.
How a SaaS PCI DSS validation runs from scoping to AOC
The sequence moves from defining what the service includes, through gap work and evidence, to testing and an assessment that ends in an Attestation of Compliance signed by a QSA or by the company on a self-assessment questionnaire. Each step produces a document or check that the next step depends on.
Define the service and its supporting environment
Start by writing down what the SaaS product does for customers in their payment flow, then list every person, process and technology component that supports it. That includes production hosting, databases, administrative access paths, support tooling, build pipelines and any internal teams with access to the environment. The output is a service description and a system inventory that the assessor will compare against the actual environment. Confirm the list with engineering, operations and support staff, since access paths are the most common gap at this stage.
Confirm the scope and the service provider status
Decide, with the assessor where possible, which components store, process or transmit account data and which could affect its security. Because the company is a service provider, all people, processes and technology involved in the service are in scope, and a merchant questionnaire cannot be used to narrow it. The output is a scope statement with data flow diagrams and a list of connected systems, reviewed and approved by the company's leadership. Record which multi-tenant obligations apply, since shared infrastructure changes the controls that must be shown.
Close control gaps against the requirements
Compare current controls with each applicable requirement in PCI DSS v4.0.1, using the defined approach or, where the company qualifies, the customized approach for a stated objective. Engineering, security and operations own the remediation, and the gap register records each finding, its owner and its fix. Where a control is met by a cloud or hosting provider, record which party is responsible. The output is a remediated control set or a documented gap list, with the responsibility record for shared controls.
Collect and retain evidence for each requirement
For every requirement in scope, gather the artifacts an assessor will sample: configuration exports, access reviews, change records, log samples, policy approvals, training records and key management records. Evidence must show the control operating over time, not only a point-in-time setting. The output is an evidence index that maps each requirement to its artifacts, owners and review dates. Ask your assessor early which samples they will request so the company can produce them without reconstructing history.
Run penetration tests and quarterly ASV scans
Perform internal and external penetration testing against the defined scope, and make sure multi-tenant obligations are covered, including support for customers' external penetration testing of their subscribed infrastructure. Run external vulnerability scans through an Approved Scanning Vendor at the frequency the standard requires. Remediate findings and retest where needed. The output is a penetration test report, scan reports with passing results, and a retest record. Independent penetration testing providers can perform this work, but the company owns the decision to accept or fix each finding.
Choose the assessment type and complete it
Decide between a Report on Compliance completed by a Qualified Security Assessor and a self-assessment questionnaire. For a service provider, SAQ D for Service Providers is the only SAQ that applies. Payment brands may also require a ROC for certain provider levels, so confirm the requirement with each brand or acquirer before committing. The output is a completed ROC or SAQ D, supported by the evidence index and the scope statement. Ask the QSA or internal team to confirm the scope matches the one approved in step two.
Issue the Attestation of Compliance
With a ROC, the QSA reviews the evidence, issues the report and signs the Attestation of Compliance for the company to share. With SAQ D, a company officer signs the Attestation of Compliance after the questionnaire is complete and accurate. Either way, the AOC is the document customers and payment brands ask for, and a certificate does not replace it. The output is a signed AOC with its scope, validity and the list of responsibilities the company provides to customers. Confirm with each customer and acquirer how they expect to receive the AOC and any responsibility matrix.
When the PCI Secure Software Standard changes the validation path
A SaaS company can validate its software to the PCI Secure Software Standard and seek listing as Validated Payment Software, but that route covers the product, not every obligation the operating company carries as a service provider. The cards below separate the two and list what to confirm before choosing a path.
Eligibility is checked at submission
A software-as-a-service offering can be validated to the PCI Secure Software Standard and listed as Validated Payment Software only if it meets the program's eligibility criteria when it is submitted. Eligibility is therefore a point-in-time test, so a platform that changes its architecture or payment functions after listing should check whether its listing still reflects the product. Ask the program which criteria apply to hosted and multi-tenant models before you prepare a submission.
Software validation covers the product
Validation to the Secure Software Standard assesses the payment software itself, including its design, development and security controls. It does not, by itself, establish that the company operating the platform meets the service provider duties that apply to its own people, facilities, hosting and customer support. Treat the listing as evidence for one part of the picture, and map which parts of PCI DSS the operating company still has to meet.
Service provider obligations still apply
A SaaS company that can affect the security of payment account data remains a service provider, and PCI DSS scope covers all people, processes and technology used to deliver its service. Confirm with your acquirer, the payment brands and your customers which service provider requirements they expect you to validate through a ROC or SAQ D for Service Providers. A software listing does not replace that answer.
Multi-tenant duties remain in place
Where customers share application infrastructure, databases or servers, PCI DSS Appendix A1 adds requirements for multi-tenant service providers. The software validation may address parts of tenant isolation, but the hosting environment, tenant separation in production and customer access to test are operational matters. Ask whether your listing and your assessment cover the same tenancy model you run in production.
Customer penetration testing support
Since 31 March 2025, multi-tenant service providers must support customers' external penetration testing, either by providing evidence of testing on the customer's subscribed infrastructure or by giving customers prompt access to test. Software validation does not satisfy this on its own. Decide early which option you will offer, and check that your customer agreements describe it.
Confirm obligations in writing
Before relying on a listing, ask the program, your acquirer and key customers to state in writing which obligations still apply to your company. Record the answers in your responsibility matrix and assessment scope, along with the version of the listed software. Repeat the check when either the software or the customer contract changes.
Who owns the SaaS controls, who prepares evidence, and who attests
The SaaS company is the service provider, and it owns every PCI DSS requirement that applies to its platform and its people. Ownership means the decisions, accountability and day-to-day operation stay inside the company, even when outside parties build or test parts of the environment. Customers rely on this team to explain how the platform protects account data in their payment flow.
- Policy and governance: Approves the security policies, risk analysis and scope decisions that PCI DSS expects the company to maintain.
- Operation of controls: Runs access reviews, change approvals, log reviews and vulnerability triage as recurring tasks.
- Engineering ownership: Builds the secure development practices and multi-tenant isolation that the platform depends on.
- Customer-facing record: Maintains the responsibility matrix and the written acknowledgments that customers request.
- Final decisions on scope: Confirms which systems, people and services are in the assessment.
Check that each control has a named internal owner who can explain it to an assessor without relying on a consultant.
An implementation partner such as DeployOpen prepares the systems, controls and evidence that the SaaS company then operates and presents to its assessor. Work typically covers hardening self-hosted open-source components inside the company's own cloud accounts or data centers, configuring centralized logging, setting up backup and recovery, and running security testing where it falls in scope. DeployOpen does not issue reports, attestations or certificates, and it does not act as the assessor.
- Hardening and configuration: Prepares system components to meet the secure configuration and access requirements in the scope agreed in writing.
- Logging and evidence: Sets up audit log collection, retention and review tooling that produces the records an assessor samples.
- Security testing: Runs penetration testing and vulnerability work where it is in scope, and supports customer penetration testing requests in multi-tenant environments.
- Documentation support: Helps draft diagrams, inventories and procedures that the company then approves.
- Fixed-scope delivery: Work, deliverables and timelines are agreed in writing before the engagement starts, and ongoing support is available as a retainer.
Before engaging a partner, confirm in writing which requirements it touches and which evidence it hands over to the company.
The assessment itself is performed by an independent party. A Qualified Security Assessor (QSA) completes a Report on Compliance (ROC) for a service provider that is required to validate that way. A service provider that validates by self-assessment completes the service provider SAQ D and signs an Attestation of Compliance (AOC). In both cases, the signed AOC is the document customers and payment brands read, and a certificate is not accepted as validation.
- Independent testing: The QSA tests controls against the standard and samples evidence, which a consultant cannot do for its own work.
- ROC or SAQ D: The validation type depends on the payment brand rules and the company's volume and level, so confirm it with the acquirer or brand early.
- AOC issuance: Only the QSA firm or the company signer completes and signs the AOC on official PCI SSC templates.
- Evidence review: The assessor reviews the responsibility matrix and the scope, including provider AOCs for services the company relies on.
- Sign-off limits: The signer attests only to the scope actually assessed.
Ask the assessor to confirm in writing which evidence it expects, and whether it will accept the partner's documentation as input.
Questions SaaS teams ask before a PCI DSS validation
Does a SaaS company have to validate PCI DSS compliance at all?
Usually yes, if the platform can affect the security of payment account data for its customers, even when it never stores, processes or transmits that data itself. PCI DSS covers service providers with access to a customer's cardholder data environment or that meet a PCI DSS requirement on a customer's behalf. Whether a given SaaS company must validate, and how often, is decided by the payment brands and acquirers that it serves, not by the PCI Security Standards Council. Confirm the obligation in writing with each acquirer or brand your customers use, and ask them which validation type they expect and by what date. Keep the answer documented, because the same question returns every year and every new integration can change it.
Is SAQ D or a ROC the right validation for a SaaS provider?
For a service provider, the correct questionnaire is SAQ D for Service Providers, and a Report on Compliance completed by a Qualified Security Assessor is the other route. A SaaS company cannot choose a merchant SAQ because its own eligibility criteria look simpler. The choice between SAQ D and a ROC is driven by what your acquirer or the payment brand requires, and by transaction volume where the brand sets tiers. Visa, for example, requires a ROC from Level 1 service providers that handle over 300,000 transactions a year, and an annual SAQ from smaller ones. Ask your acquirer which route applies before you scope the assessment.
What drives the cost and effort of a SaaS PCI DSS validation?
The main drivers are the number of systems in the cardholder data environment, how many tenants share infrastructure, how many third parties sit in the payment flow, and whether the assessment is a ROC or an SAQ. Costs fall into two groups. Assessor fees are paid to the QSA or the questionnaire review for the assessment itself, and they recur annually. Internal and implementation costs cover engineering time, logging and access controls, documentation, quarterly ASV scans and customer testing support, and they recur as well. Ask every quote to break out the assessor work, the remediation work, the evidence collection and any recurring scanning, and to state what is excluded. No general figure should be assumed until the written scope is agreed.
Can an internal team complete a PCI DSS validation alone?
An internal team can prepare for and run much of the work, but it cannot issue the validation. Only a QSA can complete a ROC, and an SAQ must be completed by the organization and attested by an authorized officer. Internal staff typically own policies, access reviews, change control, logging, vulnerability management and the evidence library, while outside help is often used for scoping, gap analysis, technical testing and the assessment itself. Keep the separation clear: an implementation partner prepares systems and evidence, and the independent assessor issues the report. Before you decide, check whether your internal team has the time and the assessor independence your acquirer expects.
How does a SaaS company handle customer penetration test requests?
Since 31 March 2025, a multi-tenant service provider must support customers' external penetration testing. It can do this either by providing evidence of testing performed on the infrastructure the customer subscribes to, or by giving the customer prompt access to test. Most providers publish a documented procedure that states which systems are in scope, what notice the customer gives, which rules of engagement apply and how findings are shared. Make sure the procedure does not expose other tenants, and confirm with your assessor that the approach satisfies the requirement. Your own internal penetration testing and external scans still apply in addition to customer requests.
Does a PCI DSS certificate from a provider count as validation?
No. PCI DSS validation is documented on official PCI SSC templates, either a ROC or an SAQ, each with an Attestation of Compliance. The PCI SSC does not recognize certificates as validation, so a customer asking for one should be sent the current AOC instead. A merchant AOC or merchant SAQ given to customers is also not sufficient evidence of a service provider's compliance. Check with each customer's acquirer what document it accepts, and ask the assessor to confirm which AOC the SaaS company should issue.
What must a SaaS company provide to a QSA before the assessment?
Expect the QSA to ask for a defined scope, an up-to-date network and data-flow diagram, an inventory of system components in the cardholder data environment, and a list of third parties that affect the payment flow. The QSA will also request the policies and procedures each requirement expects, evidence of recurring tasks such as access reviews, log reviews and vulnerability scans, and the responsibility matrix covering any cloud or hosting provider. Ask the assessor for a written document request list before fieldwork starts, and confirm which evidence the assessor will accept in each format.
How DeployOpen prepares a SaaS platform's PCI DSS evidence
DeployOpen plans, implements, hardens and documents the self-hosted open-source platforms that sit inside a SaaS company's payment flow, in the company's own cloud accounts or data centers. We prepare systems, controls and evidence for the assessment, while the organization owns its controls and an independent QSA issues the Report on Compliance or the Attestation of Compliance.
How we scope
- Every engagement starts with a written scope that names the platforms, tenants, cloud accounts and third parties in the payment flow.
- We map which systems can affect the security of customer account data, including those with access to a customer's CDE.
- We document the scope boundary and agree it with your QSA before build work begins, so assumptions are visible early.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We implement and harden open-source platform components against the requirements, including configuration baselines and access controls.
- We configure multi-tenant isolation and logging so tenant activity can be separated and reviewed as the standard expects.
- We set up vulnerability scanning and penetration testing support so customers can receive evidence or prompt test access.
- We integrate key management, encryption and centralized audit logs into your existing deployment, with changes recorded.
How we hand over
- We deliver the policies, network and data-flow diagrams, inventories and procedures that your assessor will request.
- We provide runbooks and evidence collection steps so recurring tasks can be repeated by your own staff.
- We document responsibilities for each requirement, marking which are met by your team, your providers and shared controls.
- We walk your team and assessor through the evidence trail before the assessment, so gaps are found in advance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover patching, configuration drift checks, log reviews and re-testing after significant platform changes.
- We can support your team when a customer asks for evidence or when the standard's next iteration changes requirements.
- Confirm with your QSA which evidence they accept, since an assessor's findings decide the validation outcome, not DeployOpen.
