Do your security policies work for you? Or do you have a love-hate relationship with them? As in, people love to hate security policies. Believe it or not, security policies do have a role to play in your organization’s security posture. It just may not be the role you thought.

Whenever we perform security audits, there is one question we ask even though I know what the answer will be:

What security policies do you have in place?

Invariably, the answer is along the lines of “not many.” When I ask why, I get some interesting responses.

• Our people are smart/professional/dedicated. They do not need policies to tell them what to do.
• No one would read them; why bother?
• They seem like bureaucratic overkill.
• Security policies are just an exercise in CYA.
• Could you write them for us?

Yes… for a price.

If security policies were no big deal to produce, I would not see so many messages about “does anyone have a copy of ___ that they would be willing to share?” Nor would there be so many places (like this and this) where folks can go to get security policy templates. If this sounds familiar, let’s look at ways we can make security policies work for you.

What Security Policies Cannot Do

If you are going to make security policies work for you, it will be important to understand what they can and (equally) cannot do.

• Security policies cannot regulate user behavior. You can have a policy that tells people not to put a Social Security Number in an email. However, the policy does not stop people from doing that.
• If you want to build a strong security posture, security policies are not the place to start. Why? Because these policies usually focus on what users should not do.

Side note: this discussion reminds me of a management exercise from some years back. A person walks into a room. Their colleagues are already in the room, and they want the person to complete a task. It might be to write their name on the whiteboard. The catch is that the person cannot ask any questions or say anything. And the colleagues can only respond to the person’s actions with one word: no. Of course, it takes a lot of trial and error for the person to discover the task they are supposed to complete.

The lesson in this exercise is that it is far more efficient to engage with a person to tell them what you want from them, vs. just telling them what you don’t want from them. It is like that with security. Yes, there are behaviors users should avoid. But there are more behaviors that you would like to encourage. Make your security policies work for you by encouraging users to do what you want.

What Security Policies Can Do

If security policies are not there to regulate behavior, what can they do? Plenty.

• Security policies (like other kinds of policies) can communicate expectations that the organization has about its employees. How do you want users to behave when they see a suspected phishing email? Policies are not the only (or even the main) instrument to communicate expectations. But they are part of the culture that communicates these expectations. (And to think, Melissa’s Mom said an Anthropology degree would never help me. Ha! Take that!)
• Security policies can provide the “why” for other security actions that IT will take. Here is why we are requiring multi-factor authentication. Here is why we are blocking your new phone from accessing any organizational content.
• People like to know why they are being asked to do (or not do) certain things. Security policies can fill this need. Why is it a bad idea to put a Social Security Number in an email? Let me tell you.
• Policies can include procedural information. What do I do when I receive a phishing email? Follow these steps.

Taken together, this is a good recipe for a security policy.

• Here is what we would like you to do (and not do).
• The reason we want you to do or not do __ is as follows.
• Follow these steps to take the action we have asked you to take.

The Security Policies You Need

Sometimes people ask me, “how many security policies do I need?” The answer: just enough. (Now climb back down the mountain and send the next Seeker up to see me.) You can make security policies work for you by publishing fewer policies, not more. Here I have some good news.

You need just the security policies that support your security efforts. OK, you might need one or two policies for legal reasons. No, it is not OK to use a picture you scraped from a website without the owner’s permission. Yes, we can read your email anytime we want if we have a justification.

You do not need policies that reflect security actions you are not taking. Why talk about multi-factor authentication if you have not implemented it (and do not plan to)?

My one exception to this rule is this: publish a security policy now for the work you anticipate that will require much of the organization to implement. (I am looking at you, retention policy.) Set the expectation now for policies that will require changes in user behavior, even if you are not ready to put the controls in place just yet.

Show Me the Policies

Now we get to the million-dollar question: what security policies do I need? Here is my list.

• Acceptable Use: what uses for email, web browsing, chat, etc. are considered acceptable?
• Clean Desk: a bit archaic (who even has a desk these days?) but still useful to encourage putting valuables away.
• Data Breach Response: less of a policy and more of a “what will we do” document.
• Email (if not covered in Acceptable Use): what can staff do with their organizational email account?
• Password Construction Guidelines: password complexity is typically enforced elsewhere, so this gives staff a “how do I” guide.
• Software Installation: are users allowed to install software on organizational devices? Under what circumstances?
• Technology Equipment Disposal: how are computers and the like disposed of?
• Mobile Device: can staff use their mobile device to access organizational applications and data? With what restrictions?
• Data Retention (across documents, email, and chat): just because storage is cheap, it does not mean people should keep stuff forever.

That is my list. What did I miss? What is on your list? Let me know!