History and Status of the PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) was created in response to the rapid growth of credit card transactions in the 1990s causing thousands of small companies to start storing credit card data and processing consumer transactions on unprotected networks.  Since many of these small businesses didn’t know how to properly secure these credit card transactions, it also led to a rapid increase in data theft and a growing concern from banks and credit card companies about ways to protect their brand and consumer accounts. In an effort to resolve the growing concern around payment card fraud and cybercrime in general, industry leaders such as Visa, MasterCard, and American Express got together and created a global security standard to protect online card payments.

The PCI DSS standard was established to set basic guidelines and requirements around how businesses must create a safer cardholder data environment, using basic requirements to drive minimum requirements around security that would lead to more secure business systems. As the standard evolved and procedures more refined, PCI DSS became an internationally accepted standard for all merchants and service providers.

PCI DSS History

PCI DSS was introduced in December 2004, after Visa and other brands had introduced their own standards.  These brand-specific standards weren’t well received by merchants and service providers, since these were small companies that didn’t need the confusion of multiple standards.

Companies subject to PCI DSS standards must be PCI-compliant. The requirements around how they prove and report their compliance is based on their annual number of payment transactions and how those transactions are processed. A bank or credit card brand may manually place an organization into a reporting level at its discretion. Merchant levels are:

• Level 1 – Over six million transactions annually
• Level 2 – Between one and six million transactions
• Level 3 – Between 20,000 and one million transactions, and all e-commerce merchants
• Level 4 – Less than 20,000 transactions

Compliance validation is required only for level 1 to 3 merchants and may be optional for Level 4, depending on the card brand and acquirer.

To ensure businesses comply with PCI-DSS guidelines, there are penalties for non-compliance. These penalties are not assessed by the PCI-SSC, but rather by each of the card brands that a specific merchant may use to process credit card transactions.    The fee/penalty structure is not published publicly, but fees are higher for businesses that are out of compliance with PCI requirements when a breach occurs. However, penalties and fees can be assessed against a merchant organization even if the merchant was compliant at the time a breach occurs.  Below is a sampling of penalties organizations may face:

• Fines ranging from $5,000 to $100,000 per month, rising over time until the merchant is in full compliance
• Sanctions that can rise to the level of termination of the ability to accept payment cards
• Liability for losses that customers may suffer in the event of a breach

The major payment brands established a payment security standard to regulate the way merchants and service providers processed and stored credit card transactions. The Payment Card Industry Security Standards Council (PCI SSC) was created, and this industry body published the Payment Card Industry Data Security Standard (PCI DSS) to help guide industry best practice.

With the introduction of PCI DSS v1.0 in December 2004, all merchants and service providers who process cardholder data were expected to comply with the new standard. The first version wasn’t perfect, and there have been several updates to the standard, with the newest version introduced in March 2022.

Standard Evolution

The Security Standards Council has been open about soliciting changes and ideas so they have been able to constantly change the standard to meet a challenging and evolving threat landscape. The different versions of the PCI DSS can be seen in the follow timeline:

 

Date	PCI DSS Standard
December 2004	PCI DSS v1.0 introduced.
September 2006	PCI DSS v1.1 updated to address web application security issues. This required implementation of firewalls for web-facing applications and custom application code to be professionally reviewed.
October 2008	PCI DSS v1.2 includes wireless network issues. This required the implementation of new antivirus software and wireless network security.
August 2009	PCI DSS v1.2.1 provided clarification and improvements in multiple areas. This introduced more consistency in the format and language of the Standard, and relevant supporting documentation.
October 2010	PCI DSS v2.0 was introduced to provide clarity on the PCI DSS Requirements, and flexibility that helps merchants meet the requirements and achieve compliance. The changes and updates introduced in this version included user access restrictions, data encryption, and managing encryption keys.
November 2013	PCI DSS v3.0 was introduced to address the knowledge gap and awareness pertaining to security and emerging cloud-based technologies. For this, the standard provided information and guidelines about cloud-based technologies and penetration testing.
April 2015	PCI DSS v3.1 was introduced as a short-term update intended to last until its retirement on October 31, 2016, to allow merchants time to adopt and achieve compliance for changes in the April 2016 PCI DSS v3.2.
April 2016	PCI DSS v3.2 was introduced in response to the growing threats to payment information. This version introduced new techniques and supporting guidelines that helped merchants prevent, detect, and respond to cyber threats. This required the implementation of Multi-Factor Authentication (MFA), and also accounts for Designated Entities Supplemental Validation (DESV), Transport Layer Security (TLS), and the performing of internal and external scans.
May 2018	PCI DSS v3.2.1 was introduced to provide clarification and revision in some of the requirements in the original PCI DSS v1.0.
March 2022	PCI DSS v4.0 includes expanded MFA requirements, clearly defined roles and responsibilities for each requirement, and a new set of requirements that address the ongoing threats.
March 2024	PCI DSS v3.2.1 will be retired and replaced with PCI DSS v4.0.

