Which PCI DSS validation do you submit: SAQ or ROC?
A Report on Compliance (ROC) is an assessment documented by a Qualified Security Assessor (QSA), while a Self-Assessment Questionnaire (SAQ) is a self-assessment completed by the entity itself. In most cases the compliance-accepting entity, typically the acquirer or a payment brand, decides which of the two you submit, and it may also specify a subset of requirements that must be tested and documented in a ROC. If your acquirer, contract or brand has asked for PCI DSS validation, start by asking them in writing which validation type and which Attestation of Compliance they expect, and at what annual cycle.
The right answer depends on three things: whether you are a merchant or a service provider, whether you meet every eligibility criterion of a specific SAQ, and the level the card brands assigned you by transaction volume. SAQ D for Service Providers is the only SAQ available to service providers, and all other SAQs are for merchants. An SAQ can only be used if all of its eligibility criteria are met, so confirm that against the exact SAQ type before assuming it applies. Visa, for example, requires a ROC by a QSA for Level 1 merchants and Level 1 service providers, and an annual SAQ for Level 2 and 3 merchants and Level 2 service providers. Check the rules of your own card brands, since they set the level and the requirement.
Every route, whether ROC or SAQ, ends with an Attestation of Compliance (AOC) signed by an executive officer of the entity. A ROC AOC is also signed by a duly authorized officer of the QSA company. DeployOpen prepares systems, controls and evidence for your assessment, but it does not issue any ROC, SAQ or AOC. Only your organization attests, and only the QSA or your own signing officer can complete the relevant documents, so plan who owns that sign-off before the assessment window opens.
Which SAQ fits your payment channel
Online merchants that take payments on a website are usually split by how much of the payment page they control. If the page is fully outsourced to a payment provider through a redirect or an embedded iframe, the merchant may be eligible for SAQ A. If the merchant's website can affect the security of the payment page, even while card data goes to a provider, SAQ A-EP is the questionnaire to examine. The difference lies in who controls the page and the scripts that run on it.
- Full outsourcing: Card data is entered only on the provider's hosted page, with no card data passing through your servers.
- Website influence: Your servers or scripts can alter the payment page or the redirect, which points toward SAQ A-EP.
- Scripts and scanning: Some SAQ A criteria depend on controls over page scripts and external scanning, so confirm them against the SAQ A guidance.
- Eligibility is all or nothing: Missing one criterion means the SAQ does not apply, and you must move to a different questionnaire.
- Provider attestation: Obtain the provider's own compliance evidence and confirm how the page is delivered.
Before choosing, confirm the exact eligibility criteria on the SAQ A and SAQ A-EP pages, and ask your acquirer which questionnaire they accept.
Card-present merchants take payments on payment terminals, and the questionnaire depends on whether the terminal is connected to your network and how card data is encrypted. SAQ B applies to merchants using imprint machines or standalone dial-out terminals without electronic card data storage. SAQ B-IP covers standalone terminals with an IP connection. SAQ P2PE applies to merchants using a validated point-to-point encryption solution, and SPoC is relevant to merchants using a validated SPoC solution on a commercial device.
- SAQ B: Imprint or dial-out terminals with no electronic card data storage and no connection to other systems.
- SAQ B-IP: Standalone PTS-approved terminals connected over IP, which brings network controls into scope.
- SAQ P2PE: Encryption performed at the point of interaction using a solution the assessor can confirm is validated.
- SPoC: Card acceptance on a commercial device, such as a phone or tablet, using a validated SPoC solution.
- Confirm the device list: Check that each terminal and solution appears in the relevant validated inventory before you rely on it.
Ask your terminal or encryption provider for written confirmation of validation status and responsibilities, then check the SAQ eligibility criteria for your channel.
A virtual terminal is a browser-based console where staff key in card details received by phone, mail or other channels. Because card data is typed into a system you operate, the environment is more exposed than a standalone terminal, and SAQ C-VT is designed for merchants who use only this method. The merchant must not store card data electronically and must use a provider-hosted console or a fully managed environment.
- Manual entry only: Card data is keyed into a virtual terminal, not captured electronically from another system.
- No electronic storage: Card data must not be stored after authorization, including in spreadsheets, email or call recordings.
- Dedicated, isolated access: Each computer used for the console must be dedicated to that purpose and not used for general browsing or email.
- Hosted console: The console should be provided and maintained by a payment provider that handles the card data environment.
- Mixed channels disqualify: If the same systems also accept e-commerce or terminal payments, the merchant may need a different SAQ.
Confirm with your provider that the console is hosted, and check every SAQ C-VT eligibility criterion against your actual workflow, including the staff devices involved.
SAQ C applies to merchants whose payment application systems connect to the internet and handle card data, typically through a payment application connected to a point-of-sale system or a local network. These environments have more systems that must be hardened and monitored than SAQ B or C-VT, so the questionnaire is longer. It does not apply to merchants that store card data electronically, and the internet connection and network controls matter significantly.
- Internet-connected payment applications: The payment application must sit on systems that are connected to the internet and process card data.
- Network segmentation: Systems that handle card data must be separated from other systems, and the separation must be confirmed.
- Hardening and patching: Systems in the environment must be configured securely and kept current with security updates.
- No electronic storage of card data: Storing card data electronically moves the merchant out of SAQ C eligibility.
- Vendor responsibilities: Check which controls the payment application vendor and hosting provider manage, and what they must supply in writing.
Review the SAQ C eligibility criteria and map your payment application, network and connections before you select this questionnaire.
Merchants that do not meet the eligibility criteria of any shorter SAQ, or that their compliance-accepting entities require to validate more broadly, use SAQ D for Merchants. Service providers have one questionnaire only: SAQ D for Service Providers is the only SAQ available to them, and all other SAQs are for merchants. Both SAQ D versions cover the full set of requirements, so they are the widest self-assessment route. Entities whose acquirer or payment brand requires a ROC must follow that route instead.
- SAQ D for Merchants: The default when no shorter SAQ fits, covering all applicable requirements.
- SAQ D for Service Providers: The only SAQ for service providers, regardless of how small their service is.
- Acquirer requirements: Your acquirer or payment brand may demand a ROC even when an SAQ would otherwise fit.
- Service provider duties: Service providers often must support customer assessments and provide responsibility matrices, which are outside the SAQ itself.
- Scope accuracy: Full validation covers every system in scope, so confirm scope before you complete the questionnaire.
Confirm with your acquirer or payment brand whether a self-assessment is accepted for your entity, and read the SAQ D guidance for your entity type before starting.
Who decides whether you submit a ROC or an SAQ
The validation path is not chosen by the entity alone. Four decision points shape it: who accepts your compliance, which transaction level you fall into, whether you meet every SAQ eligibility criterion, and whether any partial ROC scope has been requested. Confirm each one in writing with your acquirer before assessment work begins.
Compliance-accepting entity
Payment brands and acquirers are the compliance-accepting entities that decide whether you validate with a ROC or an SAQ. The PCI SSC does not enforce compliance or impose penalties; the payment brands decide who must validate and run any enforcement programs. Ask your acquirer which validation type it accepts for your business, and whether it wants the result in a specific format. Get the answer by email before you buy an assessor or start an SAQ.
Merchant or service provider level
Card brands set levels by annual transaction volume, and the level determines the validation path. Visa, for example, requires an annual ROC by a QSA for Level 1 merchants and Level 1 service providers, and an annual SAQ for Level 2 and 3 merchants and Level 2 service providers. Confirm your level from your acquirer's notice or brand rules, because a higher level may force a ROC even if you expected an SAQ.
SAQ eligibility criteria
An SAQ is only available when you meet every eligibility criterion for that questionnaire. A single unmet criterion, such as storing card data in a system the questionnaire does not cover, means you must use a ROC or a different SAQ. SAQ D for Service Providers is the only SAQ for service providers, while the other SAQs are for merchants. Map your payment flow against the criteria for each SAQ type and document the reasons for your choice.
Partial ROC scope requests
A ROC can cover only a subset of requirements when an acquirer asks for it, for example when it wants only certain prioritized approach milestones documented. This is not the same as an SAQ, and it does not reduce the scope of your cardholder data environment. Ask the acquirer to specify the requirements in writing, the reporting format it expects and the date it needs the report. Without that written scope, the assessor and your team may test different things.
What the Attestation of Compliance does after either route
The Attestation of Compliance (AOC) is the document that closes either validation route. A Report on Compliance and a Self-Assessment Questionnaire both end with an AOC signed by an executive officer of the assessed entity. A ROC's AOC is also signed by a duly authorized officer of the Qualified Security Assessor company, which is the assessor's way of standing behind the report. Once signed, the AOC is what you hand to others. It is intended to be shared with requesting entities under payment brand rules, so it is the artifact your acquirer, card brands and business partners will ask to see, not the underlying questionnaire or ROC. Keep the signed version current, because a lapsed or unsigned AOC is the thing a requesting party will check first.
Certificates, seals and vendor logos do not count as validation. A badge from a platform provider, a cloud marketplace or a scanning tool does not show that your cardholder data environment was assessed, and the PCI SSC states that compliance certificates are not recognized as validation. When you describe your status to a customer or partner, cite the AOC and its validation date, and do not describe a vendor's compliance as your own. Where a supplier's AOC covers a service in your payment flow, request it and confirm which requirements it covers and which remain your responsibility.
Confirm with your acquirer what you must send, to whom, and how often. Ask whether they expect the full AOC or only specific sections, whether they need it annually or on another schedule, and what they require if your scope or payment channel changes mid-cycle. Also ask whether they accept a partial ROC for a subset of requirements, since some acquirers request only prioritized milestones. Record the answers in writing, because the card brands and acquirers, not the PCI SSC, set these submission rules for your organization.
ROC or SAQ: when each option fits
This table compares the Report on Compliance and the Self-Assessment Questionnaire across who writes the evidence, who must be involved, when each route applies, who signs the Attestation of Compliance, and what the organization keeps control of. Read it first to confirm your route, then check the acquirer or payment brand rules that actually decide it.
| Question | Report on Compliance (ROC) | Self-Assessment Questionnaire (SAQ) |
|---|---|---|
| Who writes the report | A Qualified Security Assessor (QSA) documents the assessment on the official ROC template | The assessed entity completes the SAQ itself, using the official PCI SSC template |
| Who must be involved | A QSA company and its QSA employees test the environment and agree the final version with the entity | Internal staff answer the questions; no QSA is required to complete the SAQ |
| When the route applies | Decided by the payment brand or acquirer, for example Visa's annual QSA requirement for Level 1 merchants and Level 1 service providers | Used by SAQ-eligible merchants and service providers, and only if every SAQ eligibility criterion is met |
| Partial assessments | A ROC can document a subset of requirements when an acquirer requests it | An SAQ covers the full questionnaire for its type; confirm with your acquirer whether a partial SAQ is accepted |
| Attestation of Compliance signatories | An executive officer of the entity and a duly authorized officer of the QSA company sign the ROC AOC | An executive officer of the entity signs the SAQ AOC |
| Final report date | The Date of Report is when the QSA company and the entity agree on the final version | The date of completion is set by the entity when the questionnaire and AOC are finished and signed |
| What the organization owns | Controls, evidence, scope decisions and the decision to accept findings; the QSA owns its findings and report | Controls, the answers given, eligibility judgment and the accuracy of the AOC; no independent report is issued |
| Who may receive the AOC | Shared externally with requesting entities under payment brand rules | Shared externally with requesting entities under payment brand rules |
| What to confirm before starting | Your acquirer or brand requirement, QSA company listing and QSA employee qualifications | Which SAQ type matches your channel and that every eligibility criterion is met today |
Who does what in a ROC or SAQ
Your organization owns the PCI DSS controls, the cardholder data environment and every decision about how the requirements are met. Whether you submit a ROC or an SAQ, the entity is responsible for the outcome. Your team completes the SAQ or supplies the evidence a QSA samples for a ROC, and an executive officer signs the Attestation of Compliance (AOC). Because the AOC is a statement by your company, the signer needs to understand what it claims.
- Control ownership: Your staff operate the firewalls, access reviews, logging, patching and policies day to day, and they must be able to show those activities happened.
- Questionnaire completion: For an SAQ, your team answers each question on the official template and confirms eligibility criteria are met before using it.
- Evidence supply: For a ROC, your team provides configuration files, scan reports, tickets and diagrams to the QSA, and answers follow-up requests.
- AOC signature: An executive officer of your organization signs the AOC, so that person needs to review the scope and results first.
- Scope accuracy: Your team defines which systems are in scope and keeps that definition current.
Before signing, confirm who on your side owns each requirement and that the AOC matches the validation method your acquirer or payment brand requires.
An implementation partner such as DeployOpen helps your team prepare systems, configuration and evidence before an assessment. It works inside your environment, under a written scope, and hands the results back to you. The partner does not decide whether you are compliant, does not write the report, and does not issue any attestation. Its role is preparation, and that boundary protects the assessor's independence.
- System preparation: The partner can plan, configure, harden and document self-hosted open-source platforms so they meet technical requirements in your environment.
- Documentation: It can prepare network and data-flow diagrams, configuration baselines and runbooks that your team reviews and owns.
- Evidence build-up: It can set up logging, scanning and change records so evidence exists for the assessor to sample.
- Gap work: It can close technical gaps identified in readiness work, with fixes that your team approves.
- Boundaries: It does not complete the AOC on your behalf, does not sign validation documents, and does not act as the QSA for the same engagement.
Ask any partner to confirm in writing which deliverables are preparation and which are attestation, and check that the same firm is not being asked to assess its own work.
The party that validates the result depends on the method. For a ROC, a Qualified Security Assessor performs the assessment, documents it in the Report on Compliance and signs a QSA company AOC along with an executive officer's signature. For an SAQ, there is no QSA assessment: the entity completes the questionnaire itself, and an executive officer signs the AOC. Compliance-accepting entities, such as acquirers and payment brands, decide which path applies to you.
- ROC testing: The QSA samples evidence, interviews staff, observes controls and records findings for each requirement tested.
- Date of Report: The ROC is complete when the QSA company and your organization agree on the final version.
- Dual signature on ROC AOCs: A ROC AOC carries both your officer's signature and a duly authorized officer of the QSA company.
- SAQ attestation: For an SAQ, the entity's officer attests that the questionnaire answers are accurate and that eligibility criteria are met.
- Partial assessments: A ROC can cover only the subset of requirements an acquirer asks for.
Confirm with your acquirer which validation path applies, and verify that any QSA you engage is independent of the team that prepared your systems.
Independence is the line that keeps a validation credible. The assessor must judge controls it did not design or run, and the entity must own the controls it reports on. In practice, the partner can help you get ready, but the QSA or the officer makes the validation claim. Blurring that line can invalidate the validation and create friction with your acquirer.
- Owner versus assessor: The entity owns its controls, and the assessor tests them without having built them as part of the same engagement.
- Preparation versus attestation: Partners prepare systems and evidence, while only the assessor or the officer attests to results.
- Documented roles: Record who did what in the engagement letter and statement of work, so an acquirer can see the split.
- Conflicts to avoid: A firm should not assess controls it designed or operated, and should not be paid in a way that depends on the validation outcome.
- Scope of AOC: The AOC must reflect the scope and results actually validated, not the scope a partner planned.
Before engaging anyone, ask for a written statement of which party signs what, and confirm the arrangement with your acquirer or payment brand.
How to check you chose the right validation path
Choosing between an SAQ and a ROC is a decision that others can overrule, so the check starts with the party that decides. The cards below walk a compliance lead through confirming the required validation in writing, testing eligibility, checking the attestation template, verifying the assessor, and agreeing scope with the acquirer.
Confirm the required validation in writing
Your acquirer or other compliance-accepting entity, typically a payment brand or acquirer, decides whether you validate with a ROC or an SAQ, and may ask for only part of the requirements to be documented in a ROC. Ask for that instruction in writing, with the reporting year and any subset named. Your own preference or a consultant's recommendation does not settle the question. Record the answer in your compliance file before you start work. Scope questions for the same entity are covered on the PCI DSS scoping and segmentation page.
Verify SAQ eligibility criterion by criterion
An SAQ can only be used when every one of its eligibility criteria is met, so a single unmet condition rules it out. Walk through the criteria for the SAQ type you expect, such as whether payment pages are fully outsourced or whether any cardholder data is stored electronically. Keep a dated record of each answer and the evidence behind it. If any criterion is uncertain, treat the SAQ as unavailable until it is resolved with the acquirer.
Confirm the AOC version and template
Both a ROC and an SAQ end with an Attestation of Compliance signed by an executive officer, and a ROC AOC is also signed by an authorized officer of the QSA company. Check that you are using the current PCI SSC template for the PCI DSS version your acquirer expects, which is v4.0.1 for assessments in this cycle. Confirm the signatory roles before the document is finalized. A superseded template or an unsigned AOC can cause your submission to be rejected.
Verify the QSA company listing
If a ROC is required, the assessment must be performed by a Qualified Security Assessor company. Check the QSA company's current listing on the PCI SSC site, including its status and any remediation, and confirm that the individual assessor is a QSA employee of that company. Ask the QSA company what it will and will not rely on from your team or other providers, and confirm its independence from any consulting work you have bought. The full verification steps are on the choosing a QSA page.
Agree scope with the acquirer
Your validation path depends on which systems are in scope, and a narrower scope may make an SAQ possible while a broader one requires a ROC. Before choosing, document the cardholder data environment, connected systems and any outsourced payment components, then send that scope to the acquirer for agreement. Repeat the confirmation after material changes such as a new payment channel or a new hosting provider. A scope that changes after submission can invalidate the validation you already filed.
Questions buyers ask about SAQ and ROC
Can we choose the SAQ ourselves?
Usually not on your own. You can only use an SAQ if you meet every one of its eligibility criteria, and the choice of validation route is made by the compliance-accepting entities, typically your acquirer and the payment brands, not by the merchant or service provider alone. Start by asking your acquirer in writing which validation type applies to your business and which SAQ they accept. Then check each eligibility criterion of that SAQ against your actual payment flow. If your environment does not match the SAQ, the answer is a ROC, not a different SAQ chosen for convenience. Keep the acquirer's written confirmation with your compliance records, because it is the reference you will need at the next annual cycle and during any review.
Does a ROC always mean a bigger effort?
A ROC generally involves more work than an SAQ, but the size of the effort depends on the drivers rather than on the label alone. The main drivers are the number of systems in the cardholder data environment, how many connected and security-impacting systems must be examined, how many requirements your environment must be tested against, the number of locations and third parties in scope, and how mature your evidence of periodic activities already is. A ROC is produced by a Qualified Security Assessor, so the assessor's time is a recurring cost on top of your internal effort. Ask any QSA company to explain which of these drivers they expect to see in your environment before you accept a quote.
Who signs the Attestation of Compliance?
The entity being assessed signs the AOC through an executive officer, and for a ROC a duly authorized officer of the QSA company also signs it. The Attestation of Compliance is the document you share externally with requesting entities under payment brand rules, so the signatures carry the accountability for the statement it makes. An implementation partner or consultant cannot sign it for you, and a PCI SSC certificate or vendor logo does not replace it. Confirm with your acquirer which AOC version and format they expect, and make sure the officer who signs understands the scope and the requirements being attested before signing.
Can we use an SAQ if one criterion fails?
No. All eligibility criteria for an SAQ must be met to use it, so a single failed criterion means that SAQ is not available to you. Typical reasons include payment pages that are not fully outsourced, systems that store or process account data on your side, or a change in your payment flow that you did not record. The practical response is to choose the validation route that fits your environment, which may be a different SAQ type or a ROC, and to confirm that choice with your acquirer. Do not complete an SAQ and then mark the failing criterion as satisfied. That creates an inaccurate Attestation of Compliance that you would have to explain later.
What changes if the acquirer asks for a partial ROC?
A partial assessment against a subset of requirements can be documented in a ROC, for example when an acquirer asks for only certain prioritized approach milestones. The scope of the report narrows to what the acquirer requested, but the ROC still follows the same template and is still completed by a Qualified Security Assessor. Compliance-accepting entities may require that only a subset of requirements be tested and documented in a ROC, so the request should come from them in writing. Ask the acquirer to define the requirements, the reporting period and the deliverable in writing, and ask your QSA to confirm in writing that the partial report matches that definition. Confirm with your acquirer whether a partial report will be accepted for the same purpose as a full validation.
Can a partner write the SAQ for us?
A partner can help prepare the work, but the organization owns the SAQ and its Attestation of Compliance. An implementation partner such as DeployOpen can prepare systems, controls and evidence for an assessment, and it can help map your environment to the questions so your internal team can answer them accurately. It does not issue reports, attestations or certifications. The answers and the AOC signature must come from your organization, and an independent assessor must perform any validation that requires one. Where a QSA is required, the QSA must remain independent of work it is asked to validate, so the scope of help should be agreed in writing before work starts, with the deliverables and the boundaries between preparation and assessment clearly stated.
Which parts of validation do we keep in house?
Keep the decisions, the accountability and the evidence in house. Your organization must confirm its scope, decide which validation route applies with its acquirer, own each control, and provide the officer who signs the AOC. Operational evidence such as logs, access reviews, change records and policy approvals must be produced by people who run the environment. Outside parties can supply services such as external scanning or penetration testing and can prepare documentation, but they do not replace your ownership. Before you engage anyone, write down which tasks sit with your team, which go to a provider and which the assessor will examine, and share that split with your acquirer so the validation path is clear from the start.
How do we confirm our SAQ or ROC requirement with the acquirer?
Send your acquirer a written request that describes your business model, payment channels, outsourcing arrangements and the systems that touch account data, and ask them to confirm the validation type, the SAQ or ROC version and any partial assessment requirement. Ask whether they accept the current template and AOC version, what their submission deadline is, and whether any payment brand program applies to your level. Record the answer and the date, because validation rules and compliance-accepting entity requirements can differ between acquirers and payment brands. Visa, for example, publishes annual validation requirements by merchant and service provider level, which you can use as a reference point when you put the question to your acquirer.
How DeployOpen prepares your systems and evidence for either route
DeployOpen's role starts with a written scope. Before work begins, we agree in writing which validation route your organization is taking, which entity and systems fall inside the assessment, and which deliverables you will receive. For a self-assessment, that means preparing the controls and evidence that the chosen SAQ asks you to attest to. For a ROC, it means preparing the systems, configurations, diagrams, inventories and records a Qualified Security Assessor will sample during fieldwork. Your payment brand or acquirer decides which route applies, so confirm that decision in writing before scoping starts, and ask them whether any subset of requirements must be documented in a ROC.
We implement and document the technical and operational controls the route requires, using self-hosted open-source platforms inside your own cloud accounts, data centers or private networks where that fits your environment. The handover package is built for two readers: your internal team, who must keep the controls running between assessments, and your assessor, who needs to trace each requirement to a system, a configuration and a dated record. Expect the package to include a configuration baseline, change records, access review outputs, log retention settings, testing evidence and an updated network or data-flow diagram where the route calls for one. Ask for an index that maps each deliverable to the requirement it supports.
DeployOpen does not issue a ROC, an SAQ as an attestation, an Attestation of Compliance or any certificate. Only the organization can sign its SAQ or AOC, a QSA company and its officer issue a ROC and its AOC, and the payment brands decide how results are accepted. Hiring DeployOpen does not guarantee a validation result, because the outcome depends on the scope you confirm, the controls your staff operate, and what the assessor finds. If you are also considering an assessor, keep the preparation work and the assessment work with separate firms, and check the PCI SSC standard page for current requirements before you sign any scope.
