The Ultimate Guide to PCI Security & Compliance

From fintech firms to retail merchants, PCI standards are nearly ubiquitous across many industries. This makes it important to understand, for anyone involved in processing and managing credit card transactions. Read this guide to understand core aspects of PCI compliance and security standards, as well as how to implement them. You can also feel free to download our PCI checklist to track your progress on implementing core components of your PCI compliance program.

What is PCI compliance?

‍PCI compliance refers to a set of requirements for maintaining the integrity, confidentiality, and security of cardholder data which are maintained by the Payment Card Industry Security Standards Council. Typically, when people refer to PCI compliance, they’re talking about the PCI DSS (Data Security Standard).

Other standards enforced by the Payment Card Industry Security Standards Council include: 

‍

• PA-DSS (Payment Application Data Security Standard) - Predominately applies to the vendors who build payment applications, whereas PCI DSS applies to anyone who handles credit card payments. At the end of October 2022, this was replaced by the PCI Secure Software Standard, a standard within the PCI Software Security Framework (SSF).
• PCI-PTS (Payment Card Industry PIN Transaction Security) - These are physical and logical security requirements for payment hardware and other point of interaction devices processing credit cards.
• PCI P2PE (Payment Card Industry Point-to-Point Encryption) - This is an encryption standard established by the PCI Security Standards Council that enforces a designated encryption standard at point of sale terminals and throughout the payments process.

PCI DSS by far is the most common standard enforced by the council, which is maintained by a consortium of credit card companies, including Visa, MasterCard, American Express, Discover, and JCB.

Because the PCI council is not a governmental agency, PCI standards aren’t formally part of any governmental regulatory regime (in a manner akin to something like HIPAA or CCPA, for example) and thus are not federal law. Nonetheless, PCI enforcement is carried out against violating entities via fines levied by acquiring banks or sometimes by card issuers themselves. 

Some US states, like Minnesota, Nevada, and Washington, have adopted components of the PCI DSS into their state privacy and data protection statutes, but these laws should be considered distinct from (and complementary to) the PCI DSS and its enforcement.

What is the PCI DSS?

The Payment Card Industry Data Security Standard is a set of security and data protection requirements that impacts entities storing, processing, or transmitting cardholder data. The purpose is to ensure the confidentiality and integrity of cardholder data, cardholder authentication data (like CVVs or CVCs & PINs), as well as the security of the cardholder data environment as a whole, referred to by the PCI DSS as the CDE.

The cardholder data environment includes networks, point of sale systems, servers, applications, IT systems, and virtual components that are involved in the processing, storage, or transmission of cardholder data, as well as any people and processes involved in coordinating this activity.

The PCI DSS has over 300 pages of guidance, however the core aspects of PCI compliance boil down to 12 key requirements:

1. Install and maintain a firewall to protect cardholder data.
2. Use unique passwords and other security parameters, never vendor-supplied default passwords or other security parameters.
3. Protect cardholder data.
4. Encrypt transmitted cardholder data.
5. Update antivirus and malware protection regularly.
6. Maintain secure systems and applications.
7. Restrict access to cardholder data to only users who need it.
8. Assign unique IDs to those with access to data
9. Restrict physical access to data
10. Create and monitor access logs
11. Test security systems regularly.
12. Create an information security policy and update it regularly.

Who does PCI compliance apply to?

According to the Payment Card Industry Security Standards Council, PCI compliance applies to any organization that processes credit card payments. These include processors, service providers, merchants, processors, as well as any entity that processes, stores, or transmits card data or cardholder authentication data.

The PCI DSS has four different levels of compliance which determine the level of complexity that an organization’s compliance program must meet. These levels are determined by the volume of transactions an entity processes per year and include:

‍Level 1: Merchants who process more than 6 million transactions per year.

• Level 2: Merchants who process 1 – 6 million transactions per year.
• Level 3: Merchants who process 20,000 – 1 million transactions per year.
• Level 4: Merchants who process fewer than 20,000 transactions per year. 

Overview & Checklist for the 12 PCI DSS Requirements

1. Install and maintain a firewall to protect cardholder data

Full Network segmentation is a strongly recommended (though not required) practice within the PCI DSS. However, firewalls are explicitly called out as a requirement in the PCI DSS, and they are a great way of helping to ensure network segmentation. If cardholder data is limited to a segmented network that you are monitoring, and limiting traffic to, you reduce the number of systems that could potentially leak cardholder data.

2. Use unique passwords

The PCI DSS explicitly designates the need to modify or change default passwords for any vendor supplied hardware and software. Custom passwords should be complex, hard to guess, protected from abuse or misuse (with a solution like identity and access management), and rotated regularly.

3. Protect cardholder data

Cardholder data is only meant for business use or need, with no other uses being permitted. This requires that storage and retention of cardholder data needs to be kept to the minimum required to fulfill a business purpose. Where ever cardholder data is readable (primary account numbers, PINs, ect.) it should be masked. Cardholder data that is stored or in transit must be encrypted. One way to continuously ensure compliance here is to scan for and automatically remove unencrypted cardholder data from out-of-scope systems with a solution like Nightfall.

4. Encrypt cardholder data transmitted over public networks

