Welcome to PCI Compliance Guide.
Click on the links below to find answers to frequently asked questions.
Q1: What is PCI?
A: The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that ALL companies that accept, process, store or transmit credit card information maintain a secure environment.
The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with a focus on improving payment account security throughout the transaction process. The PCI DSS is administered and managed by the PCI SSC (www.pcisecuritystandards.org), an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB.). It is important to note that the payment brands and acquirers are responsible for enforcing compliance, not the PCI council. A copy of the PCI DSS is available here.
Q2: To whom does the PCI DSS apply?
A: The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data.
Q3: Where can I find the PCI Data Security Standard (PCI DSS)?
A: The current PCI DSS documents can be found on the PCI Security Standards Council website.
Q4: What are the PCI compliance ‘levels’ and how are they determined?
A: All merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period. Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit and prepaid) from a merchant Doing Business As (‘DBA’). In cases where a merchant corporation has more than one DBA, Visa acquirers must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level. If data is not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, acquirers will continue to consider the DBA’s individual transaction volume to determine the validation level.
Merchant levels as defined by Visa:
|1||Any merchant — regardless of acceptance channel — processing over 6M Visa transactions per year. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.|
|2||Any merchant — regardless of acceptance channel — processing 1M to 6M Visa transactions per year.|
|3||Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.|
|4||Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants — regardless of acceptance channel — processing up to 1M Visa transactions per year.|
* Any merchant that has suffered a breach that resulted in an account data compromise may be escalated to a higher validation level.
Q5: What does a small-to-medium sized business (Level 4 merchant) have to do in order to satisfy the PCI DSS requirements?
A: To satisfy the requirements of PCI, a merchant must complete the following steps:
- Determine which self-assessment Questionnaire (SAQ) your business should use to validate compliance. See the chart below to help you select. (Click chart to enlarge.)
- Complete the self-assessment Questionnaire according to the instructions it contains.
- Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV). Note scanning does not apply to all merchants. It is required for SAQ A-EP, SAQ B-IP, SAQ C, SAQ D-Merchant and SAQ D-Service Provider.
- Complete the relevant Attestation of compliance in its entirety (located in the SAQ tool).
- Submit the SAQ, evidence of a passing scan (if applicable), and the Attestation of compliance, along with any other requested documentation, to your acquirer.
Q6: How does taking credit cards by phone work with PCI?
A: The following post, “How Does Taking Credit Cards by Phone Work with PCI?” explains your PCI compliance responsibilities when taking credit card information over the phone (e.g., in a call center). Note that while this post was published in 2014, it is still relevant with the current version of the PCI DSS.
Q7: If I only accept credit cards over the phone, does PCI DSS still apply to me?
A: Yes. All business that store, process or transmit payment cardholder data must be PCI Compliant.
Q8: Do organizations using third-party processors have to be PCI DSS compliant?
A: Yes. Merely using a third-party company does not exclude a company from PCI DSS compliance. It may cut down on their risk exposure and consequently reduce the effort to validate compliance. However, it does not mean they can ignore the PCI DSS.
Q9: My business has multiple locations, is each location required to validate PCI compliance?
A: If your business locations process under the same Tax ID, then typically you are only required to validate once annually for all locations. And, submit quarterly passing network scans by an PCI SSC Approved Scanning Vendor (ASV) for each location, if applicable.
Q10: We only do e-commerce. Which SAQ should we use?
A: It depends on how your shopping cart is set up. See PCI SAQ 3.1: E-Commerce Options Explained.
Q11: My company doesn’t store credit card data so PCI compliance doesn’t apply to us, right?
A: If you accept credit or debit cards as a form of payment, then PCI compliance applies to you. The storage of card data is risky, so if you don’t store card data, then becoming secure and compliant may be easier.
Q12: Are debit card transactions in scope for PCI?
A: 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.
Q13: Am I PCI compliant if I have an SSL certificate?
A: No. SSL certificates do not secure a web server from malicious attacks or intrusions. High assurance SSL certificates provide the first tier of customer security and reassurance such as the below, but there are other steps to achieve PCI compliance. See Question “What does a small-to-medium sized business (Level 4 merchant) have to do in order to satisfy the PCI requirements?”
- A secure connection between the customer’s browser and the web server
- Validation that the website operators are a legitimate, legally accountable organization
Q14: My company wants to store credit card data. What methods can we use?
A: Most merchants that need to store credit card data are doing it for recurring billing. The best way to store credit card data for recurring billing is by utilizing a third party credit card vault and tokenization provider. By utilizing a vault, the card data is removed from your possession and you are given back a “token” that can be used for the purpose of recurring billing. By using a third party, you move the risk of storing card data to someone who specializes in doing that and has all of the security controls in place to keep the card data safe.
If you need to store the card data yourself, your bar for self-assessment is very high and you may need to have a QSA (Qualified Security Assessor) come onsite and perform an audit to ensure that you have all of the controls in place necessary to meet the PCI DSS specifications.
See related blog post, “Can We Securely Store Card Data for Recurring Billing?”
Q15: What are the penalties for non-compliance?
A: The payment brands may, at their discretion, fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations. The banks will most likely pass this fine along until it eventually hits the merchant. Furthermore, the bank will also most likely either terminate your relationship or increase transaction fees. Penalties are not openly discussed nor widely publicized, but they can be catastrophic to a small business. It is important to be familiar with your merchant account agreement, which should outline your exposure.
Read more about the penalties for non-compliance in our blog post, “How Can Your PCI Compliance Efforts Ultimately Save Your Business Money?”
Q16: What is defined as ‘cardholder data’?
A: The PCI Security Standards Council (SSC) defines ‘cardholder data’ as the full Primary Account Number (PAN) or the full PAN along with any of the following elements:
- Cardholder name
- Expiration date
- Service code
Sensitive Authentication Data, which must also be protected, includes full magnetic stripe data, CAV2, CVC2, CVV2, CID, PINs, PIN blocks and more.
Q17: What is the definition of ‘merchant’?
A: For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers. Source: PCI SSC
Q18: What constitutes a Service Provider?
A: The PCI SSC defines a Service Provider this way:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data.” (Source: www.pcisecuritystandards.org)
The “merchant as a service provider” role is further specified by the PCI SSC as “a merchant that accepts payment cards as payment for goods and/or services…if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers.” Learn more about how to achieve compliance as a Service Provider. See our blog post, “PCI Compliance and the Service Provider.”
Q19: What constitutes a payment application?
A: What constitutes a payment application as it relates to PCI compliance? 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.
Q20: What is a payment gateway?
A: Payment gateways connect a merchant to the bank or processor that is acting as the front-end connection to the card brands. They are called gateways because they take many inputs from a variety of different applications and route those inputs to the appropriate bank or processor. Gateways communicate with the bank or processor using dial-up connections, web-based connections or privately held leased lines.
Q21: What is PA-DSS?
A: PA-DSS refers to Payment Application Data Security Standard maintained by the PCI Security Standards Council (SSC) to address the critical issue of payment application security. The requirements within the PA-DSS are designed to ensure that vendors provide products which support merchants’ efforts to maintain PCI DSS compliance and eliminate the storage of sensitive cardholder data.
The PCI SSC administers the program to validate payment applications’ compliance against the PA-DSS, and publishes and maintains a list of PA-DSS validated applications. See PCI Security Standards for more information. Also see our blog post on the critical difference between the PCI DSS and PA-DSS here.
Q22: Can the full credit card number be printed on the consumer’s copy of the receipt?
A: PCI DSS requirement 3.3 states “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).” While the requirement does not prohibit printing of the full card number or expiry date on receipts (either the merchant copy or the consumer copy), please note that PCI DSS does not override any other laws that legislate what can be printed on receipts (such as the U.S. Fair and Accurate Credit Transactions Act (FACTA) or any other applicable laws).
See the italicized note under PCI DSS requirement 3.3 “Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS) receipts. Any paper receipts stored by merchants must adhere to the PCI DSS, especially requirement 9 regarding physical security”. Source: PCI SSC
Q23: Do I need vulnerability scanning to validate compliance?
A: If you qualify for certain self-assessment Questionnaires (SAQs) or you electronically store cardholder data post authorization, then a quarterly scan by a PCI SSC Approved Scanning Vendor (ASV) is required to maintain compliance. If you qualify for any of the following SAQs under version 3.x of the PCI DSS, then you are required to have a passing ASV scan:
- SAQ A-EP
- SAQ B-IP
- SAQ C
- SAQ D-Merchant
- SAQ D-Service Provider
Q24: What is a vulnerability scan?
A: A vulnerability 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 identifies vulnerabilities in operating systems, services and devices that could be used by hackers to target the company’s private network. As provided by an Approved Scanning Vendors (ASV’s) such as ControlScan, the scan does not require the merchant or service provider to install any software on their systems, and no denial-of-service attacks will be performed. Learn more about vulnerability scans here.
Q25: How often do I have to have a vulnerability scan?
A: Every 90 days/once per quarter, those who fit the above criteria 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) such as ControlScan.
See related blog post, “Internal vs. External Vulnerability Scans: Why You Need Both.”
Q26: What if my business refuses to cooperate?
A: PCI is not, in itself, a law. The standard was created by the major card brands 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.
For a little upfront effort and cost to comply with the PCI DSS, you greatly help reduce your risk from facing these extremely unpleasant and costly consequences. Learn how ControlScan helps simplify PCI DSS.
Q27: If I’m running a business from my home, am I a serious target for hackers?
A: Yes. Home users are arguably the most vulnerable simply because they are usually not well protected. Adopting a ‘path of least resistance’ model, intruders will often zero—in on home users—often exploiting their always-on broadband connections and typical home use programs such as chat, Internet games and P2P file sharing applications. ControlScan’s scanning service allows home users and network administrators alike to identify and fix any security vulnerabilities on their desktop or laptop computers.
See related blog post, “5 Best Practices for Securing Your Small Biz.”
Q28: What should I do if I’m compromised?
A: While many payment card data breaches are easily preventable, they can and do still happen to businesses of all sizes.
If your small- or mid-sized business has discovered it’s been breached, there are many good resources to help you with next steps. We recommend the following:
- Department of Justice, Best Practices for Victim Response and Reporting of Cyber Incidents
- PCI Council, Responding to a Data Breach – A How-to Guide for Incident Management
- Electronic Transactions Association (ETA), Data Breach Response: A Nine-Step Guide for Smaller Merchants
Q29: Do states have laws requiring data breach notifications to the affected parties?
A: Absolutely. California is the catalyst for reporting data breaches to affected parties. The state implemented breach notification law in 2003 and there are now over 38 states that have similar laws in place.
Also, as of Jan 4, 2016, NCSL.org reports: Forty-seven states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands have enacted legislation requiring private, governmental or educational entities to notify individuals of security breaches of information involving personally identifiable information.