Skip to content ↓ | Skip to navigation ↓

What do your policies look like? If your organization is like most, then your policies are probably voluminous and all-encompassing. This is a good thing – or is it?

Probably one of the most painful aspects of being an infosec professional is having to author or review policies. (Audit is the other painful aspect.) When you first entered the field, you had dreams of hacking the planet, but as you move along and progress, you may find your skills starting to fade as you slowly become more “managerial.”

Moving up the food chain is excellent for your finances and your professional development, but it comes with the price of being branded a “policy wonk.” Ouch!

I have previously written about career progression in a corporate infosec environment, and I am confident that these promotions are excellent on both an individual level and equally great for the progression of the infosec profession.

As you find yourself in the position of authoring policies, how do you proceed? Do you like to include everything possible in that policy?

One of the great curses of comprehensive policy documents is that they are only used when something goes wrong. The battle cry of “did you follow the policy?” is usually met with one or both of the following responses:

–I didn’t know there was a policy; and-

–What policy?

Like any good presentation, you must know your audience for your policies. Most system administrators neither have the time nor interest to read a 45-page document about the baseline configuration for a firewall or other network appliance.

Similarly, an employee is not going to study your equally long security policy. These lengthy tomes become the equivalent of those end user license agreements that we all tend to ignore in search of the “I agree” button.

Sometimes, as we throw words at the page when creating our all-encompassing policies, we tend to create something that resembles a JK Rowling adventure, albeit lacking the adventure part.

Can the sentiments and directives of your policies be finely tuned into something that will be read, rather than gathering dust on the shelf?

Take a moment to review your security policies to see if they can be refined into something more readable while not diluting the original intent or spirit of their purpose. Can you make those policies more concise?

When I look at some of the bloated policies out there, I often chuckle at the thought that they could benefit from a JK Rowling character pointing a wand and exclaiming “Policium concisium.”

I am not a writing coach, but here are some tips that may assist you when writing a policy, or any document:

  • Get to the point immediately. A policy is not the place to be a weaver of tales. Save those for the campfire (or your State of Security articles).
  • Use plain language. Sometimes, a large word is perfect for encapsulating an idea, but if that word makes your audience run for a dictionary, you have just lost the essence of “encapsulation.”
  • Beware the acronym. Just because something is a “term of art” to you does not mean that the reader knows what it means. If it is a term that will be repeated, then write it out first and show the acronym in parenthesis at the first mention of it. This will prevent a person from having to use an acronym search, which may be misleading. (Just look at all the possible meanings of “PRI,” which means something entirely different to an IT professional and a medical professional.)
  • Ask someone outside of your field to proofread the document. Go to a friend in another department and ask them to proofread your document. Nothing defines clarity better than if an outsider can understand it. Promise to do the same for them, or, if that is not possible, buy them lunch to thank them for their efforts.

I hope that this article assists you in your ability to create clean policies that others will understand and follow.

 

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

['om_loaded']
['om_loaded']
<!-- -->