Requirement four overlaps heavily with requirement three. Ultimately, you’ll need to work to validate that you’re only transmitting cardholder data over designated encrypted lines using secure transport protocols like SSL if doing so over the internet or properly encrypted networks if doing so over local networks and intranets. You should scan any other surfaces for unencrypted credit card data as well. For example, even if you have designated payment portals for transmitting encrypted cardholder data, you’ll want to scan systems like Zendesk, to ensure that your customer service reps are not entering cardholder data within inappropriate fields.

5. Use up-to-date antivirus solutions and protect against Malware

Malware and ransomware targeting banking and payments systems are ubiquitous, as such, PCI DSS has a requirement to keep antivirus software and malware protections on systems up-to-date and to run scans regularly.

6. Ensure systems and applications are secure & up-to-date

This requirement focuses on ensuring that the infrastructure and environments that you use are kept up-to-date. This means applying updates for servers and applications in use, including hot patches. It also requires having a thorough DevSecOps process for any custom code or applications being developed. See our free GitHub remediation guide for developer best practices regarding preventing data leakage.

7. Limit access to cardholder data by business need-to-know

Only authorized users should have the ability to access cardholder data, and even then it should only be accessed on a need-to-use basis. Fulfilling this requirement means having strong authentication and access control measures in place that can be used to restrict cardholder data access. Access should not only be restricted to authorized users, but also restricted only to circumstances where authorized users actually need to use the data for a relevant business purpose.

8. Assign unique identifiers to individuals with computer access

Creating login IDs for users allows you to associate access of resources to specific accounts or individuals, which is important for logging activity and determining if anomalous behavior has occurred.

9. Restrict physical access to cardholder data

For organizations managing physical records of cardholder data, these must be stored securely as well. Physical records not only include paper records, but any physical media (like thumb drives, CDs, external hard drives, ect.) that may contain cardholder data and can be physically exfiltrated from your premises. Having policies that require employees and visitors to physically “sign in” and “sign out” as well as using technologies like locks and video cameras are some ways that organizations can mitigate risk.

10. Track and monitor access to network resources

Requirement 10 centers around leveraging logs within your systems to ensure that anomalous behavior, like unauthorized accounts accessing sensitive information, isn’t occurring. You will want to establish a regular time to audit logs.

11. Regularly test and manage security systems and processes

Security tools and processes are no use if they’re not regularly maintained and updated. In our security playbook for remote-first organizations, we highlight practices like tabletop exercises and documentation such as incident response and disaster recovery plans in order to ensure your security doesn’t fail when you need it most.

12. Keep your information security policies up-to-date

This is something we also talk about in our aforementioned security guide. Identify key stakeholders who can manage and maintain documentation around your security policies and practices in order to keep your information security program up-to-date.

What’s the PCI certification & audit process?

How do organizations demonstrate PCI compliance? That generally depends on what PCI level it is. Level 1 Merchants are required to undergo extensive audits to verify compliance, as well as conduct an annual network scan by an approved scanning vendor (ASV). This process also requires receiving a detailed annual Attestation of Compliance and a Report on Compliance.

Lower levels of PCI compliance entail an annual PCI DSS Self-Assessment Questionnaire, as well as using an ASV to conduct scans on a regular basis.

What is PCI DSS 4.0?

PCI DSS 4.0 refers to the current version of the PCI standards that were drafted in 2019 and released in March 2022. These revisions center around several core changes, including updating authentication and security control standards to keep pace with technological improvements. We are currently in a transition period, with PCI DSS 4.0 slated to go into effect in March 2025.

To see the full list of changes from PCI DSS 3.2.1 to 4.0 you can view this document.

What are best practices for implementing PCI DSS?

One of the key aspects to planning PCI compliance is determining which of your systems are in scope or should be in scope. This is because if a system is not in scope for PCI compliance, this can reduce your overall compliance burden. 

A good PCI compliance strategy therefore centers around:

1. Identifying all in-scope systems as well as any systems “connected to” in-scope systems. These are where your PCI compliance policies must be in effect.
2. Evaluating whether you can reduce the number of in-scope systems
3. Ensuring that you have processes and technologies in place within in-scope & connected systems to fulfill your PCI obligations
4. Monitoring out of scope systems to ensure cardholder data is not leaking over from in-scope & connected systems. 

How do organizations leverage Nightfall for PCI compliance?

Nightfall is the industry’s first data loss prevention that has been built from the ground up specifically to scan SaaS platforms and cloud silos for sensitive PII, including industry specific content like PHI and PCI – like cardholder data.

With Nightfall, organizations can discover, classify, and protect cardholder data that is found in text, image, files, messages, and more, in order to ensure it’s not being stored in systems that are out of scope or that such data is not stored within in-scope systems inappropriately (such as in plaintext).

Protecting PCI with Nightfall

PCI Data Storage Requirements necessitate that specific types of cardholder data and authentication data not be stored in plain text or unencrypted within in-scope systems. With Nightfall, you can scan to verify if primary account numbers (PAN) are redacted within your in-scope systems. You can also make sure that absolutely no PCI is being shared within out-of-scope systems.

Other relevant PII types that you might be interested in detecting alongside cardholder data:

• Social Security Number
• US Bank Routing MICR
• SWIFT Code
• IBAN Code
• US Driver's License

Don't forget your free PCI compliance checklist

Download this free PCI compliance checklist so you can keep track of core aspects of your compliance program: