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 5 , Part 6
The formatting and structure of documentation may not seem like the most enthralling topic, and in many (most) ways it is not. It is however one of the most important elements of effective documentation. Delivering information in a clear and consistent way is essential to ensure documents are easy to use and effective. From your organization’s logo to the approval of the board, documentation should look, feel, and be official. Even fonts can make a difference. If you work for an organization large enough to have a style guide and/or documentation standards, much of the structure, format, look, fonts, etc. will be laid out for you. For those who are blazing the path, however, you must be prepared to make several decisions prior to developing documentation.
It is almost always easiest to design a template and determine style and formatting before putting the figurative pen to paper (hands to keyboard). (Truth be told, I cannot think of a single example where it would be better to develop documentation before developing a template, but I am doing my best not to speak in absolutes. If you have any examples to prove me wrong, please by all means share them in the comments or email me directly.)
Unfortunately, due to time and other constraints, I will not be going into great detail of the intricacies of creating and formatting templates and using styles. If you plan to have any lengthy involvement in document development, I highly recommend spending some time becoming comfortable with the advanced features of your word processing program of choice. While I think it is safe to say that many feel they are expert users of the Microsoft Office suite, there are many powerful features that many who consider themselves “power users” are unaware of. Get to know the styles, template features, and table structure. Time spent up front creating a bullet proof and consistent template and related style rules will pay immense dividends in saved time and effort down the road.
As our focus in this series is policies and procedures, we will start there. In the header, at minimum include the title, revision number, effective date, and your organization’s logo. The reason for the title should be fairly clear. Including your logo will make the document immediately identifiable as belonging to your organization. The effective date and revision data allow users to identify that they are using the correct version of the document.
In the footers, include copyright information as well as page numbers. Page numbers are important, especially with longer policies and procedures, to ensure that users know that they are looking at a complete policy and not just a page or two.
The footer is also a good place to include the document classification. As we discussed in earlier posts, some policies and procedures will be more sensitive than others. It is important to label documents so that users understand their proper handling. If you do not have an asset classification program, we strongly suggest you implement one as asset classification is one of the main building blocks of an effective information security program. Please feel free to contact SecureState’s Risk Management team for details.
Take care to have consistent header and footer designs across your organization’s documentation. I cannot reiterate enough the importance of consistency.
In our next installment, we will continue on formatting and structure and get into the details of what sections and basic information should be included in every policy and procedure.