PCI-DSS 4.0 Compliance

Overview

PCI DSS 4.0 contains 12 principal requirements organised into six goals that collectively address the protection of payment card data. The requirements cover network security, data protection, vulnerability management, access control, monitoring, and security policy. Each requirement includes detailed sub-requirements with specific technical and operational expectations.

The most significant change in version 4.0 is the introduction of the customised approach alongside the traditional defined approach. The defined approach provides prescriptive technical requirements. The customised approach allows organisations to design their own controls to meet the security objective of each requirement, validated through targeted risk analysis.

Compliance validation varies based on transaction volume and entity type. Level 1 merchants (over six million transactions annually) require an annual on-site assessment by a QSA resulting in a Report on Compliance. Smaller merchants may use Self-Assessment Questionnaires. All entities must conduct quarterly network vulnerability scans by an Approved Scanning Vendor.

PCI DSS 4.0 introduced several new requirements addressing modern threats, including expanded multi-factor authentication for all access to the CDE, automated mechanisms for reviewing audit logs, detection and protection against phishing attacks, and management of payment page scripts. Future-dated requirements became mandatory on 31 March 2025.

Key Areas

• Install and Maintain Network Security Controls - firewalls, network segmentation, and secure configurations
• Apply Secure Configurations to All System Components - hardening defaults and managing configurations
• Protect Stored Account Data - encryption, masking, and retention policies for cardholder data
• Protect Cardholder Data with Strong Cryptography During Transmission - encryption of data in transit
• Protect All Systems and Networks from Malicious Software - anti-malware and threat protection
• Develop and Maintain Secure Systems and Software - secure development lifecycle and patch management
• Restrict Access to System Components and Cardholder Data by Business Need to Know - access controls
• Identify Users and Authenticate Access to System Components - multi-factor authentication and identity management
• Restrict Physical Access to Cardholder Data - physical security controls
• Log and Monitor All Access to System Components and Cardholder Data - logging, monitoring, and alerting

Who It's For

• Merchants of all sizes that accept payment cards in any channel (in-store, online, mobile, mail/telephone order)
• Payment processors, gateways, acquirers, and issuers that handle cardholder data
• Service providers that store, process, or transmit cardholder data on behalf of other organisations
• IT and security teams responsible for protecting payment card environments and maintaining PCI compliance

Core Requirements

Policies and Governance

Organisations must establish, publish, and maintain an information security policy that addresses all PCI DSS requirements. Roles and responsibilities for cardholder data protection must be assigned. A formal security awareness program must educate all personnel on cardholder data protection.

Risk Management

A formal risk assessment process must be performed at least annually and upon significant changes. The risk assessment must identify threats, vulnerabilities, and the resulting risk to cardholder data. Risk assessment results must inform the selection and prioritisation of security controls.

Security Controls

Technical controls must address network security, system configuration, data encryption (at rest and in transit), access control, authentication (including multi-factor), anti-malware, vulnerability management, logging, and monitoring. The customised approach allows alternative controls that demonstrably meet security objectives.

Incident Response

An incident response plan must be established, tested annually, and ready for immediate activation. The plan must address breach detection, containment, communication, card brand notification, forensic investigation, and lessons learned. Specific notification requirements exist for suspected or confirmed cardholder data compromises.

Evidence and Reporting

Compliance validation depends on transaction volume. Level 1 merchants require an annual Report on Compliance (ROC) by a Qualified Security Assessor. Smaller merchants may complete a Self-Assessment Questionnaire (SAQ). Quarterly network vulnerability scans by an Approved Scanning Vendor are required.

Implementation Steps

