This article was updated October 30, 2023.

With the release of PCI data security standard (DSS) 4.0, merchants should be aware of an updated compliance approach to avoid consequences of noncompliance, potential costs, and to prevent possible security breaches and user payment card data compromises.

This framework is designed to safeguard the personal payment data of customers when it’s stored, processed, and transmitted by the companies with whom they do business.

Below, learn more about:

• Who’s affected
• PCI DSS background
• Consequences of PCI DSS noncompliance
• When is the PCI DSS 4.0 release date?
• Updated PCI DSS compliance approaches
• Clarified existing and added requirements
• Next steps

Who’s Affected?

Merchants and service providers who accept payment cards from Visa, Mastercard, Discover, American Express, and Japan Credit Bureau (JCB) must comply with the PCI DSS.

Some organizations that can affect the security of payment card data, such as merchants who take payments through iFrame or direct posts, might be required to adhere to the PCI DSS.

Following is an overview of PCI DSS, the updated compliance approach, and new requirements.

PCI DSS Background

In 1999, Visa introduced Cardholder Information Security Program (CISP) and implemented it in 2001 to protect cardholder data.

Mastercard, American Express, and Discover quickly followed, founding their own unique security programs. Merchants that accepted multiple credit card brands faced multiple security compliance programs.

The history of PCI DSS begins in 2004. As payment fraud began to rise, credit card industry leaders convened to develop a common set of security standards. The PCI’s founding members—American Express, Discover Financial Services, JCB International, Mastercard, and Visa—introduced PCI DSS 1.0 in December 2004. All merchants accepting credit cards as well as other payment processing organizations were required to comply with the new standard.

Consequences of PCI DSS Noncompliance

A security breach and subsequent compromise of payment card data has far-reaching consequences for affected organizations, including:

• Regulatory notification requirements
• Loss of reputation
• Loss of customers
• Potential financial liabilities, such as regulatory and other fees, and fines
• Litigation

Members proven to be noncompliant or whose merchants or agents are noncompliant may be assessed:

• Forensic investigation costs
• Issuer or acquirer losses, such as unlimited liability for fraudulent transactions or potential additional issuer compensation
• Dispute resolution costs

Cost for Noncompliance After a Breach

• Loss of the ability to process cards in the future
• Mandated on-site audits with Qualified Security Assessors (QSA)
• Cost for re-issuing cards
• Unlimited liability for all fraudulent charges
• Possible class-action lawsuits
• Possible federal investigation

Members could face additional fines for:

• Egregious violation
• Failure to report
• Storing full track data

Other Key Dates and Milestones

The following dates are based on current projections and are subject to change.

PCI DSS 3.2.1 will remain active for two years after 4.0 is published. The transition period until March 31, 2024, gives organizations time to become familiar with 4.0, update reporting templates and forms, and meet updated requirements.

In addition to the transition period when 3.2.1 and 4.0 are both active, organizations have until March 31, 2025, to phase in new requirements. Organizations that implement controls to meet the new requirements before the effective date are encouraged to have them assessed early.

After the effective date, the new requirements will be part of a PCI DSS assessment.

Updated PCI DSS Compliance Approaches

Historically, organizations had to proscriptively adhere to the PCI DSS requirements, as defined by the PCI Council. As part of PCI DSS 4.0, the PCI council saw this restrictiveness doesn’t work for every organization and introduced a customized approach. The new approach will allow organizations to review a customized approach objective aligned with each requirement to determine if that objective is already met in a way not strictly following the defined requirement.

For example, historically the DSS required organizations to perform periodic anti-malware scans, or implement a compensating control if there was a legitimate business or technical constraint to meet the intent of the periodic anti-malware scan requirement. However, with the customized approach, an organization could potentially rely on application allowlisting of approved software as opposed to periodic malware scans to contribute to the customized objective of stopping malware. This customized approach supports innovation in security practices, giving mature entities flexibility in showing they meet PCI requirements. An organization can implement either the defined or customized approach objective for each PCI DSS requirement.