The Latest Changes in v4.0

PCI DSS v4.0 is the latest version released in March 2022, and is officially set to be fully effective by 2025. The Security Standards Council allows time for organizations to embrace the latest updates and changes by offering a transition period after a new standard becomes effective. PCI DSS v3.2.1 will remain active until March 31, 2024, giving organizations one year to implement the new standard.

This latest version is designed to refresh the baseline to meet the technical and operational requirements for the security of sensitive account data. This new version offers clarity, provides guidance, and also facilitates flexibility by allowing the implementation of customized security solutions.

The compliance levels remain unchanged, which continue to include 4 levels for merchants, and 2 levels for service providers. These are determined by the annual number of transactions a merchant or service provider processes over a calendar year. PCI DSS v4.0 involves 65 requirements. Requirements for all entities number 54, and 11 requirements only apply to service providers.

Key Changes in v4.0

• Customized Approach – The latest PCI DSS v4.0 allows for a customized approach that offers organizations the flexibility to define their control, as opposed to a specific, prescribed control as noted by the DSS. However, with a customized approach comes additional responsibilities that include building and testing controls, monitoring the effectiveness of the control, completing the associated control matrix, and completing a Targeted Risk Analysis (TRA) for each Customized Control. Also, it should be noted that “several requirements do not have a stated Customized Approach Objective; the customized approach is not an option for these requirements.”
• Formalized Annual Scoping – Conducting annual scoping was something organizations were expected to undertake in the previous version. PCI DSS v4.0 formalized this requirement, subjecting it to validation by an assessor.
• Assigning of Responsibilities – Organizations are expected to define and appropriately communicate roles and responsibilities, and make personnel accountable for their respective tasks. The roles and responsibilities are also required to be formally assigned and documented. This requirement is effective immediately for all v4.0 assessments.
• Encryption of SAD – PCI DSS v4.0 requires the organization to “Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.” This requirement is a best practice until March 31, 2025.
• PAN Encryption – Requirement 3.5.1.1 in DSS v4.0 specifies that the hashes used to render PAN unreadable are to be keyed cryptographic hashes for the entire PAN number. This is done in association with the key-management processes and procedures, which should be in accordance with Requirements 3.6 and 3.7. This requirement is a best practice until March 31, 2025. Further, according to Requirement 3.5.1.2, if your organization is using disk encryption for non-removable media, then the PAN must also be rendered unreadable using a different mechanism that meets Requirement 3.5.1. It is important to note that this requirement is a best practice until March 31, 2025.
• Strong Authentication Requirement – The new version includes strong authentication requirements, including the need to review all user accounts and related access privileges, as per Requirement 7.2.5. This requirement is a best practice until 31 March 2025. Further, Requirement 8.4.2 specifies the implementation of Multi-Factor Authentication (MFA) for all access into the CDE. This requirement is a best practice until 31 March 2025.
• Requirement 8.3.6 indicates the implementation of strong passwords with a minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). The passwords must contain both numeric and alphabetic characters. “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.”

For more details about the updates and changes, the SSC has published its official document, Summary of Changes from PCI DSS Version 3.2.1 to 4.0.

Transition to PCI DSS v4.0

The 12 core PCI DSS requirements are not expected to fundamentally change with PCI DSS v4.0, as these are still the critical foundation for securing payment card data.  PCI SSC is also looking at ways to introduce greater flexibility to support organizations using a broad range of controls and methods to meet security objectives.

The PCI Council has offered a transition period for organizations to embrace changes and updates from PCI DSS v3.2.1 to PCI DSS v4.0. For this, PCI DSS v3.2.1 will remain active till March 31, 2024. The transition period is offered to allow organizations to get familiar with the changes and updates to accordingly implement the necessary requirements and update their reporting standards, templates, and plans. After the transition period, PCI DSS v3.2.1 will be retired, and v4.0 will be the only active version of the standard.

Achieving Compliance

Achieving and maintaining PCI DSS v4.0 Compliance is a continuous process and requires constant monitoring. While the implementation of certain latest requirements and updates are future-dated and stated as a best practice until March 2025, it is still recommended that organizations kick-start their compliance initiative in order to meet the future-dated requirements of the new version. It is important for organizations to first understand the updates and latest requirements introduced in PCI DSS v4.0.  The next step would be to undergo a readiness assessment and accordingly evaluate and plan a budget for appropriate resource allocation. Performing a readiness assessment will provide a clear roadmap for your organization towards developing activities and implementing measures to satisfy the latest requirements. This will ease the compliance process and help your organization determine and implement the security controls required for the new Standard.