Does the PCI DSS apply to me? Is vulnerability testing the same as penetration testing? Find these answers and many more within our frequently asked security questions page. Don't see what you're looking for? Ask Dara a question and have a professional answer you!
Q: My cardholder data is encrypted. How does this affect my PCI DSS scope?
A: Encryption does not render the environment out of scope for PCI DSS. The environment is still in scope for PCI DSS because cardholder data is present.
Q: Does a PoS back office server have to be in a secure location to be PCI compliant?
A: The location of a Point of Sale back office server that is part of a cardholder environment would be considered a sensitive area and would need to be secured. Based on the type of location, this could mean putting the back office server in the manager's office and locking the door to the office when the manager is not there.
Q: What is social engineering?
A: Social engineering is a non-technical way of gaining sensitive company info or installing malware by manipulating employees into breaking company procedures. Read more about various social engineering techniques in our article here.
Q: What is PCI DSS?
A: The Payment Card Industry Data Security Standard (PCI DSS) is the compliance standard that applies to all organizations that process, store, or transmit payment card data.
Q: Does the PCI DSS apply to me?
A: Regardless of size, all organizations that process, store, or transmit payment card data must comply with the PCI DSS.
Q: Which PCI compliance level does my company fall under?
A: Your PCI compliance level depends on your company's annual transaction volume. For example, Visa will assign a merchant as a Level 1 if there are over 6 million Visa transactions per year. Level 2 is assigned when the number of transactions are between 1 million to 6 million. Level 3 is assigned when the number of transactions are between 20,000 to 1 million. Level 4 is any merchant processing up to 20,000 Visa e-commerce transactions annually.
Q: I accept credit cards only by phone. Do I still need to comply with PCI DSS?
A: Yes. All organizations that process, store, or transmit payment card data must comply with the PCI DSS.
Q: I use a third-party processor. Do I still need to comply with PCI DSS?
A: Yes. Using a third-party processor may reduce the scope of your PCI compliance efforts, but you are still required to comply with PCI DSS.
Q: Which payment cards are in scope for PCI?
A: All debit, credit, and pre-paid cards that are issued by any of the five major card brands are in scope for PCI. The five major card brands are: American Express, Discover, JCB, MasterCard, and Visa.
Q: What are the consequences if my business is not PCI compliant?
A: Payment card brands may fine an acquiring bank up to $100,000 per month which will most likely be passed down to the merchant. It is wise for merchants to thoroughly read the merchant account agreement as financial penalties can be significant. In addition to fines, other consequences include card replacement costs, costly post-breach audits, and a tarnished reputation which could devastate a business.
Q: What is cardholder data?
A: The PCI Security Standards Council defines cardholder data as the full Primary Account Number, typically with the cardholder name, expiration date, and service code.
Q: What is a Merchant?
A: A Merchant is any entity that accepts payment cards branded with the five major card brands (American Express, Discover, JCB, MasterCard or Visa) as payment for goods or services.
Q: What is a Service Provider?
A: A Service Provider is any entity that stores, processes, or transmits cardholder data on behalf of another entity.
Q: What is a payment application?
A: A payment application is any software that is designed to handle payment card data. Anything from a Point of Sale (POS) system to a website's e-commerce shopping cart are payment applications.
Q: What is a payment gateway?
A: A payment gateway links the merchant to the bank or processor so that online payment card transactions are automated. Payment gateways route inputs from many different applications to the appropriate bank or processor.
Q: What is a vulnerability scan?
A: A vulnerability scan uses automated tools to check for vulnerabilities in a merchant's or service provider's systems. The scan is non-intrusive and is done remotely based on external-facing IP addresses provided by the merchant or service provider. Approved Scanning Vendors (ASVs) must conduct the scans in order to validate compliance with PCI.
Q: What is a penetration test?
A: A penetration test is an intrusive attack done by a security expert on a company's network in order to find exploitable security flaws. The test shows how deep into the network an ethical hacker can penetrate, giving the company valuable insight about the true security posture of the company. An internal penetration test is conducted from within the facility trying to gain unauthorized access, while an external penetration test is conducted outside the network trying to come in.
Q: What is Black Box and Grey Box testing?
A: Black Box and Grey Box testing are types of penetration tests. Black Box testing is conducted with no network information beyond the number of Internet accessible servers. IP-address ranges will be discovered and confirmed during testing. Grey Box testing is conducted with IP-address ranges provided by the customer prior to testing.
Q: What is the difference between a vulnerability scan and a penetration test?
A: A vulnerability scan is non-intrusive and uses automated tools to find vulnerabilities in a network. A penetration test is an intrusive attack done by a security expert to exploit vulnerabilities in a network.
Q: What is the PCI DSS required frequency for vulnerability scans and penetration tests?
A: PCI DSS requires that vulnerability scans be done at least once a quarter and penetration testing be done at least once a year. More frequent scans or tests may be required if significant changes occur, such as infrastructure or application upgrades or new system component installations.
Q: I received a survey from OCR. Does this mean I will be selected for a HIPAA audit?
A: Not necessarily. By receiving a survey, you have been included in a pool of eligible healthcare organizations or business associates that the OCR can randomly pick from to conduct HIPAA audits. It's a great time to ensure policies and procedures are in place and to seek a security risk assessment so that you find and address any gaps that a HIPAA audit would reveal.
Q: My software application was recently validated under an earlier version of PA-DSS. With the recent release of PA-DSS 3.1, do I need to have another complete validation done?
A: Not necessarily. The level of validation depends on which previous version of PA-DSS your application was validated against. You may be fine with a delta assessment, or you may be required to have a complete validation. Read more in our White Paper.
Q: I recently implemented changes to my ATM network. Am I required to conduct a TR-39 audit now or can I wait for my upcoming TR-39 renewal?
A: Any changes to your ATM network trigger a new TR-39 audit regardless of when your TR-39 renewal was previously scheduled.
Q: What is the deadline for compliance with the updated PCI DSS 3.1?
A: The deadline for compliance with PCI DSS 3.1 is June 30, 2016. However, there are a few exceptions which we outline in our White Paper.
Q: When is PA-DSS 3.1 in effect?
A: PA-DSS 3.1 came into effect June 1, 2015. However, there is a transition period for applications currently in the queue for validation. Read more in our White Paper.
Q: How does the update to PA-DSS 3.1 affect the annual revalidation process?
A: With PA-DSS 3.1 in effect, there will be an additional check asking the software vendor to attest that the application only uses or supports protocols that meet PCI SSC's definition of strong cryptography. Failure to make this attestation will move the application to the "Acceptable only for Pre-Existing" deployment listing on the PCI website. Read more in our White Paper.
Q: Why did the PCI Council issue the updated PCI DSS 3.1 and PA-DSS 3.1?
A: The PCI Council issued the updated PCI DSS 3.1 and PA-DSS 3.1 in response to recent exploits of vulnerabilities found in the widely used protocols SSL and early TLS. The updated standards remove these weak protocols as examples of strong cryptography.
Q: My payment application currently supports SSL. With PA-DSS 3.1 in effect, what action should I take now?
A: Now is the time to define steps to remove your application's support of SSL and early TLS. Work with your payment gateway (if applicable) to confirm your certification status if you remove support for the weaker protocols. Migrate to TLS 1.1+ if you depend on the weaker protocols to deliver updates or provide support for your deployed application. Read more in our White Paper.
Q: What are SSL and early TLS?
A: SSL and early TLS are widely used encryption protocols that have been in use for over 20 years. SSL/TLS encrypts a channel between two connections to ensure data reliability and privacy of the transmission. Several vulnerabilities have been found in these protocols that may allow attackers to extract data from these connections. With no known fixes to SSL, the PCI Council issued the updated PCI DSS 3.1 and PA-DSS 3.1 that removed SSL and early TLS as examples of strong cryptography. Read more in our White Paper.
Q: I'm a small merchant. Is my environment affected by issues with SSL/early TLS?
A: Yes. Regardless of size, all merchants are affected by issues with SSL/early TLS. It is essential that you remove SSL/early TLS from your cardholder data environment to protect your customer data. Work with a security expert now to plan and execute your migration to a secure alternative.
Q: According to PCI DSS 3.1, what is the deadline for "existing" implementation cases?
A: "Existing" implementation cases are those where there is a pre-existing dependency on SSL or early TLS. These types of implementations may continue using the weaker protocols until June 30, 2016. Read more in our White Paper.
Q: Are POI terminal deployments exempt from the PCI DSS 3.1 deadline?
A: Yes. POI (Point of Interaction) devices that support SSL and early TLS are not subject to the June 30, 2016 deadline imposed by PCI DSS 3.1. Read more in our White Paper.