Policies are the building blocks of any Information Technology and Information Security program.
This means any enhancements or changes will need to align to the policy or the policy will need to change. The one thing that must remain constant is that any edits you make must remain within the boundaries of regulatory guidelines and requirements.
Which Framework Should I Use?
I was given the task of comparing NIST, CIS and SANS in relation to the policies each one requires, and the one conclusion I came to is that it really does not matter what framework your organization chooses to go with as long as you can abide by what you write down. This comes down to a basic tenet of writing policies, if your organization does not or cannot follow what you have drafted then they are just words on a piece of paper. They hold no weight.
Many IT leaders and Information Security leaders I speak to understand the premise of not wanting to put down on paper that they know they will have a hard time defending against any auditor worth their salt. What this boils down to is how do we draft something so generic we have the wiggle room but do it in a way to appease regulators and auditors.
The answer is you do not. You must choose to do something or not to. Who performs the defined action determines the language you decide to add – or not add? That is your choice to make.
Whatever side of the fence you fall into there is one constant. You cannot straddle the fence. You must choose. I have had several conversations along the years regarding this very topic and the one thing that always stands out to me is this: How do I put in my policy that I do not want X to do Y? What I typically say to them is this: “Why not just add that then?
The biggest misconception about policy writing is that you cannot say something outright. But why not? What is stopping you from putting Operations will not perform function X?. The use of professional writing? Or the fact that you do not want something like that written down that may show a bias? Sure, these things may be evident in the policy but one thing that must be said about explicitly denying something that if it does occur that is an easy violation to spot.
So, how should you draft it? Implicitly deny Operations would perform such an action by stating something along the lines of “All departments may perform function X. However, Operations may require additional approvals to perform said function.”
What Can An Organization Do?
Drafting policies is truly an art form. Not everyone can do it, and there are fewer people who can do it well. With the internet it makes it easy to download a generic template with the appropriate language in it to do the job of passing muster with the regulators and auditors but upon closer inspection it will not take them long to realize you just performed a copy/paste and renamed the document. Tailor the document to you. That is what will separate your organization from all the others these regulators see. On an almost daily basis. They may not be able to tell you where they have seen the same policy 489 times but I can guarantee you they will let you know that they are seeing the same document in other organizations and that you 1. Do not follow what is in your policy, and 2. Fix it to match your processes. Both of which are extremely important things to do as an organization you will be held to that standard. If it is too much or not enough you will need to re-evaluate.
How Often is Too Often?
Depending on your approval process this can vary from the Board of Directors approving all of your policies to only those you consider to be High Risk. Whatever your organization’s process is; it needs to work, and the regulators will make sure you are up to date with the approvals.
I have always been the one to align things, so they make sense, so I have typically aligned the dates of the IT Strategic Plan to the date that an organization refreshes its’ policies. Any sooner than that does not make sense. Your environment would not have changed too drastically a small policy change here and there would not address. But in three years performing a full review and refresh keeps your policies in line with changes to technology you may have implemented and changing regulations.
What’s the Answer?
There is no one-size-fits-all when it comes to policies and procedures. No two organizations are the same so how can you expect your policies to be?
Take the template but you must tailor it to your environment otherwise it will stay a template and nothing more. Take the time to familiarize yourself with the different frameworks and understand the different complexities each framework comes with. If you want to be innovative and go against the grain within your industry I’m not here to stop you, in fact I do not think anyone will; but the one thing you will undoubtedly discover is that you are going to be struggling to figure out how to implement the procedures your new policies say you need to have.