The 12 PCI DSS Compliance Requirements: What You Need to Know

As mobile and touchless payment tools become the norm, vendors who accept and store credit card data face even more risks and vulnerabilities surrounding cardholder data and payment card data. Do you know how to implement best practices for credit card information security in the face of novel threats to cybersecurity? What do you do in the event of a breach? What is PCI, and what are the compliance requirements associated with accepting credit card payments? How do other companies navigate the credit card and payment landscape?

The Payment Card Industry Data Security Standard (PCI DSS) is designed to deter credit card-based fraud, and help merchants and service providers both prevent and effectively respond to cybersecurity attacks and data breaches potentially compromising cardholder data. Such data breaches can be costly in terms of a business’s reputation, its bottom line, and non-compliance with the PCI data security standard (DSS). Read on to learn more about the 12 core PCI DSS requirements and how your organization can benefit from achieving and maintaining PCI DSS compliance. 

PCI DSS Compliance Overview

If you’re wondering how to be PCI compliant, the Payment Card Industry Data Security Standard (PCI DSS) issued by the Payment Card Industry Security Standards Council (PCI SSC) provides security guidelines for merchants, payment processors, and service providers which transmit, process, and store cardholder data and account data. Essentially, all companies performing some kind of credit card payment processing or accepting payment card transactions must be mindful of PCI DSS, their compliance levels according to the standard, and their obligations related to credit card information. Depending on how many credit card transactions they process and their compliance level from one to four, companies may have to undergo a different degree of compliance activity. Level One organizations are required to undergo a formal audit by a Qualified Security Assessor (QSA). QSAs are formally certified professionals who have passed the test to receive their credentials, and are uniquely qualified to sign off on a PCI DSS Report on Compliance. Organizations in Levels Two, Three, and Four, are obligated to complete an annual Self-Assessment Questionnaire (SAQ) aligned with their organization and industry. Though these SAQs do not have to be formally reviewed by a QSA or other PCI professional, they do require a thorough understanding of the PCI data security standard and the company’s environment, security, and operations. In fact, there are many different types of SAQs, and a company’s first objective when seeking to become PCI compliant should be to understand the scope of their compliance obligations.

Image: SAQ Guide

Source: SAQ Guidelines

The PCI Security Standards Council is a coalition of the five largest credit card companies (American Express, Discover Financial Services, JCB International, Mastercard and Visa), founded to, “enhance global payment account data security by developing standards and supporting services that drive education, awareness, and effective implementation by stakeholders.”  While these five companies had started to develop their own individual policies, prior to 2004 there were no global industry standards. 

Image: PCI SSC Mission

Source: PCI About Us

In December of 2004, the PCI DSS requirements standardized the elements of secure payment environments and provided a guidepost for best practices related to accepting, transmitting, and storing cardholder data. These requirements have evolved in response to new forms of payment and data storage, from new point of sale (POS) technologies to emerging ecommerce technologies to contactless payment.

The most recent version, PCI DSS v4.0, was released in March 2022. The previous standard, PCI DSS v3.2.1, will remain in place for two years to ensure smooth adoption. During the transition period, the PCI Security Standards Council recommends organizations prepare for PCI DSS v4.0 compliance by studying the new standard, reviewing and updating their templates and forms accordingly, and focusing on adopting changes to comply with the standard.  

Is PCI DSS a Legal Compliance Requirement?

PCI DSS is not a law, but the security standard does have an impact on the law. According to an American Bar Association post, PCI DSS compliance is not a legal requirement, but because each credit card company has its own PCI DSS language and related fees for noncompliance, PCI DSS compliance becomes part of the contractual agreement between the vendor and credit card company. Moreover, there are certain states with PCI DSS written directly into their state-level laws, like Nevada, or have significantly overlapping language with PCI DSS, like Minnesota. State laws are variable and PCI DSS remains the dominant industry standard for handling cardholder data, backed by the major credit card brands internationally, so you can stay on top of any potential emerging liability by adhering to PCI DSS in the first place.

Plus, the PCI data security standard does a good job of laying out some best practice security controls around the cardholder data environment that make sense even in small businesses, like maintaining good firewall configurations and changing default account passwords.

The 12 Requirements of PCI DSS Compliance

The following overview will help you plot out how to be PCI DSS compliant. We’ll summarize the 12 PCI DSS requirements below and you can find extra information in the PCI DSS 4.0 resource hub. The 12 requirements of PCI DSS compliance are designed to support your organization’s development of a strong information security system and fall under six overarching categories: 

1) Build and maintain a secure network and systems

2) Protect cardholder data

3) Maintain a vulnerability management program

4) ​Implement strong access control measures

5) Regularly monitor and test networks

6) Maintain an information security policy

