Writing policy statements is like writing a legal contract. First, two parties must agree on what they want to achieve, and then they must put it in a contract. If the two parties can’t agree on what they want to achieve, they can never agree on the contract language. In writing security policies, too, this first step is often missed. When this occurs, the resulting policy language can lack context, and the goals may seem confusing. In contrast, following an implementation process (as previously depicted in Figure 13-1) means getting agreement on a target state with funding and executive support.

Writing policies supporting an agreed-upon target state is much easier and provides a way to quickly gain approval for supporting policy language. Still, don’t underestimate the time it takes, especially in a large organization. Words can have different meanings to different people. You want to create a clear and concise policy in language that is easily understood.

Don’t use imprecise language such as “should” or “expected.” For example, consider a policy that states, “You should use an eight-character password.” Do you have to? It sounds more like a suggestion than a rule. A clearer policy statement would be, “You must use an eight-character password.”

Be sure to assign clear accountability to specific roles. You must assume at some point that a policy will not be followed. The language must indicate who is accountable. For example, assume the policy language states, “Management is responsible for reviewing an employee’s access every 90 days.” Who is “management”? The manager? The line supervisor? The executive over the department? This language can be confusing. A better policy language statement would be, “All employees with direct reports must review their direct reports’ access every 90 days.” You can now go to a system of record (such as a corporate directory) and determine who should be performing what reviews.

Be sure to be precise about which resources the policy covers. Avoid requiring specific products in a policy. Policies should focus on what needs to be achieved and not how. Often, technology policy can have broad implications across multiple technical environments. A lack of precision and a failure to state a solution can be confusing and limiting. For example, assume a policy states, “All servers must use EFS when storing credit card information.” Encrypting File System (EFS) is a feature of Microsoft Windows that can be used to encrypt information on a hard drive. This policy is not precise and limits encryption to a specific vendor product. It’s not unusual to put technical limits on solutions, such as requiring a minimum of 256-bit encryption. But it’s not a good idea to require specific vendor products in policy.

Here’s why: First, EFS is a Windows product. How do you store credit card information if you’re using a UNIX or Linux platform? Second, the policy objective should not be the use of EFS. The objective should be the encryption of the credit card information. This allows the flexibility to use the appropriate solution or tool.

Additionally, the policy as written is unclear. Does it allow credit card information to be stored on laptops? If a server is the only place you are allowed to store credit card information, the policy must state that clearly. A better policy statement would be, “Only production servers may be allowed to store credit card information. Additionally, all credit card information must be encrypted when stored.” You can still limit which technologies can be used by adding, “Only an approved encrypted solution may be used.” That addition allows control over which specific encryption products can be used by calling for a defined approval process.

The key point is to be sure that there’s clear agreement on the target state. Use that agreement to write the supporting language in policy. When writing policy, use precise language that clearly defines the outcome and assigns accountability.