1. Misunderstanding.
Don't treat PCI DSS as a purely technical standard. A few minutes browsing through it and you'll know why -- there is a stack of technical requirements.
Usually, however, it's hard to meet the technical requirements without first taking care of policy issues. For example, it's a bit backwards to install new firewall when you don't yet have configuration standards.
The trick for achieving compliance is to read the PCI DSS backwards. Start at requirement 12 and have your risk management framework in order, then your policies, then procedures, configuration standards, then implement it, and audit it.
Don't let a technical manager own your PCI compliance responsibilities. The path of least resistance is down, and generally the most difficult challenges for compliance are within the business and business process -- not technology. Make sure PCI lands on the desk of someone who has the authority to enforce it throughout the organisation.
That said, of course the staff responsible for PCI DSS Compliance need to have a full and complete knowledge of the standard. Someone with "just enough" knowledge of the standard can be dangerous and wind up costing you more than you bargained for.
2. Misinterpretation.
The requirements and the priorities of the standard are well laid out by the PCI council, but it is important to fully understand the scope of compliance within your business. If you have card data used across many systems, you cannot be compliant as an organization until ALL cardholder systems are compliant.
Many fall into the trap of investing too much time and resources into deciding on the minimum effort required in order to achieve compliance. It buys time from the banks, but it's not a long term approach.
This distortion of the intent of the standard is not only damaging to compliance, but can distract from the security of your organisation as a whole. Apply PCI in accordance with the "spirit" of the rules.
3. Validation.
Validation is not compliance, and compliance is not validation. While organisations that come under PCI DSS must be fully compliant at all times, validation is periodic and its rigour depends on the size of the merchant.
If you are genuinely compliant, staying that way will not be hard, and passing a validation check won't be difficult. If you've cut corners to do the absolute minimum, ongoing validation is when your poor approach will bite you on the ass. Also remember you could be asked to validate your compliance at any time -- especially after a security incident.
4. Cause.
The specific requirements of the PCI DSS are nothing extraordinary, rather they are generally considered to be best practice. If you're not compliant, you really have to ask why.
For each and every point, find out what the root cause of non-compliance is. Is it poor risk management? Lack of resources? Legacy systems? While this can be an overwhelming task at first, if it's performed from a top down approach (as suggested in the first point) it will pay dividends.
5. Framework.
An ad-hoc approach simply does not work. Tying it all together into a framework is the only way to achieve continued compliance. This must cover and have support from all aspects of the business that PCI touches. This can be everyone from HR, project managers, data entry staff, receptionists, etc. Have a plan and work to it.
6. Beware Snake Oil.
You may have noticed the discussion of specific products has been avoided. That's deliberate. There are endless combinations of products that can be used to achieve compliance, but there is no specific product that is required for compliance. If anyone suggests otherwise to you, vendor, QSA, consultant etc -- you are best to politely escort them from the building.
Declan Ingram works for Securus Global, a Sydney-based security consultancy. He has a pwnie-tail and likes to fly aeroplanes dangerously.
