A Software Developer’s Guide to PCI Levels

By Alison Gunnels

The terms PCI, PCI DSS, and PCI compliance are bounced around in financial-information-processing environments, sometimes without sufficient context. Developers where PCI applies know that it is crucial (at least to management!), but security and compliance teams don't constantly interrupt their audit prep long enough to show devs how inherent their involvement is to payment card security.

An approach to PCI that neglects developers and software testers isn't complete and adds pain and time to the process. If you're a dev who needs to understand your part in PCI compliance, this short overview will help illustrate how deeply you impact security performance in your organization.

An Era of Rampant Fraud

In the United States, few organizations are required by law to implement and enforce information security controls. Since security—especially technical security—often has a high cost, the protection afforded for sensitive data can be insufficient.

In the late 1990s and early twenty-first century, this was certainly the case for credit card data. Insufficient data security around both credit cards and identity data allowed criminals to steal, trade, and create fraudulent credit accounts. The issuers of credit cards bore an enormous cost for identifying and mitigating fraud, which could not be passed on to the consumer, who was also a victim. Card-issuing banks began to publish security standards independently within a few years, then quickly formed a cooperative to provide a single well-considered standard. These separate standards, and the resulting collaboration, became the start of PCI.

PCI and Its Various Acronyms

PCI stands for Payment Card Industry, although it is also often used as shorthand for PCI Data Security Standard (PCI DSS). PCI DSS version 1.0 was created in 2001 through a joint effort by credit card companies to deter fraud. The standard set some guidance for merchants and processors about security to protect card and cardholder information. This first PCI standard predates the creation of the PCI Security Standards Council (PCI SSC). The current version, PCI DSS 4.0, was released in March 2022.

PCI DSS intends to protect consumers, merchants, processors, and issuers from the cost and difficulty of fraudulent transactions due to the theft of cardholder and account information. Although this standard is the law in only a few places, PCI DSS compliance is required for merchants and processors to handle credit and debit cards from the most popular banks, including Visa, American Express, and Mastercard.

PCI DSS covers a wealth of security controls, including system configuration, policies and procedures, and permissions for access to cardholder data. Secure software development and management are critical to PCI compliance: development-related activities are impacted within every one of PCI DSS's twelve areas, from policies that support the secure development lifecycle to the testing requirements to declare code secure enough.

The full PCI DSS standard can be found on the PCI SSC website.

PCI DSS Levels—Does Development Change?

There are four categorizations of merchants under PCI DSS. These predefined categories dictate the compliance requirements for any merchant or credit card processor. The four levels of PCI compliance, as laid out by the PCI SCC, relate to how many transactions a merchant processes on an annual basis:

Level 1: Merchants processing over 6 million card transactions per year.

Level 2: Merchants processing 1 to 6 million transactions per year.

Level 3: Merchants handling 20,000 to 1 million transactions per year.

Level 4: Merchants handling fewer than 20,000 transactions per year.

While there are material differences to the overall enterprise depending upon the level at which credit card transactions are handled, this distinction is less important for the developer. For instance, a level 1 organization requires external auditing to ensure controls are in place. The audit must be performed by a Qualified Security Assessor (QSA) who is independent of the enterprise. Organizations at other PCI levels can complete a self-assessment questionnaire instead of using an external auditor. Regardless of whether these differences are material to the organization, the software developer within any PCI-compliant environment must still ensure that their software does not have vulnerabilities outside of PCI DSS requirements.

The burden of full compliance with the security software requirements drives some merchants to outsource their payment processing. This can be ideal for smaller shops, which would prefer their developers to concentrate on product information rather than financial compliance objectives.

Scope of PCI for Developers

The scope of PCI for developers is most easily understood when broken into three concepts:

1. Protect account holder data by persisting as little as possible.
2. Protect data in storage and transit.
3. Ensure information systems and software are not vulnerable to malicious interference.

Security controls accomplish these goals throughout the PCI DSS framework. The three points below summarize these themes.

Protecting Account Holder Data by Persisting It as Little as Possible

Account holder data comprises information about the cardholder and the account itself. Cardholder data includes the card's primary account number (PAN), the cardholder's name, and the card's expiration date. Account data is the "full track" (magnetic stripe) data, the card verification code, and the PIN or PIN block.

PCI compliance limits the time that account holder data can be kept on an information system and whether the data can be stored in a readable format. PAN storage is kept to an organizationally defined minimum unless the entity holding it cannot function otherwise—such as the issuer or storer. There is no exact definition of the minimum amount of information that can be stored; each organization must understand its own data use requirements.

