By Rob Chapman, Director of Security Architecture, Cybera

Whether you work at a large company or a small business, it isn't always a world of sunshine and rainbows when you're the primary PCI compliance person. On the regulatory side, you have to keep up with all kinds of guidelines, not to mention the various standards bodies. In fact, you almost have to be a PCI-DSS guidelines guru if you truly want to be successful.

From the company perspective, it can be a lonely job. Maybe you're the entire PCI team by yourself. But even if you're on a larger team, you likely get a lot of blank faces or glossy-eyed stares when you mention PCI compliance to anyone else in the company. The same might apply to some of the vendors you work with, many of whom somehow seem to regard PCI as a four-letter word.

At a minimum, being the PCI "expert" means carrying a lot of burden and responsibility. It also means feeling like you're on an island by yourself much of the time. But I hope you don't feel too isolated. There are a lot of us out here, and we tend to have a lot of shared experiences.

Dispelling the Myths around PCI Compliance

Going back to the types of responses you get when you mention PCI, odds are that you've heard a variety of strange questions, comments, and theories when it comes to PCI compliance. To many, it's some abstract concept that generally has to do with credit cards or customer payments.

Having worked with a ton of PCI folks across all types of industries and IT environments, I've probably heard enough weird stories to fill 20 blog posts. That's why I wanted to share a few insights I've gathered over the years, so consider these my tips on how to avoid some very basic but common PCI mistakes.

Mistake 1: Don't Assume Something Is Beyond the Scope of PCI Compliance

This is something you need to be careful with, especially around your vendors and their products. Just because a certain device or application doesn't process or transmit card data, that doesn't mean it's immune from PCI compliance. When it comes to PCI scope, any system that directly touches card information is unquestionably in scope. And if that system touches any larger connected systems, those systems are therefore in scope as well.

Sometimes you'll need to educate your vendors and co-workers so they understand that any object that communicates directly with a POS or similar card processing system is, by definition, in PCI scope. The same goes for whatever that object touches, as a connected system. If you're not sure about whether something is in scope, err on the side of caution and treat it like it is.

Mistake 2: Don't Assume Your CDE Is Accurately Defined

This potential mistake involves the fundamental objectives of PCI compliance and what we're trying to protect. In the PCI-DSS guidelines, the scope is intentionally narrowed to your payment card data environment (CDE). Properly defining your CDE is the foundation for everything else you do in regard to PCI compliance.

That's why you must clearly understand how credit card transactions are created and transmitted-all the way from the customer to the processing bank and back. Following the complete journey of the data will show you exactly what is in PCI scope and what isn't. When you can, simplify that journey to reduce your overall PCI scope (and better protect cardholder data).

Mistake 3: Don't Blur the Lines between PA-DSS and PCI-DSS

The third mistake to avoid is mixing up the PA-DSS (which certifies payment solutions) and the PCI-DSS (which determines how well you adhere to published standards). For example, there are certain cases where a system with PA-DSS certification will fail to meet PCI-DSS compliance standards.

This often involves vendor-related situations. For example, during a compliance review, a QSA might ask for verification that you've applied a certain security patch on the operating system for your POS system. But if you've had no control or insight into those system updates, what do you do? After all, vendors typically handle those types of baseline updates to the platform on which their system runs.

Even when the lines of system responsibility start to blur, however, you're ultimately on the hook. As a result, work closely with any vendors whose systems are in PCI scope and make sure they're certified for PA-DSS.

One Last Takeaway: Don't Outsource Ownership

If you can avoid those three common mistakes, you'll be well on your way to PCI compliance. That's important, because you're ultimately responsible for everything when it comes to compliance. Even if you decide to outsource certain elements of compliance, you can never outsource ownership. But don't worry-you're ready for it.

##

About the Author

As Director of Security Architecture at Cybera, Rob Chapman is responsible for the company's overall cybersecurity architecture and PCI compliance initiatives. During his career, he has focused on areas ranging from academic and enterprise technologies to big data and audiovisual systems. Chapman has a Masters in Educational Leadership and Instructional Technology from Tennessee Technological University. He currently resides in Columbia, TN.