4 Myths of PCI Compliance

October 24, 2019 Security and Compliance, MOVEit

If your organization is finding it difficult to comply with PCI DSS, the Payment Card Industry Data Security Standard, it could be due to some of the misconceptions about the standard.

The standard is commonly referred to simply as PCI, and many people think it was developed by the federal government. But it was created in 2004 by Visa, MasterCard, Discover, American Express, and JCB.

PCI is enforced by these credit card networks as well as banks and merchant service providers. No merchant is subject to penalties for failing to maintain PCI compliance, but if a breach of credit card data occurs, an organization can be subject to major fines and lawsuits.

While working with many of our clients to help them achieve PCI compliance, we have discovered there’s a lot of misunderstanding about PCI due to several myths that keep circulating. In this article, we discuss four of the most common myths that many organizations believe to be true.

Myth #1 – PCI DSS compliance can be achieved using internal resources.

Every regulation has its own compliance nuances, including PCI. Unless you have an internal resource who has taken a company through compliance before, you will likely need to turn to an external resource who has helped other companies achieve compliance, preferably within your industry.

Achieving compliance depends heavily on detailed documentation of all of your security controls. You also need to know where all of your security gaps exist, where sensitive data is being exposed, and have plans in place for how you are going to close those gaps.

It can be easy for internal personnel to not realize the specific risks their company faces. Over time, they may also forget to consider how new threats might impact existing controls.

In many cases, internal IT teams "don’t know what they don’t know" and they are not able to map security controls to PCI DSS compliance requirements. But by working with an outside consultant, they can give you a fresh view and apply industry best practices so that you will know everything you need to know.

Myth #2 – If we are audited following a breach, we can handle the audit on our own.

If you were to be audited by the IRS, would you take them on all by yourself, or would you bring in your accountant? It’s a rhetorical question but the same holds true for a PCI compliance audit.

Just as you would work with an outside consultant to achieve compliance, you should do the same should you ever get audited following a breach. The auditors may steamroll you if you don’t know your security controls inside and out, or if you can’t demonstrate the progress you’ve been making in closing known security gaps.

And as is the case with the tax code, PCI DSS compliance requirements are open to interpretation. The extent to which your security controls have been implemented, and how well the controls protect data can be subjective opinions.

It’s best to have someone by your side who knows both your security controls and the PCI requirements inside-and-out. They can also recognize when an auditor may be incorrectly interpreting information or stretching the scope of the regulation too far. In these cases, you need someone who can push back.

Myth #3 – PCI compliance protects you from lawsuits

Should your organization be breached after achieving PCI compliance, you may still face potential lawsuits from multiple parties. This includes the credit card processor, the bank issuing the card, and any customers whose personal data was stolen.

Payment processors typically do not hold you responsible if their systems are determined to be the source of the breach. But proving which entity’s network was the source of a breach requires security forensic expertise—yet again a situation where it makes sense to call upon an outside consultant to help you. Any disagreements about the source of a breach will need to be settled by an independent, third-party auditor, who would then investigate the source of the breach.

Still, PCI compliance will give you a stronger legal defense. The courts will take a close look at the protective measures you deployed in advance and whether you were neglectful in overlooking any IT security risks you should have known about. By proving your compliance with the PCI standard, the chances are much better your security posture will be looked upon more favorably by the courts.

Myth #4 – Avoiding fines and bad publicity are the primary benefits of compliance

If your company’s credit card payment system suffers a breach, and regulators discover you are not in compliance with PCI, you may very well be subject to stiff penalties. Nobody wants to pay a fine, and it certainly doesn’t do any good if word gets out to the general public that you aren’t careful with customer credit card information.

But optimists who look at PCI compliance realize the main benefit comes from the opportunity it creates to build trust with customers and any business partners that share credit card transaction processing data. By achieving and marketing your PCI compliance, you are demonstrating just how serious you are about protecting credit card data.

That will make more customers and partners feel comfortable about doing business with you. And this has a direct impact on your revenue-generation potential.

For Your Compliance Toolbox

In addition to working with an outside consultant to help you achieve PCI compliance, you will likely need to deploy security tools that help you maintain compliance on a day-to-day basis. Many IT teams keep MOVEit from Ipswitch in their toolbox to assure secure file transfers.

You can download this whitepaper to learn how MOVEit helps you implement the seven key security controls required of file transfer operations in order to help assist in compliance with PCI as well as HIPAA.

Greg Mooney

Greg is a technologist and data geek with over 10 years in tech. He has worked in a variety of industries as an IT manager and software tester. Greg is an avid writer on everything IT related, from cyber security to troubleshooting.

Read next Why Email and EFSS are Unsecure