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 numbers. 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 expensive 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. 

TLDR

PCI DSS compliance entails 12 essential steps to protect cardholder data. These include securing networks with firewalls, using robust passwords, encrypting stored and transmitted data, safeguarding against malware, maintaining secure systems and applications, access control to the data, access monitoring, regularly testing security measures, and educating personnel on security policies. These measures ensure that credit card information remains secure, fostering trust and security in payment transactions.

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 that 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 which defines 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 and provide an Attestation of Compliance. 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 its 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 policies, prior to 2004 there were no global industry standards. 

Image: PCI SSC Mission

Source: PCI About Us

In December 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. PCI DSS v3.2.1 was superseded by v4.0 on March 21, 2024, and the official effective date for v4.0 is March 31, 2025. Entities utilizing a third-party service provider (TPSP) that is validated on the previous version will still be compliant as long as the validation was completed before the retirement of v3.2.1 and 12 months have not passed since the service provider’s validation. 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.

Additionally, the PCI data security standard effectively outlines essential security controls for the cardholder data environment, which are applicable even to small businesses. These include maintaining strong firewall configurations and updating default account passwords, reflecting best practices to enhance overall security. 

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, and this article includes these changes. 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 malicious entities 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, 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 4.0 defines that the organizations must implement more robust encryption and tokenization measures.

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.  In particular, PCI DSS 4.0 indicates that organizations are required to use advanced malware protection mechanisms with detect and respond capabilities. This also 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 (DevSecOps), 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. PCI DSS 4.0 also dicates to use Just-in-time access mechanisms, which grant temporary permissions as needed. 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. PCI DSS 4.0 enhancements indicate that the MFA is required for all access to the cardholder data environment, including internal network access.

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 receipts or electronic records, 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 more comprehensive penetration tests, including timelines and schedules. This includes external and internal testing, as well as testing after significant changes to the environment. 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 has introduced updated requirements with specific implementation deadlines: there was a transition period until March 31, 2024, during which organizations can choose to comply with either v3.2.1 or v4.0. Starting April 1, 2024, all new assessments must use v4.0. Some new requirements in PCI DSS 4.0 are considered best practices until March 31, 2025, after which they become mandatory on April 1, 2025. These updates aim to enhance payment card security by addressing modern threats and promoting advanced security measures like encryption, malware protection, and secure access controls.

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 compliance programs.

Frequently Asked Questions About PCI DSS Requirements

Is PCI DSS compliance legally required?

PCI DSS (Payment Card Industry Data Security Standard) compliance is not legally mandated by government laws, but it is required by the payment card industry itself. 

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

 While PCI DSS v4.0 was officially released on March 31, 2022, the transition period ended on March 31, 2024. As of April 1, 2024, all new assessments must be conducted using PCI DSS v4.0.