Organizations must go through the following steps with each customized control.

Entity Criteria

The entity implementing a customized approach must satisfy the following criteria for each custom control:

• Complete a controls matrix.
• Perform and document a targeted risk analysis.
• Perform testing to prove effectiveness, and document testing performed, methods used, what was tested, when testing was performed, and results of testing in the controls matrix.
• Monitor and maintain evidence about effectiveness.
• Provide completed controls matrices, targeted risk analysis, testing evidence, and evidence of effectiveness to its assessor.

Assessor Criteria

The assessor performing an assessment of customized controls must satisfy the following criteria:

• Review the entity’s controls matrices, targeted risk analysis, and evidence of control effectiveness to fully understand the customized control and verify the entity meets all customized approach documentation and evidence requirements.
• Derive and document the appropriate testing procedures needed to conduct thorough testing of each customized control.
• Test each customized control to determine whether the entity’s implementation meets the requirement’s customized approach objective and results in an in-place finding for the requirement.
• At all times, QSAs maintain independence requirements defined in the QSA qualification requirements. This means if an individual QSA is involved in designing or implementing a customized control, that individual QSA doesn’t also derive testing procedures for, assess, or assist with the assessment of that customized control.

Additionally, the Items Noted for Improvement (INFI) worksheet is a new concept introduced in version 4.0. This worksheet is intended for usage between the assessor and the assessed entity, such that items found not in place and remediated as part of an assessment are to be documented and acknowledged by the assessor and assessed entity.

Clarified Existing and Added Requirements

Each section’s requirements, many of which are new or clarified, are important to follow.

Install and Maintain Network Security Controls

• Network changes must have documented security impact, approval, testing, and rollback procedures.
• Configuration of network security controls such as firewall rules, security groups, and more should be secured against unauthorized changes.
• Host-based firewalls or other end-point protection solutions must be installed on computing devices that connect to both untrusted networks and the cardholder data environment (CDE). This requirement applies to system components indirectly connected to the CDE.

Protect Stored Account Data (SAD)

• SAD stored by issues is limited to legitimate business use and must be encrypted.
• SAD stored prior to authorization must be included in data retention and disposal policies, procedures, and processes.
• SAD stored prior to authorization must be encrypted.
• Technical controls must be implemented to prevent the copy or relocation of primary account number (PAN), or credit or debit card number when using remote access technologies.
• Keyed cryptographic hashes must be used when hashing is used to render PAN unreadable.
• Disk and partition level encryption is only acceptable to render PAN unreadable for removable media. Specific implementation considerations will need to be made for cloud native transparent encryption.

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

• Only trusted keys and certificates should be accepted, and certificates used to transmit PAN over open, public networks are valid and not expired or revoked.
• An inventory of trusted keys and certificates used to transmit PAN over open, public networks must be maintained.

Protect All Systems and Networks from Malicious Software

• Perform periodic anti-malware scans and active or real time scans, or perform continuous behavioral analysis.
• Define the frequency for analyzing system components not at risk for malware.
• Define the frequency of periodic malware scans.
• Implement a malware solution for removable electronic media.
• Detect and protect against phishing attacks using technical mechanisms.

Develop and Maintain Secure Systems and Software

• Implement a vulnerability management program to identify and rank vulnerabilities. Include vulnerabilities for bespoke and custom software.
• Maintain an inventory of bespoke and custom software. This might require automated tools.
• Deploy a web application firewall (WAF) for public-facing web applications.
• Controls are implemented for payment page scripts loaded in the consumers browser such that each script is authorized, integrity is validated, and an inventory of scripts and written justification is maintained. This might involve additional tooling.

Restrict Access to System Components and Cardholder Data

• Define an access control model.
• Review all user accounts and related access privileges at least once every six months and address inappropriate access. Obtain management acknowledgement of the review.
• Assign and manage all application and system accounts and related access privileges.
• Periodically review all access by application and system accounts and related access privileges and address inappropriate access. Obtain management acknowledgement of the review.

