PCI DSS Compliance in India: Complete Guide for BFSI & Fintech
Most Indian fintechs think they are PCI DSS compliant. Then a QSA asks to see the last quarterly ASV scan, the change-management ticket for the last firewall rule you pushed, and the list of everyone who touched a production card table in March. The room goes quiet.
That silence is the real state of PCI DSS compliance in India. The certificate on the wall says one thing. The evidence trail says another. And the gap between the two is exactly where card data breaches, RBI penalties and blocked bank onboarding actually live.
What PCI DSS really is, and why RBI made it non-negotiable for you
PCI DSS stands for the Payment Card Industry Data Security Standard. It is not an Indian law. It is a contractual standard owned by the PCI Security Standards Council, backed by Visa, Mastercard, RuPay, American Express, Discover and JCB. If you store, process or transmit cardholder data, your acquiring bank contractually obliges you to comply. Break that, and the bank, not a regulator, fines you first.
In India the standard stopped being optional the moment RBI folded it into its own mandates. RBI's Payment Aggregator and Payment Gateway guidelines require every PA and PG to be PCI DSS compliant before authorisation. The Card-on-File Tokenisation mandate, live since October 2022, forbids merchants and aggregators from storing actual card numbers at all, which changed the compliance scope for most fintechs overnight. And RBI's Master Direction on Digital Payment Security Controls expects your card environment to meet exactly the controls PCI DSS codifies. So while PCI DSS is technically a card-brand standard, in practice an RBI examiner and your acquiring bank both treat it as the floor.
The version that matters now is PCI DSS v4.0.1. The old v3.2.1 was retired in March 2024. A large block of v4.0.1 future-dated requirements became mandatory on 31 March 2025. If your last assessment was against v3.2.1, or against v4.0 without the newly enforced controls, you are already behind.
The four levels, and why merchants get their level wrong
Your PCI level is set by transaction volume, and it decides whether you can self-assess or must bring in a QSA. A QSA is a Qualified Security Assessor, an individual or firm certified by the PCI Council to perform on-site assessments. Most Indian companies underestimate their level because they count only their own transactions and forget the aggregated volume their acquirer sees.
| Level | Annual card transactions | Validation required | Typical Indian entity |
|---|---|---|---|
| Level 1 | Over 6 million (or any breached entity) | On-site audit by a QSA, Report on Compliance (ROC), quarterly ASV scans | Large PA/PG, bank, big e-commerce |
| Level 2 | 1 million to 6 million | SAQ or ROC depending on acquirer, plus ASV scans | Growing fintech, mid-size merchant |
| Level 3 | 20,000 to 1 million e-commerce | Self-Assessment Questionnaire (SAQ), ASV scans | Mid e-commerce, D2C brand |
| Level 4 | Under 20,000 e-commerce / under 1 million total | SAQ, ASV scans | Small merchant, early-stage startup |
Two things trip people up. First, if you are a payment aggregator or gateway, your acquirer will almost always insist on Level 1 regardless of your own volume, because you touch other people's card flows. Second, any entity that suffers a card data compromise gets pushed to Level 1 and a mandatory on-site QSA audit, whatever its transaction count was the day before.
The 12 requirements, translated into what you actually have to build
PCI DSS v4.0.1 has 12 requirements grouped into six control objectives, with roughly 300 individual sub-requirements underneath. Auditors do not care about the poster version. They care about the evidence. Here is the honest translation of what each requirement costs you in real work.
| Req | Headline | What the auditor actually wants to see |
|---|---|---|
| 1 | Network security controls | Firewall and router rulesets with business justification per rule, reviewed every 6 months |
| 2 | Secure configurations | Hardening baselines (CIS), no vendor default passwords, inventory of system components |
| 3 | Protect stored account data | Proof you do not store the PAN, or if you must, strong cryptography, key management and data-retention purge logs |
| 4 | Encrypt data in transit | TLS 1.2 or higher on all card flows, valid certificates, no legacy protocols on the CDE perimeter |
| 5 | Anti-malware | EPP/EDR on in-scope systems with current signatures and periodic scan evidence |
| 6 | Secure software | SDLC with code review, a documented change-control ticket for every production change, patched within defined windows |
| 7 | Restrict access by need-to-know | Role-based access matrix, deny-by-default, quarterly access reviews signed off |
| 8 | Identity and authentication | Unique IDs, MFA for all access into the CDE (a v4.0.1 hardening), password policy proof |
| 9 | Physical access | Data-centre access logs, visitor records, media destruction certificates |
| 10 | Logging and monitoring | Centralised logs, 12-month retention (3 months hot), daily log review, time sync |
| 11 | Test security | Quarterly ASV scans by an approved vendor, annual internal and external penetration test, segmentation testing |
| 12 | Governance | Information security policy, risk assessment, incident response plan, and the new targeted risk analyses v4.0.1 demands |
The CDE in that table is the Cardholder Data Environment: every system that stores, processes or transmits card data, plus anything connected to it. Getting your CDE scope right is the single most valuable thing you can do, because scope drives cost. If a well-configured segmentation firewall keeps your CDE to eight servers instead of eighty, your audit shrinks accordingly.
What the new v4.0.1 controls will catch you out on
Teams that comfortably passed v3.2.1 for years are failing on the requirements that hardened after 31 March 2025. These are the ones that consistently surprise Indian fintechs in the audit room.
- Requirement 8.4.2: MFA is now mandatory for all access into the CDE, not just remote and admin access. Console-level access from inside the office counts.
- Requirement 6.4.3 and 11.6.1: you must inventory and manage every script running on your payment pages, and detect unauthorised changes to payment page headers. This is the anti-Magecart control, and almost nobody has it.
- Requirement 12.3.1: targeted risk analysis. For every control where you use a custom frequency, you must produce a documented risk analysis justifying it. This is new paperwork with teeth.
- Requirement 3.4.2: technical controls to prevent copying of the PAN when accessed via remote access, unless there is a documented business need.
- Requirement 5.4.1: anti-phishing mechanisms to protect staff, a control most did not have before.
- Requirement 8.3.6: minimum 12-character passwords where passwords are still used, up from the old 7.
A scene from the audit room
A Bengaluru payment aggregator, Level 1, mid-series-B. On paper, immaculate. Policies signed, tokenisation live, a slick internal dashboard. On day two of the on-site, the QSA pulls the change tickets for the last ninety days and cross-references them against the actual firewall config diffs pulled straight from the device.
Eleven changes on the firewall. Six tickets. Five rules pushed live with no approval, no rollback plan, no record of who did it. One of them opened a management port to a wider range than intended. Nobody had noticed because nobody was reviewing the ruleset, which quietly failed Requirement 1.2.7 as well. The client was convinced they were compliant. They had a certificate from the previous year to prove it.
That is how PCI failures actually happen in India. Not through a dramatic missing control, but through the drift between what your policy says you do and what your logs prove you did. The certificate is a snapshot. Compliance is continuous. The audit exists to test whether the snapshot was ever real.
What it costs and how long it takes
Founders always want the number first, so here it is with the honest caveats. Cost scales with your level, your CDE size, whether you have done this before, and how much remediation you need before an auditor will even certify you. The audit fee is often the smallest line item; remediation is where the budget goes.
| Entity type | Indicative QSA/audit fee (INR) | Typical remediation spend (INR) | Realistic timeline |
|---|---|---|---|
| Level 4 SAQ merchant | No QSA; ASV scan 40k to 1L/yr | Minor; 1L to 5L | 4 to 8 weeks |
| Level 2 fintech (SAQ/limited ROC) | 4L to 10L | 5L to 25L | 3 to 5 months |
| Level 1 PA/PG (first time) | 10L to 30L | 25L to 1Cr+ | 6 to 9 months |
| Level 1 recertification | 8L to 20L | Ongoing BAU | 3 to 4 months |
A few realities behind those ranges. Quarterly ASV scans and an annual penetration test are recurring costs you carry every year, not one-time. First-time Level 1 always overruns on timeline because scope and segmentation are never as clean as the architecture diagram claims. And budget for tooling you probably do not have yet: a SIEM for Requirement 10, an EDR for Requirement 5, a file-integrity and script-monitoring capability for Requirements 11.5 and 11.6, and a secrets/key-management setup for Requirement 3. Those licences often exceed the audit fee.
A realistic timeline from zero to certified
- Weeks 1 to 3: Scoping and gap assessment. Define the CDE, produce data-flow diagrams for every card path, run a gap analysis against all 12 requirements. This is where a good auditor earns their fee by shrinking scope.
- Weeks 4 to 12: Remediation. Fix the gaps: implement MFA, harden configs, stand up logging, tighten access, deploy script monitoring, write the missing policies and the targeted risk analyses.
- Weeks 8 to 14: Testing. First ASV scan (expect to fail and re-scan), internal and external penetration test, segmentation testing to prove the CDE boundary holds.
- Weeks 14 to 18: Formal assessment. QSA on-site or remote evidence review, sampling, interviews, walkthroughs. Fix any findings raised.
- Weeks 18 to 20: Report on Compliance and Attestation of Compliance issued. Submit AOC to your acquiring bank.
How to choose an auditor without getting a rubber stamp
The Indian market has two kinds of QSA relationship. One treats the audit as a document-collection exercise and hands you a clean certificate that means nothing the day a real attacker shows up. The other sits in your architecture, argues about your scope, and makes you genuinely more secure. You want the second, even though the first is cheaper and less uncomfortable.
- Confirm the firm holds a current QSA listing on the PCI SSC website, and ask which named QSA will actually sign the ROC, not just the sales lead.
- Ask how they approach scope reduction and segmentation. If they show no interest in shrinking your CDE, they do not understand your cost base.
- Insist on Indian regulatory fluency: they must map PCI DSS to RBI PA/PG guidelines, the tokenisation mandate, CERT-In's 6-hour incident reporting rule and the DPDP Act, because your bank and regulator will ask.
- Prefer a CERT-In empanelled firm. CERT-In empanelment signals the auditor meets the Indian government's bar for security auditing and can support your CERT-In obligations alongside PCI.
- Reject any promise of certification in a few weeks with no remediation. Real assessments find gaps. A too-easy pass is a liability you will inherit.
The fix-it checklist before you engage a QSA
Do this groundwork first and you will cut both your audit cost and the number of embarrassing findings. Every item here is something an auditor will ask for on day one.
- Draw an accurate data-flow diagram for every path card data takes, and confirm whether tokenisation has genuinely removed the PAN from your storage.
- Segment the CDE with an enforced firewall boundary and document the business justification for every rule.
- Turn on MFA for all CDE access, including internal console access, per Requirement 8.4.2.
- Stand up centralised logging with 12-month retention and evidence of daily review.
- Get one clean quarterly ASV scan on the board and schedule the annual penetration test.
- Inventory and monitor every script on your payment pages for Requirements 6.4.3 and 11.6.1.
- Write the incident response plan and test it, and align it to CERT-In's 6-hour reporting window.
- Produce the targeted risk analyses for every custom control frequency under Requirement 12.3.1.
- Run a quarterly access review and remove every dormant or over-privileged account before the auditor finds them.
- Confirm all card flows use TLS 1.2 or higher and kill any legacy protocol on the CDE perimeter.
The certificate is not the point
Come back to that quiet audit room. The certificate on the wall was never the achievement. It was a claim that your evidence should be able to back up on any random Tuesday, not just on assessment day. PCI DSS in India is hard precisely because RBI, your acquirer and the card brands have all quietly agreed it is the minimum, and the minimum is now continuous, evidenced and version 4.0.1.
If you want that evidence trail to hold when someone actually pulls on it, get people who have sat on the other side of the table. CyberSigma's CERT-In empanelled auditors and PCI QSAs do this hands-on, in the architecture, not from a checklist, so your compliance survives contact with a real assessor and a real attacker.
FAQs
Is PCI DSS legally mandatory in India?
PCI DSS itself is a contractual card-brand standard rather than a statute. But RBI's Payment Aggregator and Payment Gateway guidelines make it mandatory for PAs and PGs, and your acquiring bank contractually requires it if you handle card data. In practice, for any Indian fintech touching cards, it is non-negotiable.
Does the RBI tokenisation mandate mean I no longer need PCI DSS?
No. Card-on-File tokenisation removes the stored PAN, which dramatically reduces your PCI scope and is a very good thing. But you still transmit and process card data during the transaction, so you remain in scope. Tokenisation makes PCI cheaper, not unnecessary.
What is the difference between an SAQ and a ROC?
A Self-Assessment Questionnaire (SAQ) is a self-attestation used by lower-volume merchants. A Report on Compliance (ROC) is a formal assessment produced by a QSA after an on-site audit, required for Level 1 entities and often demanded of aggregators by their acquirer regardless of volume.
How much does PCI DSS certification cost for an Indian fintech?
For a first-time Level 1 payment aggregator, expect roughly 10 to 30 lakh for the QSA fee and often 25 lakh to over 1 crore in remediation and tooling. Level 2 fintechs typically run 4 to 10 lakh for assessment plus remediation. Recurring ASV scans and annual pentests add ongoing cost every year.
How long is a PCI DSS certificate valid?
The Attestation of Compliance is valid for 12 months. You must recertify annually, run ASV scans every quarter, and maintain the controls continuously in between. A certificate does not protect you if the underlying controls drift, which is exactly what auditors test for on recertification.
Do I need a CERT-In empanelled auditor for PCI DSS?
PCI DSS strictly requires a listed QSA. However, choosing a firm that is both a QSA and CERT-In empanelled is a strong advantage in India, because it lets you align PCI DSS with RBI expectations, CERT-In's 6-hour incident reporting obligation and the DPDP Act under one auditor who understands the full Indian regulatory picture.
Liked the post? Share on:
Leave A Comment