Policies and procedures have very much in common. Procedures extend the scope of what policies start. Policies state who, what, and why. Procedures state how. Here is the complete list of all of the topics that need to be covered in both policies and procedures, denoting which topics are optional and which are required.

		Policy	Procedure
	Title	Required	Required
	ID	Required	Required
	Guarantor or approver	Required	Required
1.0	Policy overview	Optional	Optional
2.0	Purpose	Required	Required
3.0	Compliance with public and organizational rules	Required	Required
3.a	Recourse for non-compliance	Optional	Optional
4.0	Scope	Required	Required
4.a	Coverage	NA	Required
4.b	Assignment	NA	Required
4.c	Required knowledge	NA	Required
4.d	Required tools	NA	Required
5.0	Policy Description (policy) Extended definition (procedure)	Required	N/A
5.a	Procedure goals	NA	Optional
5.b	Supporting and supported procedures	NA	Optional
5.c	Procedure triggers	NA	Optional
5.d	Potential mishaps & reaction steps	NA	Optional
5.e	Successful execution	NA	Optional
5.f	Reports	NA	Optional
6.0	Procedure steps	NA	Required
7.0	Procedure checklists	NA	Optional

Optional and required sections of policies and procedures

There is no "set" look and feel of what a policy document should look like. They can be as simple as a word processing document with the required information, or they can be made to look like forms such as the one that follows[1].

Sample formatting for a policy document

Policy identification information

The policy identification information (Title, Control ID, etc.) is used to discern one policy from the next. When working with the Unified Compliance Framework, each control statement can act as a policy title, and each control ID within the UCF can serve as the control ID for your policy documents.

The effective date of your policy should be the date that the person who is approving it signs off that it is complete.

The revision date of your policy should be automatically entered if at all possible. Most word processing applications will allow you to enter a "modified date" field into your document so that when a user makes changes to the document, the revision date is incremented to the current date.

