PCI DSS SAQ vs ROC: Which Validation Path Do You Need?

A merchant once handed us a self-signed SAQ A and said his acquirer was happy. Twenty minutes into the walkthrough we found his checkout page posting card data to his own server before redirecting to the gateway. That single line of JavaScript meant he was never eligible for SAQ A in the first place. He had been attesting to controls he did not have, for three years, with a signature that made him personally liable. Nobody had ever asked him one hard question.

That is the real problem with the SAQ versus ROC decision. It is not a form-length question. It is a scope and liability question that most people get wrong at the very first step, and the cost of getting it wrong does not show up until a card gets breached and a forensic firm reads your attestation back to you in a claims meeting. This guide is about choosing the right validation path honestly, with the Indian acquiring and regulatory context that actually applies to you.

PCI DSS (the Payment Card Industry Data Security Standard) gives you two ways to prove you meet its requirements. Both cover the same 12 requirement families in the current v4.0.1 standard. What differs is who assesses you and how much of your environment gets examined.

A SAQ, or Self-Assessment Questionnaire, is a shortened yes or no checklist you complete about yourself. You tick the boxes, sign an Attestation of Compliance (AOC), and submit it to your acquiring bank or the brand. No independent auditor is mandatory. There are nine SAQ types, each mapping to a specific way you handle cardholder data, and each contains only the subset of requirements relevant to that scenario. SAQ A has around 30-something questions. SAQ D has over 300, essentially the full standard.

A ROC, or Report on Compliance, is a full independent assessment performed by a QSA, a Qualified Security Assessor certified by the PCI Security Standards Council. The QSA does not accept your yes or no answers. They sample systems, pull evidence, interview staff, watch you perform tasks, and write a detailed report against every applicable requirement and testing procedure. The output is a ROC document plus a QSA-signed AOC. Some large organisations run this internally through an ISA, an Internal Security Assessor, but the rigour is the same.

Put plainly: a SAQ is you telling the brand you comply. A ROC is a certified auditor telling the brand you comply, having checked. The word that decides between them is transaction volume, but the trap is scope.

Visa and Mastercard classify every merchant into one of four levels based on annual transaction count. Your level dictates whether a ROC is mandatory or whether a SAQ is permitted. The thresholds below are the widely applied brand criteria; your acquirer can always impose a stricter level, and being breached generally pushes you up to Level 1 regardless of volume.

Service providers follow a separate scale. If you store, process, or transmit card data on behalf of others (a payment gateway, a PA-DSS-era software vendor, a hosting provider handling cardholder data), Level 1 kicks in at 300,000 transactions a year, and many acquirers and NPCI-linked schemes expect a ROC well below that. Below Level 1, service providers may use SAQ D for Service Providers. In practice, if you are a payment aggregator regulated by the RBI, expect to be treated as Level 1 and to produce a QSA ROC every year.

In India the merchant-level maths is not the whole story. The RBI Guidelines on Regulation of Payment Aggregators and Payment Gateways require any entity handling card data to be PCI DSS compliant, and the RBI Master Direction on Digital Payment Security Controls expects card-handling systems to be validated by an independent assessor. If you hold a Payment Aggregator authorisation, your compliance is not a private matter between you and Visa. It is a licence condition the RBI can act on.

We have seen fintechs that qualified for a SAQ on transaction volume still be asked for a QSA ROC by their sponsor bank as a condition of the nodal account. The bank carries the residual risk, so the bank sets the bar. When you plan your validation, ask your acquirer and, if applicable, your sponsor bank what they require in writing, before you assume the SAQ path is open to you.

If you are on the SAQ path, choosing the wrong SAQ is the single most common failure we see. The SAQ type is not a preference. It is determined entirely by how card data flows through your systems. Get the flow wrong and your attestation is void.

The decisive question for e-commerce is simple to state and easy to get wrong: does any card data ever touch a system you control, even for a millisecond? If your checkout uses a full redirect or a properly isolated iframe served entirely by your gateway, you may be SAQ A. If your page uses a direct-post, a JavaScript SDK that captures the card fields, or any script you host on the payment page, you are SAQ A-EP at minimum, which pulls in external vulnerability scanning by an ASV (Approved Scanning Vendor) and a great deal more.

