Information Security Policies and Procedures Part 5

Monday, May 16, 2011

Alex Hamerstone


This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series: Part 1 Part 2 Part 3 Part 4

In this installment, we will discuss fonts, and then move on to additional structural elements necessary in documentation, starting with policies.

Does the font matter? Certainly.

As I mentioned in a previous post, if your organization has a corporate style guide, the font and document layout is likely already determined. However, if you are blazing a trail through the documentation, you will need to choose a font.

If you are planning on distributing hard copies of your documents, a Serif font is easiest on the eyes. For documentation meant to be viewed on a monitor, a Sans Serif font is best.

Of course, rare is the document that is viewed in one format only. Lucky for us, Microsoft has come up with a font designed to be easy to read both on screen and when printed; this font is Calibri.

Side Note: Serif? Sans Serif? Seriously? For those of you who are not familiar with typography, serif fonts are those with serifs, the little embellishments on the letters. Think Times New Roman. Sans Serif, as students of French will note, are fonts without serifs.

Perhaps the best known example, at least to a generation raised with computers, is Arial. If you have any confusion, type a few letters in Arial and Times New Roman and compare them side by side.

(In case you don’t think typography is cool, read Steve Jobs’ 1995 commencement address to Stanford “I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.”) So when you refer to your documentation as a work of art, Mr. Jobs may concur.

Before we get too far down the road into typography (kerning anyone?), let’s move on to some additional structural elements necessary in documentation, starting with policies. In addition to the elements discussed in previous posts, policies need a few standard sections.

These sections include purpose, scope, policy details, and enforcement. You may also wish to include a section with definitions or relevant standards/laws.

The purpose section should include information about why the policy is necessary. You may also wish to add some information about how the issue was dealt with historically. It is also a great place to reiterate some company values.

An example is “To ensure compliance with (regulation) and create a more secure environment, this company has implemented this policy…“ Some policies will require a paragraph to get the point across, while others may only need a line or two.

The scope is generally fairly straightforward. To whom does the policy apply? Employees? Contractors? Visitors? To what facilities does this policy apply? To what systems? And so on and so forth.

The policy details section is one into which we will take a much deeper dive in a future post. For now, just know that this section enumerates the rules of the policy. It may also refer to related procedures.

The Enforcement section is where you outline the consequences for non compliance. Is it up to and including termination? A written warning? Be sure to involve HR and Legal in this part.

As we continue in this series, we will expound on each of these areas. Hopefully by now you are feeling more comfortable with documentation development. Please feel free to email me any questions or ask them in the comments section.

In the next installment, we will discuss knowing your audience.

Cross-posted from SecureState

Possibly Related Articles:
Compliance Enterprise Security Management Documentation Administration Policies and Procedures
Post Rating I Like this!
krag brotby I don't agree with your definition of policies, standards and procedures and is not what we teach and test for CISM. While the definitions may be somewhat arbitrary, it makes more sense and improves useability in my view to define as follows:

Policies are a statement of management intent and direction

Standards set the allowable boundaries for people, processes, and technology without needlessly limiting the procedural options.

Procedures are detailed steps to accomplish a particular task within the bounds of the standard.

So in your stoplight analogy, the policy would be "the flow of traffic must be regulated effectively in manner that maximizes throughput consistent with safety" or some such.

The standard would set the acceptable limits on devices to accomplish the task and

procedures would specify the steps in the operation of the lights but other procedures
could be used that would accomplish the same thing.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.