We've reviewed policies as a major type of documentation and why having policies is very important. Now, let's briefly overview how a policy is created and effected. The IT policy creation process is as follows:
- Recognize
- Plan
- Research
- Draft
- Approve
- Adopt
- Disseminate
- Implement
- Monitor
Table of Contents
1. Recognize
You realize you need a policy when one or all of these items need to be covered:
- Compliance with laws or regulations.
- such as HIPAA, PCI, FBI CJIS.
- Risk assessments and/or audits that reveal inconsistencies or gaps.
- such as username standard within AD.
- Guidance on best practices or clarification on departmental stances.
- such as password creation, safe web browsing, or other IT safety concerns.
- 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?
In the planning process, you may discover that the policy you are beginning to write is not entirely specific to IT. Other departments may be 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. 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 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. It's time to get approval once you clean up your draft and have a well-thought-out policy.
5. Approve
The approval process differs among organizations. Generally, two main types of approval processes happen. One is to get management or administration's review and recommended or required changes. The second type is to involve committees or focus groups. The only real differences between the two are the 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. 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 it. 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 it.
7. Disseminate
It's best to have the policy in a central location so that users can easily find and read it. 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 likely need to change its business practices to comply. 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 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 must be reviewed at a minimum annually. 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 of your organization's contemporary goals and 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 those covered by the CJIS Security Policy, require detailed system and network account logs. It's up to your organization to put standards and controls in place to monitor user compliance and the life of the policy itself.
Conclusion
It's normal to encounter 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 add 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 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 information depositories achieve organization through article and policy enumeration.
Research based in part by:
1. IT Policy Development and Administration Framework by University of Michigan
- Policy Administration Process for university wide IT policies, by Indiana University
- Policy Development Process with Best Practices by the Association of College and University Policy Administrators
- IT Policy Process by University of Wisconsin-Madison
- Policy Development Process by Ohio State University
- 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?
