Key Takeaways
- PCI DSS v4.0 superseded v3.2.1 in March 2024 with full enforcement of new requirements from March 2025.
- 12 requirements grouped into 6 control objectives: build and maintain a secure network, protect cardholder data, maintain a vulnerability management programme, implement strong access control, regularly monitor and test networks, maintain an information security policy.
- Major v4.0 changes: MFA expanded (every account into the CDE), customised approach (alternative to defined requirements), script integrity (6.4.3 and 11.6.1), targeted risk analysis, more frequent reviews.
- Merchant levels 1 to 4 determine validation approach (ROC for Level 1, SAQ for lower levels). Indian merchants typically self-assess via SAQ except large platforms which need a ROC.
- Service providers (payment aggregators, gateways, hosting providers in card flow) face additional requirements beyond merchant baseline.
What Changed in v4.0
PCI DSS v4.0 was a structural revision. The most consequential changes for Indian businesses:
Customised approach: alternative to defined-requirement compliance. Allows organisations to demonstrate the control objective is met by a different mechanism, with targeted risk analysis and documented justification.
MFA expansion: required for all access into the Cardholder Data Environment (CDE), not just remote and admin access. Affects internal users, applications, system accounts.
Script integrity: requirements 6.4.3 and 11.6.1 mandate maintenance of an inventory of all scripts on payment pages and monitoring for unauthorised changes. Targets Magecart-style digital skimming attacks.
Targeted risk analysis: required for several flexible-frequency activities. Documented analysis justifies the chosen frequency.
More frequent reviews: certain policies and procedures require annual review where v3.2.1 was less specific.
The 12 PCI DSS Requirements at a Glance
- R1: Install and maintain network security controls
- R2: Apply secure configurations to all system components
- R3: Protect stored account data
- R4: Protect cardholder data with strong cryptography during transmission over open public networks
- R5: Protect all systems and networks from malicious software
- R6: Develop and maintain secure systems and software
- R7: Restrict access to system components and cardholder data by business need to know
- R8: Identify users and authenticate access to system components
- R9: Restrict physical access to cardholder data
- R10: Log and monitor all access to system components and cardholder data
- R11: Test security of systems and networks regularly
- R12: Support information security with organisational policies and programs
Need Compliance Programme Help?
Codesecure delivers ISO 27001, SOC 2, PCI DSS, DPDP, HIPAA, GDPR, RBI, SEBI and NIST CSF programmes for Indian businesses. ISO/IEC 27001:2022 certified delivery, named ISO 27001 LA consultants, fixed-price proposals.
See Compliance Services →Merchant Levels and Validation Types
Merchant level is set by the card brands (Visa, Mastercard, RuPay, Amex) based on annual transaction volume. Level 1 (over 6 million transactions per year) requires an annual Report on Compliance (ROC) by a Qualified Security Assessor. Level 2 (1 to 6 million) typically requires SAQ D plus quarterly external scans. Level 3 (20K to 1M e-commerce) typically SAQ A, A-EP, or D depending on architecture. Level 4 (under 20K e-commerce or under 1M total) typically SAQ A or B.
SAQ (Self-Assessment Questionnaire) types vary by acceptance method: SAQ A fully outsourced card processing (small e-commerce using hosted pages), SAQ A-EP direct post or iframe with merchant control, SAQ B imprint or standalone dial-up POS, SAQ B-IP standalone IP POS, SAQ C integrated POS, SAQ C-VT virtual terminal, SAQ D merchants and service providers handling card data with no other SAQ applicable.
Script Integrity (6.4.3 and 11.6.1) for E-commerce
Requirements 6.4.3 and 11.6.1 explicitly target Magecart-style digital skimming where attackers inject malicious JavaScript into checkout pages to capture card data at entry.
6.4.3 requires merchants to maintain a documented inventory of all scripts loaded on payment pages, with business justification for each, and to authorise scripts before deployment. 11.6.1 requires monitoring of payment-page scripts for unauthorised changes. Detection time should be appropriate to risk.
Practical implementation: Content Security Policy with strict source allowlist plus Subresource Integrity on every external script, plus a dedicated client-side monitoring tool (Jscrambler, Source Defense, c/side, Akamai Page Integrity Manager, Imperva) that alerts on script changes. Even merchants using hosted payment pages must implement these requirements because the page containing the redirect or iframe is itself a target.
VAPT Requirements Under PCI DSS
PCI DSS requires penetration testing at minimum annually plus after any significant change. Scope must cover the entire CDE plus connected systems. Internal and external testing both required for Level 1. The pentest must be performed by qualified internal or external resources independent of the area being tested.
Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are required for merchants and service providers that have external CDE-facing systems. Internal vulnerability scans quarterly by qualified personnel or tools.
Codesecure delivers PCI DSS-aligned VAPT covering the CDE, ASV scan coordination, and remediation tracking. We are not an ASV ourselves; ASV-required scans are coordinated through a partner ASV.
Audit Pressure or Customer Questionnaire?
Whether you need a gap assessment, an internal audit, a customer security questionnaire response or a board-ready compliance status, our compliance lead is available for a 30-minute free scoping call.
Talk to a Compliance Lead →Common Non-Compliance Areas
Recurring findings in Indian PCI DSS readiness assessments: incomplete CDE scoping (systems excluded without segmentation evidence), shared admin accounts, MFA not enforced inside CDE (only external), encryption keys stored alongside encrypted data, log retention shorter than 12 months, vulnerability scans not documented quarterly, vendor compliance evidence incomplete, change management not consistently followed, incident response plan not exercised, training records patchy.
Most of these are operational rather than technological. Closing them takes 3 to 6 months of focused effort. Then the auditor confirms operating effectiveness over the audit period.
Service Provider Obligations
Service providers (payment aggregators authorised by RBI, payment gateways, BIN sponsors, hosting providers in card flow, managed service providers with CDE access) face additional requirements. Annual independent assessment (ROC) for Level 1 service providers (300K+ transactions). Quarterly attestation to customers. Specific reporting obligations to card brands.
Indian payment aggregators authorised under the RBI Guidelines for Payment Aggregators and Payment Gateways must demonstrate PCI DSS compliance as part of the authorisation. Codesecure supports PA-aspirants and PAs through PCI DSS readiness and ongoing maintenance.
Frequently Asked Questions
Is PCI DSS mandatory in India?
Card brand requirement, not statutory. But Visa, Mastercard, RuPay and Amex contractually require their merchants and service providers to comply. RBI authorisation for payment aggregators references PCI DSS. Non-compliance leads to higher transaction fees, fines, or revoked acceptance privileges.
Can we be PCI DSS compliant without a QSA?
Yes for merchants at Level 2 to Level 4 (SAQ self-assessment). Level 1 merchants and Level 1 service providers require an external QSA-led ROC. Mid-size organisations sometimes engage an Internal Security Assessor (ISA) trained equivalent.
How does scope reduction work?
Use hosted payment pages (iframe or redirect), tokenisation, P2PE-validated terminals, or move payment-data processing to a PCI-compliant service provider. Each reduces the merchant's scope materially. Choose the strategy at architecture-decision time, not after audit.
What about Indian payment networks like UPI?
UPI does not handle card data, so PCI DSS does not directly apply to UPI flows. PCI DSS applies wherever card data (PAN, sensitive authentication data) is stored, processed or transmitted. UPI-only Indian fintechs may avoid PCI DSS scope entirely. Fintechs accepting cards alongside UPI need PCI DSS for the card flow.
Does PCI DSS overlap with DPDP?
Partially. PCI DSS covers cardholder data; DPDP covers personal data. Customer email and address held alongside card data falls under both. Run them as a unified programme to share evidence and reduce duplicate effort.
Can Codesecure help us with PCI DSS?
Yes. Codesecure delivers PCI DSS readiness, gap closure, pentest scoping, ASV coordination and ongoing programme management for Indian merchants and service providers. Codesecure is not a QSA; we work alongside whichever QSA the customer selects for Level 1 ROC engagements.
Reach PCI DSS v4.0 Without Last-Minute Scrambles
Codesecure delivers PCI DSS v4.0 readiness, gap closure and pentest for Indian merchants, payment aggregators and service providers. ISO/IEC 27001:2022 certified delivery, named consultants, integrated PCI plus DPDP programmes.
