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

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 novel threats to cybersecurity – do you know how to protect your company from a breach? The Payment Card Industry Data Security Standard (PCI DSS) is designed to help merchants and service providers both prevent and quickly, effectively respond to cybersecurity attacks and data breaches that could compromise cardholder data. Such data breaches can be costly, both in terms of a business’s reputation and its bottom line. 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) provides security guidelines for merchants and service providers which transmit, process, and store cardholder data and authentication data. PCI compliance is compliance with the Data Security Standards (DSS) set by the Payment Card Industry Security Standards Council (PCI), a coalition of the five largest credit card companies (American Express, Discover Financial Services, JCB International, Mastercard, and Visa). While these five companies had started to develop their own individual policies, prior to 2004 there were no industry standards. 

In Dec. 2004, the PCI DSS requirements standardized the elements of secure payment environments and 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 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 after the PCI DSS v4.0 release date to ensure smooth adoption. During the transition period, the PCI Security Standards Council recommends that organizations prepare for PCI DSS v4.0 compliance by studying  the new standard, reviewing and update their templates and forms accordingly, and focusing on adopting changes to comply with the standard.  

Source: PCI DSS v4.0 Implementation Timeline,

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 that have written PCI DSS directly into state law, 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, so you can stay on top of any potential emerging liability by adhering to PCI DSS in the first place. 

What Are 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, and 6) maintain an information security policy. 

Fortunately, the 12 core PCI DSS compliance requirements are not expected to change substantially with PCI DSS 4.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 – that is they put a boundary around your organization’s network to prevent the wrong people from accessing your data. You can also create firewalls within your network to protect particularly sensitive data and regulate access to different groups or users internal to your organization – not every staff member or employee will need access to cardholder data, after all. This PCI DSS requirement also dictates how to configure your routers to protect cardholder data on your internal networks; your 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 security configuration 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 – 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 that you make it impossible for 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 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. Encryption gives IT admin 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

Per 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, and remote devices as well as on-site devices. Requirement 5 includes keeping 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. This requirement includes keeping all anti-virus software updated, conducting periodic scans of your systems for 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 essentially outlines a risk management system for identifying vulnerabilities, implementing security patches, prioritizing risks and the 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 vulnerabilities. 

In light of recent major data breaches to code 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; this requirement mandates that employee access be fully 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 REQUIREMENT 8: Identify and authenticate access to system components

Requirement 8 stipulates that all users with access to cardholder data 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. 

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 and physical access to areas where onsite 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. 

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 ensure that your IT administrators can catch anomalous login activity that might indicate a hacker is targeting user login credentials to access cardholder data. Audit logs and trails should include user identification, date and time, and they should be automated and reviewed by administrators with restricted privileges. 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, and the data 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. 

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, unknown vulnerabilities. So, even following the requirements for PCI DSS can introduce risk – 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. 

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

This requirement makes PCI DSS integral to IT governance. It covers employee training, risk minimization, and establishing a strong security policy that is adhered to across your organization. This policy should be documented and distributed to all relevant employees, and PCI DSS stipulates that 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 use 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 complicated for your organization. PCI DSS v4.0 introduced some new requirements with “future dated” implementation deadlines – that means they will give merchants and service providers 2 years after PCI DSS 4.0 was published in March 2022 to adopt the new requirements. Your organization will have 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. 

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.

Related Articles