Any business involved with the collection, storage, transmission, and use of credit cardholder information must follow the Payment Card Industry (PCI) Data Security Standard (DSS) developed by the PCI Security Standards Council to safeguard cardholder information to prevent theft, fraud, and misuse.
Periodically, the PCI SSC issues revisions and updates to these standards to further clarify and increase payment security measures that merchants, credit card issuers, payment processors, and other organizations institute in their operations. The PCI SSC continually works to ensure a safe environment for consumers sharing payment data in the digital age before, during, and after purchases.
What Is the PCI DSS and Why Is It Important?
Major credit card companies such as MasterCard, Visa, Discovery, American Express, and JCB International created the Payment Card Industry Security Standards Council (PCI SSC) to help companies globally with their security systems when transmitting, receiving, using, and storing cardholder information. To prevent security breaches and fraud, the PCI SSC has maintained and promoted the Payment Card Industry Data Security Standards (PCI-DSS) as a way for businesses and merchants to improve their payment account security protocols and network systems.
Given the ever-increasing number of data breaches each year around the world, it probably comes as no surprise that data security is a major concern for online merchants who regularly accept and process credit cards. Each time an online retailer wins the loyalty of a new customer, they understand that the customer has taken a leap of faith in providing their payment information.
The PCI DSS serves to assist online sellers in protecting their vital cardholder data that contains personally Identifiable information (PII). PCI SSC’s ongoing efforts have become an invaluable resource for retailers who care about their customers.
12 PCI-DSS standards
The PCI-DSS standards are based on 12 requirements that deal with network security and internal controls.
- Installing/maintaining a firewall configuration for networks and systems
- Avoid using vendor-supplied defaults for passwords and other security procedures
- Protecting cardholder data during storage
- Using encryptions during cardholder data transmissions in open and public networks
- Using and updating anti-virus software
- Developing and maintaining secure network systems and applications
- Restricting user access to cardholder data
- Creating a unique ID for users who need to access cardholder data
- Restricting any physical access to cardholder information
- Tracking and monitoring all access to network systems and data
- Testing security processes and systems
- Maintaining information security policies
Each requirement is further broken down into multiple standards that helps to provide comprehensive details to improve your security systems and methods. By following the standards, you can mitigate risks to your security systems and further protect cardholder data.
Evolution of PCI-DSS Over the Years
Leading up the formation of PCI, the payment card giants took note of the rapidly rising rates of industry-wide fraud between 1988 and 1998. Damages for Visa and MasterCard totaled $750 million lost due to credit card fraud in those years. It was clear that, without verifiable security, credit card companies would continue to face major losses.
Defense against mounting fraud losses—both individually and collectively—would require a unified front, a breadth of understanding of rapidly increasing threats, and a strategy for mitigation. They worked together to establish a set of security standards that would become known as PCI DSS.
In 2001, Visa was the first of the payment card companies to implement security standards for businesses to accept payments online. Other major card companies followed suit shortly thereafter with their own security programs. However, with multiple security programs in place, merchants had a greater burden of learning, implementing and maintaining compliance to accept more than one type of credit card.
At this point, the group went back to the drawing board to develop a more collaborative and cohesive approach to card payment security. This gave birth to the PCI DSS, which was introduced in 2004.
In 2006, the PCI SSC was formed to serve as a global forum for the payment card industry to come together to continually monitor industry risks and respond with regular updates to the PCI DSS. PCI SSC focuses on developing, enhancing, disseminating, and assisting with understanding security standards to provide effective payment account security.
The first version of the PCI DSS, which was simply called PCI DSS version 1.0, was released December 15, 2004 and featured a basic, yet still comprehensive, set of security standards for merchants to follow. Any online retailers and other types of organizations that received and processed credit card payments were required to comply with the new standard.
In 2006, the same year that PCI SSC was independent global monitoring collective was officially formed, the group already had updates to the standard and released verion 1.1, calling for merchants to review all online applications and install firewalls to their systems for an added layer of security. This version also provided additional clarification and addressed minor revisions.
PCI DSS version 1.2 was released in October 2008 to enhance clarity and address newly evolving risks and threats.
In August 2009, PCI DSS 1.2.1 was released to share minor creations and to create clarity and consistency to the standards and all supporting documents.
In 2010, the PCI SSC group came across some substantial changes that would help merchants commit to PCI DSS compliance more readily. The PCI SSC reviewed data that the Ponemon Institute polled of 155 Qualified Security Assessors (QSA) to help them shape this update. Some of the official changes in this version involved the following:
- Restricting access to data on a need-to-know basis.
- Encrypting the data.
- Managing and controlling the encryption keys.
The PCI Council felt it was important to address the issue of the current lack of education, awareness and intention of the PCI DSS in this version, which was released in November 2013. The council also focused on the evolution of emerging mobile and cloud-based technologies and how they would relate to the PCI DSS. Additionally, penetration testing and threat modeling were formally introduced into the mix.
This short-term update, released April 2015, was only 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 3.2 release.
The PCI DSS version 3.2 was released in 2016 and went into full effect in 2018. It was developed by the SSC to respond to the growing threats to payment information. Similar to preceding updates, the council introduced new ways to help prevent, detect, and respond to cyberattacks that can lead to costly breaches and damage consumer trust. The refinements in PCI DSS v3.2 are also intended to help provide clarity and guidance to help companies maintain the council’s standards in everyday business practices.
- Multi-Factor Authentication – The accessing of cardholder information only by authorized personnel has been the biggest issue organizations faced around the world. In the past, PCI DSS addressed the need for multi-factor authentication for untrusted entities using remote access to enter cardholder data environments. The PCI V3.2 update now requires for there to be multi-factor authentication for any administrative staff using local access to these same cardholder data environments. This update was designed to further prevent unauthorized access being made from outside of your organization as well as inside the organization from administrative personnel who are only using one form of authentication to enter the cardholder data environment. The name “two-factor authentication” was changed to “multi-factor authentication” for more consistent wording and to encourage organizations to use two or more authentication methods no matter where the administrative personnel are located.
- Designated Entities Supplemental Validation (DESV) – The Designated Entities Supplemental Validation (DESV) gave credit card service providers a set of criteria to manage ongoing security issues and oversight programs. These requirements were designed to increase the protection of payments as it establishes how to scope the environment, establish security measures to instantly detect failures in security control systems, provide timely alerts to these failures, and address the development of compliance program oversight to ensure all security processes are operating as desired. In PCI V3.2, the DESV requirements were consolidated into an appendix, making it easier to review the criteria and decide whether to incorporate the requirements into best practices voluntarily. For some organizations, it is mandatory to undergo a DESV assessment as requested by a credit card brand or issuer.
- More Secure Version of TLS – In December 2015, the PCI Data Security Council introduced migration dates for organizations to move away from Secure Sockets Layer (SSL) and early Transport Layer Security (TLS). In the PCI V3.2, there are appendices to help your organization with the migration reporting efforts.
- Added Service Provider Scrutiny – The PCI Compliance Guide states: “Service providers will undergo additional scrutiny of their management processes, and penetration testing will be required on a more frequent basis.” According to the PCI Data Security Standard Requirements and Security Assessment Procedures, and specifically regarding Requirement 11.2, companies must perform internal and external scans—or ASV scans—quarterly, and rescans as needed, or after any significant change and only by qualified personnel.
Most importantly, this series of requirements under 11.3 is a guideline for pen testing frequency:
Requirement 11.3.1 – Companies should conduct external penetration testing at least on an annual basis or after any significant change in the organization’s operating environment.
Requirement 11.3.2 – Companies are required to perform internal penetration testing at least annually or after any significant change in the organization’s operating environment.
Requirement 11.3.3 – Any exploitable vulnerabilities identified during penetration testing must be corrected, and testing must then be repeated to verify corrections.
Requirement 11.3.4 – Companies must perform network segmentation testing to validate if segmentation controls and methods are operating effectively.
Requirement 184.108.40.206 – Service providers must perform penetration testing on segmentation controls every six months. Previously performed at least annually, this PCI DSS v3.2 update was important because it allowed each specific entity to demonstrate that their segmented environment was truly isolated during testing. It’s important to validate the effectiveness of segmentation to make sure the PCI DSS scope stays current to stay on course with any changing business objectives.
PCI-DSS v3.2.1 is the current version, released on May 31, 2018. It introduced relatively minor changes, like the clarification updates and a correction to previous requirements. It revised several of the standard requirements that were a part of the original PCI-DSS.
Related article: How to Prepare for Your Upcoming PCI Audit.
Rely on the Services of a Combined IT Security and CPA Firm
At AWA, we understand how important protecting your valued customers’ cardholder data is to you. We also understand the wrench that this type of update can throw into your team’s regular tasks. We can help you get up to speed on all the changes, helping you identify any gaps that might compromise your customers’ data.
Contact us so we can help you prepare for the new changes expected later this year.
Editor’s Note: This post was originally published in 2019 and has been updated for accuracy and comprehensiveness.