PCI Compliance Levels: A Developer’s Guide to PCI Compliance

Compliance is something that developers dislike. Traditionally led by risk and information security teams, compliance standard enforcement in organizations is not something software engineers are trained to do. So when the words “PCI compliance” are tossed around, for many developers it mentally translates to limitations, guardrails, bottlenecks, and drastic changes to their workflows that impact productivity. 

But that doesn’t have to be the case.

In reality, PCI compliance means greater attention to application and data security. It can provide a cross-division framework to execute the vision of fraud-free payments. As we delve deeper, we’ll get to know PCI compliance from a developer perspective, review PCI compliance levels and their meaning, and provide you with actionable tips on how to ensure PCI compliance throughout your SDLC.

What is PCI Compliance and why should developers care?

PCI compliance is often used as a shorthand for Payment Card Industry Data Security Standard (PCI DSS) compliance. The PCI DSS provides merchants and processors with set of highly technical guidelines on how to secure credit card and cardholder data. It aims to protect consumers, merchants, processors, and credit card issuers from data theft that results in fraudulent transactions and places heavy fines on businesses that handle credit card information but fail to comply with PCI DSS.

The global standard was created in 2001 through a collaboration between credit card companies to combat credit card fraud. The current and latest version of the PCI DSS, published by the PCI Security Standards Council (PCI SSC), is version 4.0, and it was released in March 2022.

PCI DSS includes a number of security controls that cover technical and operational practices for system components included in or connected to environments that interact with cardholder data. For developers, the relevant PCI compliance requirements to know are 3, 4, and especially 6 as they include guidelines for securing cardholder data at rest and in transit, managing access controls, and ensuring network security.

Before we discuss the role of developers in PCI compliance and the requirements you should be familiar with, let’s break down the levels of PCI compliance. 

PCI Compliance Levels Explained

The guidelines in the PCI DSS have different demands for businesses of different sizes. Generally speaking, the more transactions your applications process, the more stringent measures you’ll need to follow. 

This is the reason why many small businesses that handle large volumes of credit card transactions prefer to outsource payment processing features and applications to a trusted third party.

PCI Compliance Level 1

Level 1 of PCI DSS compliance is the highest level of stringency and applies to businesses that process over 6 million transactions annually, as well as businesses that have experienced a breach involving credit card information. To comply with PCI DSS Level 1 businesses must:

• Undergo an annual Report on Compliance (ROC) by a third party auditor – a Qualified Security Assessor (QSA). The assessment involves an in-depth review of the organization’s security policies, procedures, network and software architectures, application design, and other vital protective measures.
• Pass a quarterly network scan by an Approved Scan Vendor (ASV).

PCI Compliance Level 2

Level 2 of PCI DSS compliance is less stringent than Level 1, and it applies to businesses that process between 1 million and 6 million transactions per year. To comply with PCI DSS Level 2 businesses must:

• Complete an annual Self-Assessment Questionnaire (SAQ) – a checklist that covers areas of security like data protection, vulnerability management, access control management, as well as monitoring, testing, and pentesting.
• Pass a quarterly network scan performed by an ASV.
• Complete an attestation of compliance (AoC) form.

PCI Compliance Level 3

Level 3 of PCI DSS compliance applies to businesses that process between 20,000 to 1 million transactions per year. The requirements for compliance are identical to those in PCI compliance level 2.

PCI Compliance Level 4

Level 4, the most basic level of compliance, applies to businesses handling fewer than 20,000 transactions per year. To comply with PCI DSS Level 4, organizations are required to:

• Complete their annual self-assessment questionnaire (SAQ) 
• In some cases, pass a quarterly network scan executed by an ASV.
• Complete an attestation of compliance (AoC) form.

Developer’s Role in Ensuring PCI Compliance

PCI compliance isn’t just for security and compliance experts. Developers also play a big part in making sure credit card information stays safe when creating software and after it’s launched.

Simply put, PCI compliance means that when building software, developers should work closely with security and compliance teams. Together, they make sure credit card details are safe, whether they’re being moved around or stored.

