PCI DSS Certification in Mumbai

Why Mumbai carries most of India's PCI DSS burden

Mumbai is where India's card economy is administered. The Reserve Bank of India and SEBI are both headquartered here, and so are the acquiring banks, NBFCs, payment aggregators, payment gateways and card networks whose systems actually touch cardholder data. If your organisation stores, processes or transmits account data — or can affect the security of a transaction that does — PCI DSS applies to you regardless of size, and your acquirer or the card brands decide how you must validate it.

That last point is the one Mumbai finance teams most often discover late. PCI SSC writes the standard, but it does not set your validation path. Your acquiring bank or the payment brand does, and in India a sponsor bank carrying RBI exposure will often be the stakeholder who decides you need a full Report on Compliance rather than a self-assessment.

“Certification” is the search term, not the mechanism

There is no PCI DSS certificate. Compliance is demonstrated in one of two ways: a Report on Compliance (ROC) produced by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ) completed by the entity — and in both cases an Attestation of Compliance (AOC) is the document your bank actually asks for. Any provider offering to “certify” you against PCI DSS is describing something the standard does not contain.

For a QSA-led assessment, PCI SSC mandates its ROC Template, and every requirement is reported as exactly one of four findings: In Place, Not Applicable, Not Tested, or Not in Place. Any use of Not Tested makes the engagement a Partial Assessment, which your acquirer will see on the AOC. The overall result is Compliant, Compliant but with Legal Exception, or Non-Compliant — there is no partial credit.

Which SAQ applies, and why the answer changed in 2025

PCI SSC publishes ten SAQs — A, A-EP, B, B-IP, C, C-VT, D for Merchants, D for Service Providers, P2PE and SPoC — and eligibility is assessed per payment channel. Qualifying on one channel tells you nothing about the others. Of the nine merchant questionnaires, only SAQ A and SAQ A-EP cover e-commerce at all.

In April 2025 PCI SSC added two eligibility criteria to SAQ A for e-commerce merchants: every element of the payment page delivered to the customer's browser must originate only and directly from a compliant third-party provider, and the merchant must have confirmed its site is not susceptible to attacks from scripts affecting its e-commerce systems. The document's own revision history records these as new criteria rather than clarifications — so a Mumbai merchant who legitimately used SAQ A in 2024 may now belong on SAQ A-EP, which brings ASV scanning and a substantially wider requirement set, without having changed a line of its own code.

Where v4.x actually bites

PCI DSS v4.0.1 is the only active version. v3.2.1 retired on 31 March 2024 and v4.0 retired on 31 December 2024. The 51 future-dated v4.x requirements stopped being best practice and became mandatory in assessments from 31 March 2025, so they are fully in scope for anything assessed today.

v4.x also introduced the customized approach, which lets you meet a requirement's stated objective by means other than the defined control — useful for mature environments, but it requires a targeted risk analysis and it excludes compensating controls entirely. Compensating controls remain available only under the defined approach, and only where a legitimate, documented technical or business constraint prevents meeting the requirement as written.

What we do, and who does it

CyberSigma is a PCI SSC-listed Qualified Security Assessor company and a CERT-In empanelled information security auditing organisation, with an office in Mumbai. A typical engagement runs: scoping and cardholder-data-flow mapping, a gap assessment against v4.0.1, remediation support with your engineering teams, evidence collection, then the formal assessment and the ROC or SAQ with its AOC.

Scoping is where Mumbai engagements are won or lost. Most cost overruns we see come from a cardholder data environment that was never properly bounded — a reporting database nobody segmented, a call recording system capturing card numbers, a legacy batch file moving PANs between systems. Finding those before the assessment starts is cheaper than finding them in it.

Related

PCI DSS compliance services · SAQ vs ROC: which validation path you need · VAPT services in Mumbai · RBI payment data localisation audit