We've already discussed four important attributes of a good identity policy. In addition to those specific attributes, there are important guidelines that will help ensure that your policies are implementable, enforceable, understandable, and guided by the business:
Never release a policy that you can't or won't enforce. Creating policies that people ignore weakens the process.
Build a policy review framework. The review framework is a document that gives status information and a review schedule for each policy.
Good policies are general enough to not need frequent updating. Policies should be unambiguous without being so specific that they lose their relevance with every change to the business operations of the organization.
Avoid referencing specific standards or products in your policies. Instead, use an interoperability framework to call out specific products and standards. Merely reference specific sections of the interoperability framework in the policy. This will ensure that policies don't have to be continually updated as new products and standards are released.
Policies should not specify processes or "best practices." Policies, however, should talk about "what" not "how."
Policies should not contain confidential or proprietary information, because they will be widely distributed. When this is unavoidable, be sure that the policy is properly classified and that chosen classification allows everyone who must see it to have access.
Rather than writing large, monolithic policies, break them into short, modular documents and cross-reference specific sections when needed. Develop modular policy structures just as you would modular software. The benefits are similar. Short modular policies:
Can be reused by reference from multiple places
Benefit from being written by an expert in that specific area
Are relevant for a longer period of time
Are easier to maintain
Make sure that your human resource and legal teams review policies as part of the review process. This is especially important where enforcement is concerned. Without proper review, you likely will not be able to take action against individuals.
Use a document management system for controlling the policy writing process. This same system can be used to distribute and version policies when they are complete. Writing policies in a word processor, using email for workflow, and putting together a simple web site for distribution works for small numbers of documents with infrequent modification but becomes unwieldy for more active policy maintenance processes. This needn't be an expensive proposition. Plone, an open source document management system, is certainly up to the task for almost any organization.
Rather than starting from scratch, consider buying policy templates from one of the many security vendors or consulting companies who service this market. Alternately, hiring a consultant to put together an identity policy suite specific to your organization may jump start the process and give you a number of workable policies in fairly short order. A set of sample policy templates that mirror the identity policies discussed next is available at http://www.windley.com/identity-policy.
What should a policy look like? Typically, identity policies have a set of sections that follow an identifiable outline . I recommend the following sections:
This section is typically just a paragraph or two long and answers the question, "Why is this policy needed?"
This section is also generally short and identifies what is covered by the policy.
This section is simply a list of definitions of terms used in the rest of the document. Clear definitions are important in avoiding ambiguity in later sections and avoiding lengthy explanations of concepts in the main body of the policy. Note that the point of this section is not to give dictionary definitions so much as to give definitions specific to the organization and how the words are used in the policy.
This section is a list of other policies, standards, and documents that are used in the body of the policy.
This section is the main body of the document and describes in detail the requirements of the policy. This section may have a number of subsections.
This section describes what actions will be taken when the policy is violated. Some enforcement actions may be against personnel (e.g., an HR action), and others may be against organizations (e.g., a budget action). In the case of personnel actions, you typically won't include them in the policy directly, but by reference to the appropriate HR policy.
This section lists who is responsible for the policy and its review, modification, and enforcement. Specify this by title and position, not name, so that the policy is not outdated by irrelevant personnel actions.
This section documents each revision by date and the primary changes.
The specific policies you develop may have all or only some of these sections depending on the circumstance. I recommend that you develop a policy template for your organization and use it for every policy so the policies have a consistent style and format.