PCI DSS v4.0.1Supported in OneClickComply

Meet PCI DSS v4.0.1 requirements with less manual effort

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard, published by the PCI Security Standards Council to protect cardholder data and sensitive authentication data. It sets 12 principal requirements covering network security, secure configuration, data protection, vulnerability management, access control, logging, testing and security policy. Version 4.0.1 is a limited revision of v4.0 that clarified wording without adding or removing requirements.

See the PCI DSS requirements

PCI DSS Aligned

Automated Evidence

OneClickFix Enabled

Continuous Monitoring

In-House Audit Team

Who needs PCI DSS

Is PCI DSS right for your organisation?

Any organisation that stores, processes or transmits payment card data, or whose systems can affect the security of that data, needs to comply with PCI DSS. Compliance is required by the payment brands and enforced through acquiring banks and contracts, so it applies from the moment you accept or handle card payments. Your acquirer or the card brands decide whether you validate with a Self-Assessment Questionnaire or a Report on Compliance from a Qualified Security Assessor.

It is usually required by customers, partners or schemes rather than by law.

Issued by: PCI Security Standards Council (PCI SSC)
Latest version: v4.0.1, published June 2024
Previous version: v4.0, retired 31 December 2024
Future-dated requirements effective: 31 March 2025
Applies to: Entities that store, process or transmit cardholder data, or can affect its security
Enforced by: Payment card brands and acquiring banks, through contracts
Validation route: Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC) by a QSA, with an Attestation of Compliance
Type: Standard (contractual)
Region: Global
In OneClickComply: Supported today

How we help

OneClickComply makes it simple

OneClickComply maps the PCI DSS v4.0.1 requirements to a single set of controls, then collects evidence automatically from your cloud, identity and device tools so you can see where you stand against each requirement. OneClickFix resolves supported misconfigurations in one click, continuous monitoring alerts you when controls drift, and AutoComplete generates the policies Requirement 12 expects. Our in-house audit team and Ask an Auditor help you prepare for your SAQ or QSA assessment.

Requirements covered

12 principal requirements grouped under six goals, broken into numbered sub-requirements and testing procedures, plus Appendix A1 (multi-tenant service providers), A2 (SSL/early TLS for POS POI terminals) and A3 (Designated Entities Supplemental Validation).

Already working towards another framework?

ISO 2700125% of PCI DSS overlaps
SOC 287% of PCI DSS overlaps
NIST CSF72% of PCI DSS overlaps
GDPR20% of PCI DSS overlaps

Evidence you collect once counts towards every framework it applies to.

Read the official PCI DSS source

Manual PCI DSS vs. OneClickComply

Manual PCI DSS

Working through hundreds of sub-requirements in spreadsheets and PDFs
Collecting screenshots of firewall rules, MFA settings and log reviews before every assessment
Writing and updating policies by hand for each requirement
Losing track of third-party service providers and their compliance status
Finding out a control has drifted only when the assessor asks for evidence

With OneClickComply

A single control set mapped to every PCI DSS v4.0.1 requirement, with progress tracked in one place
Evidence collected automatically from your connected tools and kept ready for your SAQ or QSA
Policies generated from your real environment and kept current
A vendor register that records each service provider, its responsibilities and its evidence
Continuous monitoring that alerts you to drift long before assessment day

Capabilities

Everything you need for PCI DSS

All 12 PCI DSS v4.0.1 requirements mapped to ready-made controls

Automated evidence collection for access, logging, configuration and MFA requirements

OneClickFix for supported misconfigurations, with each change logged as evidence

AutoComplete policies for information security, acceptable use and incident response

Continuous monitoring with alerts when cardholder data environment controls drift

Vendor risk management to track third-party service providers under Requirement 12.8

How it works

Three steps to PCI DSS compliance

Connect & scan

Connect your cloud, identity and SaaS tools. OneClickComply checks them against PCI DSS and shows you exactly where you stand.

Fix & generate

OneClickFix remediates technical gaps in one click, and AutoComplete generates PCI DSS-aligned policies from your real environment.

Monitor & evidence

Continuous monitoring keeps you compliant, and our in-house audit team is on hand when you need expert guidance.

Requirements

PCI DSS v4.0.1 requirements

All 12 PCI DSS v4.0.1 principal requirements and Appendices A1 to A3, with their sub-requirement groups; individual sub-requirements and testing procedures sit beneath each group.

