PCI DSS v4.0.1 Compliance Guide

Any business that stores, processes or transmits payment card data, or can affect the security of that data, is expected to comply with PCI DSS. For IT companies this reaches well beyond online shops: payment gateways, SaaS platforms with built-in billing, hosting providers, managed service providers and agencies that build checkout pages can all be in scope. This guide explains how PCI DSS v4.0.1 works, how to reduce your scope, which validation route applies to you, and what changed when the future-dated requirements became mandatory in March 2025.

What is PCI DSS?

PCI DSS is a set of technical and operational security requirements for protecting payment account data. It applies to the cardholder data environment (CDE): the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, plus systems connected to them or able to affect their security.

Full form and definition

PCI DSS stands for Payment Card Industry Data Security Standard. Cardholder data includes the primary account number (PAN), cardholder name, expiry date and service code. Sensitive authentication data includes full magnetic stripe or chip data, card verification codes (CVV2, CVC2) and PINs, and must never be stored after authorisation.

Law, standard or certification?

PCI DSS is a contractual industry standard. Your obligation comes from your merchant agreement with an acquirer or your contracts with payment partners, not from statute, although a few US states reference PCI DSS in their data security laws. Organisations "validate compliance" rather than holding a certificate; an Attestation of Compliance (AOC) is the document customers and partners ask for.

History and background of PCI DSS

Before 2004, each card brand ran its own security programme. Visa, Mastercard, American Express, Discover and JCB aligned their programmes into PCI DSS 1.0 in December 2004 and formed the PCI Security Standards Council in 2006 to manage it.

Version 4.0 was published in March 2022, the largest revision in a decade. A limited revision, v4.0.1, followed in June 2024 to correct errors and clarify intent. Version 3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024. The requirements that v4.0 introduced as "future-dated" best practices became mandatory on 31 March 2025.

Why was PCI DSS introduced?

Card fraud from compromised merchant systems was rising quickly, and inconsistent brand programmes made compliance confusing. A single standard gave merchants and service providers one baseline and gave the brands one way to measure it.

Main objectives and purpose

The 12 requirements are grouped under six goals:

• Build and maintain a secure network and systems
• Protect account data
• Maintain a vulnerability management programme
• Implement strong access control measures
• Regularly monitor and test networks
• Maintain an information security policy

Who needs PCI DSS compliance?

Merchants

Any entity that accepts payment cards from Visa, Mastercard, American Express, Discover or JCB. Card brands assign merchant levels by annual transaction volume; Level 1 merchants (for Visa and Mastercard, generally more than six million transactions a year) need an annual ROC, while smaller merchants usually complete an SAQ.

Service providers

Businesses that store, process or transmit cardholder data on behalf of others, or manage components that can affect its security. For IT companies this includes:

• Payment gateways, processors and payment facilitators
• Hosting and cloud providers whose customers run cardholder data environments
• Managed service and security providers that administer in-scope systems
• SaaS platforms that take card payments for their customers' end users
• Call centre and support outsourcers that take card payments by phone

High-volume service providers (more than 300,000 transactions a year under Visa and Mastercard rules) generally need an annual ROC.

Geography

PCI DSS applies worldwide wherever the card brands operate. In India, the Reserve Bank of India's card-on-file tokenisation rules, in force since 1 October 2022, separately prohibit merchants and payment aggregators other than card issuers and networks from storing card data, which reinforces PCI DSS scope reduction.

Key requirements of PCI DSS v4.0.1

1. Install and maintain network security controls such as firewalls and cloud security groups.
2. Apply secure configurations to all system components, removing defaults.
3. Protect stored account data: minimise storage, never store sensitive authentication data after authorisation, render PAN unreadable, and manage keys.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect systems and networks from malicious software, including anti-phishing measures.
6. Develop and maintain secure systems and software: patching, secure development, public-facing web application protection and payment page script management.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access, including multi-factor authentication for all access into the CDE.
9. Restrict physical access to cardholder data.
10. Log and monitor all access to system components and cardholder data, using automated log review.
11. Test security regularly: vulnerability scans, penetration tests, segmentation tests and change detection.
12. Support information security with policies and programmes: risk analysis, awareness, incident response, third-party management and scope confirmation.

Requirements that became mandatory on 31 March 2025

