Guidelines on Policy Content

When developing content, many go about creating a policy exactly the wrong way. The goal is not to create hundreds of pages of impressive-looking information, but rather to create an actionable security plan. The following guidelines apply to the content of successful IT security policies.

A security policy should be no longer than is absolutely necessary. Some believe that policies are more impressive when they fill enormous binders, or contain hundreds or thousands of policies. In fact the sheer amount of information in those policies is what makes them useless. Brevity is of the utmost importance.

• A security policy should be written in “plain English.” While, by nature, technical topics will be covered, it is important that the policy be clear and understood by the target audience for that particular policy. There is never room for “consultant-speak” in a security policy. If there is a doubt, the policy should be written so that more people can understand it rather than fewer.

• A security policy must be consistent with applicable laws and regulations. In some cases there are laws that apply to a company’s security practices, such as those covering encryption. Some states have specific disclosure laws and some industries have specific regulations. Research and become familiar with any regulations or laws that apply to your company’s security controls.

• A security policy should be reasonable. The point of this process is to create a policy that you can actually use rather than one that makes your company secure on paper but is impossible to implement. Find a middle ground in the balance between security and usability that will work for you.

• A security policy must be enforceable. A policy should clearly state what actions are permitted and what actions are in violation of the policy. Further, the policy should spell out enforcement options when non-compliance or violations are discovered.

For more information visit www.InstantSecurityPolicy.com.

What a Security Policy Should Cover

A security policy should be written so that it can be understood by its target audience (which should be clearly identified in the document). For example, technical policies can by nature be more technical than policies intended for users, which should be written in everyday language. At no point should a security policy use confusing or obscure legal terms.

A security policy should not allow room for misunderstanding so that there is universal understanding of the policy and consistent application of security principles across the company.

A Security policy should have, at minimum, the following sections.

• Overview: Provides background information on the issue that the policy will address.
• Purpose: Specifies why the policy is needed.
• Scope: Lays out exactly who and what the policy covers.
• Target Audience: Advises for whom the policy is intended.
• Policies: This is the main section of the document, and provides statements on each aspect of the policy. For example, an Acceptable Use Policy might have individual policy statements relating to Internet use, email use, software installation, network access from home computers, etc.
• Definitions: For clarity, any technical terms should be defined.
• Version: To ensure consistent use and application of the policy, include a version number that changes with any changes to the policy.

For more information visit www.InstantSecurityPolicy.com