EXPERT ADVICE
Yes, PCI Applies to You

Folks in IT tend to ask a lot of questions. We're a curious breed by nature. In fact, we have to be. Change comes about so quickly in our industry, technology moves so fast, and our businesses adapt so fluidly that we have to ask questions just to keep up. Some might even say that a healthy curiosity is the hallmark of a successful IT professional -- and I wouldn't disagree.

So when I'm in the field and an IT professional has a question about some specific technology, about some new regulation, or about their information security program, it's not usually cause for comment. But when all those folks are asking the same question? Well, that's a different story. That's what I've been noticing recently. Many of the IT pros that I've encountered in the field, regardless of industry and size of the organization, are all asking the same question: "Does PCI (that is, the Payment Card Industry Data Security Standard) apply to me?" And the answer, in almost every case, is "yes."

So, even though I usually try to use this forum as a vehicle to provide general rather than specific guidance to IT pros, please bear with me as we get a little bit more granular this time around. Since we all seem to be asking the same question, hopefully addressing it head-on can give you some insight as to whether you need to comply, what steps you can take to get started if you do, and maybe put the question to bed in your organization once and for all.

Step One: Who Has to Comply?

Historically, there's been some confusion on the part of organizations about whether they need to comply with the PCI DSS. We may have heard about the DSS -- the standard that outlines specific technical requirements for safeguarding cardholder information -- but we may be unsure about whether the standard applies. After all, for many of us, our core business is not retail , we don't operate an e-commerce site, we don't "sell stuff," so why would we need to comply with a standard that's mostly targeted toward the retail community? Does it apply, for example, to educational institutions, to government, to healthcare, to manufacturing, or to telecom? Why would it?

The short answer, for most of us, is that we have to comply if we process credit card transactions. The reason: Most of us (if we look hard enough) are processing plastic somewhere in our organization. The PCI Standards Council (the organization chartered with setting the standard) sums it up succinctly: "The PCI DSS applies to any entity that stores, processes, and/or transmits cardholder data. ... If your business accepts or processes payment cards, it must comply with the PCI DSS."

The rub here is that most of us process credit card transactions somewhere in our business -- even if it's only a few transactions, just a tiny blip on your corporate radar. This extends beyond just the retail sector to pretty much all industries and all sectors. Take, for example, healthcare. If you're a hospital or medical center, keep in mind you usually have on-site gift shops, pharmacies and cafeterias. Education? How about your cashier (e.g. for tuition payments) and your bookstore(s). Government? How about for payment of fines -- even the cashiers at local municipal buildings (most of them, anyway) take plastic for things like vehicle registration and permits. Visa doesn't say "everywhere you want to be" for nothing.

The first step to putting the question to rest in your organization is to do a comprehensive introspection of your business. Are you processing credit card transactions? If so, where -- and how? If you dig, you're very likely to find that you are processing them, and with just a bit of legwork, you can come up with a pretty thorough list of where that is.

Step Two: So We Have to Comply - What Does That Mean?

Assuming that you've gone through the process of finding out whether or not you process credit cards, the second step (for those that do process them) is to determine what the scope of their compliance efforts need to be. You need to determine where you process credit cards, and what parts of your infrastructure are connected to those systems, because those are the areas that are in scope for compliance.

In other words, the standard applies to the areas of the organization that intersect the payment "lifecycle" -- your "cardholder data environment." These are the areas where perform the card processing, where you store the cardholder data, and those systems, facilities, or other resources that are connected to them.

For example, if you have systems that are physically and/or logically segregated from the payment processing environment, those systems are out of scope of the standard. Physical security procedures would not apply for facilities that don't process data and that don't contain systems that are connected to the cardholder data environment. But keep in mind that if you haven't done some planning around this already, you may be surprised to discover that much of your environment is part of you cardholder data environment.

As a hypothetical example, if you are an educational institution and you process credit cards via the bookstore, that bookstore is in scope for DSS compliance (because that's where you store, process, or transmit credit card data). If you use a network-based point of sale in that bookstore, any system that is on the same network (and not separated by a firewall, router ACLs, or other mechanism) is also in scope because it's connected to those systems.

So, chances are, much of your network is in scope -- unless you've put some thought into this already and have taken specific steps to segregate the systems in the cardholder data environment. A good practice here is to catalog and document those areas where you do process the data and to take a hard, honest look at whether you segregate those systems or not. If you don't, maybe now is a good time to do some planning about how to further insulate them from the rest of the network.

Step Three: Compliance Validation ... or Not

Lastly, once you have an understanding of the scope of the cardholder data environment and how far it does (or doesn't) extend, the next step is to determine what your individual reporting and validation requirements are, since not only must you comply with the standard, but you may also have validation and reporting requirements. The specifics of what you have to do for this requirement will vary by card brand, the number of transactions that you process and your role in the payment lifecycle. They may also vary according to any specific requirements your acquiring bank (the bank that handles your transactions) may have.

Specifically, if you're on the smaller side, chances are good that you'll just need to complete a self-assessment questionnaire; if you're on the larger side, you may need to go through a formal external assessment process -- either way, you should consult the specific requirements for your card brand to determine what your reporting requirements are. You may also wish to contact your acquirer to determine what other requirements over and above what's required by the card brand that they may have. From here, you can put together a plan to make sure that you do what needs to be done.

At the end of the day, PCI compliance isn't hard -- it just needs some attention and due diligence on the part of your organization to address. If you haven't started yet, now's a good time.

Ed Moyle is currently a manager with CTG's information security solutions practice, providing strategy , consulting and solutions to clients worldwide, as well as a founding partner of Security Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.