What is PCI compliance?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of standards created to help protect cardholder data, ensure credit card transactions are handled securely and to help reduce the risk of fraud or data breaches anywhere in the payment ecosystem. It is governed by the Payment Card Industry Security Standards Council (PCI SSC). 

PCI compliance involves adhering to these standards set out by the PCI SSC. 

Who needs to worry about PCI compliance? 

Any organization that handles credit card payments or payment information of any kind, no matter how small the business or number of transactions, must satisfy PCI DSS compliance requirements. Compliance is mandatory in order for the major banks and credit card companies to agree to work with the organization. 

Short answer: if an organization accepts or uses credit cards in any way, PCI compliance is a must. 

What happens if you don’t comply with PCI DSS?

Even though PCI DSS is not a government-regulated standard, the PCI SSC can take action if an organization does not comply with PCI DSS standards. The usual consequence of non-compliance is a monetary fine - this could be banking fines (for each card stolen), paying for legal fees, costs associated with federal audits and so on. 

The financial impact of non-compliance (up to a whopping $500,000 per incident) is often a strong enough threat for organizations to take compliance seriously. The additional risk of other banks, partners, and customers losing trust in an offending organization is often an even stronger incentive to remain compliant. 

What are the 12 PCI DSS requirements and how to prove you are compliant

1. Build and maintain a secure network

PCI standards require that you install and maintain a firewall configuration to protect cardholder data. Without a properly functioning firewall and properly configured routes, the first critical layers of an organization’s network defense can be compromised. 

Compliance: In order to comply with this requirement an organization must demonstrate that they indeed have all of the above installed and functioning correctly. They must also show that they have the right testing and validation measures in place, used to ensure appropriate measures are in place and functioning as they should. 

2. Apply secure configurations

An org must ensure they apply secure configurations to all system components. Orgs should never use vendor-supplied defaults for system passwords or any other security measures - instead implementing their own more robust parameters. 

Compliance: Orgs must demonstrate that they are not operating with any vendor-supplied passwords or security measures. Scanning tools can help identify any missed ‘factory’ passwords. 

3. Protect Stored Data

Organizations that collect and store any cardholder data must ensure that it is adequately protected. This means encrypting any stored cardholder data within existing systems. 

Compliance: Many organizations can become automatically compliant with this requirement by opting to NOT store cardholder data at all. If an org does opt to store it, they must prove that they have data encryption practices and policies in place. 

4. Use cryptography

Orgs must use strong cryptography when transmitting cardholder data over open or public networks. Any credit card information transmitted across a public network (e.g. web payments over the internet), must be encrypted. Encryption methods like SSL are often a first choice. 

Compliance: Policy-driven testing solutions can help verify that an organization is 1) using encryption methods and 2) that they are working correctly. 

5 Protect systems and networks from malicious software

Orgs must use antivirus programs across all internal systems,  helping to block malware and viruses. Antivirus software should be updated and the latest available version, at all times. 

Compliance: Proof of antivirus software use and inspection to verify use of the latest version will satisfy this requirement. 

6. Develop and maintain secure systems and software

Implementation of a robust AppSec program, from tooling to procedures and resources can be helpful in getting the best and most accurate view into an org’s security stance. Use of a full suite of AppSec tools (think SAST, DAST, Pentesting) can help identify weaknesses or vulnerabilities in software, and ensure secure coding practices throughout the software development lifecycle. 

Compliance: Use of software composition tools (SCA) can help produce a software bill of materials (SBOM) that provides a complete list of an organization’s software and known vulnerabilities. An SBOM can satisfy this regulation. 

7. Restrict system component and cardholder data access

Access to sensitive cardholder data should be limited to a need-to-know basis. Access should be very limited and recorded (ie. an org knows who is seeing this data and when). Documentation of this access should be recorded and regularly reviewed to ensure the right people have access to cardholder data.

Compliance: solutions can track and monitor access to applications and files, identifying unnecessary or suspicious access, while also demonstrating adequate restriction to only necessary data accessors. 