• MFA for all access into the CDE, not only remote and administrative access (8.4.2)
• Inventory and authorisation of scripts on payment pages, with integrity checks (6.4.3), and change and tamper detection on payment pages (11.6.1)
• Automated mechanisms for audit log reviews (10.4.1.1)
• Targeted risk analyses to justify the frequency of periodic tasks (12.3.1)
• Stronger password length requirements of at least 12 characters (8.3.6)
• Anti-phishing mechanisms (5.4.1)
• Authenticated internal vulnerability scanning (11.3.1.2)
• Disk-level encryption no longer sufficient on its own to render PAN unreadable on non-removable media (3.5.1.2)

Defined and customised approaches

Version 4 introduced the customised approach: instead of following a requirement's defined procedure, a mature organisation can meet its stated objective with a different control, supported by a targeted risk analysis and assessor testing. Most organisations use the defined approach for most requirements.

How to implement PCI DSS: step by step

1. Find all card data. Trace every payment flow and search systems, logs, databases, tickets and recordings for PANs.
2. Reduce scope. Use hosted payment pages or iframes from a compliant provider, tokenisation, and point-to-point encryption for card-present payments. Delete stored card data you do not need.
3. Segment the network so that the CDE is isolated from other systems, and plan to test that segmentation.
4. Determine your validation route with your acquirer or the brands: which SAQ type, or a ROC.
5. Run a gap assessment against the applicable requirements.
6. Remediate: MFA, logging, hardening, patching, script management on payment pages, key management.
7. Collect evidence and complete the SAQ, or engage a QSA for the ROC.
8. Run quarterly ASV scans of external-facing systems and fix failures.
9. Operate the controls continuously: log review, access reviews, periodic risk analyses and annual scope confirmation (every six months for service providers).

Documentation required

• Network and data flow diagrams for the CDE
• Inventory of system components, payment page scripts and third-party service providers
• Information security policy and operational procedures for each requirement
• Roles and responsibilities, including a written responsibility matrix with service providers
• Targeted risk analyses for flexible-frequency requirements
• Incident response plan
• Scan reports, penetration test reports and segmentation test results
• SAQ or ROC, and the Attestation of Compliance

Audit and assessment requirements

Validation options

Validation	Who performs it	Typical use
Self-Assessment Questionnaire (SAQ A, A-EP, B, B-IP, C, C-VT, D, P2PE, SPoC)	The organisation itself, sometimes with an Internal Security Assessor	Smaller merchants and low-volume service providers (SAQ D for service providers)
Report on Compliance (ROC)	Qualified Security Assessor (QSA)	Level 1 merchants and service providers
Approved Scanning Vendor (ASV) scans	PCI SSC-approved scanning vendor	Quarterly external vulnerability scans

Validation is annual. Penetration tests are required at least yearly and after significant changes, and segmentation controls must be tested yearly for merchants and every six months for service providers.

Estimated implementation timeline

• SAQ A merchant using a fully outsourced payment page: a few weeks.
• SAQ D merchant or small service provider: 3 to 6 months.
• First ROC for a payment platform or hosting provider: 6 to 12 months, including remediation.

Cost considerations

• QSA fees for a ROC, or ISA training for internal assessors
• Quarterly ASV scans and annual penetration tests
• Security tools: MFA, log management and SIEM, file integrity and script monitoring, vulnerability scanners
• Network segmentation and architecture changes
• Payment provider fees for tokenisation or hosted fields, which often pay for themselves through reduced scope

Scope reduction is the most effective cost control. A merchant that never touches card data can be in SAQ A with a short checklist; one that stores PANs needs most of the standard.

Benefits of PCI DSS compliance

• Ability to accept cards and to win business from merchants and payment partners who require your AOC.
• Lower risk of card data breaches and the forensic, reissue and fraud costs that follow.
• Proven controls (MFA, logging, segmentation) that strengthen the whole environment.

Risks and consequences of non-compliance

• Non-compliance fees and higher transaction fees from acquirers.
• Liability for fraud losses, card reissue costs and mandatory forensic investigations after a breach.
• Termination of the merchant agreement or placement on card brand match lists.
• Regulatory action under data protection laws if card data is breached.

Common implementation mistakes

• Underestimating scope: forgetting jump hosts, CI/CD pipelines, logging systems and admin workstations connected to the CDE.
• PANs in logs, support tickets, call recordings and analytics.
• Assuming a PCI-compliant payment provider makes you compliant; you still own the systems that serve or redirect to its payment page.
• Ignoring scripts on the checkout page, which is the target of web skimming (Magecart) attacks.
• Treating compliance as an annual project instead of continuous operation.
• Choosing the wrong SAQ type.

