PCI DSS v4.0 Explained in Simple Words for Business Owners

Most business owners think PCI DSS is done the day they sign an SAQ or receive a certificate from a vendor. Then a card scheme forwards a breach notification, a forensic firm called a PFI (PCI Forensic Investigator) shows up, and the same owner discovers that the certificate they framed was worth exactly nothing because their card data was flowing through a system nobody had scoped.

PCI DSS v4.0 was written by people who have watched that scene play out hundreds of times. It is not new bureaucracy for its own sake. It is the card industry closing the exact gaps that let breaches happen while everyone was technically compliant. This is a plain-English walk through what changed, what it costs, and what your team actually has to do — from an auditor who signs the report.

PCI DSS stands for Payment Card Industry Data Security Standard. It is a private contractual standard owned by the PCI Security Standards Council, which is backed by Visa, Mastercard, American Express, Discover and JCB. It is not a law and no government enforces it. Your acquiring bank enforces it through your merchant agreement. If you store, process or transmit cardholder data — a card number (the PAN, or Primary Account Number), the cardholder name, the expiry, or the service code — you are in scope. In India that means almost every e-commerce merchant, payment aggregator, PA-PG entity regulated by the RBI, and most SaaS platforms that touch card rails.

Version 4.0 was published in March 2022. Version 3.2.1 was formally retired on 31 March 2024. A large batch of the tougher v4.0 requirements were future-dated and became mandatory on 31 March 2025. So if your last assessment was against 3.2.1, you are already behind, and the future-dated controls are no longer optional. In late 2024 the Council issued a minor revision, v4.0.1, which is now the operative version — clarifications, not new burden.

Before anything else, you need to know your merchant level. This single fact decides whether you fill in a self-assessment questionnaire over a weekend or endure a three-month on-site audit by a QSA (Qualified Security Assessor). Levels are set per card brand by annual transaction volume, but Visa and Mastercard thresholds are the ones almost everyone follows.

Two traps here. First, a breach can vault you to Level 1 overnight regardless of volume — the schemes reserve that right. Second, if you are a Level 4 merchant using a compliant payment gateway, you still are not off the hook; you complete the right SAQ (usually SAQ A for fully outsourced e-commerce, or SAQ A-EP if your site touches the payment page). Picking the wrong SAQ is the single most common mistake I see, and it silently invalidates the whole exercise.

PCI DSS has always had twelve core requirements grouped under six goals. The structure survived into v4.0. Here is what each one really asks of you, without the clause language.

Do not treat v4.0 as a cosmetic re-number. Roughly 64 new requirements were added, most of them future-dated to 31 March 2025. Each one maps to a real-world attack the old standard let through. These are the ones that actually change your budget and your work.

Under 3.2.1 you needed MFA only for administrative and remote access into the cardholder data environment (CDE). Requirement 8.4.2 now demands MFA for all access into the CDE, including internal users at a console. If your developers and support staff log in with a password alone, that is a finding. Budget for an identity platform if you do not have one.

This is the headline change and the one most Indian e-commerce firms are unprepared for. Magecart-style attacks inject malicious JavaScript into a merchant's checkout page and quietly siphon card data as the customer types it, upstream of any gateway. Requirement 6.4.3 says you must inventory and authorise every script that runs on your payment page and confirm its integrity. Requirement 11.6.1 says you must deploy a change-and-tamper detection mechanism that alerts you when your payment page's HTTP headers or scripts are modified. A framed certificate does nothing against this; you need tooling. This alone catches a huge share of real-world card breaches, which is precisely why the Council made it mandatory.

Minimum password length moved from 7 to 12 characters (Requirement 8.3.6). Disk-level encryption on multi-user systems no longer counts as rendering the PAN unreadable (Requirement 3.5.1). Anti-phishing controls are now explicit. And targeted risk analysis, under Requirement 12.3.1, lets you set the frequency of certain activities based on documented risk rather than a fixed calendar — freedom that comes with the burden of writing and defending the analysis.

v4.0 introduces two ways to meet most requirements. The defined approach follows the stated control as written. The customised approach lets a mature organisation meet the security objective using a different control of its own design, provided it documents a full targeted risk analysis and the QSA independently derives testing procedures. This is genuinely useful for cloud-native and container-heavy shops. It is also a trap for the immature: if you cannot produce rigorous risk documentation, do not go near it. Most first-time assessees should stick to the defined approach.

Owners always ask for a single number and there isn't one — it depends on your level, your architecture, and how much remediation you need. But here are honest working ranges from the Indian market, separating the assessment fee from the far larger remediation and tooling spend that nobody warns you about.

The lesson buried in that table: the audit fee is rarely your main cost. Remediation and ongoing tooling are. A first-time Level 1 assessment for an Indian payment aggregator commonly runs three to six months end to end, and the RBI's own PA-PG framework requires valid PCI DSS compliance (a current Attestation of Compliance) as a precondition for authorisation — so for regulated fintechs this is not optional, it gates your licence.

Let me give you a scene, because the abstract requirements never land otherwise. A mid-size Indian D2C brand, roughly Level 2, is confident. Their payment page is a hosted iframe from a well-known gateway, so they assumed SAQ A and a light touch. On day one I ask a single question: show me the source of your checkout page. It loads an analytics tag, a heat-mapping script, and a chat widget — three third-party JavaScript files running in the same DOM as the payment iframe.

That changes everything. Because those scripts share the page, the merchant is exposed to e-skimming and drops out of SAQ A into SAQ A-EP, with Requirements 6.4.3 and 11.6.1 fully in play. They had no script inventory, no integrity monitoring, and no idea who had added the chat widget. The finance director's face when the scope tripled is the moment PCI DSS stops being paperwork and becomes real. We spent the next six weeks building a script allow-list, deploying tamper detection, and removing two marketing tags nobody could justify. The certificate came later — the security came first, which is the entire point of v4.0.

Non-compliance is not a paperwork problem; it is a financial and legal one, and in India it now stacks with the Digital Personal Data Protection Act (DPDP Act, 2023).

If you are starting cold or moving off 3.2.1, do it in this sequence. Skipping straight to buying tools before you have scoped is how firms waste lakhs protecting systems that were never in scope.

It is easy to treat PCI DSS as a cost centre. Done properly it is not. The segmentation work reduces your attack surface for every threat, not just card fraud. The logging and MFA you build satisfy DPDP, ISO 27001 and SOC 2 controls simultaneously, so one disciplined programme services several obligations. And a current Attestation of Compliance is a commercial asset — it shortens enterprise procurement and unlocks partnerships that gate on it. The firms that suffer are the ones treating it as an annual certificate hunt; the ones that thrive treat the twelve requirements as a baseline operating standard.

Come back to the owner with the framed certificate and the flowing card data. The gap between those two things — the paperwork and the reality — is exactly what v4.0 was written to close. MFA into the whole CDE, script integrity on your payment page, honest scoping: none of it is glamorous, all of it is the difference between being compliant and being secure. Aim for the second and the first follows.

At CyberSigma we are senior CERT-In empanelled auditors and PCI QSAs who do this hands-on — scoping, gap assessment, and the awkward payment-page questions — so you find the third-party script before an attacker does, not after. If you want a straight read on where you actually stand against v4.0.1, that is the conversation we are happy to have.