8. Identification and authentication of users

Orgs should identify users and authenticate their access to system components - employees should be assigned a unique ID to help monitor and track access and activities.

Compliance: Reporting or solutions that provide recordings of user access across the org’s ecosystem. The ability to answer “who accessed this asset, and when?” satisfies this requirement. 

9. Restrict physical access to data

Orgs should restrict physical access to cardholder date. This means devices, buildings, or any other tangible location data is stored.

Compliance: Evidence of physical security measures (cameras, secure rooms, IP cameras) satisfies this requirement. 

10. Logging and monitoring of access

Orgs should log and monitor all access to system components and cardholder data. This logging should provide clear insight into normal (accepted) access, and flag any abnormal access to allow for quick investigation and remediation, as necessary. These logs are required in the event of a breach. 

Compliance: Evidence of adequate logging and monitoring is required. This can be achieved with a security information and event management (SIEM) solution in place. 

11. Regular security testing of networks and systems

Regular vulnerability scans to identify any weaknesses in an org’s environments should be a best practice. Cans should be a regular occurrence but are particularly important in the event of any organizational changes to the network, systems or applications. 

Compliance: Evidence of continuous monitoring, pentesting, vulnerability scanning, or regular audits can help satisfy this requirement. 

12. Organizational support of IT

Orgs must support IT efforts with procedural and policy-based efforts around security. All employees should undergo security training and security champions or dedicated security teams should help maintain security awareness. Clear policies around security, risks, and company data should be communicated regularly. 

Compliance: Evidence of a clearly defined security policy, procedures, and dedicated security teams can help satisfy this requirement. 

What is PCI DSS v4.0.?

The latest update to existing PCI DSS requirements is PCI DSS v4.0 (with very minor revisions released in v4.0.1), requiring organizations to be compliant by March 31, 2025. 

This aim of this update to prior editions of PCI DSS is to: 

1. Continue to meet the security needs of the payments industry (evolve with changing security threats). 

2. Promote security as a continuous process.

3. Increase flexibility for organizations using different methods to achieve security objectives.

4. Enhance validation methods and procedures.

Read more about what you need to know about PCI DSS v4.0.

How Fastly can help with PCI Compliance

Fastly’s next-gen WAF can help organizations adhere to the latest PCI data security standards, simplifying compliance without putting your security at risk. Our Next-Gen WAF can help you meet these requirements and provides advanced web application and API protection (WAAP) for your applications, APIs, and microservices. But there are plenty of other reasons to love the Fastly Next-Gen WAF.

Our proprietary SmartParse technology replaces tedious regex-based tuning and enables highly accurate decisions, resulting in fewer false positives than other WAF solutions. That’s why more than 90% of our customers run the WAF in full-blocking mode, with the confidence that they will be protected against malicious actors without the danger of disrupting legitimate traffic.

Developers love it, too. The Fastly Next-Gen WAF flexibly deploys in any environment and can protect apps and APIs wherever they are – in containers, on-prem, in the cloud, or on the edge. While other WAFs can act as blockers for innovation, the Fastly Next-Gen WAF’s flexibility and accuracy ensure it can integrate seamlessly into any DevSecOps stack, making security simple for everyone.

Best of all, it deploys in as little as 10 minutes, with an average time to full blocking in 60 minutes. Given how soon the PCI DSS deadline is approaching, every minute counts.

PCI-Compliant Caching and Delivery

Fastly’s CDN can also help you remain compliant. We have designed Fastly's core CDN service with Payment Card Industry Data Security Standard (PCI DSS) compliance in mind. With proper authorization on your account, you can use Fastly's beresp.pci VCL variable to automatically cache content in a manner that satisfies PCI DSS requirements.

Adding the beresp.pci variable to an object prevents writing of that object to non-volatile disk storage on the edge. Combined with frontend and backend TLS, this feature allows you to cache and transmit flagged content through the Fastly network in compliance with our PCI certification.