PCI DSS Requirement 12.1 requires that companies: “Establish, publish, and maintain an information security policy…” It then lists a number of requirements for a PCI compliance policy.   So, what exactly is a security policy?

First, it is important to understand that a “policy” is NOT simply a document. The policy document is a record of the policy statement that was approved, and the document is a tool for disseminating the policy, as appropriate. The document should be a reflection of the policy that has been approved by management. The possession of a written document that articulates a series of ‘dos’ and ‘don’ts’ does not mean a company has a policy.  To be effective, a policy must be approved by appropriate authority, appropriately documented, disseminated to those to whom it applies, and enforced.

It is important to remember that writing and approving a policy is the easy part.  Ensuring adherence to the policy and enforcing the policy is the difficult part.  Quite simply, a policy that is not enforced will not be followed for very long.  People are inherently efficient, meaning that they (this author included) take  the path of least resistance.  Policies require difficult, often inefficient methods and interject administrative friction and inefficiencies into processes.  Without enforcement, policies will simply not be followed for very long.

Writing and documenting a policy is often much easier than implementing the policy.   Consider the following example: Company X passes a policy that requires all computer and IT users’ access to systems and data to be modeled on “need to know” and “model of least privilege” (standard access control model).  While seemingly simple, this policy statement implies much more.  First, it requires an audit of every user’s existing access privileges, as well as identification and documentation or their roles and responsibilities.  It also requires identification and classification of all types of data.  Using the data classification matrix and each user’s established requirements, each role then needs to have access levels documented and assigned based upon the “need to know” and “model of least privilege.”  As can be seen, a simple one line policy statement may have deep implications and be very difficult to implement.

After documenting the policies, it is important to ensure that your company adheres to the documented policies on a consistent, and repeatable basis.  This is a three-step process that can be described simply as SDC or:  “Show, Demonstrate, & Convince.”

1) Show that your company has a documented security policy that is up to date, approved by management, and appropriately disseminated.

2) Demonstrate to the auditor that your company is currently in compliance with the policy.  This is typically accomplished through showing existing processes.

3) Convince the auditor that your company has a history of following the policy by producing relevant documentation/evidence (ie…change control documentation) to show compliance over time. (last 3 months, last 6 months).

By using the Show, Demonstrate & Convince model with policies and departments, you can have confidence that your company’s policies are being enforced and followed.

How does your company enforce its security policy? What have you learned from the experience? We’d like to know.