Fortunately, the 12 core PCI DSS compliance requirements are not expected to change substantially with PCI DSS v4.0. Read on to learn about the 12 PCI DSS requirements in greater detail: 

PCI DSS REQUIREMENT 1: Install and maintain a firewall configuration to protect cardholder data

Firewalls are access control measures — they put a boundary around your organization’s network(s) to prevent the wrong people from accessing your data. You can also create firewalls within your network to protect particularly sensitive data and restrict access to different groups or users internal to your organization since not every staff member or employee will need access to cardholder data. This practice of network segmentation can be done virtually or physically. Network segmentation can be applied to any type of sensitive or protected data, and can certainly be leveraged to support this first security requirement.. This PCI DSS requirement also dictates how to configure and manage your routers to protect cardholder data on your internal networks.An organization’s IT team should continually monitor firewall traffic, and review router configurations every six months and reconfigure them if necessary. 

PCI DSS REQUIREMENT 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Often, operating systems, servers, firewalls, and other elements of your infrastructure and technology stack arrive with factory-set defaults for usernames and passwords. Change them as quickly as possible – they are easy to guess and might even be shared on the Internet. This requirement also reflects industry best practices, like the National Institute of Standards and Technology (NIST) password guidelines. Furthermore, users who create accounts to access applications should not be offered a default password. If you’re complying with both PCI DSS and NIST, you’re on the right track. Unfortunately, it is simple for a skilled hacker or cybercriminal to cycle through common default passwords to gain access to employee or customer records. Make sure you do not allow users to continue using default passwords to access cardholder data; PCI DSS suggests disabling “all unnecessary default accounts before installing a system on the network.”

PCI DSS REQUIREMENT 3: Protect stored cardholder data

This requirement stipulates that, unless it is absolutely necessary for business function, cardholder data should not be stored at all. If the cardholder data must be stored, it is your responsibility to 1) limit storage time, 2) purge data quarterly, 3) render all authentication data unreadable via encryption and display “masking” (showing only the first or last four numbers of the Primary Account Number (PAN), and 4) ensure that all cryptographic keys and encryption tools are documented, recorded, and protected. 

PCI DSS REQUIREMENT 4: Encrypt transmission of cardholder data across open, public networks

While a firewall can help you keep cyber criminals out of your internal networks, it can be more challenging to ensure that cardholder data is not compromised while it is transmitted over open, public networks. PCI DSS mandates that merchants use encryption tools to ensure that the data is unreadable, both during user input and in the case that a hacker gains access to the data through security vulnerabilities. Encryption gives IT admins time to protect and restore the data before a skilled hacker has the chance to decipher it. 

PCI DSS REQUIREMENT 5: Protect all systems against malware and regularly update anti-virus software or programs

According to PCI DSS requirement 5, you must use anti-virus software on all systems that might be impacted by malware (malicious software) attacks; this includes all user laptops, tablets, system infrastructure, and remote devices as well as on-site devices. This includes keeping a close watch on the ever-changing malware landscape so that you’re aware of new threats and that all systems requiring anti-malware are covered. In practice, companies should have a policy governing the “hardening” of new systems and infrastructure, with anti-virus and anti-malware installation built-in as part of the documentation. This requirement includes keeping all anti-virus software updated, conducting periodic scans of your systems for security vulnerabilities, and keeping audit logs, which are covered in greater detail in requirement 10.

PCI DSS REQUIREMENT 6: Develop and maintain secure systems and applications

PCI DSS requirement 6 outlines a risk management system for identifying vulnerabilities, implementing security patches, prioritizing risks, and the recommended order of security actions. This requirement stipulates that security measures be implemented during every stage of the software development process, from coding to applying patches, to addressing vulnerabilities. 

In light of recent major security vulnerabilities like Log4J, PCI DSS requirement 6 has become increasingly important; even code designed to maintain audit logs must be protected, access to the code must be limited, and software engineers also need to be trained in secure coding strategies. 

PCI DSS REQUIREMENT 7: Restrict access to cardholder data by business need-to-know

This requirement can align with your identity and access management protocol; only people who absolutely need to know cardholder data for business operations should have access to that data, otherwise employee access to the cardholder data environment (CDE) should be restricted as a default. User roles should be clearly defined and access controls implemented as soon as a user is terminated, leaves the company, or changes roles. When dealing with access to payment card data or cardholder information, organizations should implement a process of approving access to this data to support stronger access controls. Until access is approved, a user should not receive those permissions. 

PCI DSS REQUIREMENT 8: Identify and authenticate access to system components

Requirement 8 stipulates that all users with access to cardholder data, and system assets in general, have a unique ID, allowing their activities and login events to be traced, tracked, and monitored. Each user should also create a strong password (consider following NIST password guidelines), and any other authentication tools (keys, cards, or multi-factor authentication applications) should be assigned to individual users. The point of this requirement is to ensure that all users are authorized and that any activity can easily be traced to an individual. Along with audit logs and audit trails, requirement 8 can help to prevent internal fraud and catch when a user’s login information may have been hacked, or an attacker has penetrated the organization’s defenses. 

