We kicked off the exploring series by taking a look at policies. We started with recognizing policies as a major type of documentation. We moved into the importance of having policies. Then we took a look at how a policy is created and effected.
In order to wrap up our first exploring series, let's look at general policy formatting tips:
- Every document you create, let alone a policy, should have a title.
- Resist the temptation of adding your organization's or agency’s name to the policy title.
- To avoid redundancy, don't affix the word “policy” to the title.
- Breakup the policy into multiple sections for easier readability.
- Don't write a big block of text. Use headings, lists and appropriate spacing.
- Avoid making the policy unnecessarily long.
- Use brief, descriptive words.
- Add important dates to the policy (effective date, last revision, next revision, or other relevant dates.).
- Either add revision history or IT Department contact information. This in addition to applicable dates show users the policy is current and valid.
- Use appropriate authoritative wording. Words like “may” and “shall” have different meanings. Read more at RFC 2119 on IETF Tools.
I've seen many policy documents with many sections, including a table of contents. I'd rather keep it as simple as possible so this is the layout I prefer:
Introduction (AKA Overview)
- Include any information needed to establish the policy. Add an official stance, authoritative legal basis, or any other related information to kick off the policy.
- This will establish why the policy is needed. Quickly define what the policy is specifically for like protecting personal information, auditing guidelines or equipment usage.
- Who is this policy aimed towards? This refers to the roles and responsibilities accountable for adhering to the policy. It could be departmental or the organization as a whole.
- This is the actual policy statement or list of policy directives. The policy includes rules or standards. Avoid using procedures or checklists in the policies section. This section is only to help readers develop an understanding of compliance. References to procedures and checklists may be included in the resources section or attached as an addendum.
- This section adds legitimacy to the policy by describing actions for non-compliance. Add a quick blurb on how compliance will be measured. You can also explicitly list what is considered a violation.
- The resources section houses supplemental information including references to official documents, other policies, etc. Any other information could include links to forms, a glossary or other relevant information.
What is the preferred format and layout for your policies?
Check out Policy Content and Organization Guide by Iowa State University. It's a little overkill for most organizations but nevertheless, a great example of an approved method for formatting policies.
As previously mentioned, this will be the final post in the exploring policy series. However, this will certainly not be the last time I cover policies. I do plan to make additional posts as well as templates and other resources. A quick reminder of what the exploring series is designed to be – a first look at a particular subject. This can be any topic that I dig deep into. The information doesn't have to be brand new.
What did you think of the first exploring series? How can it be made better?