What Are the PCI DSS Requirements for March 2025?

There are 12 requirements of the Payment Card Industry Data Security Standard (PCI DSS) version 4.0 that will start being enforced on April 1, 2025. These requirements are designed to enhance your company’s development and implementation of a fortified information security system. The requirements are housed under six encompassing categories, including:

• Build and Maintain a Secure Network and Systems
• Protect Account Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

In relation to email specifically, we’ll be focusing on the 1st and 5th requirements, which DMARC adoption helps satisfy.

• Requirement 1.4.2 and 1.4.3: Network connections between trusted and untrusted networks are controlled
• Requirement 5.4: Anti-phishing mechanisms protect users against phishing attacks

The current PCI DSS iteration (released in June 2024) suggests that DMARC is a best practice (as noted in section 5.4.1 v. 4.0.1) to reach PCI DSS compliance. However, in the 2025 updates, PCI DSS will require that DMARC be properly implemented by all businesses to be fully considered for PCI DSS certification.

Plus, the overseeing PCI Security Standards Council recommends that “anti-phishing controls be applied across an entity’s entire organization” to help combat email phishing and spoofing attacks.

This new DMARC requirement means that every organization, including merchants, must adopt DMARC for all of their sending domains to verify the emails sent by their company (or on their brand’s behalf). PCI DSS requirements apply to the cardholder data environment (CDE), which includes merchants, processors, acquirers, issuers, and other service providers.

The ultimate goal of these email authentication standards is to protect customers from sharing credit card details and other sensitive information with online fraudsters who impersonate legitime companies. Since the payment card industry will require DMARC in 2025, the sooner your business implements DMARC, the sooner it can become PCI DSS certified.

Full List of PCI DSS Requirements

1: Install and Maintain Network Security Controls

This requirement is designed to help merchants protect cardholder data, which is more vulnerable to attack than other data types. Installing a firewall (the first line of defense for a network) adds another layer of protection to sensitive credit card information. Your business should establish firewalls and router standards to help standardize a process for allowing or denying access rules to your network.

Sections:

• 1.1 Processes and mechanisms for installing and maintaining 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 computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

2: Apply Secure Configurations to All System Components

Requirement 2 means organizations should immediately change vendor-supplied passwords/logins to avoid a breach. Default passwords are easily discovered and shared online, which allows cybercriminals to gain access to customer and employee records.

Sections:

• 2.1 Processes and mechanisms for applying secure configurations to all system components 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

Although the best scenario is to never store cardholder data, some situations require it. If so, steps must be taken to protect that information, including:

• Limiting storage time
• Purging data regularly
• Rending authentication data unreadable (encryption)
• Ensuring all encryption tools are documented, recorded, and protected

Sections:

• 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 authorization.
• 3.4 Access to displays of full primary account number (PAN) and ability to copy cardholder data are restricted.
• 3.5 PAN is secured wherever it is stored.
• 3.6 Cryptographic keys used to protect stored data are secured.
• 3.7 Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

This standard requires merchants to encrypt cardholder data when it is transmitted over public networks. It is important for protecting sensitive information from online threats and unauthorized access.

Sections:

• 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
• 4.2 PAN is protected with strong cryptography during transmission.

5: Protect All Systems and Networks from Malicious Software

To comply with this requirement, you must install and maintain anti-virus software on all systems that could be vulnerable to malware, including laptops, tablets, and remote devices. This requirement helps ensure the security of cardholder data environments.

Sections:

• 5.1 Processes and mechanisms for protecting all systems and networks from malicious software (malware) are defined and understood.
• 5.2 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 methods.

6: Develop and Maintain Secure Systems and Software

This requirement details a risk management system for identifying weaknesses, applying security patches, and prioritizing risks. It ensures that security measures are implemented during every step of the software development process, from coding to applying patches to addressing vulnerabilities.

Sections:

• 6.1 Processes and mechanisms for developing and maintaining 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

Requirement 7 restricts who has access to cardholder data. It applies to employees, consultants, contractors, internal and external vendors, and all other nonessential parties. Access needs to be approved, restricted, removed, limited, and reviewed continuously.

Sections:

• 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business 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(s).

8: Identify Users and Authenticate Access to System Components

A unique ID must be assigned to everyone with access to cardholder information. This practice lets users’ activities and logins be monitored and traced. Strong password credentials are also prioritized.

Sections:

• 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.
• 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s 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 MFA systems are configured to prevent misuse.
• 8.6 Use application and system accounts and associated authentication factors is strictly managed.

9: Restrict Physical Access to Cardholder Data

This guideline ensures that sensitive cardholder data is not accessible to unauthorized individuals. Physical theft or tampering is just as detrimental as a sophisticated hacking attack, making Requirement 9 a critical component to card security.

Sections:

• 9.1 Processes and mechanisms for restricting physical access to cardholder data 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 authorized 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 unauthorized substitution.

10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10 includes logging and monitoring systems to keep track of who accesses network resources and any cardholder details. It reinforces security measures and accountability, and also provides data breach specifics if/when they occur.

Sections:

• 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
• 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity and the forensic analysis of events.
• 10.3 Audit logs are protected from destruction and unauthorized modifications.
• 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-synchronization 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

Keeping fraudsters from accessing your collected data is imperative, especially when changes or updates are made to your security systems. External and internal tests must be conducted often to identify any vulnerabilities that cybercriminals can target.

Sections:

• 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
• 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
• 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
• 11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.
• 11.5 Unauthorized changes on payment pages are detected and responded to.

12: Support Information Security with Organizational Policies and Programs

Employee training, risk management instruction, and invoking a strong security policy across your company is necessary. A documented policy must be distributed to and reviewed by the entire staff to reinforce anti-fraud practices.

Sections:

• 12.1 A comprehensive information security policy that governs and provides direction for protection on the entity's information assets 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 to information assets associated with third-party service provider (TPSP) relationships is managed.
• 12.9 TPSPs support their customers’ PCI DSS compliance.
• 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.