The revision number should always start with 1.0 for the original document and then be incremented in decimals in order to keep the numbers from reaching astronomical proportions as you continually update your policies (yeah, like that's going to happen, the updating that is).

Example policy title and identification information

Why we don't ask you to document revision history

Some authors will ask you to also document the revision history of your policy. That can automatically be done for you through most word processors and databases (if you are maintaining your policies and procedures in a database). Microsoft Word and Microsoft Sharepoint will both allow you to turn on version tracking and track all changes to documents as you create and edit them. Sharepoint will even go so far as to force the user to check out a document and then enter information into a field, documenting the changes when checking the document back in.

What we end up seeing if you add a manual revision history to the front of the document is that only a few cryptic notes were added that someone did this or that - nothing of substance has ever been added there. You can't recreate the older document or go back to an earlier version just by reading those notes and undoing the changes mentioned.

The better methodology is to use your software to create, and store, multiple versions of your documents that you force users to comment on and that allow you to reinstate the older versions. What follows is the version history of this section that you are reading now. Because of version tracking, we can go back to any one of the 8 earlier versions of this material and restore that that point.

Built-in version tracking in Word

Policy overview

The policy overview is probably the most important aspect of the policy as this is the heart of the whole thing. The policy overview should reflect the tone of the organization in its direction and meaning. Remember, a policy describes your organizational management's decision to enact a control or set of controls.

The policy statement should be both easy to read and easy to understand.

Some authors will tell you that you should begin each policy statement with the words "it is the policy of your company that..." Malarkey. If you are writing a policy statement for your organization, it is a given that this is the policy of the organization. Duh. You can just as easily state "the organization will..." or "the entity will..." naming the department or business unit that the policy belongs to.

The policy overview doesn't have to be long. In fact, it is better if it is not. Short, succinct, to the point. Here's our example for a policy statement that is a one-to-one relationship between a control and a policy.

The organization will ensure that the continuity plan addresses considerations and contingency solutions for websites (extranet, intranet, workflow) and coordinates those solutions with all relevant support groups.

When writing your policy overview for compliance, they can either be taken directly from the control statement in the regulation (if you only have to deal with one regulation) or can be taken directly from the policy statements that we supply within the Unified Compliance Framework.

Purpose

Your purpose should define the goal that you want to achieve. It, too, should be concise yet comprehensive, made up of two or three sentences at most. When finished reading this, the reader should know why they have to follow this policy.

The purpose of this policy is to ensure that the websites have been properly documented for configuration changes to the hardware and the software and any configurable items have been catalogued and accounted for in the continuity plan. The coordination steps are necessary to ensure proper integration with both security plans and incident management plans.

You know you've written a solid purpose statement when you can combine the policy statement and the purpose to form a logical what (policy) and why (purpose).

Always remember to add a "why" to your purpose statement

When writing this book, we got into a wonderful dialog about what should go into a policy. In general, a policy describes who should do what. In general, a policy is a directive that obligates personnel to follow it, regardless of whether they know why. However, within most organizations, where teamwork, consensus-building, and giving promotions based upon contributions and improvements (often resulting from questioning "why's") is more of the norm, we encourage companies to incorporate the "why" into their policy statements. Even though it adds a bit to the size of a policy, and is different from conventional views on the purpose of policies, we think that is okay. We're all for changing convention, and incorporating the human factor, if the ultimate result is (in this case) more effective information security and compliance. There are five reasons for adding the "why" to the purpose statement.

1. From a psychological impact perspective, most people in non-government and non-military enterprises will not blindly follow an order unless they know why they are being told to do so, and know and understand how it impacts them personally. If they can clearly and easily see how it impacts them, they are more likely to comply with it. If you want a policy to be effective and be followed (most of us do) then folks in these organizations must understand the reasoning behind them by being provided with the "why."

2. From an awareness perspective, incorporating the "why" of the policy into the policy itself makes the policy easier to understand and justify in the reader's mind. It also draws your personnel back to the policy itself more often if they want to understand why a policy has been implemented. It is always good to have policies that are actually read, and read closely, by personnel. Those that are issued, quickly glanced over and never looked at again are not as effective as policies that are read more than once.

3. From a compliance perspective, including the "why" into the policy itself can, arguably, help support regulatory requirements for awareness and training. In many of the organizations whose information security programs I've reviewed, their information security training efforts have consisted almost entirely of the (poor) practice of just copying the policies onto PowerPoint slides and requiring personnel to read them from their desks whenever they have time. If the "why" is part of the policy, then at least some actual education about the need for the policy can be passed on to the employee/learner.

4. From a business leader's perspective, knowing the "why" of the policy demonstrates the business need for the policy and makes clear that the policy was not just created because someone in the information security area thought it was a good idea. Business leaders want to know why someone else in the organization is putting restrictions upon them or giving them orders. If the "why" is right there within the policy then they can have this answer without spending what they will view as wasted time calling up someone in information security or, what is often the case, calling the CIO, or whatever CxO owns the information security area, and asking and complaining. If business leaders easily know "why" a policy is in place, they will more likely make sure the folks they manage are following the policy; their compliance actions example will then inspire compliance from their direct reports.

5. From an interpretation clarification perspective, it gives the user guidance when faced with gray areas at the edges of the policy - if they understand the "why," they are in a better position to make appropriate judgment calls when they come up.

Let's put this into practice. Below are two sets of purpose statements. Each in their original form and then followed by a version with the "why" added to it.

Original: This policy provides guidelines to protect the organization Information systems from malicious Internet attacks.

With the "why" included: This policy specifies some technologies that must be implemented to help protect the organization from malicious attacks from outside networks, such as the Internet, as well as help protect against malicious code and attacks that could originate within the network. Preventing such unauthorized intrusions and attacks will not only keep the business processes available to allow everyone to perform their work and meet their deadlines, it will also help our organization to comply with multiple laws and regulatory requirements to safeguard our customer information.

Original: Systems and network logs are supplemented with additional tools that watch for signs of intrusions or intrusion attempts, as well as alert responsible parties when such events occur. The purpose is to accumulate data from network and servers, building a "fingerprint" of usage.

With the "why" included: This policy provides the actions personnel must take, and the technology that must be implemented, to help ensure unauthorized attempts to access network and systems resources are identified, prevented and appropriate personnel quickly alerted. Preventing unauthorized access will help ensure unauthorized individuals do not access our business resources, as well as ensure the network is kept available for business processing and that the data used for business is accurate. Implementing logs and intrusion detection tools will also help our organization to comply with multiple laws and regulatory requirements to establish such information security safeguards.

The one caution we would add, however, is that the "why" not dilute the directive nature of the policy. A sophisticated end user may read the "why" statement, decide that the policy doesn't properly address the "why" in a particular situation and then take it upon him/her-self to make an exception to the policy. That would be the wrong answer. If they feel the policy should not apply because of the "why," they should follow the organizational policy for requesting exceptions. There are lots of different policies that could be used to address a particular "why" situation and the management of the company has determined to address it in the way articulated by the policy. It cannot be left up to the individual users to second-guess that decision based on their personal interpretations of the "why" statement that accompanies the policy.

Compliance

It is absolutely necessary to enter the citations for the authority documents that your policy complies with. This doesn't have to be anything fancy or complete, just a listing of the known documents and their citations. Why? Because they validate the policy. They demonstrate they are not just fluffy ideas, but necessary controls.

If you are using the Unified Compliance Framework's IT Impact Zone spreadsheets, audit guides, or policies and procedures, you'll have a full listing of all of the regulatory citations for each of the controls and you can use that list.

Recourse for non-compliance

Many policy authors add a section about the action steps that will be taken when users ignore or circumvent the policy. We feel that this is optional. However, in the absence of such information, you definitely need to ensure you have a sanctions policy; most regulations require them.

Scope

The scope always calls out who in the organization must abide by the policy in question. It is as simple as that.

Policy descriptions

A well written policy description will synthesize the what of the policy with the who of it as well as the why of it. There are two general types of policies, program-level policies and issue-specific level policies. We'll start with a simple issue-specific policy description first.

Issue specific policies need to be developed to address particular activities and sometimes particular systems. The policy revolving around documenting the website for the continuity plan is an issue-specific policy. Here's our purpose simply restated to thread the who, what, and why together.

The systems continuity and disaster recovery team will coordinate with the website design and management team to ensure that the websites have been properly documented for configuration changes to the hardware and the software and any configurable items have been catalogued and accounted for in the continuity plan. These coordination steps are necessary to ensure proper integration with both security plans and incident management plans.

Your description for the policy can also be a "Reader's Digest" version of your procedure steps if you have already written them - which is why this part is optional. Here's our example description to give you an idea:

While creating the documentation of the websites for the organization, the staff will ensure that the following information is being gathered and certified:

• Server configuration, hardening, and security testing

• Server configuration imaging and off site storage

• Application serial number backups and off site storage

• Program code testing to ensure that proper domain information is being supported (versus static IP addresses)

• Decisions about spare parts/duplication/replication of components

• Malicious code, patch management, anti-spyware management

• Server-level firewall and IDS decisions

• DNS and access control considerations (are these being protected by duplicating them off site?)

• Storage redundancy decisions (i.e., whether to store all data locally on RAID storage, within a Storage Area Network or across the network using iSCSI), including configuration information

• Server-level data backup/replication and storage decisions

• Server-level secondary power considerations

• Server-level cooling considerations

In addition to this documentation, the organization will ensure that proper coordination is conducted with the security team and the incident response team.

The whole point is to distill the contents of the procedure steps down into something that a manager will take the time to read and be able to understand as a policy. Which means that they should be able to read it in under 60 seconds and you shouldn't use technology words that might scare them.

Writing a program-level policy description for a grouped set of controls

Writing a program-level policy description for a grouped set of controls is slightly different, and can become much longer, than writing a statement where the policy and the control is a one-to-one relationship. The primary purpose of a program-level policy is to 1) document the organization-wide goals, 2) define the program management structure, 3) define the reporting responsibilities, and 4) clarify roles and responsibilities across a set of multiple controls.

