"If you don't know where you are going, any road will take you there." – The Cheshire Cat, Alice in Wonderland by Lewis Carroll
If you've ever sat down to write an information security policy, this sentiment likely rings true deep within your soul. One minute, you sit down to write a policy about implementing strong authentication. Three weeks later, you emerge with a 300-page dissertation weighing the pros and cons of various forms of multifactor authentication for each of the organization's high-risk systems and users.
You sit back to look at your work and think, "Is this a policy?"
There are a lot of ways to write a policy and there are equally as many things to avoid. One way to ensure your policies are successful is to have a well-defined roadmap. At Tandem, when we sit down to write a policy, we break our policies into the following key sections.
The first section of a policy is the policy statement. This statement is the policy itself. Everything else is supporting material. A policy statement is a short summary of what the policy is designed to do and is typically no more than a sentence or two.
For example, an "IT Asset Management" policy statement could say:
"Maintain an accurate asset inventory to identify and classify assets, determine security requirements, manage vulnerabilities, monitor for end-of-life support, and comply with applicable laws and regulations."
This simple statement defines expected behavior and required actions. This is a policy, but it is only the beginning.
The commentary section is about answering the question, "Why?" Why is the policy important and what do the policy's key terms mean? This section is especially important if the policy is being read by individuals who do not have a lot of outside knowledge on the topic in the context of your business (e.g., the Board of Directors, auditors, personnel, etc.).
Continuing with the example of an "IT Asset Management" policy, the commentary could answer questions, such as:
The answers to these questions are not "policy," per say. However, the answers are very foundational to helping the reader understand the language and intent of the policy.
The implementation section is about answering the question, "How?" How do you plan to achieve the policy's expectations? This section may also be referred to as "standards" or "procedures." This is the part where the policy ideals become reality.
For example, if the "IT Asset Management" policy statement says to "maintain an accurate asset inventory," then the implementation section would define things, such as:
The implementation section takes the policy expectations and breathes life into them. It isn't just about defining behavior. It's about doing what has been defined.
The responsibility section is about answering the question, "Who?" Who is responsible for implementing this policy? A policy is only as good as the individuals carrying it out.
For an "IT Asset Management" policy, the person responsible may be someone like the Information Security Officer (ISO) or a Network Administrator, or maybe even both. Shared responsibilities are common in the world of information security and technology, which is why it is so important to have an effective governance structure clearly defined up front. Somebody needs to make the policy happen.
Connecting any related policies is not a requirement, but it can improve the quality of life for both the author and the reader.
Some examples of other information security policies which could be connected to an "IT Asset Management" policy could include:
Listing related policies means the same content does not need to be written twice. This is a major time-saver. It can also result in more consistency and accuracy among the policies. To learn why, check out point #3 on our list of common policy writing mistakes.
"Trust, but verify" has been a long-time mantra of the security community and essentially, this is exactly why this section exists. It isn't enough to write out what needs to be done and assign responsibility to do it. Someone else should check on things and make sure the policy is being implemented according to expectations and if not, do some root cause analysis to figure out why.
For example, on a regular basis (e.g., monthly, quarterly, semiannually, etc.), the organization's security committee can:
Learn more about this topic in our article: How to Conduct a Policy Review Meeting.
Part of the reason information security policies exist is to mitigate the risk of information security threats to the organization. By associating policies with threats from the GLBA risk assessment, it is easy to demonstrate how policies are effectively reducing the risk of those threats.
For example, knowing what IT assets you have and implementing processes to protect them significantly reduces the potential impact of threats like a fire or if the asset is lost or stolen. It can also reduce the likelihood of a threat which emerges due to the use of shadow IT (i.e., assets operating in the organization's environment without the organization's control).
Map your policies to regulatory guidance and/or frameworks which may apply. It is important to reference the guidance or frameworks which helped define or provided direction for your policy as this lets outside readers know the policy is driven by industry-accepted guidelines or requirements.
For example, an "IT Asset Inventory" policy might be connected to:
Policies are written at a point in time, but can serve as long-term decision-making tools for your organization. Using a well-defined framework can not only help prevent unnecessary wandering, but it can also make sure you reach your desired destination in a timely fashion. If you would like to learn more about this process, check out Tandem Policies. Learn more at Tandem.App/Policies-Management-Software or sign-up to watch a demo today.