Two Security Policy Writing Tips

Reading Anton Chuvakin's On Nebulous Security Policies reminds me I wanted to share two very simple, basic, common sense, advices about writing the Security Policy.

Although norms like ISO27000 may give good guidelines to the content you put into the Security Policy, it would be quite suboptimal to write nothing more and nothing less. You have to adapt it to your organization and you can benefit from it.

My first advice is:
Stick to what you already have, or almost have. For instance, if you already backup 95% of your servers, you can write something like "all servers must be backed up". That will help you communicate what you already do and obtain more observance from your own teams.
If, on the contrary, you only backup a few servers, don't go into writing that they must all be backed up. That would show that you don't do what you say and that you write things you don't have a clue how to put in practice.

My second advice is:
Think of IT problems actually occurring, where you would welcome help from top management, and write these principles into the policy. This way, the top-management-approved policy will support your efforts to address these problems. For instance, if you would like to clarify that the IT service doesn't support hardware that wasn't bought by the IT service itself, the Security Policy is the right place to state it.