When PAN is stored for any reason, it cannot be stored entirely in plain text. Likewise, storage of the cardholder's name, expiration date, and service code must be kept to a minimum. However, this information need not be encrypted. The sensitive authentication data—that is, everything on the magnetic stripe, the verification code (CVV or similar), and the account PIN or PIN block—must not be stored after authentication.

Protecting Data in Storage and Transit

Protection of data in storage and in transit can be achieved through encryption. However, strong encryption is one of many mechanisms to protect this data. PCI also allows for capturing and storing incomplete data, such as truncating information in storage.

Likewise, the same protections can be applied to data in transit. Encryption of data in transit is usually thought of over public networks and at the border of an organization's network. However, for best practice, data should be encrypted every time it moves between information systems. This is an advantageous way to handle PCI compliance because the systems that handle cardholder data can be an enclave within the enterprise's computer network; therefore, PCI compliance systems may communicate with non-PCI-compliant systems even though they are not going outside of the internal network.

Ensuring Information Systems and Software Are Not Vulnerable to Malicious Interference

Developers who configure and maintain their environments sometimes focus on making access and functionality easy for the end user, paying less than due attention to whether the ease is balanced with appropriate security. This is not limited only to system and network administrators. When these systems are used to write and test code for financial processing, they may become part of the cardholder data environment (CDE). The CDE is the target of many PCI DSS security requirements since it hosts and processes sensitive cardholder information. So, many of the protections needed for production processing may also apply to developer networks.

How should developers protect data to this standard? The answer lies in the requirements and sub-items of PCI DSS. Many of the specifics of software development security are found in PCI DSS Requirement 6.2.

PCI DSS Requirement 6.2: Developing and Maintaining Secure Custom Software

Software developers are particularly interested in Requirement 6 of PCI, the directive to develop and maintain secure systems and software. The subcomponents of Requirement 6 include network, information system, and software requirements. Item 6.2 is the meat for developers: bespoke and custom software are developed securely.

What Are the Items in 6.2?

• Item 6.2.1 requires software development based on industry standards or best practices in any DSS guidance. Information security issues are taken into account in every stage of development.
• Item 6.2.2 requires security-related training for software developers. Developers should be trained on software security relevant to their job and the languages in which they write software. It also requires that secure software design and secure coding techniques are part of a developer's training. Finally, developers must be trained annually on any security testing tools.
• Item 6.2.3 requires that custom software be reviewed before its release to production or customers to identify potential security issues. Code reviews should look for both existing and emerging software vulnerabilities. Code is to be developed according to the implemented security coding guidelines, and vulnerabilities are to be corrected before release. Code reviews are generally performed programmatically and with software designed for precisely that purpose. Not every software manufacturer can purchase or run these programs capably. The sub-bullet 6.2.3.1 addresses appropriate conduct if manual code reviews are necessary.
• Item 6.2.4 prioritizes finding widespread attacks and vulnerabilities in the security review. Injection attacks, weak cryptography, and cross-site scripting or request forgery are examples of these common high-risk vulnerabilities that security teams and developers should strive to eliminate in their code.

Beyond PCI DSS Item 6.2

Although 6.2 is the most applicable section of PCI DSS for developers, you should still carefully consider development requirements. Item 6.3.2 requires organizations to maintain an inventory of in-house software and documentation around its function and components. This single requirement introduces the need for a full-fledged development process to address behaviors around code creation and deployment.

Section 6.5 of PCI DSS covers protections for all of the environments surrounding the processing of credit card data, such as keeping real PANs only in CDE environments or ensuring that all CDE environments are fully documented and running only secure versions of code. If software development testing requires live PANS or other cardholder data, all security protection for the production environment is applied to the testing environment. Your development and testing environments become part of your CDE.

Conclusion

The responsibility for writing and testing software that enables secure storage, transport, and processing of financial data is a significant burden for both developers and the organizations that employ them. While a software developer may feel distant from the compliance requirements that his customers or enterprise must meet, PCI compliance will never be possible without the participation of software engineers.

If this is a concern for your organization, consider engaging a third-party financial processor like Rapyd for commercial transactions so that your developers can spend their effort improving your core product. Rapyd provides PCI-compliant processing for financial transactions such as payroll and one-to-many payout automation. The Rapyd Developer pages give example use cases and a catalog of developer documentation for ease of integration. If integration with a simple API call is your goal, Rapyd might just be the solution you need.