PCI DSS Versus PA-DSS FAQs
This topic reviews the PCI DSS and PA-DSS standards and addresses a series of questions about these standards in an FAQ format.
This topic addresses the following questions:
- What are PCI DSS and PA-DSS Standards?
- Do I (merchant) need to be PCI DSS compliant?
- Do I need to be PCI DSS compliant, if I am using a PA-DSS compliant application?
- Does it make any difference if the payment application used by us (merchant) is PA-DSS compliant?
- What is the link between PCI DSS and PA-DSS requirements?
What are PCI DSS and PA-DSS Standards?
Payment Card Industry Security Standards Council (PCI SSC) has defined Payment Card Industry Data Security Standards (PCI DSS) for Merchants, and Payment Application Data Security Standards (PA-DSS) for software vendors that develop payment application. Both these standards are part of the same eco system that ensures the safe handling of payment information.
Do I (merchant) need to be PCI DSS compliant?
Yes, every merchant needs to be compliant with the PCI DSS v3.0, regardless of the transaction volume. Though, the validation requirements are different based on the transaction volume (defined by the Merchant Bank). Visa has listed this table to map the requirements for PCI validation with the transaction volume:
Level | Merchant Criteria | Validation Requirements |
1 | Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region | Annual Report on Compliance (ROC) by Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) if signed by officer of the company Quarterly network scan by Approved Scan Vendor (ASV) Attestation of Compliance Form |
2 | Merchants processing 1 million to 6 million Visa transactions annually (all channels) | Annual Self-Assessment Questionnaire (SAQ) Quarterly network scan by ASV Attestation of Compliance Form |
3 | Merchants processing 20,000 to 1 million Visa e-commerce transactions annually | Annual SAQ Quarterly network scan by ASV Attestation of Compliance Form |
4 | Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually | Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by merchant bank |
Source: http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp
Do I need to be PCI DSS compliant, if I am using a PA-DSS compliant application?
Yes, using a payment application that is PA-DSS compliant does not mean that a merchant is also PCI-DSS compliant. Though it does make the process of becoming PCI DSS compliant much easier. Since the payment applications are developed for merchants to secure customer's cardholder data, these applications are developed based on the PCI-DSS requirements. The best way to minimize and prevent the potential risks for security breaching is the implementation of a PA-DSS application within a PCI-DSS compliance environment.
Does it make any difference if the payment application used by us (merchant) is PA-DSS compliant?
Yes, because PA-DSS Standards were derived out of PCI DSS Standards to ensure that software vendors provide payment applications that have all the features that can enable the merchants to have a PCI DSS compliant solution. So the audit process becomes much easier as many of the PCI DSS requirements are directly met while others are partially met, by just having a PA-DSS compliant payment application. Though the merchant will have to adhere to some requirements that are not related to payment application, such as business process requirements.
What is the link between PCI DSS and PA-DSS requirements?
Here is the mapping of PCI DSS and PA-DSS requirements:
PCI Goal | PA-DSS Section | PCI-DSS Section |
Build and Maintain a Secure Network | 6. Protect wireless transmissions 8. Facilitate secure network implementation | 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 | 1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data 2. Protect stored cardholder data 9. Cardholder data must never be stored on a server connected to the Internet 11. Encrypt sensitive traffic over public networks | 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks |
Maintain a Vulnerability Management Program | 5. Develop secure payment applications 7. Test payment applications to address vulnerabilities 10. Facilitate secure remote access to payment application 12. Encrypt all non-console administrative access | 5. Protect all systems against malware and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications |
Implement Strong Access Control Measures | 3. Provide secure authentication features | 7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data |
Regularly Monitor and Test Networks | 4. Log payment application activity | 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes |
Maintain an Information Security Policy | 13. Maintain a PA-DSS Implementation Guide for customers, reseller, and integrators 14. Maintain instructional documentation and training programs for customers, resellers, and integrators | 12. Maintain a policy that addresses information security for all personnel |
Copyright © 2014-2017 Aptify - Confidential and Proprietary