As a PCI QSA, and having maintained security credentials allowing me to perform audits for various IT regulatory compliance initiatives, I have found myself engaged in multiple conversations with organizations who are buying into the commonly believed myths about PCI DSS compliance.
PCI DSS is certainly no exception to the rule when it comes to regulatory compliance standards being misunderstood. While (in my opinion) the PCI Security Standards Council (SSC) does pretty well at providing standards and supporting materials to enhance payment card data security for merchants, service providers, and acquirers, we are contacted almost weekly by organizations confused on what they are classified as, and what their potential requirements are.
In addition, we are brought in quite frequently to either confirm and/or deny organizational myths about whether PCI DSS applies to them, or if “skimping” on requirements could lead them to potential security breaches. With that in mind, I have compiled my personal top six list of commonly believed myths about PCI DSS.
Top 6 List of Commonly Believed Myths PCI DSS
#6 Our Company is compliant with PCI DSS because we utilize PCI DSS compliant applications. – First of all, applications and/or systems cannot be considered PCI DSS compliant, only organizations can achieve compliance. The proper terminology is Payment Application Data Security Standard compliant.
Secondly, utilizing a PA DSS compliant application does not guarantee and organization to be PCI DSS compliant, rather it is simply demonstrating support of PCI DSS requirements and ensuring the application(s) is managed in accordance with PCI DSS guidelines. Even if the application is PA DSS compliant during testing the application still needs to be installed in accordance with the vendor’s instructions to maintain the compliance. PCI QSA’s generally still include the application in the scope of the PCI DSS validation.
#5 If our organization experiences a security breach, the certificate of compliance will protect us against penalties, fines, and other legal ramifications.- While I have heard many QSA’s make this statement to customers, the reality is that is not necessarily true. Once a security breach has been recorded many “after-action” type activities begin. One of the main exercises is that of a forensic investigation. With this investigation it will be further determined how the breach occurred and in the end how it could have been prevented. Once the investigation is completed, these forensic reports will be provided to the card brands and they will actually make a final determination on whether or not your company is liable for the breach of credit card data. In reality, the certificate of compliance you had prior to the security breach is of little use during the forensic process.
#4 If we outsource our card processing we will be PCI DSS compliant. – Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI DSS standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.
#3 Our third-party contract calls out PCI DSS compliance from our prime; however, we are still delaying to gauge the effort and they have not made it an issue. Our scope of credit card data is small as a service provider. – Delaying.The fact of the matter is your organization is engaged in storing, processing, and/or transmitting credit card data. The liability should compel you to take action to mitigate the risk to your company’s reputation and the financial well-being of the company you work for. Our recommendation would be to start off with a PCI DSS risk assessment and initial PCI QSA review. The PCI DSS risk assessment and review will identify your potential threats and PCI DSS weaknesses that can later be used in a prioritized approach to implementing PCI DSS. Delay tactics with contracts in place create bigger relationship problems and could be the downfall of your organizations reputation with customers and business partners.
#2 Our organization is too small to be required to maintain PCI DSS compliance. – PCI is applicable to any size of business. If you take even 1 credit card a year, you need to be PCI compliant. Business can only flourish if proper infrastructure is established such as Human Resources, Marketing, Customer Service, etc. In the same way PCI Compliance is something that should be setup and considered as a key ingredient of your business infrastructure as may likely be essential in how you gather payments and process customer information.
#1 We are PCI DSS compliant, therefore we are secure! – This has to be the number one misconception of any regulatory compliance requirement, and it simply is not true! In fact, I cannot tell you the number of times we have had security engineers discover significant security flaws with “compliant” customers. In addition, even the PCI SSC recognizes this to be a fact, and have documented it in their own “Myths of PCI Compliance” as follows “successful completion of system scan or assessment for PCI is but a snapshot in time. Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.”
The above list is only a partial capture of some of the most common myths we hear from customers and comrades in the field. PCI DSS is not a safe harbor against potential credit card data breaches, nor is it a requirement reserved for only large companies. The fact with PCI DSS is that it is a regulatory compliance standard that when implemented and maintained correctly can improve organizational security posture, provide customer(s) confidence your protection their credit card data, reduce financial risks, and reduce threats that could cause a breach of cardholder data.