To developers, PCI might seem like other rules they’ve heard of, like GDPR (which is about personal data privacy) or HIPAA (which is about health information). But PCI is special because it’s all about keeping credit card details secure.

It’s important for developers to understand this difference. They need to know the special rules of PCI and make sure they follow them when they write code, design software, or launch new tools. By thinking about these rules early on, they can build software that’s safe and follows the rules, without slowing down or losing creativity.

PCI Compliance Best Practices for Developers

Developers have different levels of involvement with different requirements and sub-requirements in the PCI DSS, and the best way to explain their roles in ensuring PCI compliance is by looking at it as three key goals for software engineers:

• Protect credit card and cardholder data processed and stored by your applications.
• Secure payment information in transit.
• Ensure information systems and software are safe from exploitation through vulnerabilities.

For each above goal, there are different tools, some of which are tailored to the needs of software engineering teams. Let’s break them down to understand how to achieve each PCI compliance goal.

Credit card and cardholder data protection

Protecting cardholder data from malefactors is at the heart of PCI compliance, and there are a number of ways developers can do that. But first, it’s important to understand what exactly is considered protected data under PCI DSS.

Cardholder or account holder data refers to information about the cardholder and the account itself and includes the card’s primary account number (PAN), the cardholder’s name, and the card’s expiration date, as well as the “full track” (magnetic stripe) data, the card verification code, and the PIN or PIN block.

To protect this data, developers should:

• Keep all the above-mentioned data in a secure environment while the application is running. 
• Place appropriate safeguards and use sensitive data discovery tools like SpectralOps to prevent critical data from public exposure in runtime.
• Implement strict policies to minimize or eliminate, when possible, the storage of payment data.
• Avoid storing authentication data (full track, card verification code, and the account PIN or PIN block) in the system.
• Limit data retention and storage times.
• Never store the data in clear text format and employ strong cryptographic encryption.

Data security in transit

PCI DSS requirement 4 demands that all cardholder data is protected with strong encryption when traversing public networks. In a cloud-native environment, even traffic between microservices across clouds is technically traversing over a public network. 

For developers, this means:

• Effective use of TLS, SSL, and SSH protocols of the latest versions in the applications they develop.
• Regularly updating encryption keys and certificates.
• Avoiding sending credit card data in plain text, even in internal communications.
• Monitoring and logging data movement to quickly spot and stop any unusual activities.
• Making sure that mobile apps also follow strong encryption when sending credit card details.
• Testing the applications regularly for any weak spots in data transfer security.
• Setting up alerts for failed data transfer security checks.

Vulnerability management and secure coding

PCI compliance requires that application and code security are prioritized and addressed at every step of the SDLC, starting with the software requirement analysis for security requirements, and throughout the operational environment.

For developers, this translates into:

• Implement PA-DSS (Payment Application Data Security Standards) best practices for application development.
• Automate patch management.
• Integrate static and dynamic application security testing (SAST and DAST) into your CI/CD pipeline to scan for vulnerabilities, and address them according to severity.
• Employ monitoring and timely alerts for dev-related security issues.
• Document all steps of the application development process, as well as all external resources used (like frameworks or libraries) for easier auditing.
• Use version control with the ability to roll back changes.

Automating PCI Compliance with SpectralOps

PCI compliance is not something you achieve and forget about. As you grow your business and expand the capabilities and features of your applications, it’s important to remember how these changes affect your PCI compliance posture. For example, a boom in business that dramatically increases your number of transactions may move you between compliance levels.

As noted above, the principles behind PCI compliance are not different from other privacy and security standards. They provide a set of technical guidelines for ensuring the security of credit card and credit card holder information, some of which mirror Secure Software Development Life Cycle (SSDLC) and DevSecOps best practices.

When it comes to detecting vulnerabilities and misconfigurations in your code, SpectralOps offers a developer-friendly solution that integrates seamlessly into your CI/CD pipeline to keep vulnerabilities out, and code secrets in.