1. Scope and objectives - Identify all systems, processes, and people that store, process, or transmit cardholder data. Define the cardholder data environment (CDE) and assess whether network segmentation can reduce scope. Determine your compliance validation level based on transaction volume.
2. Gap assessment - Evaluate your current security controls against PCI DSS 4.0 requirements, including new and updated requirements effective March 2025. Identify gaps in network security, encryption, access control, monitoring, and documentation. Determine whether to use the defined or customised approach for each requirement.
3. Control implementation - Implement or upgrade controls to meet all applicable requirements. Deploy network segmentation, configure encryption for data at rest and in transit, implement multi-factor authentication, establish logging and monitoring, and harden system configurations. Address new v4.0 requirements including targeted risk analysis.
4. Evidence and documentation - Collect and organise evidence for each requirement including network diagrams, configuration standards, access control matrices, vulnerability scan results, penetration test reports, and policy documents. Prepare for assessment by a QSA or complete the appropriate SAQ.
5. Review and continuous improvement - Conduct quarterly internal security reviews and annual reassessments. Perform quarterly ASV scans and annual penetration tests. Monitor for changes that could affect scope or control effectiveness. Update policies and procedures as the standard evolves.

Frequently Asked Questions

When does PCI DSS 4.0 become mandatory?

PCI DSS 4.0 became effective on 31 March 2024, when v3.2.1 was retired. However, certain new requirements identified as future-dated have a mandatory compliance date of 31 March 2025. After this date, all v4.0 requirements must be fully in place.

What is the customised approach?

The customised approach allows organisations to meet PCI DSS security objectives through alternative controls and methods rather than the specific technical implementations prescribed in the defined approach. It requires a targeted risk analysis and must be validated by a QSA.

Who needs to comply with PCI DSS?

Any organisation that stores, processes, or transmits payment card data from major card brands must comply. This includes merchants, payment processors, acquirers, issuers, and service providers. Compliance validation requirements vary based on transaction volume.

What are the main changes in version 4.0?

Key changes include the customised approach for meeting requirements, expanded multi-factor authentication requirements, enhanced encryption requirements, targeted risk analysis for certain controls, and updated requirements for detection and response capabilities.

What is a QSA?

A Qualified Security Assessor is a professional certified by the PCI Security Standards Council to perform PCI DSS assessments. QSAs evaluate an organisation's compliance and issue the Report on Compliance. Level 1 merchants and large service providers typically require QSA assessments.

How does scoping work in PCI DSS?

The cardholder data environment includes all systems, processes, and people that store, process, or transmit cardholder data, plus any systems connected to or that could impact the CDE. Network segmentation can reduce scope by isolating the CDE from other parts of the network.

What happens if we fail a PCI DSS assessment?

Organisations that fail an assessment must develop and implement a remediation plan to address identified gaps. Card brands may impose financial penalties, increase oversight, or restrict processing privileges depending on the severity and duration of non-compliance.

Does PCI DSS apply to e-commerce?

Yes. E-commerce environments that handle payment card data must comply with PCI DSS. The scope depends on the payment integration method used. Organisations using redirects or iframes to hosted payment pages may have a significantly reduced scope compared to those that directly handle card data.

Why It Matters

• Payment card fraud costs the global economy billions annually. PCI DSS 4.0 addresses this by establishing mandatory security requirements for every organisation in the payment card ecosystem. Compliance protects both consumers' financial data and organisations from the significant costs of data breaches, including fines, forensic investigations, and loss of card processing privileges.
• Version 4.0 responds to the evolving threat landscape by strengthening requirements around authentication, encryption, and continuous monitoring. The introduction of the customised approach acknowledges that a one-size-fits-all prescriptive standard cannot keep pace with diverse technology environments and emerging threats.
• Non-compliance with PCI DSS carries severe consequences including financial penalties from card brands, increased transaction fees, mandatory forensic audits, and potential loss of the ability to process card payments. For many businesses, loss of card processing capability would be an existential threat.

Common Challenges

• Accurately scoping the cardholder data environment, especially in complex environments with multiple payment channels and third-party integrations
• Implementing the new multi-factor authentication requirements across all access to the cardholder data environment
• Transitioning from the defined approach to the customised approach without introducing gaps in control coverage
• Managing the volume of new and updated requirements introduced in v4.0, many with future-dated mandatory compliance
• Maintaining continuous compliance between annual assessments rather than treating PCI DSS as a point-in-time exercise
• Coordinating PCI DSS compliance across multiple service providers and ensuring third-party compliance
• Implementing continuous monitoring and automated log analysis capabilities required by updated monitoring requirements