PCI DSS 4.0 for Indian Merchants and Payment Aggregators

PCI DSS 4.0 is the current mandatory version of the Payment Card Industry Data Security Standard, replacing version 3.2.1 after its retirement in March 2024. For Indian merchants, payment aggregators (PAs), payment gateways (PGs), and fintechs that store, process, or transmit cardholder data, compliance is not optional — card networks (Visa, Mastercard, RuPay) and acquirers enforce it contractually. Version 4.0 introduces a Customized Approach for mature organisations, expanded multi-factor authentication (MFA) mandates, targeted risk analysis, and continuous monitoring requirements. Critically, 64 future-dated requirements that were phased in from 31 March 2025 are now fully mandatory. This guide explains what changed, who it affects in India, and how to scope, assess, and remediate efficiently.

Who Must Comply with PCI DSS in India

Any organisation that touches payment card data falls under the PCI DSS umbrella, regardless of whether it is headquartered in India or abroad. In the Indian context, three major categories are relevant:

Merchants accepting card payments — from large e-commerce platforms to retail POS operators — are tiered by annual transaction volume. Tier 1 merchants (over 6 million Visa or Mastercard transactions per year) must complete a full Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA). Tier 2–4 merchants typically self-assess using a Self-Assessment Questionnaire (SAQ).

Payment Aggregators and Payment Gateways licensed by the Reserve Bank of India (RBI) under the Payment Aggregators and Payment Gateways guidelines (March 2020) are required by RBI to hold a PCI DSS certificate at Level 1. This is non-negotiable: RBI has embedded PCI DSS compliance as a condition of authorisation. The RBI PA/PG circular explicitly references the standard as a baseline security requirement.

Fintechs and Neobanks that issue co-branded cards, store card tokens, or operate card-linked loyalty programmes must scope their cardholder data environment (CDE) correctly or face card-brand fines routed through their acquirer.

The 12 Requirements: What PCI DSS 4.0 Actually Covers

PCI DSS organises its controls into 12 high-level requirements grouped across six goals. Version 4.0 restructured the language around outcomes rather than prescriptive checklists, but the 12 headings remain:

The Four Major Changes in PCI DSS 4.0

1. Customized Approach

The most architecturally significant change is the introduction of a Customized Approach alongside the existing Defined Approach. The Defined Approach is the prescriptive, step-by-step path — it specifies exact controls. The Customized Approach lets organisations with mature security programmes design their own controls that meet the stated objective, provided they document the control, perform a targeted risk analysis, and have a QSA validate the outcome.

This is not a shortcut — it is harder. It requires thorough documentation and a QSA willing to assess bespoke controls. For most Indian merchants and PAs, the Defined Approach remains the right choice. The Customized Approach is relevant for large banks and financial institutions that already operate controls that exceed the prescriptive baseline.

2. Expanded Multi-Factor Authentication

PCI DSS 3.2.1 required MFA for remote access into the CDE. Version 4.0 extends this to all administrative access into the CDE, regardless of whether the session originates from within the corporate network or remotely. Database admins, application administrators, and system operators who access CDE systems from internal networks now require MFA.

For Indian organisations with legacy on-premise infrastructure and large internal admin teams, this is a significant operational change. OTP-over-SMS does not qualify — phishing-resistant MFA (TOTP apps, hardware tokens, or passkeys) is required for privileged access.

3. Targeted Risk Analysis (TRA)

Version 4.0 introduces a formalised Targeted Risk Analysis process for several requirements that previously had fixed timescales. For example, the frequency of reviewing log anomalies, the schedule for reviewing access rights, and the cadence of internal vulnerability scans could historically be set to a fixed period. Under 4.0, an organisation must justify its chosen frequency through a documented risk analysis that considers threat likelihood, detection capability, and compensating control maturity.

This shifts compliance from a calendar-driven tick-box exercise to a risk-informed programme — which is better security, but more documentation work.

4. Continuous Monitoring and Automated Log Analysis

Requirement 10.7 now mandates that critical security controls are monitored continuously and that failures are detected and responded to promptly. Log review can no longer be a weekly manual task — automated alerting on suspicious patterns is required. This aligns PCI DSS 4.0 with SIEM (Security Information and Event Management) best practice.

SAQ vs ROC: Which Assessment Path Applies to You

