Let’s Talk Information Security Policy Development!
Today I have decided to talk about an issue that has been a pet peeve of mine for many years, that can affect you information security policy development efforts. 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 “sys log” 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 will be posting on how to create a governance framework for ISO 27001.
Discussion
What are your experiences?
Do you agree or disagree with the thoughts shared in this article?
How do you see the industry addressing the Art of Policy Development?
If you have thoughts on any of these questions or other relevant and related ones, please leave a comment in the comment section below. Please note to keep our environment clean and free of advertisments of any kind, comments may not include external links, citing company names to promote them, or the like.
