Exploring the IT Policy Creation Process

We’ve reviewed policies as a major type of documentation and why having policies are very important. Now, let’s jump into a brief overview of how a policy is created and effected. The IT policy creation process is as follows:

1. Recognize
2. Plan
3. Research
4. Draft
5. Approve
6. Adopt
7. Disseminate
8. Implement
9. Monitor

1. Recognize

You realize you need a policy when one or all of these items need to be covered:

1. Compliance with laws or regulations
   • such as HIPAA, PCI, FBI CJIS
2. Risk assessments and/or audits that reveal inconsistencies or gaps
   • such as username standard within AD
3. Guidance on best practices or clarification on departmental stances
   • such as password creation, safe web browsing, or other IT safety concerns
4. New services or technologies that change typical business operations in some way
   • such as using tablets instead of laptops or BYOD

2. Plan

Once you recognize a need to fulfill, you begin the planning process. These are likely questions to be asked:

• Why is this policy important?
• What is covered?
• What is the scope of applicability? (Who are the stakeholders?)
• Who do I need to contact to follow up with or to review the proposed policy (before approval process)?
• What information is related to this information?
• Where will the information be accessed?
• When does this policy take effect?
• When will the policy be updated?
• What are the enforcement or compliance conditions?

You may discover in the planning process the policy you are beginning to write is not entirely specific to IT. There may be other departments involved, such as HR, Risk Management, Legal, etc. Therefore, it’s important to determine who the stakeholders are.

A policy may spawn other policies within the organization or other departmental standards. For example, the IT department could have an email standard or guideline based on an office communications policy.

3. Research

With the general policy framework out of the way, you can focus on the topic itself. Don’t be afraid to look up information because conducting research is a task that never stops happening. A new policy writer may look at “best practices” within the IT industry or even in-depth articles about certain security methods. As this policy writer learns and evolves into an invaluable resource, research will still be necessary as technology, laws, and regulations change. Even at the simplest level of annually reviewing a policy, the policy writer should perform sufficient research to ensure the policy written a year ago is still relevant to his or her organization today.

4. Draft

Review example policies and sample templates. If you haven’t already, design a policy template that you’ll start with when drafting new policies. Then jot down your notes and rough ideas in the sections. Keep your research in mind and organize your thoughts accordingly. Once you clean up your draft and have a well thought out policy, it’s time to get approval.

5. Approve

The approval process differs among organizations. Generally, there are two main types of approval processes that happen. One is to get management or administration’s review, along with recommended or required changes. The second type is to involve committees or focus groups. The only real differences between the two are the amount of time it takes to get approval and whether or not the policy gets a trial run. Nearly everything else is similar or could be similar.

If the approval process mentioned above is overkill for your organization, then you need leadership support of some type. Either way, the approval process gives legitimacy and urgency to learning and understanding the policy.

6. Adopt

Once the policy is approved management or administration will adopt the policy. Establishing an adoption date is important for compliance with legal issues, especially if you’re on a time limit. Once the policy is acceptable it’s imperative to get leadership to adopt and promote the policy.

7. Disseminate

It’s best to have the policy in a central location so that users can find and read the policy with ease. Next is education and awareness. Once the policy can be easily retrieved, it’s best to facilitate the ease of adoption by holding training, reminders, meetings, or anything that pushes awareness within the organization. The goal is to avoid the excuse of ignorance by making reasonable accommodations for users to learn the policy.

8. Implement

Once the policy has been received or otherwise read, each business unit or department will most likely need to make changes to their business practices to be compliant. Identifying what needs to change is key to having sufficient time to implement the policy is important. During this transition phase, it’s crucial to have an easy to locate and easy to read the policy.

9. Monitor

As you’ve seen, writing a policy isn’t a “write it and done” type of activity. It even goes further than implementing what is written. You, as the policy writer, need to keep up with it. Policies and other related guidance documents need to be reviewed annually at a minimum. Although policies are generally broad and technologically agnostic, you still need to ensure policies are meeting legal and regulatory obligations. The verbiage also needs to make sense with your organization’s contemporary goals, current use of technology and cover modern best practices.

Also, after you’ve implemented the policy and have kept it updated, there needs to be a method to measure compliance with some type of audit. An audit can be as simple as a walkthrough. Some requirements, like systems covered by the CJIS Security Policy, for example, require detailed system and network account logs. It’s up to your organization to put standards and controls in place to not only monitor compliance in users but also the life of the policy itself.

Conclusion

It’s pretty normal to run into people who don’t like the policy and want an exception. Exceptions to policies are usually not tolerated. In the case where exceptions are necessary due to business interruption or other important concerns, the requesting party must comply with the policy exception process. It’s up to you how this is done but it does require mutual agreement between the requesting department and your department.

Some organizations also require authorization from management or administration in addition to the mutual agreement for exemptions. Once approved, you may consider adding an addendum to the policy describing a permanent (and perhaps non-perpetual) and public exception for a business unit or departmental group. The addendum would need to explain why the business unit or department does or does not follow the policy and what controls they would have to follow instead in order to keep up the legitimacy of the policy.

One thing you may wish to do as more policies are being written is to number your policies. This practice will help your IT security framework to stay current. To put this in perspective think of how statutes and other depositories of information achieve organization through article and policy enumeration.

Research based in part by:

1. IT Policy Development and Administration Framework by University of Michigan

1. Policy Administration Process for university wide IT policies, by Indiana University
   1. IU Online Information Security and Privacy Program
2. Policy Development Process with Best Practices by the Association of College and University Policy Administrators
   1. IT Policies
3. IT Policy Process by University of Wisconsin-Madison
4. Policy Development Process by Ohio State University
   1. Their IT policy layout is awesome by the way.

2. Policy Development and Approval Process by Iowa State University

My experiences have reflected the research found in the University articles mentioned above. What do you fine folks think? Does this overview reflect your education or experience of creating a policy?