Cisco Blogs

What does it take to be PCI Compliant ?

April 12, 2011 - 0 Comments

Many people wonder what it takes to be PCI compliant. More importantly, people want to know the difference between PCI, FISMA, DIACAP and STIG. With so much alphabet soup, one has to wonder what it all means, and what is the best way to navigate these waters.

I’m not here to provide you with all the answers, but I can certainly help you to understand where PCI fits into the picture.

First, let’s decipher the alphabet soup. PCI compliance is an agreement between the credit card provider and the company or organization that accepts their card as payment. It is intended to create a level of security with checks and balances to insure the integrity of the card provider and card holder’s information. It has nothing to do with FISMA, STIG’s or DIACAP.

Now, on to the next acronym. A STIG is a Security Technical Implementation Guide, roughly equivalent to the information that you would see in a Design and Implementation Guide for PCI. Being STIG compliant means that once your hardware or software is deployed and hardened according to the STIG guidelines, that it will continue to work as stated. If it doesn’t, it is removed. Nothing to it, right? So STIG’s are a pre-requisite to deploying anything into a government environment.

Once deployed, there is a Government Certification & Accreditation process that needs to be completed. This is where FISMA (for civilian agencies) and DIACAP (for DoD agencies) comes into play. So, saying that a product or process is FISMA compliant does not mean it is PCI compliant. It simply means that the product has been deployed according to the STIG, and that a subsequent C&A process has been completed and the product meets FISMA or DIACAP compliance (a topic for another novel, another time.)

The important point in this discussion is that government agencies, even though they have strict rules and processes around security and product deployments, do not necessarily meet the PCI standards as set forth by the PCI Security Standards Council, nor does it mean that they will pass a PCI audit. And, if a breach does occur, the fines can be exorbitant. Configuration of the products and following the procedures required for PCI compliance is on top of the existing certifications in government, not in place of them.

To find out more about what it actually means to be PCI compliant, and how you can accomplish it, you may want to attend a seminar called Simplify PCI Compliance: A Holistic Approach to Meeting the 2.0 Mandate. If you are interested, just click on the link and register. I’m sure you will find it useful.

As always, if you have any comments, concerns or questions, please feel free to use the comment section below, and I look forward to sharing additional security related information in the near future.


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.