PCI DSS 4.0: What Changed and What Indian Businesses Must Do Now

Most Indian merchants who called us in a panic through 2024 and early 2025 had the same story. They had passed their PCI DSS assessment every year for a decade, the compliance certificate sat framed on the wall, and then their acquiring bank sent a one-line email asking for their v4.0 attestation. That was the moment they discovered that the standard they had quietly ignored as a paperwork exercise had grown teeth.

PCI DSS 4.0 is not a cosmetic version bump. It is the biggest structural rewrite of the Payment Card Industry Data Security Standard since it was born in 2004, and the grace period is over. Version 3.2.1 was formally retired on 31 March 2024, and the future-dated requirements, the ones everyone kept deferring, became mandatory on 31 March 2025. If your last Report on Compliance or Self-Assessment Questionnaire predates that, you are not compliant. You just have not been audited against the new baseline yet.

PCI DSS is the security standard that any organisation storing, processing or transmitting cardholder data must meet. It is set by the PCI Security Standards Council, not by RBI, but in India it reaches you through your acquiring bank and the card networks (Visa, Mastercard, RuPay via NPCI, American Express). Your merchant agreement contractually binds you to it. So while there is no Indian statute called PCI, the enforcement is very real: non-compliance can mean fines passed through your acquirer, higher transaction fees, or in the worst case, termination of your ability to accept card payments. For a fintech or a payment aggregator regulated by RBI, PCI DSS also sits underneath the RBI Payment Aggregator and Payment Gateway guidelines, which explicitly require PCI DSS certification.

There are dozens of individual changes across the 12 requirements. But if you strip away the noise, 4.0 moves in four directions at once. Understand these and the specific clauses stop feeling random.

The old game was to get clean for the two weeks the assessor was on site, then relax. 4.0 kills that. A large number of requirements now demand a documented, targeted risk analysis (requirement 12.3.1) that justifies how often you perform a given control, and evidence that you actually performed it at that cadence all year. The assessor no longer just checks that a control exists. They check that it ran, on schedule, with logs to prove it.

For the first time, you can meet a requirement using a control the standard did not prescribe, as long as you can prove it meets the stated Customised Approach Objective. This sounds liberating. In practice it is only for mature organisations with strong security teams, because you must document the control, perform your own risk analysis, and the QSA has to design bespoke testing procedures for it. Ninety percent of Indian merchants should stick with the Defined Approach and treat the customised approach as an escape hatch for one or two genuinely non-standard controls, not a lifestyle.

This is where most Indian shops will fail their first 4.0 assessment. Multi-factor authentication is now required for all access into the cardholder data environment, not just remote or administrative access (requirement 8.4.2). Passwords, where still used, jump to a minimum of 12 characters (8.3.6). And by the deadline, MFA implementations must resist replay and cannot be bypassed by any user including administrators (8.5.1).

Two requirements, 6.4.3 and 11.6.1, exist because of Magecart-style attacks where malicious JavaScript skims card data from the payment page in the customer's own browser. If you run a checkout page in India that loads any third-party script, a chat widget, an analytics tag, a payment SDK, these two clauses now apply directly to you. Most Indian e-commerce teams have never heard of them.

Here is the shortlist we walk every Indian client through first, because these are the ones that most commonly turn a routine reassessment into a scramble.

Let us make this concrete. A mid-sized payment aggregator in Bengaluru, RBI-licensed, processing on their own infrastructure, called us for a v4.0 gap assessment after ten years of clean 3.2.1 reports. Confident team. Good engineers.

We started with scope. The CTO said the cardholder data environment was three servers in a rack. We asked to see the network diagram and the data-flow diagram, the actual artefacts required under requirement 1.2.4 and 12.5.1. The data-flow diagram was two years old. When we traced a live transaction, card data was transiting a logging pipeline into an Elasticsearch cluster nobody had listed, and a copy of masked-but-recoverable data was landing in an S3 bucket for a reconciliation job. Scope had quietly tripled. That single finding meant three more systems now needed quarterly ASV scans, hardening, and access review.

Then we opened the checkout page in a browser and ran the developer console. Fourteen third-party scripts. A tag manager, two analytics vendors, a session-replay tool, a live-chat widget, and an old A/B testing snippet the growth team had forgotten. Under 6.4.3 every one of those needed a business justification, an authorisation record, and an integrity check. They had zero. That is a Magecart skimmer's dream, and it was one finding, unremediated, that would have failed the whole Report on Compliance.

The MFA gap was the last one. Remote VPN access had MFA. But once you were on the internal network, the admin console for the payment switch took a username and a password. Under 8.4.2, that is now a failure. Retrofitting MFA onto a legacy internal application took them eleven weeks and a small integration project.

None of this was exotic. It is the ordinary reality of a system that grew for a decade while the compliance paperwork stood still. The point of 4.0 is to force that gap into the open before an attacker finds it first.

PCI DSS does not live alone in India. It sits inside a stack of obligations that a foreign-authored standard does not mention, and your QSA should be mapping the overlaps so you are not doing the same work three times.

The RBI card-on-file tokenisation mandate is the one that quietly helps you. Since it forces most merchants to stop storing the actual card number and use a network token instead, it can dramatically shrink your PCI scope. If you have implemented CoF tokenisation properly, many storage-related requirements simply fall away because you no longer hold the Primary Account Number. We regularly use this to move clients toward the far lighter SAQ A eligibility. Scope reduction is the single highest-leverage move in PCI, and Indian tokenisation rules hand it to you.

Clients always want a number. It depends entirely on your merchant level and whether you store card data, but here are realistic Indian ranges for the assessment itself, separate from remediation engineering, which is usually the larger spend.

The trap is treating the assessment fee as the total cost. On a first 4.0 engagement, remediation, retrofitting MFA, deploying client-side monitoring, rebuilding a data-flow diagram, tightening logging, routinely costs several times the audit fee. Budget for the gap, not just the certificate.

If you do nothing else, work through this list in order. It maps directly to where 4.0 assessments break in India.

The merchants who panicked in 2024 were not careless. They were caught by a standard that finally stopped rewarding the point-in-time performance and started asking whether security actually happens the other 51 weeks of the year. That is the real change in 4.0, and every specific clause is just an expression of it. Treat compliance as something that runs continuously, and the audit becomes a formality. Treat it as an annual costume you put on for the assessor, and 4.0 will find you out.

If you want a straight read on where you stand, CyberSigma's PCI QSAs are also CERT-In empanelled auditors who do this hands-on, in the room, tracing the real transaction rather than reading your last certificate. A scoping conversation is usually enough to tell you how big the gap really is.