For an example, let's look at a set of hierarchical controls from the UCF that have to do with reviewing and prioritizing each business unit's information processes (shown in the following diagram). For the sake of argument, we are going to tie all of the controls under "Communications systems considerations" (UCF ID 743) together into a single policy. And there isn't anything that we can find that says you can't do that. This means that our policy statement can't just reflect the policy for this single control. It must also state top level direction for each of the controls that fall beneath the one we chose to become our policy driver.

Nested controls within a single policy

The grouped policy would look something like this:

Emergency procedures for critical network equipment and services will include system capacity, and cabling provider, route, and central office diversity. [UCF ID 743] This will entail additional considerations as well, including:

1.   Local Area Network considerations: The organization will ensure that the continuity plan addresses considerations and contingency solutions for the local area networks that are critical to the communications infrastructure. [UCF ID 01381]

2.   Wide Area Network Considerations: The organization will ensure that the continuity plan addresses considerations and contingency solutions for the wide area networks, internet connectivity, and telecommunications services that are critical to the communications infrastructure. [UCF ID 01294]

3.   Primary and alternate telecommunications service agreements contain priority-of-service provisions: The organization will ensure that both the primary and alternate telecommunications (WAN, MAN, Internet connectivity, voice) service agreements contain priority-of-service provisions in accordance with the organization's availability requirements. [UCF ID 01396]

4.   etc....

The point we are trying to make here is that the policy can be written effectively as a one-to-one relationship between controls and policies, or just as effectively as a grouped set of controls under a single program-level policy. Of course, the grouped set of controls will have to be broken into several procedures. And we'll deal with that when we talk about procedures.