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.

At the Heart of Security: Doing What You Say And Saying What You Do

Security is about deciding what's forbidden, what's allowed and enforcing these decisions.

There's the technical part, doing what you can to technically enforce the decisions.
And there's the human part, managing things in a way that reduces related uncertainties.

The human part is the most important. You cannot enforce every decision technically. Besides, you have to allow for people to switch on/off certain features, eg to allow for good functioning outside of the company's premises. So, you forcibly leave some room for employees to decide by themselves whether they respect the rules or not. And that's the moment when the human factor matters.

The most important tool for the human factor is the security policy. You have to say what you do in terms of security and to do precisely what you say.

If you don't do what you say, you invite people to force the system, they think they can fool you. It may go as far as disregarding completely the policy.
If you don't say what you do, you invite people to rebel and contest the security measures. Additionally, you scramble people's understanding of your security policies, which may lead them to give up trying to respect it.