Identify Users and Authenticate Access to System Components

• Shared authentication credentials allowed on exception basis.
• Account lockout attempts to be set at 10 attempts.
• Password length of 12 characters. If not possible, minimum length of eight characters.
• Passwords or passphrases must be changed every 90 days or the security posture of accounts is dynamically analyzed and real-time access to resources is automatically determined.
• For service providers, if passwords or passphrases are the only authentication factor for customer user access, then they’re either changed at least every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts.
• Implement multifactor authentication (MFA) for all access into the CDE—including physical console access—in addition to remote network-level and administrative MFA.
• MFA system isn’t susceptible to replay attacks and can’t be bypassed.
• Interactive service account usage isn’t allowed, unless for exceptional circumstances that are documented, and usage can be attributed to a user.
• Passwords or passphrases for any application and system accounts that can be used for interactive login aren’t hard coded in scripts, configuration or property files, or bespoke and custom source code.
• Passwords or passphrases for any application and system accounts are changed periodically and have sufficient complexity for how often they are changed.

Log and Monitor All Access to System Components and Cardholder Data

• Automated mechanisms are used to perform audit log reviews.
• For all entities including merchants, failures of critical security control systems are detected, alerted, and addressed promptly.
• For all entities including merchants, failures of any critical security controls systems are documented and responded to promptly restore security functions and address the root failure.

Test Security of Systems and Networks Regularly

• The assessed entity creates a penetration testing methodology that requires retention of results for 12 months. Includes the approach to address results.
• Clarified that penetration test findings are corrected in accordance with the entity’s assessment of the risk posed by the security issue.
• All vulnerabilities, including those not ranked as high-risk or critical, are addressed based on the risk defined in the entity’s targeted risk analysis, with rescans conducted as needed.
• Internal vulnerability scans are performed via authenticated scanning using appropriately managed credentials.
• A change- and tamper-detection mechanism is deployed to periodically detect and alert personnel to unauthorized modification to the HTTP headers and the contents of payment pages as received by the consumer browser. This might involve additional tooling.

Tests for Service Providers

• Multitenant service providers support their customers for external penetration testing.
• Intrusion detection or intrusion prevention techniques detect, alert, or prevent, and address covert malware communication channels.

Support Information Security with Organizational Policies and Programs

• A program is implemented to monitor third-party service provider (TPSP) PCI DSS compliance status at least once every 12 months.
• An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident.
• Perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it’s performed.
• For entities using a customized approach, perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach.
• Document and review cryptographic cipher suites and protocols in use at least once every 12 months.
• Review hardware and software technologies in use at least once every 12 months.
• Document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment.
• Incident response procedures to be in place and initiated upon detection of stored PAN anywhere it’s not expected.

Policies and Programs for Service Providers

• Document and confirm PCI DSS scope at least every six months or when there’s a significant change to the in-scope environment.
• Document a review of the impact to PCI DSS scope and applicability of controls when there’s a significant change to organizational structure.
• Support customer requests for information to meet Requirements 12.8.4 and 12.8.5.

When an entity has an agreement with a TPSP for meeting PCI DSS requirements, they must work together. If the TPSP doesn’t meet PCI DSS requirements, they aren’t met for the entity, either.

Next Steps

• Update your understanding and inventory of your CDE.
• Update your risk assessment and prioritize risks.
• Evaluate whether the defined approach or customized approach is appropriate.
• Work with stakeholders and QSA as early as possible.
• Perform a gap analysis using PCI 4.0.
• Start remediation now.
• Continue to monitor progress and changes in 4.0 and promote security as an ongoing process.

We’re Here to Help

For guidance on PCI DSS 4.0 compliance requirements, contact your Moss Adams professional.

Additional Resources

• PCI DSS Audits Services
• IT Compliance Services