PCI DSS version 2.0 must be adopted by all organizations with payment card data by 1 January 2011, and from 1 January 2012 all assessments must be against version 2.0 of the standard.
It specifies the 12 requirements for compliance, organized into six logically-related groups, which are called “control objectives”.
| Control Objectives |
PCI DSS Requirements |
| Build and Maintain a Secure Network |
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
|
| Protect Cardholder Data |
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
|
| Maintain a Vulnerability Management Program |
5. Use and regularly update anti-virus software on all systems commonly affected by malware
6. Develop and maintain secure systems and applications
|
| Implement Strong Access Control Measures |
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
|
| Regularly Monitor and Test Networks |
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
|
| Maintain an Information Security Policy |
12. Maintain a policy that addresses information security
|
Eligibility for PA-DSS Validation:
Applications won’t be considered for PA-DSS Validation, if the ANY of the following point is “TRUE”:
- Application is released in beta version.
- Application handle cardholder data, but the application itself does not facilitate authorization or settlement.
- Application facilitates authorization or settlement, but has no access to cardholder data or sensitive authentication data.
- Application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements.
- Application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions. For example:
- Reporting and CRM
- Rewards or fraud scoring
- The application developed in-house and only used by the company that developed the application.
- The application developed and sold to a single customer for the sole use of that customer.
- The application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components.
- The application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components.
- The application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own.
- The application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties.
- The application an operating system, database or platform; even one that may store, process, or transmit cardholder data.
- The application operates on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing.
For custom software development projects, “Requirement 6: Develop and maintain secure systems and applications” section is more applicable and needs to be taken care while doing the system design and in coding.