PCI Compliance Overview

Version 2.0 of PCI-DSS didn’t arrive quietly. It came with a hard deadline: all organizations handling payment card data had to adopt it by January 1, 2011, and from January 1, 2012 onward every assessment has been conducted against that version. The deadline mattered because standards without enforcement dates tend to accumulate dust.

The 12 PCI-DSS requirements

The standard organizes its requirements into six control objectives. These are reference material—the kind of thing you need to be able to scan and locate quickly:

Build and maintain a secure network

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Protect cardholder data

• Requirement 3: Protect stored cardholder data.
• Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Maintain a vulnerability management program

• Requirement 5: Use and regularly update antivirus software or programs.
• Requirement 6: Develop and maintain secure systems and applications.

Implement strong access control measures

• Requirement 7: Restrict access to cardholder data on a need-to-know basis.
• Requirement 8: Assign a unique ID to each person with computer access.
• Requirement 9: Restrict physical access to cardholder data.

Regularly monitor and test networks

• Requirement 10: Track and monitor all access to network resources and cardholder data.
• Requirement 11: Regularly test security systems and processes.

Maintain an information security policy

• Requirement 12: Maintain a policy that addresses information security for all personnel.

Relevance to software development

Requirement 6—“Develop and maintain secure systems and applications”—is where custom software development teams live within this framework. It applies during system design and throughout the coding phase, setting the expectation that security isn’t bolted on at the end. We’ll spend most of this series unpacking what Requirement 6 actually demands in practice.

When PA-DSS validation does not apply

Not every payment-related application is a candidate for PA-DSS validation. The following 13 scenarios describe applications that are ineligible:

1. Beta or pre-release versions of an application.
2. Applications that handle cardholder data but do not facilitate authorization or settlement.
3. Applications that facilitate authorization or settlement but have no access to cardholder data.
4. Applications requiring source code customization that affects PA-DSS requirements.
5. Back-office systems that store cardholder data but do not facilitate transactions.
6. In-house applications used only internally within an organization.
7. Applications developed exclusively for a single customer.
8. Shared libraries that are not bundled with their supporting components.
9. Shared libraries that are not bundled with supporting software.
10. Single modules that cannot independently facilitate authorization or settlement.
11. SaaS offerings that are not sold, distributed, or licensed to third parties.
12. Operating systems, databases, or platforms (as opposed to payment applications).
13. Applications running on consumer handheld devices not dedicated solely to payment acceptance.

If your application falls into one of these categories, PA-DSS certification is not the right path—but that doesn’t mean compliance disappears. It means the compliance obligation shifts to a different mechanism, and the next question is figuring out which one applies to your situation.