PHONE: (305) 744-5447 / (866) 553-3779

FAX: (866) 582-4901

1722 Sheridan St., Hollywood, FL 33020

North America's Premier ISO 27001 Training & Consulting Services Provider

  • twitter
  • facebook
  • googlePlus
  • linkedin

COPYRIGHT © CENTER FOR INFORMATION MANAGEMENT AND ASSURANCE. LLC. ALL RIGHTS RESERVED.

Talk Policy to Me Baby!

February 19, 2015

 

Today I have decided to talk about an issue that has been a pet peeve of mine for many years. One of the most over used word in the area of information management is the word, “policy.” As we understand it in its most basic meaning, a policy is a statement of management's expectations. Given that, why do vendors reference: "Setting the policy in the system to ....?" When saying this, they are really speaking to an application or system configuration setting. To take this further, if we're going to configure a router to send a syslog file to a file server, is this really something "management" has decided upon and wants enforced, or merely a technical configuration or setting, aimed at achieving a higher level issue that is nested in a true management policy?

 

With the above example, I know there is still the open window for a philosophical debate that these settings satisfy a management expectation, so therefore it is a "policy." So in an attempt to thaw such a debate, let's go a little further. I'm going to use the example of a client environment we went into where there were 165 individual Information Security Policies, ranging from three to five plus pages each. Using the philosophical thought process, the author of these policies explained that the company's information security management system's, (ISMS) Statement of Applicability (SoA), declared these 165 controls as applicable and therefore a policy would need to be authored for each.By way of background information, the company had performed their legal and regulatory review required by ISO 27001, and determined in addition to the applicable controls under 27001 Annex A, they would also need to integrate PCI-DSS controls. So now that they have a fairly significant volume of qualified controls, we need to consider what are the other relevant requirements of a "policy."  In order for a policy to be accepted as being in place, the following are some fundamental test that should be applied:

  • has the policy been approved by management?

  • is there evidence of its approval?

  • do the approving authorities have a clear and complete understanding of what they approved?

In the case of the client referenced above, they were unable to provide evidence that management had reviewed or approved any of the 165 policies, therefore for all intent and purposes, they were unable to demonstrate that there was even a single policy in place.

 

Unfortunately, the example referenced above is not an isolated case, and one might extrapolate that having a clear understanding of what a policy is, as well as, how to properly write and publish one is a unique skill set that is lacking in many organizations today.

 

So the objective of this blog posting, was simply to raise awareness that writing policy is an art, not an exercise of publishing volumes of document. Also it serves to highlight, for organizations that have not written a governance framework for a structured management system like an ISO standard, the organization should seek guidance from authoritative sources or expert support resources to ensure that the objective is not only met, but you are able to realize the full value of expressing the policy statement to the organization and interested parties. Lastly, this article is a primer for a series of articles that I will be posting on how to create a governance framework for ISO 27001.

Please reload

Recent Posts

Please reload

Archive

Please reload

Tags