As you advance in your career, you will likely reach the point where you will put away the toolkit and become a full-time manager. Moving up even further, to the top-most ranks (i.e. CIO, Deputy CIO, Director) you will be responsible for writing policy. You may have had input to policies for your organization, but from the middle-management and technical levels in the organization, you were likely writing process documents (i.e. Standard Operating Procedures (SOPs), technical manuals, etc.). It is important to first understand the difference between writing for policy and writing for processes.
- Policy – Policies are the why we do what we do in the organization and outlines the rules of doing the organization’s business.
- Process – Processes are the how we do things specific to our work and outlines the procedure for putting a policy into action.
Look at it this way:
You can have a policy without a process, but you cannot have a process without a policy.
What is Policy?
Policies are generally put in place to bring some sort of positive effect or to avoid negative effects. Generally, there are two different categories of policy: Subjective policy and objective policy. (Wikipedia, 2019)
- Subjective – Decisions that need to be based on relative merits, such as a work-life policy; and
- Objective – Decisions that are operational and can be tested and enforced (e.g. password policy, physical security access policy, contracting policy, etc.)
Within these, there are different classifications of policies. These include, but are not limited to:
- Distributive Policies – These “extend goods and services to members of an organization, as well as distributing the costs of the goods/services amongst the members of the organization. Examples include government policies that impact spending for welfare, public education, highways, and public safety, or a professional organization’s benefits plan.” (Wikipedia, 2019)
- Regulatory Policies – (or mandates) These “limit the discretion of individuals and agencies, or otherwise compel certain types of behavior. These policies are generally thought to be best applied when good behavior can be easily defined, and bad behavior can be easily regulated and punished through fines or sanctions. An example of a fairly successful public regulatory policy is that of a highway speed limit.” (Wikipedia, 2019) In the Federal Government, regulatory policies are often referred to as “the regs”.
- Constituent Policies – These “create executive power entities, or deal with laws. Constituent policies also deal with fiscal policy in some circumstances.” (Wikipedia, 2019)
The Anatomy of a Policy
- At a minimum, a policy should contain the following:
- A Purpose statement that spells out what the policy is and why it is being implemented;
- A Function of the policy that spells out how this policy is to be implemented and executed;
- Who is Responsible for what in the implementation and execution of the policy; and
- Definitions of any acronym or initialism used within the policy statement that anyone in the organization may be unfamiliar with.
- Penalties for failure to adhere to regulatory or constituent policies.
Understanding What a Policy Expects of You
Most policies are written as legal documents. Because of that, many policies are purposefully written to be a bit ambiguous; leaving things open for interpretation. In the Federal Government, this is accomplished by using one of three qualifier words: “Must”, “Should”, or “May”.
- Mandatory: “Must” (avoid using the word “shall” or “will”) means the reader has no discretion to deviate from what is written. The only way to deviate is if a person of superior authority grants it. For example, if a cybersecurity policy states that you must do something and you disagree with it, it would have to be overridden by someone at the C level (i.e. CIO, CISO, COO, or CEO) or above to allow you to deviate from it.
- Recommended: “Should” means that this is the organization’s preferred approach but does permit the reader to deviate if the reader can accomplish the objective another way. “Recommended” can also be used if “should” does not convey the point adequately in the context of the sentence.
- Advisory: “May” means that the reader has the option to pursue alternative courses of action and is only used when neither law, regulation, nor management policy dictates which of the other options follow.
What if There is No Policy in Place?
It may be that there is no policy in place for a given situation. A good way to get started is to formulate the policy into an Interim Directive. This can help you get your policy out quickly, while it goes through a thorough review and approval process.
An Interim Directive will be very similar to the finalized policy but will not be codified into the organization’s formal policies. It is still relevant and should be adhered to but is not a “grown up” policy that is part of the organization’s overall policy documentation. Where a formal policy must be approved by the leadership of the entire organization (e.g. Board of Directors), the Interim Directive can be approved by a specific upper management director (e.g. COO, CEO, or CIO). Interim Directives also have a set time period that they are valid. It can be 90 days or up to one year. I would not recommend any Interim Directive be valid for more than one year. This should be more than enough time to have it codified into permanent policy; however, if it should take longer, the Interim Directive can always be reissued for another period of validity. The rule of thumb I use is this:
- Interim Directives must state their validity period and may not exceed a maximum period of one year. There must be wording in the directive that specifies the validity period.
- Interim Directives must still be cleared by the relevant departments that it affects before it is submitted for full policy approval.
- Once the Interim Directive has been sent, within two working days a link should be posted on the electronic version of the organization’s permanent policy site. This ensures that everyone can access the Interim Directive and adhere to it while the approval process is ongoing.
Getting the Policy on Paper
IT policies generally cover technical aspects of the organization and how it does business. It may not be as deep in the weeds as, say, a maintenance SOP, but it still has a technical aspect at its roots. Your policy should start with a Subject Matter Expert (SME). This can be a front-line supervisor or mid-level manager.
In 2012, I drafted the policy for the Department of State’s video teleconferencing network. It has been updated since my initial draft; however, the core of the document is still what I drafted. As an example, you can see what I did here:
The Policy Approval Process
From there, it should start its way up the organizational chain. Each person on the policy formulation team then gives their input and massages the draft policy to take it from a working-level document to a management-level document. People on the policy formulation team can wear more than one hat in this process. You may have a director that came from the ranks and has full understanding of the technical and management of the subject matter and can write most of the policy themselves. This is fine; however, I still recommend people at the working-level be part of the policy formulation team since, in the end, it is they who will have to implement the policy (or assist their customers who must adhere to the policy) on a day-to-day basis.
Giving Policy Some Teeth
As I noted in the section The Anatomy of a Policy, the penalties for not adhering to a regulatory or constituent policy needs to be spelled out. Once it is, it also needs to be enforced and it needs some teeth behind it to ensure compliance. If you create a cyber-security policy that says all employees are required to log off their workstations at the end of the day to ensure that hackers are unable to access the entire network if they gain access to a single PC, and the penalty is that the employee will be docked one day’s pay for failure to comply, then you must hold them to it. If you do not, it is likely that the policy will be ignored because people will figure it is just a paperwork exercise and do whatever they want. Make sure you enforce your policies by giving them some teeth. Otherwise, why bother writing the policy at all?