Reference	Requirement
1	Install and maintain network security controls
1.1	Processes and mechanisms for network security controls are defined and understood
1.2	Network security controls (NSCs) are configured and maintained
1.3	Network access to and from the cardholder data environment is restricted
1.4	Network connections between trusted and untrusted networks are controlled
1.5	Risks to the CDE from devices that connect to untrusted networks and the CDE are mitigated
2	Apply secure configurations to all system components
2.1	Processes and mechanisms for applying secure configurations are defined and understood
2.2	System components are configured and managed securely
2.3	Wireless environments are configured and managed securely
3	Protect stored account data
3.1	Processes and mechanisms for protecting stored account data are defined and understood
3.2	Storage of account data is kept to a minimum
3.3	Sensitive authentication data (SAD) is not stored after authorisation
3.4	Access to displays of full PAN and ability to copy PAN is restricted
3.5	Primary account number (PAN) is secured wherever it is stored
3.6	Cryptographic keys used to protect stored account data are secured
3.7	Key management processes cover all aspects of the key lifecycle
4	Protect cardholder data with strong cryptography during transmission over open, public networks
4.1	Processes and mechanisms for protecting cardholder data in transmission are defined and documented
4.2	PAN is protected with strong cryptography during transmission
5	Protect all systems and networks from malicious software
5.1	Processes and mechanisms for protecting against malware are defined and understood
5.2	Malicious software (malware) is prevented, or detected and addressed
5.3	Anti-malware mechanisms and processes are active, maintained and monitored
5.4	Anti-phishing mechanisms protect users against phishing attacks
6	Develop and maintain secure systems and software
6.1	Processes and mechanisms for developing secure systems and software are defined and understood
6.2	Bespoke and custom software are developed securely
6.3	Security vulnerabilities are identified and addressed
6.4	Public-facing web applications are protected against attacks
6.5	Changes to all system components are managed securely
7	Restrict access to system components and cardholder data by business need to know
7.1	Processes and mechanisms for restricting access by need to know are defined and understood
7.2	Access to system components and data is appropriately defined and assigned
7.3	Access to system components and data is managed via an access control system
8	Identify users and authenticate access to system components
8.1	Processes and mechanisms for identification and authentication are defined and understood
8.2	User identification and related accounts are strictly managed throughout the account lifecycle
8.3	Strong authentication for users and administrators is established and managed
8.4	Multi-factor authentication (MFA) is implemented to secure access into the CDE
8.5	Multi-factor authentication (MFA) systems are configured to prevent misuse
8.6	Use of application and system accounts and their authentication factors is strictly managed
9	Restrict physical access to cardholder data
9.1	Processes and mechanisms for restricting physical access are defined and understood
9.2	Physical access controls manage entry into facilities and systems containing cardholder data
9.3	Physical access for personnel and visitors is authorised and managed
9.4	Media with cardholder data is securely stored, accessed, distributed and destroyed
9.5	Point-of-interaction (POI) devices are protected from tampering and unauthorised substitution
10	Log and monitor all access to system components and cardholder data
10.1	Processes and mechanisms for logging and monitoring are defined and documented
10.2	Audit logs are implemented to support detection of anomalies and forensic analysis
10.3	Audit logs are protected from destruction and unauthorised modification
10.4	Audit logs are reviewed to identify anomalies or suspicious activity
10.5	Audit log history is retained and available for analysis
10.6	Time-synchronisation mechanisms support consistent time settings across all systems
10.7	Failures of critical security control systems are detected, reported and responded to promptly
11	Test security of systems and networks regularly
11.1	Processes and mechanisms for regular security testing are defined and understood
11.2	Wireless access points are identified and monitored, and unauthorised ones are addressed
11.3	External and internal vulnerabilities are regularly identified, prioritised and addressed
11.4	External and internal penetration testing is regularly performed and findings corrected
11.5	Network intrusions and unexpected file changes are detected and responded to
11.6	Unauthorised changes on payment pages are detected and responded to
12	Support information security with organisational policies and programmes
12.1	A comprehensive information security policy is known and current
12.2	Acceptable use policies for end-user technologies are defined and implemented
12.3	Risks to the cardholder data environment are formally identified, evaluated and managed
12.4	PCI DSS compliance is managed
12.5	PCI DSS scope is documented and validated
12.6	Security awareness education is an ongoing activity
12.7	Personnel are screened to reduce risks from insider threats
12.8	Risk from third-party service provider (TPSP) relationships is managed
12.9	Third-party service providers support their customers' PCI DSS compliance
12.10	Suspected and confirmed security incidents that could affect the CDE are responded to immediately
A1	Additional requirements for multi-tenant service providers
A1.1	Multi-tenant service providers protect and separate all customer environments and data
A1.2	Multi-tenant service providers facilitate logging and incident response for all customers
A2	Additional requirements for entities using SSL/early TLS for card-present POS POI terminal connections
A2.1	POI terminals using SSL and/or early TLS are not susceptible to known SSL/TLS exploits
A3	Designated Entities Supplemental Validation (DESV)
A3.1	DESV: a PCI DSS compliance programme is implemented
A3.2	DESV: PCI DSS scope is documented and validated
A3.3	DESV: PCI DSS is incorporated into business-as-usual (BAU) activities
A3.4	DESV: logical access to the cardholder data environment is controlled and managed
A3.5	DESV: suspicious events are identified and responded to