The merchant in our opening was SAQ A-EP wearing an SAQ A badge. The difference between those two forms is roughly 120 requirements and quarterly ASV scans he had never run.

People assume a ROC is a longer SAQ. It is not. It is a different activity. Here is a compressed version of what a real QSA engagement looks like, from our own audit rooms.

Day one is scoping, and it is adversarial in the useful sense. We do not accept your network diagram. We trace a live transaction end to end, then hunt for the systems you forgot: the jump host an engineer built two years ago, the log aggregator that stores masked-but-recoverable PANs, the disaster-recovery site nobody patches. Scope in a ROC is proven, not asserted. This is where most first-time ROC clients discover their environment is 40 percent bigger than they thought.

Then comes evidence. For Requirement 8 (identity and access) we do not accept a password policy PDF. We pull the actual authenticator configuration, sample twenty accounts, and check that MFA is enforced into the cardholder data environment, that shared IDs are gone, and that a leaver from three months ago is actually deprovisioned. For Requirement 10 (logging) we ask you to show a genuine investigation using your logs, live, in the room. For Requirement 11.3 we read the penetration test report, then ask the tester to explain a finding they closed. A SAQ asks did you do this. A ROC asks show me, and then asks show me again for a different sample.

The v4.0.1 additions have made this heavier. The customised approach lets you meet a requirement objective by an alternative control, but you must produce a targeted risk analysis for each one, and the QSA has to validate your reasoning. Requirement 6.4.3 and 11.6.1 now demand active management and change-detection of payment-page scripts, precisely the client-side attack that has burned so many Indian e-commerce merchants. If you have deferred these thinking v3.2.1 rules still apply, that grace period is over.

The figures below are indicative Indian market ranges for a mid-sized environment. They move with scope, number of sites, cloud footprint, and how much remediation you need. Treat them as planning numbers, not quotes.

Notice the last row. A SAQ feels cheaper because you sign it yourself. That is exactly why it can be expensive. When a breach happens, the forensic investigator (a PFI, a PCI Forensic Investigator) compares your attestation to reality. If you attested to controls you did not have, the acquirer can claw back fines, non-compliance assessments, and card-reissuance costs, and your safe-harbour evaporates. A wrong SAQ is not a saving. It is deferred, amplified cost.

Strip away the noise and it comes down to three questions, in order.

There is a fourth, quieter reason to choose a ROC even when a SAQ is permitted: assurance for someone who matters. Enterprise customers, especially banks and insurers you sell to, increasingly demand a QSA AOC rather than a self-signed one during vendor due diligence. If a self-signed SAQ is costing you deals, a ROC is a commercial instrument, not just a compliance one.

A payment aggregator we assessed had grown from a SAQ A-EP mindset into handling tokenised flows for dozens of merchants. On volume they were arguably Level 2. Their sponsor bank, carrying RBI exposure on the escrow account, sent a two-line email: annual QSA ROC, or the account is suspended in ninety days. There was no negotiation and no brand table to appeal to. We ran the ROC, found their token vault logging was incomplete against Requirement 10, fixed it in six weeks, and they kept the account. The lesson is that in India your riskiest stakeholder, not the transaction count, often sets your validation path.

Come back to that merchant with the void SAQ. His mistake was not laziness. It was that no one ever sat across the table and asked whether his attestation matched his architecture. The SAQ was designed to let honest, low-risk merchants self-assess cheaply, and it does that well. It fails only when it is used as a way to avoid looking at your own environment. A ROC is not a punishment for being big. It is what you use when the truth needs to be proven, not promised.

If you are unsure which side of that line you sit on, that is the exact question we answer for a living. CyberSigma runs PCI DSS scoping and QSA assessments hands-on as CERT-In empanelled auditors, and we would rather tell you your real SAQ in an afternoon than certify a fiction. Talk to us before you sign anything.