What is PCI DSS v4, and what does it mean for a business that takes cards?

What is PCI DSS?

The Payment Card Industry Data Security Standard is set by the PCI Security Standards Council (PCI SSC). The Council describes it as a baseline of technical and operational requirements designed to protect payment account data. It applies to every entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the environment where that data lives. That includes merchants, processors, acquirers, issuers and service providers.

PCI DSS is not a law. It is enforced through contracts: card networks require it of acquirers, and acquirers require it of the merchants they sign up. Which validation a business must complete, and how often, is set by its acquirer and the card brands, not by the Council.

What changed in version 4?

The Council’s summary of changes from v3.2.1 to v4.0 counts 64 new requirements. Of these, 13 applied immediately and 51 were "future-dated": best practice until 31 March 2025, then mandatory. As of October 2026 that grace period is long over, so every v4 requirement now counts in an assessment.

Beyond new rules, v4 changed how the standard is written. Requirements are phrased as objectives, and an entity may meet many of them through a customized approach, its own control designed to meet the stated objective, backed by a targeted risk analysis, in place of the defined approach. Several requirements now let an entity set the frequency of a task through its own targeted risk analysis, where v3.2.1 fixed it. Terminology was modernised: "firewalls and routers" became network security controls, "anti-virus" became anti-malware, and "cardholder data" became account data where appropriate.

What are the 12 requirements?

The structure is unchanged from earlier versions: six goals and twelve principal requirements. In plain terms:

Which new requirements matter most?

Of the 51 future-dated requirements, a handful change day-to-day work for most businesses:

• 8.4.2 — Multi-factor authentication for all access into the cardholder data environment, not just remote or administrator access. v4.0.1 added a note that MFA is not required for non-administrative access to the environment when only phishing-resistant factors, such as FIDO passkeys or security keys, are used.
• 5.4.1 — Anti-phishing. Processes and automated mechanisms to detect and protect staff against phishing attacks.
• 6.4.3 — Payment page scripts. Manage all payment page scripts that are loaded and executed in the customer’s browser.
• 11.6.1 — Change and tamper detection on payment pages. Alert on unauthorised changes to the HTTP headers and contents of payment pages as the browser receives them.
• 3.4.2 — Remote access. Technical controls to stop staff copying or relocating card numbers when using remote-access technology.
• 12.3.1 — Targeted risk analyses for requirements that let the entity set its own frequency.

The two payment-page rules, 6.4.3 and 11.6.1, target e-skimming: malicious scripts injected into a checkout page that copy card details as the customer types. Our post on passkeys and FIDO explains what makes an authentication factor phishing-resistant.

Which self-assessment questionnaire applies?

Smaller merchants usually validate with a Self-Assessment Questionnaire (SAQ) rather than an on-site assessment by a Qualified Security Assessor. Each SAQ covers only the requirements relevant to a particular way of taking cards. The lightest, SAQ A, is for card-not-present merchants (e-commerce, mail or telephone order) that have completely outsourced all account data functions to PCI DSS validated third parties, and that do not store, process or transmit any account data electronically on their own systems or premises.

On 30 January 2025 the Council announced changes to SAQ A that took effect on 31 March 2025. It removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A, and added an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The underlying requirements remain in PCI DSS itself; they were removed only from that questionnaire. Even under SAQ A, requirements that protect the merchant’s own web server, such as parts of requirements 2, 6 and 8, still apply when it redirects customers to a third party or embeds the third party’s payment form.

How do you keep PCI scope small?

The cheapest requirement to meet is one that does not apply. Scope follows the card data, so the main lever is keeping card numbers away from your own systems:

1. Use a hosted or embedded payment page from a PCI DSS validated provider, so card details go straight from the customer’s browser to the provider.
2. Store tokens, not card numbers. For repeat billing, keep the provider’s token or a network token. In India, RBI’s card-on-file tokenisation rules already bar merchants from storing card numbers.
3. Never collect card details by email, chat or spreadsheet. One stray file brings an entire laptop or mailbox into scope.
4. Watch your checkout page. Limit third-party scripts on pages that host or embed the payment form, and know who can change them.
5. Turn on MFA everywhere that touches payments: the provider dashboard, your hosting and your code repository.
6. Keep the evidence. Your provider’s Attestation of Compliance and your own SAQ are what an acquirer will ask for.

Network tokens and provider vaults are compared in network tokens vs PCI vaulting. For exporters paid by bank transfer rather than card, PCI DSS does not arise at all; it is a card-data standard.