Always check the official PCI DSS text for the exact wording.

PCI DSS FAQs

What is PCI DSS v4.0.1?

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard, published by the PCI Security Standards Council in June 2024. It is a limited revision of v4.0 that corrected typographical errors and clarified the intent of some requirements and guidance, without adding or deleting any requirements. It sets 12 principal requirements for protecting cardholder data and sensitive authentication data.

Who needs to comply with PCI DSS?

Any entity that stores, processes or transmits cardholder data, or that can affect the security of the cardholder data environment, needs to comply with PCI DSS. This includes merchants of every size, payment processors, acquirers, issuers and service providers such as hosting, payment gateway and managed security providers. The payment brands require compliance, and acquiring banks enforce it through merchant agreements.

Is PCI DSS a law?

No, PCI DSS is not a law. It is an industry standard owned by the PCI Security Standards Council, which was founded by the major payment card brands. Compliance is a contractual obligation imposed by the card brands and acquiring banks on organisations that accept or handle card payments. Data protection laws such as UK GDPR still apply separately to any personal data involved.

What changed between PCI DSS v4.0 and v4.0.1?

PCI DSS v4.0.1 is a limited revision with no new or deleted requirements. It fixed formatting and typographical errors and clarified the focus and intent of some requirements and guidance. PCI DSS v4.0 was retired on 31 December 2024, leaving v4.0.1 as the only supported version. The future-dated requirements introduced in v4.0 kept their effective date of 31 March 2025.

What happens if you do not comply with PCI DSS?

Non-compliance can lead to consequences set by the card brands and acquiring banks rather than by the PCI Security Standards Council. These can include fines passed on through the acquirer, higher transaction fees, mandatory forensic investigations after a breach, and in serious cases losing the ability to accept card payments. The exact consequences depend on your contracts and the card brands' programmes.

How do you validate PCI DSS compliance?

You validate PCI DSS compliance either by completing a Self-Assessment Questionnaire (SAQ) or by having a Qualified Security Assessor produce a Report on Compliance (ROC), followed by an Attestation of Compliance. Your acquirer or the payment brands decide which route applies, usually based on transaction volume and how you accept payments. Quarterly external vulnerability scans by an Approved Scanning Vendor are also required in many cases.

How does PCI DSS relate to ISO 27001 and SOC 2?

PCI DSS overlaps significantly with ISO 27001 and SOC 2 on access control, logging, vulnerability management, incident response and policy, but it is more prescriptive and focused only on cardholder data. ISO 27001 certification or a SOC 2 report does not replace PCI DSS validation. Mapping one control set across all three lets you reuse evidence and reduce duplicated effort.

Does OneClickComply support PCI DSS v4.0.1?

Yes. OneClickComply supports PCI DSS v4.0.1 today, with its requirements mapped to controls in the platform, automated evidence collection from connected tools, AutoComplete policies and continuous monitoring. Our in-house audit team can guide you through preparing for your SAQ or QSA assessment. OneClickComply does not issue PCI DSS validation itself; that comes from your SAQ or a Qualified Security Assessor.

Related standards

All standards

Get PCI DSS ready, not stressed

Automate controls, gather evidence continuously and stay audit-ready, all on one platform.