Writing Security Policies

As expected, one requirement of a SAS 70 audit is that you have a formal security policy. I’m not going to get into the policy we came up with at this time, but I do want to point out a very relevant article about this I found over on one of my favorite security related blogs, the Security and Risk Management Strategies Blog by the Burton Group. A few weeks ago there was a very good post on that site titled Business Matters. The article pointed out one of the fundamental principles IT professionals sometimes forget, especially when writing a security policy…the users must be willing to adopt the policy.

When we design new applications, we spend lots of time, as we should, finding out what all the requirements are from the end users and ensuring we design the application in such a way that they will want to use it. A lot of times, we approach it as trying to make their job easier, maybe we are eliminating duplicate entry of data or papers that have to be manually filed and maintained. Sometimes we change aspects about the application simply because the users tell us it would be easier for them that way such as the layout of a screen or the order in which things occur. Whatever the case, it’s very obvious that, when developing new applications, we know if the users will not accept the system and use it, the system will be a failure.

Writing an Information Security Policy is often thought of differently. We think we must protect the information and the users are just going to have to get used to the policy. However, we forget, that business must continue as usual as well. The user’s are likely not going to get any of their expectations changed because of this new policy. So a sales person will likely still be expected to make the same number of calls per week after the policy is put in place. So if your policy adds extra time to the process, it is very likely the sales person is either going to blatantly ignore the policy, or maybe comply with it on the surface, but find some way to work around it in the background.

As IT Managers in the small business world, we are often very familiar with the processes and users in the other departments, so we may be able to get by without much communication with the users before hand simply because we are familiar with them and know them well. However, I would still caution against that. Get your users involved early in the process of writing a security policy. You can send out some early drafts and ask for feedback on what items may cause them issues. Since we are talking about information security here, there will likely be some compromises that have to be made by the users, but there may also be some compromises that can be made on the IT side to make the users happier as well. Whatever the case, at least this way they’ll feel that they had some input into the process and be much more likely to accept it. So my challenge to anyone out there writing an Information Security Policy is to treat it more like developing an application and be sure to get end user feedback.

Don’t know where to start on your Information Security Policy? There was recently a good post on the Cracked, inSecure, and Generally Broken blog that gave some good links for just this sort of information.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: