PCI DSS 4.0: Requirements Explained

The latest iteration, PCI DSS 4.0, became effective on March 31, 2024. However, organizations were given until March 31, 2025, to implement future-dated requirements. These include stronger authentication protocols, more robust access controls, and security training for personnel.

The clock is ticking for organizations to meet these latest requirements. Non-compliance can result in hefty fines and increase the risk of data breaches.

Read on to learn about the PCI DSS 4.0.1 updates and how they differ from the previous version. We’ll also break down a list of future-dated requirements that organizations must meet to achieve PCI compliance.

What is PCI DSS v4.0?

PCI DSS 4.0 is the latest version of the payment card industry standard, introducing significant changes to the previous version (v3.2.1). It was released on March 31, 2022. However, organizations could use v3.2.1 for two years until March 31, 2024, while they reviewed and implemented the new changes in v4.0.

The updated version places more emphasis on the following:

• Greater flexibility and methods for organizations to demonstrate compliance
• Continuous monitoring and testing instead of “point-in-time” checks
• Improved validation and reporting procedures to support transparency

It also introduces new technical and operational requirements that enhance cardholder data security (more on that shortly).

>> Watch: How to Fast-Track PCI 4.0 Compliance

Who does PCI DSS 4.0 apply to?

PCI DSS 4.0 applies to any organization that handles payment card data, regardless of size or number of transactions. This includes:

• Merchants
• Financial institutions
• Service providers
• Brick-and-mortars
• Online retailers

Organizations must transition to v4.0 by March 31, 2025, to maintain their certification and avoid fines. Penalties for non-compliance range from $5,000 to $100,000 per month.

>> Read: How European Buy-Now, Pay-Later Simplifies PCI Protection & GDPR Compliance

March 2025 deadline for PCI DSS 4.0 future-dated requirements  

PCI DSS v3.2.1 was officially retired on March 31, 2024, with a one-year grace period to meet future-dated requirements. These were labeled as best practices but are now mandatory for companies processing cardholder data after this date.

Organizations have until March 31, 2025, to meet future-dated requirements. 

Here are the key compliance requirements:

Roles and responsibilities

PCI DSS 4.0 requires organizations to define and document roles and responsibilities for all 12 requirements. For example, the first PCI DSS requirement is to “Install and Maintain Network Security Controls.” 

For this requirement, organizations must designate someone to install firewalls, manage security configurations, and monitor network traffic. They should implement systems to keep this individual accountable for these tasks.

Sensitive Authentication Data (SAD)

PCI DSS 4.0 has new requirements to safeguard SAD, like card verification codes and expiration dates. Under requirements 3.2.1 and 3.3.2, organizations must:

• Have policies for handling, storing, and disposing of SAD before authorizing payments.
• If SAD must be stored electronically (temporarily) before authorization, it must be encrypted and protected. Storage after authorization is strictly prohibited.

Malware

Under requirement 5.3.2.1, organizations that perform periodic malware scans to meet requirement 5.3.2 (“The anti-malware solution”) must define how often they’ll scan their systems for viruses based on their targeted risk analysis.

Requirement 5.3.3 also mandates that organizations install anti-malware software on removable electronic devices, such as USB and external flash drives.

Phishing attacks

Phishing attacks account for 73% of data breaches involving social engineering.

Requirement 5.4.1 requires organizations to have mechanisms to protect personnel against phishing attacks. These include using anti-phishing tools like secure email gateways to block emails containing malicious links.

Custom software

Requirement 6.3.2 requires organizations to maintain an inventory of any custom software. This type of software is typically purpose-built for an organization, either in-house or by a third party.

Automated scans

PCI DSS 4.0 introduces the following requirements to secure payment pages and their scripts:

• 6.4.2: Requires a Web Application Firewall (WAF) or equivalent to detect and block web-based attacks.
• 6.4.3: Organizations must implement methods to verify and authorize scripts on payment pages to ensure their integrity.

Access reviews

The principle of least privilege grants users the minimum privileges they need based on their roles.

PCI DSS 4.0 requires organizations to:

• Check user accounts and access privileges (7.2.4)
• Implement role-based restrictions to applications and system accounts (7.2.5)

According to requirement 7.2.5.1, organizations must also review all access privileges to ensure no unnecessary or excessive permissions are granted. 

Multi-factor authentication (MFA)

Requirement 8.4.2 mandates MFA for all access into the CDE, not just administrative access. It applies to all system components, including cloud environments, servers, and endpoints.

Passwords

Another new change in PCI DSS 4.0 is requirement 8.3.6, which mandates a minimum password length of at least 12 characters (up from seven characters). The only exception is for legacy systems that only support eight characters.

Requirement 8.3.10.1 applies to service providers. If passwords are the only authentication method for customer user access, passwords must be changed every 90 days.

Requirement 8.6.3 protects passwords against misuse. Organizations must change passwords they suspect are compromised or if there’s evidence of unauthorized access to any system.

Audit log reviews

Requirement 10 mandates the tracking and monitoring of all access network resources and cardholder data, ensuring events are logged and auditable. 

Requirement 10.4.11 requires automated mechanisms to identify and alert suspicious activity in audit logs. Organizations can use Security Information and Event Management (SIEM) solutions like ManageEngine to comply (this Reddit thread offers some good advice).

Security controls

Requirement 10.7.2 requires organizations to detect and promptly address issues in security control systems, such as:

• Intrusion Detection System (IDS)
• Change-detection mechanisms
• Anti-malware solutions
• Access controls
• Audit logging mechanisms

Authenticated scanning

Authenticated scanning, also known as credentialed scanning, is a type of vulnerability scan that tests the security of systems, databases, and applications.