Periodically performing validation that privileged access remains appropriate is another control organizations may want to consider as part of controlling user access.

PCI DSS REQUIREMENT 9: Restrict physical access to cardholder data

Requirement 9 covers the measures that vendors must take to secure the physical environment in which card payments may be accepted, and where cardholder data may be transmitted or stored. Hand-in-hand with the security restrictions covered in Requirement 7 and the identification guidelines in Requirement 8, employees who accept a physical card payment must have physical identification.Furthermore, physical access to areas where on-site personnel will be handling cardholder data should be restricted. Moreover, all documentation with cardholder data on it, whether paper receipt or electronic record, should be rendered unreadable and kept in a physically secure location. It may be tempting to ignore the possibilities of a physical compromise, but physical theft or tampering can pose just as much of a threat as a sophisticated hacking attack.

PCI DSS REQUIREMENT 10: Track and monitor all access to network resources and cardholder data

Requirement 10 provides guidelines for logging, tracking, and monitoring all user activities.Keeping audit logs and audit trails ensures your IT administrators can catch anomalous login activity indicative of a hacker targeting user login credentials to access cardholder data. Audit logs and trails should include user identification, date, and time, at minimum, and should be automated and reviewed by administrators with restricted privileges and the appropriate credentials. This requirement also dictates that audit trail data be kept for at least a year, with at least three months of data immediately accessible for review. Log data, of course, should not be altered in any way. Keeping audit trails in pristine condition is necessary to catch errors and data breaches and to trace them back to specific user data, fostering accountability. 

PCI DSS REQUIREMENT 11: Regularly test security systems and processes

Any time you make changes to your system, including altering your firewalls or router configurations, you introduce the potential for new vulnerabilities. Even anti-virus software designed to prevent an attack could lead to vulnerabilities if it isn’t updated. Requirement 11 provides a highly detailed overview of how to conduct vulnerability scans and penetration tests, including timelines and schedules. Since new software and malware attacks can introduce unknown vulnerabilities, regular scans and tests are essential to implementing the right security patches and upgrades. Penetration tests are recommended at least annually — with remediation follow-up and retesting after the report is issued!

PCI DSS has an additional requirement that is relatively unique to the PCI standard, relating to the vulnerability scans that must be performed by PCI DSS compliant organizations each quarter. These quarterly vulnerability scans must be performed by an Approved Scanning Vendor or “ASV,” identified and authorized by the PCI SSC. Organizations must take steps to remediate or otherwise address any vulnerabilities identified by those scans, documenting progress and action plans.

PCI DSS REQUIREMENT 12: Maintain a policy addressing information security for all personnel

This requirement marries PCI DSS to IT governance. It covers employee training, risk minimization, and establishing a strong security policy to be adhered to across your organization, which should dovetail nicely with other risks, governance, and cybersecurity frameworks. This policy should be documented and distributed to all relevant employees, and PCI DSS stipulates it must be reviewed “at least annually”. 

To keep the policy up to date, organizations should also schedule regular risk assessments (again, “at least annually”). PCI DSS compliant organizations should also minimize employee misuse and implement internal controls to prevent fraud by screening potential hires; creating and distributing usage policies for how to utilize technologies involved in transmitting, storing, or accessing cardholder data, including computer hardware, email, browsing the web, and messaging; and organizing “security awareness” training for all personnel. 

Leveraging Technology to Meet PCI DSS Compliance Requirements

PCI compliance requirements can be complex, but they don’t need to be confusing for your organization. PCI DSS v4.0 introduced some new requirements with “future dated” implementation deadlines – meaning they will give merchants and service providers 2 years after PCI DSS 4.0 was published in March 2022 to adopt the new requirements, until approximately 2024. Your organization still has time to adapt and evolve to meet the new compliance requirements while you work to establish compliance with existing requirements; make the most of that time by streamlining your efforts, effectively coordinating stakeholders to meet operational and compliance goals.

You can keep track of the 12 PCI DSS requirements and stay up-to-date on the new ones by automating your compliance procedures. If your business collects, manages, and stores customers’ payment information and card data, you can streamline your operations by incorporating compliance management software into your programs.

Frequently Asked Questions About PCI DSS Requirements

Is PCI DSS compliance legally required?

PCI DSS is not a law, but the security standard does have an impact on the law.

What is the deadline for becoming PCI DSS v4.0 compliant?

PCI DSS v4.0 introduced some new requirements with “future dated” implementation deadlines – meaning they will give merchants and service providers 2 years after PCI DSS 4.0 was published in March 2022 to adopt the new requirements, until approximately 2024.