What’s a “Policy Cycle”?
| by Steve Flick | ||||
First, what is a policy? Well, in an article we recently ran, we established that a policy and procedure are two distinct entities. According to the dictionary, policy is a “definite course or method of action selected from alternatives and in light of given conditions to guide and determine present and future decisions”.
Organizations typically have high- and low-level policies. High-level policies govern the entire company in most or all circumstances. They are somewhat generalized and often articulate soft goals. They speak of company desires, needs, and aspirations. High-level policy doesn’t readily lend itself to procedures; instead, it takes the form of a standard, or a guideline.
Low-level policy deals with a more specific set of circumstances. Low-level policy is the kind that usually leads to procedures. An example of a low-level policy that everyone’s familiar with has to do with attendance; employees are expected to come to the office to carry out their duties during “normal working hours”.
Because the world around us is continually changing, our policies – especially the high-level policies – have to be reviewed and reshaped occasionally. We do this by implementing “the policy cycle”. The policy cycle consists of:
- Setting the policy agenda;
- Writing policy;
- Implementing policy;
- Enforcing it;
- Reviewing the policy; and
- Updating policy.
Setting the Policy Agenda
Your organization has limited resources – time, money, people, etc. Whatever your company’s intent, whatever its objectives and strategy, you can only do so much. Your policy agenda is a concession to the scarcity of resources. What resources you have, you manage well and you prioritize.
The smaller the organization, the easier it is to set a policy agenda, generally. It’s with large organizations that we see more intense competition to politicize an agenda – to get preferred items on the agenda because they serve localized interests, which are easier to understand and deal with, rather than those of the entire company.
Writing Policy
A policy has to be easy to understand and implement. Policy statements have to be written clearly, concisely, and directly. Policies should not be open to interpretation, though this isn’t always possible, especially with high-level policies. In that case, the company must identify policy experts who will be readily available to interpret policy and resolve differences.
Policy writing has to be an iterative process. Policy drafts should be reviewed by a representative sample of the group or groups who will be responsible for implementing the policy on a daily basis.
Implementing Policy
People have to know that a policy exists if they’re to be held accountable for it. Not only do they need to be aware of it – they should also know why the policy exists. People generally view policies as restrictions and unless it’s clear where and why the policy originated – that there’s a valid reason for it and that the organization benefits – compliance will be a problem.
Policies have to be communicated effectively and there needs to be a suitable introductory period to ensure compliance. People should have plenty of advance notice – give them time to learn the policy, discuss it with others, understand it, and submit their comments. When people feel like they’ve had a say in policy, they’re more likely to comply.
Enforcing Policy
Given that policies are often developed in response to problems, how do you make sure the problem doesn’t recur? Well, you try not to do what a lot of governmental bodies often do – you don’t make policy that’s unenforceable. The U.S. Congress has been doing this for years with respect to food safety, writing more laws for the FDA to enforce while hampering its ability to conduct inspections by slashing its budget.
Policy has to be clear on what constitutes compliance and what happens in the event of noncompliance. There has to be a clear responsibility for ensuring compliance and imposing penalties.
Reviewing and Updating Policy
Policies are often changed only because a noticeable event or trend occurred which forced the organization to respond. A notable example of that is the proliferation of smartphones; so many individuals have purchased smartphones and incorporated them into their daily routines so quickly that the company can’t keep up.
The majority of company policies, once written and implemented, are rarely looked at again. Yet, all policies have to be reviewed on a regular basis to ensure that they reflect the business realities of the moment. A good example of that is some automakers’ infatuation with the SUV, based on a policy of maximizing profit rather than giving customers what they need. Even if $140 barrels of oil and the decline in SUV sales weren’t a strong enough signal to them, the automakers should have been reevaluating their policy periodically with an eye to updating it. Their hundred-year-plus histories should have told them – you either change or you have change forced on you.
What about your organization? When was the last time you reviewed any of your policies? Do you follow a policy cycle?
Categories:
Policy
Tags:
communicate • effective communication • implement • Policies • Policy • project resources • review • writing
Bizmanualz has been at the forefront of deploying business best practices since 1995 delivering Policies, Procedures and Forms; quality systems implementation; and strategic business process improvement to help business owners achieve the growth and expansion they envision.
Learn more about Bizmanualz solutions:
Originally published in 2010 by Bizmanualz, Inc. under the title What’s a “Policy Cycle”?. All rights reserved. Reproduction permitted with attribution only. www.bizmanualz.com
6 Responses to “What’s a “Policy Cycle”?”
Leave Your Comment










May 5th, 2010 at 10:15 am
Hi Steve
I would like you to please clarify something to me: In an Information Security Policy Architecture (ISPA), where do the low-level policies lie?
By low level I mean the very low-level policies e.g. RBAC (Role-Based Access Control policies), the low-level network policies, e.g. QoS policies, Routing policies, etc. (the policies that are sometimes even confused with device configuration).
I know the structure of the ISPA to be as follows:
Firstly, the CISP (Corporate Information Security Policy) sometimes called the EISP (Enterprise Information Security Policy). Secondly, the sub-policies, like the ones stated in the famous ISO/IEC 27002 (previously ISO 17799). Following these are standards and guidelines. Lastly, there are procedures.
Where do the low-level policies stated previously fit in this architecture?
May 6th, 2010 at 5:11 pm
Mvivi, I’m not at liberty to say, since I’m unfamiliar with the details of ISPA. I’m not sure what the question has to do with the Policy Cycle, either.
The Policy Cycle applies to any level of policy. True, higher-level policies are going to govern the wording, scope, roles, etc., of lower-level policies. However, what many of us miss is that low-level policies can also have an effect on their policy “parents”.
Security policy is, itself, a subset of corporate policy. To those who would argue that IS policy is an entity unto itself – that it’s the same wherever we go – my reply to them would be that this mindset is what’s brought about the deconstruction of corporate IT.
IT exists to serve the corporation – not the reverse. Mvivi, if you have a copy of the ISPA you’re willing to share, perhaps we can discuss this further in the not-too-distant future.
Thanks for bringing ISPA to my attention.
June 25th, 2010 at 4:21 am
thank you for the analysis. however, how does these policy making process ralate to the problem solving situation?
June 25th, 2010 at 10:36 am
Policies often come about as a result of some problem. For example, someone abuses his Internet privilege by spending way too much company time on Facebook — as a result, that person is sacked and the company institutes a policy of restricting (or forbidding) Internet use.
The problem’s already occurred AND it’s because of one person (in this instance) that the policy was instituted. Policies often result from the actions of a few; the majority of employees don’t need a policy statement to tell them what is improper behavior.
The policy makes it clear what is expected and what will happen if the policy is violated. Also, any policy has to be enforced; otherwise, it’s worthless.
To sum it up, policy making is often part of the solution (i.e., corrective action).
February 6th, 2011 at 10:26 am
Can you please clarify the elements for assessing the impact of a policy?
February 8th, 2011 at 6:05 pm
Why was the policy implemented? What were the goals (objectives) of the policy’s author? Did implementing and enforcing the policy bring about the desired results? Were the objectives met?
Companies generally develop policy either to encourage desirable behavior or discourage undesirable behavior. Did you stop the bad behavior by instituting the policy, or did you promote good behavior? To what extent (e.g., 5% fewer incidents)? That’s how you assess the impact of the policy.