graph TD
    A[Do you store process or transmit cardholder data?] -->|No| B[Out of Scope — document segmentation]
    A -->|Yes| C[How many card transactions per year?]
    C -->|Over 6M Visa or MC| D[Tier 1 Merchant or Level 1 PA]
    C -->|Under 6M| E[Tier 2-4 Merchant]
    D --> F[ROC by QSA — mandatory]
    E --> G[Which SAQ applies?]
    G -->|Card-not-present — fully outsourced CDE| H[SAQ A]
    G -->|Imprint only or standalone terminals| I[SAQ B]
    G -->|eCommerce — partial card page| J[SAQ A-EP]
    G -->|IP-connected terminals| K[SAQ C]
    G -->|Internal CDE| L[SAQ D — full controls]
    F --> M[Annual ROC plus quarterly ASV scans]
    H --> N[Lightest burden — 22 controls]
    L --> O[Heaviest burden — all 12 requirements]

    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style D fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style M fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style N fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style O fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style G fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style H fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style I fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style J fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style K fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style L fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

The self-assessment questionnaire you complete depends entirely on how your organisation handles card data. SAQ A applies when you have fully outsourced all card processing and your e-commerce pages redirect to a third-party hosted payment page with no card data ever touching your servers. SAQ D is the most comprehensive and applies to any merchant or service provider with an internal CDE.

Scoping and Segmentation: The Most Efficient Path to Compliance

Scope defines which systems, people, and processes must comply. Everything in or connected to the CDE is in scope. The most effective compliance strategy is minimising the CDE through:

1. Tokenisation: Replace the Primary Account Number (PAN) with a surrogate token in your systems. Only the token vault (held by your payment processor) touches the real PAN.
2. Network segmentation: Use firewall rules and VLANs to isolate CDE systems. Systems that have no network path to the CDE can be documented as out of scope.
3. Hosted payment pages: For e-commerce merchants, redirecting to a PCI-compliant hosted payment page (operated by your PA/PG) means card data never enters your domain.

VAPT and ASV Scanning Requirements

PCI DSS 4.0 Requirement 11 mandates specific security testing:

1. Requirement 11.3: Internal vulnerability scans must be performed at least quarterly and after any significant change, and high-risk and critical vulnerabilities must be remediated before the next scan.
2. Requirement 11.3.2: External vulnerability scans must be performed quarterly by an Approved Scanning Vendor (ASV) approved by the PCI SSC. ASVs are a specific certification category distinct from general security firms.
3. Requirement 11.4: Penetration testing must be performed at least annually and after significant infrastructure changes. The scope includes network-layer and application-layer testing.
4. Requirement 6.4: All public-facing web applications must be protected by a WAF or undergo a web application vulnerability assessment at least annually.

xychart-beta
    title "PCI DSS 4.0 — Future-Dated Requirements: Illustrative Category Distribution (64 total)"
    x-axis ["Authentication", "Monitoring", "Encryption", "Software Security", "Risk Analysis", "Other"]
    y-axis "Approx Count" 0 --> 20
    bar [12, 11, 9, 14, 8, 10]

The 31 March 2025 Deadline: What Became Mandatory

When PCI DSS 4.0 was published in March 2022, the PCI SSC designated 64 requirements as future-dated, meaning they were best-practice guidance that would become mandatory on 31 March 2025. As of that date, these are now fully enforceable. The most operationally significant ones include:

1. Requirement 5.3.3: Anti-phishing mechanisms must be in place for personnel who could be targeted via email.
2. Requirement 6.3.2: An inventory of all bespoke and custom software must be maintained.
3. Requirement 6.4.2: WAF or equivalent protection for all public-facing web applications must be deployed (not merely planned).
4. Requirement 8.4.2: MFA for all access into the CDE (the expanded scope beyond remote access).
5. Requirement 10.7.2: Failures of critical security controls must be detected, alerted, and resolved promptly.
6. Requirement 12.3.2: A TRA must be performed and documented for requirements where frequency is driven by the entity's own risk assessment.

External Authoritative Sources

The PCI Security Standards Council publishes all official documentation at pcisecuritystandards.org, including the full PCI DSS 4.0 standard, the SAQ forms, the list of approved QSAs and ASVs, and the Customized Approach guidance. The RBI's Payment Aggregator and Payment Gateway framework circular (March 17, 2020) is available at rbi.org.in and explicitly lists PCI DSS compliance as a licensing prerequisite for Payment Aggregators.

For further reading on India's broader cybersecurity and data protection obligations, the CERT-In guidelines under the IT Amendment Rules 2022 are published at cert-in.org.in, and the Digital Personal Data Protection Act 2023 framework is available through meity.gov.in.