In this article, I review the Payment Card Industry Data Security Standard (PCI-DSS) policy requirements and provide a policy framework, including a PCI DSS sample policy that uses the framework.

Getting Started

The best advice regarding policy creation is: don’t over engineer it!  The policy document should be a definitive guide to conduct, but should not include the implementation details (i.e., procedures).  It may make reference to standards, but it should not contain those standards.

In fact, the simplest and most straightforward way to create a policy for PCI-DSS is to extract the policy directly from the PCI-DSS, almost word-for-word.  This alone won’t make you compliant, but it’s a step in the right direction.

For example, requirement 12.7 says to screen potential employees to minimize the risk of attacks from internal sources.  The policy statement should be just that: We shall screen potential employees to minimize the risk of attacks from internal sources.  What screening results are acceptable under which circumstances should be delineated by HR’s Standard for Employee Screening.  How screens are conducted should be detailed in HR’s Procedure for Employee Screening.

Benefits of the Framework

Why go to the trouble of separating the policy statement from the implementation details?

It limits unnecessary debate.

Policy typically is owned at the highest levels of an organization.  Do you really want senior management to discuss what steps 1-4 should be in the account generation process?  If the policy consists almost entirely of elements that directly are required to be present in order to attain compliance, there isn’t much to debate.

It facilitates change.

Perhaps the only thing more difficult than generating policy is changing policy.  If the policy introduces specific standards or procedural elements, it must be changed whenever the standard needs to be updated or whenever the procedure changes.  By deploying a policy made only of PCI-DSS requirements, the policy only needs to change when the requirements change.

It distributes effort appropriately.

In this framework, the departments responsible for executing the policy are responsible for defining the standards and procedures to do so.  Ensuring that those standards and procedures meet the requirements  becomes the responsibility of the central office or internal audit.  Think of what that will mean in terms of comprehension.  Rather than being handed a 200 page policy wherein their requirements are buried, the department is responding to a 2 page document by contributing aligned standards and procedures.  You may still end up with a 200 page manual, but it will be the work of many and well understood by all.

It speeds implementation.

The departments understand their business processes.  A central policy containing standards or procedures may be incompatible with those processes, and could end up needing to be completely reworked and re-approved.

Meanwhile, the business unit may have an alternate, but equally legitimate mechanism that is more appropriate to their area.  They have a better idea of what will promote and what will stymy the appropriate behaviors among their employees.  And some departments may seize PCI-DSS as an excuse to introduce standards and procedures that they were unable to implement previously due internal resistance.

It simplifies review.

Even for a standard as prescriptive as PCI-DSS, the policy document can be kept to two or three pages. This can greatly simplify the policy review process (which likely involves senior management) that PCI-DSS requires annually.

The Sample Policy

• Introduction

• Policy Statement

• Applicability and Availability 

• Adherence to Standards

• Handling of Cardholder Data

• Access to Cardholder Data

• Critical Employee-facing Technologies

• Roles and Responsibilities

• Related Documents

  • Standards
  • Incident Response Plan
  • Procedures

Posted in PCI DSS, Policy |