I like writing information technology policies; specifically information security policies–those are my favorite. There is something tremendously satisfying about clearly and elegantly outlining an organization’s goals and expectations regarding the use and protection of its technology resources.
Recently I was asked what I think are the defining characteristics of a good information security policy. In my experience, characteristics of good policies include:
Adhere to a Structure
Sometimes it is hard to determine the difference between a policy document and a process document. Making sure that an organization has a clear understanding of the structure it will use for its IT policies can set you up for success. I generally recommend the following approach to policy-like documents:
– Policies are formal documents that express organizational leadership’s high-level IT direction and goals. They are approved by a leadership body, are broad in scope, and rarely change.
– Standards are used to support the approved policies. They state with more specificity the activities and actions needed to meet the policy goals, including the minimum level of behavior needed to comply with the policy.
– Procedures are often step-by-step checklists that are tailored to specific processes or technologies mentioned in a standard or policy. They are narrow in scope and change frequently.
#Protip: Following a structure helps the reader understand the type of document that they are reading. Determine the structure for your policy and process documents before you start writing.
Easy to Read
Ensuring that policies are readable is key. 54% of US adults read at or below the sixth-grade level. Often, organizational policies are written in very formal or quasi-legal language which can make it hard for average readers or readers with accessibility issues to read and understand policy prohibitions. Even worse, technology policy often includes references to technical jargon, which can be hard to parse. Consider the differences in the following statements:
- Prohibited actions include sharing organizational authentication and authorization mechanisms.
- End users may not share their organizational usernames and passwords.
The second statement is written using an active voice, simple language, and is free from heavy technical jargon. The subject (end users) must take action (not share usernames and passwords). This sentence is easier to read, and in my opinion, makes for a smarter policy statement. When in doubt, default to the writing rules that you learned in primary school for creating easy-to-read sentences.
One way to make sure your policy document is easy to read is to ask others to read it–especially non-IT reviewers. Ask them what they think the policy means, and what actions they need to take in response to the policy. Also, ask your reviewers what edits you could make so that your policy is easier to read.
#Protip: Writing policies using simple and plain active language with concise text that is jargon- and acronym-free ensures that end users can read the policy document.
Easy to Understand
In the fast-paced information economy in which we live, readers are pressed for time and will generally only read things that are directly relevant to them. To make policy and process easy to understand, I recommend liberal use of predictable headings and white space. This helps to make policies scannable and allows readers to quickly pick out the information that they are looking for. I find the following headings and sections to be most useful when I am scanning a policy document for information:
- Policy statement: A clear statement of permitted or forbidden actions.
- Who is affected by the policy: States the people, units, or departments affected by the policy, as well as any policy exclusions.
- Definitions: Defines terms that have special meaning in the policy. If technical jargon or specialized terms must be used in the policy, they should be fully defined and used consistently throughout the policy.
- Roles and responsibilities: Lists who must follow the policy as part of their job responsibilities and specific actions that they must take
- Compliance: States how the institution will enforce the policy and also states what happens when units and employees fail to follow the policy.
- Related documents: Lists other documents that the reader can consult to understand the policy.
- Policy contact: Lists the person who is responsible for answering questions about the policy.
Whenever it makes sense, I like to include specific examples in a policy so that the reader knows exactly what is expected of them. This is especially important for IT policies, which often require readers (also known as end users) to engage in or change specific behaviors. Policies that are easy to understand and follow are more likely to lead to the desired result.
As policies usually apply to an entire organization, they are almost always written for the end user audience. It’s important to keep this specific audience in mind. Addressing a policy to multiple reader audiences (e.g., end users and technical staff) leads to long, dense documents and makes it hard for the reader to find information that is directly relevant to them. If the reader cannot quickly find the information relevant to them, they are unlikely to follow the requirements of the policy.
#Protip: To make policies easy to understand, format them in predictable ways, use specific examples, and write to a single audience type.
Have General Applicability
In general, the processes for revising organizational policies are arduous and require review and approval from multiple stakeholders. This focus on general applicability is especially important for IT and information security policies, where technological changes and advancements could require more frequent policy revisions. Given the length of the policy-making process at many organizations, it simply is not practical to revise a policy every time technology changes. The additional technical detail needed to describe operational processes, technologies, or activities should be made available through standards and procedures associated with the policy, as those types of documents tend to be easier to revise when needed.
Care must also be taken so that policy provisions don’t stifle the underlying business of the organization. An organizational IT or information security policy cannot contemplate all possible situations. As such, it should be written broadly to empower the organization’s end users to take the actions needed to protect the organization’s IT resources and data.
#Protip: Policies should be expressed in broad, generally applicable terms and set the guardrails for appropriate behaviors and activities without unduly impeding an organization’s business.
Finally, I regularly recommend that organizational IT policies follow a policy development process that ensures that policies are developed, reviewed, approved, implemented, evaluated, revised, and (sometimes) retired on a regular basis. A life-cycle-based process helps introduce rigor, predictability, and reliability into an organization’s IT policy operations.
Not everyone wants to write IT policies, but everyone can write a good one if they keep the characteristics of a good policy at their fingertips when they start drafting.
[1] See Barbara Bush Foundation for Family Literacy, Literacy Gap Map, https://map.barbarabush.org/overview/#intro (accessed May 8, 2023)
This post was authored by Vice President Joanna Grama, who advises clients on information security program governance and strategy.