Compliance challenges for IT companies

• Shared responsibility in cloud: document which requirements the cloud provider, your platform and your customer each meet.
• Agencies building checkouts must manage scripts, third-party tags and change control on the merchant's payment pages.
• Multi-tenant SaaS handling payments for customers becomes a service provider and must provide AOCs to them.
• Software vendors selling payment software may need validation under the PCI Secure Software Standard; the older PA-DSS programme closed in 2022.

Best practices and recommendations

• Do not store card data unless you must; use network tokens or provider tokens.
• Use a provider-hosted payment page or hosted fields, and lock down scripts with a content security policy and integrity monitoring.
• Build the CDE as a separate cloud account or project with its own identity boundaries.
• Automate evidence collection for logs, configurations and access reviews.
• Align secure development with the OWASP Top 10, which Requirement 6 references through common vulnerability categories.

Tools and technologies that help

• Payment gateways with tokenisation and hosted payment fields
• Point-to-point encryption (P2PE) solutions for card-present payments
• Web page script inventory and tamper monitoring tools
• SIEM and automated log review
• Vulnerability scanners and ASV services
• Data discovery tools that search for PANs

Relationship with other compliance frameworks

PCI DSS and related frameworks

Framework	Relationship
ISO 27001	Broad management system; many controls overlap, but ISO 27001 does not replace PCI DSS validation
SOC 2	Customers may accept both; PCI DSS is far more prescriptive for card data
OWASP Top 10	Informs secure coding and web application testing under Requirement 6
SOX	Public companies' payment systems can be in scope for both

Real-world implementation examples

The following are illustrative composites based on common patterns, not named clients.

E-commerce agency

An agency maintaining 30 online stores moved all of them from self-hosted card forms to the payment provider's hosted fields, added a content security policy and script monitoring on checkout pages, and helped each merchant move from SAQ A-EP towards SAQ A eligibility.

SaaS billing platform

A subscription billing platform that stored PANs for recurring charges replaced them with gateway tokens, removed the card vault from its own infrastructure, and reduced its ROC scope to the small set of systems that call the gateway.

Frequently asked questions

Is PCI DSS a law?

No. It is an industry standard enforced through contracts with acquirers and card brands, though a few US states reference it in law.

What is the current version of PCI DSS?

PCI DSS v4.0.1, published in June 2024. Version 4.0 was retired at the end of 2024.

Is there a PCI DSS certificate?

Not formally. Organisations validate compliance and produce an Attestation of Compliance. "PCI certified" is common shorthand for a valid AOC.

Which SAQ do I need?

It depends on how you accept payments. Fully outsourced e-commerce payment pages may qualify for SAQ A; direct post or JavaScript integrations usually need SAQ A-EP; storing or processing card data needs SAQ D. Confirm with your acquirer.

Can we store CVV codes?

No. Card verification codes and other sensitive authentication data must not be stored after authorisation, even if encrypted.

Does using Stripe, Razorpay or PayPal make us compliant?

It greatly reduces your scope, but you still need to validate compliance for your part, typically with a short SAQ.

How often are ASV scans required?

At least quarterly and after significant changes, with passing results.

Is MFA required for all users?

Since 31 March 2025, MFA is required for all access into the cardholder data environment, not only remote or administrative access.

What happens if we have a card data breach?

Expect a forensic investigation by a PCI Forensic Investigator, possible fines and liability for fraud and reissue costs, and stricter validation requirements afterwards.

Does PCI DSS apply to service providers that never see card data?

It can, if they manage systems that could affect the security of cardholder data, such as hosting or administering the CDE.

How long does a first ROC take?

Typically 6 to 12 months including remediation, depending on scope and maturity.

Conclusion and next steps

PCI DSS rewards good architecture. Shrink the scope first, then protect what remains with strong identity, logging, hardening and testing, and operate the controls all year.

1. Map every payment flow and find stored card data.
2. Reduce scope with tokenisation and hosted payment pages.
3. Confirm your SAQ or ROC route.
4. Close gaps against the v4.0.1 requirements, including those mandatory since March 2025.
5. Validate annually and monitor continuously.

How we keep this guide up to date

We review this guide every six months and whenever the PCI Security Standards Council publishes a new version, SAQ revision or significant FAQ. Each review checks version numbers, effective dates and the SAQ list.