PCI DSS v4.0 Reference

PCI DSS v4.0 — Key Facts

Item	Detail
Current version	PCI DSS v4.0 — published March 2022
v3.2.1 retirement	v3.2.1 retired 31 March 2024 — v4.0 is now the only active standard
New future-dated requirements	64 new requirements in v4.0 were \"best practice\" until 31 March 2025, after which they became mandatory
Who must comply	Any organisation that stores, processes, or transmits cardholder data (CHD) — merchants, service providers, payment gateways, acquirers
India context	All RBI-regulated payment aggregators, payment gateways, acquiring banks, and merchants above thresholds must comply. NPCI mandates PCI DSS for UPI apps handling card data
Compliance validation	Annual self-assessment (SAQ) or audit by a Qualified Security Assessor (QSA) depending on transaction volume
Merchant levels	Level 1: >6M transactions/year → QSA audit required. Levels 2–4: lower volumes → SAQ typically acceptable
Service provider levels	Level 1: >300K transactions/year. Level 2: less than 300K — different SAQ required

Two compliance approaches in v4.0

Defined Approach

Follow every specific requirement exactly as written. Most common approach. Straightforward to validate — auditor checks each requirement.

Customised Approach

New in v4.0. Demonstrate you meet the security objective of each requirement through alternative controls. Requires documented methodology and is assessed by QSA only. Gives more flexibility for modern architectures.

SAQ Type Selector

Answer the questions below to identify which Self-Assessment Questionnaire applies to your organisation. If in doubt, consult your acquirer or a QSA.

What is your organisation type?

Merchant — accept card payments from customers Service Provider — process card data on behalf of merchants

How do you accept/process card payments?

Fully outsourced / redirect — customers enter card data directly on a third-party page (PayU, Razorpay, Stripe). Your servers never touch card data. Iframe / hosted fields — payment fields are hosted iframes from your PSP. Your site renders them but card data never hits your servers. JavaScript tokenisation — card data is tokenised in-browser (Stripe Elements, Braintree). Your servers receive a token, not card data. API / direct post — card data is posted directly to your servers, which then call the payment API. Service provider — I store, process, or transmit card data for other merchants.

SAQ Types Reference

SAQ	Who it applies to	Controls
SAQ A	Card-not-present merchants fully outsourcing to a PCI-compliant third party. No electronic CHD storage. Includes redirect and iframe.	~13 requirements. Simplest SAQ.
SAQ A-EP	E-commerce merchants using third-party JS (Stripe Elements, Braintree). Your site loads the JS but card data goes direct to PSP.	~190 requirements. More comprehensive than SAQ A.
SAQ B	Merchants using imprinters or standalone dial-out terminals only. Very rare today.	~41 requirements.
SAQ B-IP	Merchants using standalone IP-connected terminals not storing CHD.	~83 requirements.
SAQ C	Merchants with payment application systems connected to internet. Not storing CHD.	~158 requirements.
SAQ C-VT	Merchants entering card data via isolated virtual terminals on a dedicated PC.	~83 requirements.
SAQ D (Merchant)	All other merchants not covered by A, A-EP, B, B-IP, C, or C-VT. Storing or processing CHD directly.	All 12 requirements — most comprehensive.
SAQ D (Service Provider)	Service providers storing, processing, or transmitting CHD.	All 12 requirements + additional service provider requirements.

All 12 PCI DSS v4.0 Requirements

Build & Maintain Secure Networks

Req 1 Build and maintain a secure network and systems

Req 2 Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Account Data

Req 3 Protect stored account data

Req 4 Protect cardholder data with strong cryptography during transmission

Maintain a Vulnerability Management Program

Req 5 Protect all systems and networks from malicious software

Req 6 Develop and maintain secure systems and software

Implement Strong Access Control Measures

Req 7 Restrict access to system components and cardholder data by business need-to-know

Req 8 Identify users and authenticate access to system components

Req 9 Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Req 10 Log and monitor all access to system components and cardholder data

Req 11 Test security of systems and networks regularly

Maintain an Information Security Policy

Req 12 Support information security with organisational policies and programs

Key Changes from PCI DSS v3.2.1 → v4.0

Change Area	What changed	Effective
Customised Approach	New option to demonstrate security objective equivalence via alternative controls instead of following requirements verbatim. Requires QSA validation.	31 March 2024
Multi-factor Authentication (MFA)	MFA now required for ALL access into the cardholder data environment (CDE) — not just remote access. Includes administrators accessing from within the internal network.	31 March 2025
Password requirements	Minimum 12-character passwords (up from 8). Password change required if compromise suspected — but periodic forced changes no longer mandatory if MFA is in place.	31 March 2025
Anti-phishing controls	Requirement 5.4.1: anti-phishing mechanisms in place — this includes email filtering, URL filtering, and user training. New explicit requirement.	31 March 2025
Targeted risk analysis	Many requirements now allow timing/frequency to be set based on a documented targeted risk analysis rather than fixed intervals.	31 March 2024
E-commerce / skimming prevention	Requirement 6.4.3/11.6.1: payment page scripts inventoried and authorised. HTTP headers monitored for unauthorised modifications. Specifically targets Magecart/skimming attacks.	31 March 2025
Pen test scoping	Clarified that internal and external penetration testing must cover the full CDE boundary, not just a sample.	31 March 2024
Audit log protection	10.3.3: audit logs protected from destruction and modifications by all users including admins. Immutable log storage required.	31 March 2025
Encryption of CHD at rest	Req 3 restructured — clearer requirements on protecting stored account data. Primary Account Number (PAN) must be rendered unreadable wherever stored.	31 March 2024
Roles and responsibilities	Each requirement now explicitly states who is responsible — clearer accountability across the organisation.	31 March 2024