Complete guide to PCI-DSS v4.0

01What PCI-DSS is

The Payment Card Industry Data Security Standard is a contractual standard maintained by the PCI Security Standards Council (Visa, Mastercard, Amex, Discover, JCB) and enforced by acquiring banks and payment-network agreements. PCI-DSS v4.0 was published in March 2022; v4.0.1 in June 2024 with editorial corrections. The future-dated requirements that were optional through 31 March 2025 are now in force.

PCI-DSS is not Indian law. It is a contractual obligation imposed by your acquirer / network on anyone who stores, processes, or transmits card data. Non-compliance triggers fines (escalating monthly), increased transaction fees, and ultimately termination of card-acceptance.

02Who it applies to

• Merchants — any entity accepting card payments, in any channel.
• Service providers — payment gateways, payment processors, card-data hosting providers, BPOs handling card data.
• Issuers — banks issuing cards (covered through related PCI standards).
• Indian context — RBI Master Directions on card-data storage prohibit merchants from storing CVV/CVC and limit other card-data retention; tokenisation is mandatory for online merchants. PCI-DSS still applies to processing and transmission, even where storage is largely eliminated.

03Merchant levels

Networks vary slightly. Acquirers may impose stricter validation than the network minimum. Confirm your level with your acquiring bank.

04SAQ types

• SAQ A — fully outsourced e-commerce; redirect or iframe to PCI-DSS-compliant gateway.
• SAQ A-EP — e-commerce where merchant page does not directly receive cardholder data but controls the page rendering it.
• SAQ B / B-IP — standalone POS terminals; B-IP for IP-connected.
• SAQ C / C-VT — POS systems isolated from network; virtual terminals.
• SAQ D — applies when no other SAQ fits; the comprehensive one. Roughly 350 questions.
• SAQ P2PE — for merchants using a validated point-to-point encryption solution.

05Scoping & CDE

The single most consequential PCI-DSS decision is scope:

• Cardholder Data Environment (CDE) — every system that stores, processes, or transmits cardholder data, plus any system connected to such a system.
• Connected systems — anything reachable into CDE (jump hosts, monitoring systems) is in scope.
• Segmentation — strong network and identity segmentation can keep non-CDE systems out of scope. This is the highest-leverage cost control.
• Tokenisation / P2PE — replace cardholder data with tokens; reduces scope dramatically.

06The 12 requirements

1. Network security controls — firewalls, NSGs, segmentation.
2. Secure configuration — hardening; default-credentials banned.
3. Protect stored cardholder data — encryption, key management, retention limits, no SAD storage.
4. Protect cardholder data in transit — strong cryptography over open networks.
5. Anti-malware — covers endpoints and servers.
6. Develop and maintain secure systems — patch SLA, secure SDLC, vulnerability management, web-app protection.
7. Restrict access by need-to-know — role-based access, least privilege.
8. Identify users and authenticate access — MFA on all CDE access, password rules, account management.
9. Restrict physical access — facilities, media handling.
10. Log and monitor — daily log review (or risk-based as per v4.0), centralised logging, FIM.
11. Test security — quarterly ASV, internal scans, annual pen-test, segmentation testing.
12. Maintain an Information Security Policy — including incident response, third-party governance, awareness.

07v4.0 key changes

• Customised approach — for the first time, organisations can implement a control differently if they meet the security objective and document a Targeted Risk Analysis (TRA).
• MFA expanded — required for all access into the CDE, not just remote.
• Risk-based — many requirements (e.g. log review frequency) now allow risk-based determination with documented rationale.
• Phishing-resistant authentication for service providers (future-dated in v4.0; effective now).
• Anti-skimming on payment pages — Magecart-class attacks driven explicit controls (req 6.4.3 / 11.6.1).
• Cryptography agility — documented approach to legacy crypto retirement.
• Service-provider obligations tightened — quarterly continued-due-diligence on critical services.

08ASV scans & pen-test

• Quarterly external ASV scans — by an Approved Scanning Vendor; passing scan record kept on file.
• Internal vulnerability scans — quarterly + after significant change.
• Annual penetration test — both external and internal; with segmentation testing in segmented environments.
• Methodology — based on industry-accepted (NIST SP 800-115, OSSTMM, OWASP); v4.0 expects qualified testers with documented credentials.
• Re-test after high/critical findings within 30 days.

09ROC & QSA

• QSA — Qualified Security Assessor; PCI-SSC-certified.
• Report on Compliance (ROC) — produced by QSA; submitted to acquirer; supports the AOC (Attestation of Compliance).
• Internal Security Assessor (ISA) — your own employee with PCI-SSC training; can perform certain assessments for some networks.
• Indian QSAs — multiple India-based firms certified; some global firms also operate in India.

10Service providers

• Service provider AOC — kept on file for every CDE-touching vendor.
• Responsibility matrix — explicitly which controls the vendor performs vs which you perform.
• Continued due diligence — quarterly review of critical services.
• Vendor incident notification — contractual breach-notification clauses.

11Common mistakes

• Assuming "we use Stripe / Razorpay" eliminates PCI-DSS scope. SAQ A still applies.
• Treating tokenisation as scope-out without P2PE / vendor AOC support.
• Storing CVV — explicitly prohibited and unrecoverable as a finding.
• One annual SAQ filed without operational follow-through during the year.
• ASV scans not retained, not remediated, or remediated past the SLA.
• Pen-test commissioned without segmentation testing where segmentation is claimed.
• Custom Approach used without a documented Targeted Risk Analysis.
• Service-provider AOCs missing, expired, or for the wrong service.
• v4.0 future-dated requirements not implemented despite the deadline having passed.

1290-day roadmap

• Days 1–15. Confirm merchant level + applicable SAQ. Map cardholder-data flows end-to-end. Identify CDE and connected systems.
• Days 15–30. Segmentation review; storage minimisation (no CVV, tokenise where possible); descope what can be descoped.
• Days 30–50. 12-requirement gap register against v4.0.1; prioritise MFA expansion, anti-skimming on payment pages, log review.
• Days 50–65. Quarterly ASV scan scheduled; annual pen-test scoped with segmentation testing; service-provider AOC inventory refreshed.
• Days 65–80. Customised Approach decisions documented (TRAs); v4.0-specific controls validated.
• Days 80–90. SAQ / ROC walkthrough with QSA / ISA; remediation backlog with named owners; AOC submission to acquirer.