Under requirement 11.3.1.2, organizations must perform internal vulnerability scans via authenticated scanning to identify potential vulnerabilities. This applies to both internal and external scans, depending on the CDE architecture.

Hardware and software reviews

Requirement 12.3.4 requires organizations to conduct annual reviews of the hardware and software technologies used in their environment to ensure they remain supported by vendors. 

PCI DSS scope

A new PCI DSS 4.0 requirement (12.5.2) mandates organizations to document and confirm their PCI DSS scope once every 12 months or following significant changes. Service providers must document and confirm PCI DSS scope every six months (12.5.2.1).

Security awareness training

Requirement 12.6.3.1 requires organizations to provide training that educates employees on common threats and vulnerabilities that could impact the security of a CDE. This includes raising awareness of common attacks like phishing.

PCI 4.0 change objectives

The Payment Security Council made major changes to the PCI DSS with the following objectives in mind.

Meet changing security needs of the payment industry

Online payment systems are constantly under attack. 

A single breach can impact cardholder data security and cause serious harm. Warner Music Group fell victim to a web skimming attack in which hackers stole data billing addresses and credit card details by injecting malicious code into its e-commerce websites.

As a result of evolving cyber threats like the one above, PCI DSS 4.0 now requires methods to verify and authorize payment page scripts (6.4.3).

Promote security as a continuous process

A key change from PCI DSS 3.2.1 is the assessment frequency. PCI DSS 4.0 emphasizes more continuous testing and monitoring of payment systems to ensure ongoing security effectiveness. 

Add flexibility and support for additional methodologies

PCI DSS has offered organizations a “defined approach” to demonstrate compliance. It’s been the standard testing methodology for previous versions with specific procedures for assessors to confirm controls.

One of the most significant changes from PCI DSS 3.2.1 to 4.0 is the addition of a “customized approach.” It gives organizations greater flexibility in meeting security objectives and proving compliance. However, companies that take this approach will need to:

• Generate a control matrix describing how customized controls meet specific requirements
• Perform a risk analysis and provide all documentation
• Document testing to confirm the control meets requirements
• Describe how the control is monitored and maintained over time

Enhance validation methods and procedures

PCI DSS 4.0 now offers increased alignment between the information reported in a Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance (AOC). This makes compliance reporting more transparent and efficient, making it easier for organizations to demonstrate their security status.

The “Prioritized Approach” to achieve PCI DSS compliance

The PCI Security Standards Council offers a Prioritized Approach to help organizations pursue PCI DSS compliance and prioritize their efforts to address the highest risk factors.

It maps PCI DSS 4.0 requirements into the following six key milestones.

Milestone 1: Don’t store sensitive authentication data and limit data retention

The first milestone focuses on minimizing the exposure of authentication data. Attackers can’t exploit sensitive data if there’s nothing to steal.

Implementation steps:

• Implement automated purging systems to permanently delete CVV
• Use transient field tokens to temporarily hold CVVs to retry authorizations
• Establish clear data retention and disposal policies

Milestone 2: Protect systems and networks

The second milestone focuses on protecting company networks against external threats. 

Implementation steps:

• Implement firewalls and intrusion detection systems (IDS)
• Develop incident response procedures in the event of a breach
• Keep security patches up to date

Milestone 3: Secure payment applications 

The third milestone ensures payment applications are secure and free from vulnerabilities.

Implementation steps:

• Conduct regular security assessments of payment applications
• Monitor for any unauthorized modifications to scripts on payment pages
• Test for common vulnerabilities like SQL injections

Milestone 4: Monitor and control access 

The fourth milestone involves implementing access controls to restrict access to cardholder data environments (CDE) to prevent unauthorized access.

Implementation steps: 

• Implement technical solutions like fine-grained access control
• Deploy multi-factor authentication (MFA)
• Maintain detailed access logs

Milestone 5: Protect stored cardholder data

The fifth milestone focuses on securing stored payment data and preventing unauthorized access.

Implementation steps:

• Implement security measures like encryption
• Use network tokens to keep cardholder data safe
• Implement robust access controls to CDEs

Milestone 6: Finalize compliance efforts

Finally, the last milestone is about completing the remaining compliance activities.

Implementation steps:

• Complete final security assessments
• Address any remaining gaps or vulnerabilities
• Prepare compliance documentation

Ease PCI compliance

Storing cardholder data in your systems exposes it to potential breaches and increases the risk of it replicating across systems – a problem known as sensitive data sprawl. It dramatically increases the scope of compliance efforts and adds more complexity to data security.

Skyflow’s Data Privacy Vault eases PCI compliance by isolating, protecting, and governing PCI data in a secure vault that tokenizes card data for safe usage.

Here’s an example of how Skyflow replaces sensitive data with tokens:

‍

By de-scoping cardholder data from their infrastructure entirely, organizations can securely process payments and reduce their PCI compliance scope by 90%.

Skyflow offers the following capabilities:

• Simplified audit logging: Features like real-time monitoring and audit logging allow security teams to conduct audits and detect any misuse of sensitive data.
• Advanced data governance: Fine-grained access controls enable organizations to govern access to PCI data and implement the least privilege principle.
• Data residency solution: Meet local data residency laws by storing customer data in region-specific vaults – without building new infrastructure in each region.

Read how Apaya, a payment automation platform, uses Skyflow to protect customer data and achieve PCI compliance.

Reduce your PCI compliance scope

PCI DSS 4.0 introduces major changes designed to secure cardholder data and address emerging threats. These include flexible ways to demonstrate compliance, enhanced validation methods, and additional requirements around roles and responsibilities. 

Learn how Skyflow eases PCI compliance and reduces compliance scope with features such as encryption, tokenization, and fine-grained data governance. Keeping cardholder data out of your systems simplifies PCI compliance and avoids payment processor lock-in.