Policy or Procedure?

[brian]

There appears to be a wide variety of solutions to integrate the PCI DSS requirements into an entities governance structure. I have seen some organizations take the PCI DSS requirements and reformat them as a business manual for credit card processing. Then a few policies are created as required such as a retention and disposal policy to meet the spirit of PCI DSS requirement 3.1. Others have condensed PCI DSS into a 3-4 page set of policies that seem incomplete.
We recently retained a QSA to assist in writing organizational card handling requirements. The QSA informed us the only acceptable method of compliance is to make all requirements a policy rather than creating procedures (business manuals) with supporting policies as needed. A policies and procedures solution would be considered a control weakness in a PCI audit.
The process of creating policy can be a long and tortured process for us since we are a public entity. So, does this policy only edict for PCI Dss requirements seem proper or does it appear that our QSA has taken an overly conservative stance?

[lyalc]

Regardless of what is in the policies, documented procedures addressing specific processes and operational activities are required by PCI DSS.
Trying to do everything in PCI as a policy suggests there is confusion about the "intent" nature of policies, and the 'how to/what to do" nature of procedures.

I have seen companies add a couple of PCI-specific statements to their existing policies, then either update/tweak existing procedures or develop new procedures where appropriate.
lyalc

[jbhall56]

In my experience, SOX has only complicated the policy process because an organization makes the process a tortured and complicated process. I have publicly held clients that have streamlined the process so that it is much more efficient and less cumbersome. However, I do understand your pain if you fall into the first category.

That said, remember the definitions of a policy, standard and procedure. I bring this up because after years and years of review, it seems that people either don't know these definitions or choose to ignore these definitions, regardless of organizational size.

A policy is a high level statement of direction or guidance. It will explain the need for the policy, it will define the policy, it will assign responsibilities for enforcement (titles, NOT people), assign responsibilities for checks and balances (titles, NOT people), and it will assign responsibilities for periodic review (titles, NOT people) and define the review period (typically annually). A policy DOES NOT go into morbid detail, that is for standards and procedures. Any policy that is more than two, possibly three, pages in length is NOT a policy.

A standard is a statement of rule. A good example of a standard is a naming convention or date usage convention. Standards typically only take a page or two to document, but I have seen instances where more paper is required.

A procedure is a set of instructions that describe how to complete a particular task. Procedures can take pages and pages of documentation to be complete. Good procedures marry text with pictures, as needed, and are at a level of detail that avoids any miscommunication to instruct the reader(s) in how to properly complete the task. Procedures can be broken up by department or can document a complete process from start to finish. How you document your procedures is up to how your organization prefers that they be documented.

[DMertz]

Brian,

I think you may need a new QSA.

The comments by Jeff from RSM McGladrey are dead on. And, the model he described is dead on. Not only is this what PCI is looking for, it is industry best practice for a governance model - whatever the compliance standard.

Establishing policies is a an important process because they are evidence of Executive Management's committment to data security. Further, they create the framework/foundation for the implementation of PCI - and any other applicable compliance requirements.

Also, if multiple compliance requirements impact your organization - and as a public entity I am confident there are - then this is the mechanism to create a single compliance framework to address all of the applicable standards.

Standards further refine policy. And, standards are more flexible than policy. For example, to change a standard which states the data retention period of transaction data is six months may require only an approval by on the CIO while the change in policy requires a board level approval.

Procedures should be looked at as the implementation of policy. The procedures document the operational processes which the organization has adopted which are in compliance with company policy.

Creating a set of well crafted policies is the foundation to meeting any compliance standard.

David Mertz
Partner
Compliance Security Partners, LLC
816 256-2125

[dyoot]

Then how do you comply with 12.1.1 where it says the security policy must address all requirements in the spec?

[cmark]

Brian,

Dave is right on with his recommendation. There is the idealism of the PCI DSS and the reality of the world in which we live. I am going to get on a soapbox a bit so bear with me.

There is a requirement (3.4) that requires all cardholder data to be rendered unreadable wherever it is stored. Companies using call centers may actually have voice recordings of cardholder data. Would all of these merchants be non-compliant without meeting the letter of the law??? No. This is a clear area where idealism may conflict with reality and the goal of the PCI DSS....which is to protect cardholder data and not push compliance for the sake of compliance.

First off...the PCI validation is an assessment and not an audit. There is no 'control weakness' language anywhere in the PCI DSS. I know the language in the standard says 'audit' but this was left in intentionally to try to alleviate confusion.

The intent and objective of the requirement is more important than the letter of the law. Th e objective is to ensure you have a consistent, repeatable process to securely manage your environment in a manner that is consistent with the PCI DSS. Additionally, the policies and procedures should be consistent with the size and complexity of the organization.

If you have policies/procedures etc. that you can demonstrate your organization follows and you have a process to update the policies and procedures and you can manage your environment I think it is acceptable.

If a company has a comprehensive set of policies based upon some standard (ISO, etc.) and they can demonstrate that their policy supports the objective of the PCI DSS it really doesn't matter if the policy is written as: Policy Requirement 1: Install and maintain....Policy Requirement 2: etc.

One of the changes this year to the QSA program is going to be a QA process and additional training to ensure that QSAs know where their responsibility begins and ends.

[brian]

I really appreciate this forum and those who donate their time to educate the rest of us.

Thanks

[wconway]

To Cmark's post, remember to complete the QSA Feedback Form: https://www.pcisecuritystandards.org/docs/qsa_feedback_form_-_brands_and_others.doc

[ka1oxd]

Jeff has some good points and it also depends on the industry that you are in when developing policies, procedures, standards, and guidelines. Some think that a tiered approach to policies are better. A Tier 1 policy would be the high level directive from the Board of Directors, where a Tier 2 policy would be technical in nature and would be from the owner of the technology. A Tier 3 policy would be an application specific policy. The symantics of what it is called all boils down to: Does the policy (or whatever) define responsibility, accountablity, audit requirements, review, and documentation to support compliance fact

[cmark]

Walt brings up a good point. Troy L. (formerly of Amex and PCI SSC TWG) is now responsible for QA of the process. He will read the feedback forms and follow-up. Very good advice.

Thanks Walt