PCI DSS Compliance Frequently Asked Questions (FAQs)
PCI DSS Compliance FAQ page, commonly referred to as frequently asked questions page. Populated with excellent Payment Card Industry Data Security Standard frequently asked questions with answers.
What is PCI DSS and some of its major concerns for Merchants and Service Providers?
PCI DSS stands for the Payment Card Industry Data Security Standard, a multi-layer security standard developed by the major payment brands, with the Payment Card Industry (PCI) Security Standards Council (SSC) in Wakefield, MA having oversight of the management and continued development and enhancement of the PCI DSS framework.
Merchants and Service Providers need to understand that the PCI DSS framework has been readily accepted and adopted by all major payment brands, is a comprehensive and in-depth compliance standard.
Who is the PCI SSC and their role in PCI DSS compliance?
PCI SSC stands for the Payment Card Industry Security Standards Council, an independent industry standards body providing oversight, guidance, and supporting initiatives for the Payment Card Security Standards. Though most organizations may be aware of the PCI DSS frameworks, the PCI SSC also provides the same guidance for other Payment Card Security Standards, such as the PA-DSS, PED, along with guidelines to use for Approved Scanning Vendors (ASV) and Qualified Security Assessors (QSA).
Do the Payment Card Brands have any additional requirements or specific information available for PCI DSS?
Each payment card brand (Visa, Master Card, American Express, Discover, and JCB International) has a website discussing their data security rules, initiatives, and overall compliance requirements. These compliance specifics can be found by following the below links:
American Express (AMEX): Data Security Opening Policy (DSOP)
JCB International: Data Security Program
MasterCard: Site Data Protection (SDP)
What is the PCI DSS Self-Assessment Questionnaire?
The PCI Data Security Standard Self-Assessment Questionnaire is a validation tool intended to assist merchants and service providers who are permitted by the payment brands to self-evaluate their compliance with the Payment Card Industry Data Security Standard (PCI DSS).
Which Self-Assessment Questionnaire (SAQ) should we complete?
You should reference the PCI DSS SAQ Instructions and Guidelines document for information about the different SAQs and the types of environments that each SAQ is intended for. Merchants should also consult with their acquirer (merchant bank) or payment brand to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment.
Is encrypted cardholder data in scope for PCI DSS?
Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable in order to meet PCI DSS Requirement 3.4. Because encrypted data can be decrypted with the right cryptographic key, encrypted cardholder data remains in scope for PCI DSS.
Is pre-authorization account data in scope for PCI DSS?
Yes, PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted, irrespective of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but such data would need to be protected according to PCI DSS. Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.
Is Voice-Over-IP (VoIP) in scope for PCI DSS?
PCI DSS requirements apply wherever account data is stored, processed, or transmitted. While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.
What are the fines and penalties assessed to companies for non-compliance with PCI DSS?
Any fines and/or penalties associated with non-compliance with the PCI DSS and/or confirmed security breaches are defined by each of the payment card brands. For specific information regarding these penalties we suggest contacting the individual payment card brands.
What is the definition of “remote access”?
PCI DSS requirement 8.3 is intended to apply to users that have remote access to the network, where that remote access could lead to access to the cardholder data environment. In this context, remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for the cardholder data environment. In this context, remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for purposes of this requirement. If the corporate network has appropriate segmentation such that remote users cannot access the cardholder data environment, two-factor authentication during remote access to the corporate network is not required by PCI DSS. However, two-factor authentication is required for any remote access to the cardholder data environment, and is recommended for remote access to the corporate network.
How do I determine whether my business would be required to conduct an independent assessment or a self-assessment?
Merchants should contact the acquiring financial institutions with whom they have merchant agreements (for example, their merchant bank) to determine whether they must validate compliance and the specific requirements for performing and reporting their compliance validation. Service providers should contact the individual payment brands for further information.
When do I have to start using PCI DSS 3.0?
PCI DSS version 3.0 is effective from January 1st, 2014, and all entities should be working towards compliance with the latest PCI standards as soon as they are able. To ensure entities have enough time to transition without falling out of compliance, version 2.0 will remain active until December 31st, 2014. After this date, all compliance validations must be to PCI DSS version 3.0.
Can my organization combine sections from PCI DSS version 2.0 and 3.0?
When validating compliance, either through a Report on Compliance (ROC) or a self-assessment questionnaire (SAQ), requirements should not be ‘combined’ from the two versions of the standard – validation will be to either version 2.0 or version 3.0 in its entirety.
When can we start using version 3.0 of the SAQs?
Version 3 of the self-assessment questionnaires (SAQs) are used to validate compliance against PCI DSS version 3, which is effective from January 1st, 2014. The PCI SSC strongly encourages all organizations to transition to version 3 of the PCI DSS and validate using the accompanying SAQs as soon as possible. Merchants should consult with their acquirer (merchant bank) or payment brand, as applicable, to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment.
Are debit card transactions in scope for PCI DSS?
In-scope cards include any debit, credit, and pre-paid cards branded with one of the five card association/brand logos that participate in the PCI SSC – American Express, Discover, JCB, MasterCard, and Visa International.
What is the definition of “cardholder data”?
Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security number, etc. All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data.
What constitutes a “payment application”?
The term payment application has a very broad meaning in PCI. A payment application is anything that stores, processes, or transmits card data electronically. This means that anything from a Point of Sale System (e.g., Verifone swipe terminals, ALOHA terminals, etc.) in a restaurant to a Website e-commerce shopping cart (e.g., CreLoaded, osCommerce, etc) are all classified as payment applications. Therefore any piece of software that has been designed to touch credit card data is considered a payment application.
Does my organization require vulnerability scanning to validate PCI DSS compliance?
If you electronically store cardholder data, post authorization, and/or if your processing systems have any internet connectivity, a quarterly scan by a PCI SSC Approved Scanning Vendor (ASV) is required.
What is a network security scan?
A network security scan involves an automated tool that checks a merchant or service provider’s systems for vulnerabilities. The tool will conduct a non-intrusive scan to remotely review networks and Web applications based on the external-facing Internet protocol (IP) addresses provided by the merchant or service provider. The scan will identify vulnerabilities in operating systems, services, and devices that could be used by hackers to target the company’s private network.
How often do I have to scan?
Every 90 days/once per quarter you are required to submit a passing scan. Merchants and service providers should submit compliance documentation (successful scan reports) according to the timetable determined by their acquirer. Scans must be conducted by a PCI SSC Approved Scanning Vendor (ASV).
What if a “merchant” refuses to cooperate with PCI DSS requirements?
PCI is not, in itself, a law. The standard was created by the major card brands such as Visa, MasterCard, Discover, AMEX, and JCB. At their acquirers/service providers discretion, merchants that do not comply with PCI DSS may be subject to fines, card replacement costs, costly forensic audits, brand damage, etc., should a breach event occur.
What should my organization do if we are ever exposed to a breach or become compromised?
We recommend following the procedures outlined in Visa’s” What to Do If Compromised
Visa Fraud Control and Investigations Procedures” document: https://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf
Do individual states have laws requiring data breach notifications?
Yes. States such as California have implemented breach notification(s) law(s) in 2003 and there are now over 38 states that have similar laws in place. See https://www.privacyrights.org for more detail on state laws.