I mentioned in my Securing a Cloud Based Platform post that we embarked upon an effort to build a PCI compliant security program; we really needed to improve upon several areas:

1. We needed to improve our documentation
2. We needed to modify existing or add new technologies
3. We needed to improve existing or add new workflow

As we learned, most of the PCI standard is about documenting what you do and doing what you document.  Sure, there are plenty of standards stating the minimum password length, key rotation standards and data retention policies – I’ll get to some of the bits and bytes soon enough.  But let’s start with documentation, which is where I started.  What I didn’t initially understand was that there is a juicy, riveting 113 page Reporting on Compliance (“ROC”) Reporting Instructions for PCI DSS v2.0.  This is basically the auditor’s instruction book which completely describes exactly how an auditor will gather evidence, ask questions, etc…  This is the auditor’s playbook and there are 12 requirements.

So, why do I mention that the auditor’s instructions are available, because if you need to write an Information Policy and Standard document then you should organize it to correspond exactly to the PCI ROC’s organization.  Why?  Because if you don’t then you get to have the fun that I enjoyed for several months which includes providing the auditor with a map of where my policy documentation states the required language.  My policy documentation is well over 100 pages, so the exercise of mapping my 100 pages to the 113 pages of auditor instructions was a truly ridiculous waste of time.  If I had to do it over again, the first 12 sections of my policy would map directly to the 12 PCI requirements and I would store extra beyond these basic policies.  In fact, I think that it is silly that the PCI council doesn’t produce a compliant security policy document (at least not one that I could find anyway) that organizations can simply adopt, or at least use as a starting document.