Policies, Standards And Procedures

Nothing bothers me more than asking for an organization’s firewall policy (or any policy actually) and getting my own personal version of ‘War and Peace’. The document is a mix of policies, standards and procedures all in a vain attempt to get as many topics covered as possible in a single document. And then the writers of these tomes wonder why no one actually reads them and therefore they have little or no compliance.

As that as our backdrop, here is my take on how to properly write policies, standards and procedures.

POLICY

Webster’s dictionary defines a policy as:

“a high-level overall plan embracing the general goals and acceptable procedures”

The key phrase here is “high level” not details like I encounter in most policies I read.

At a minimum, a policy needs to cover the following topics.

• Problem statement. This section defines the problem or issue that the policy addresses. This should be no more than two paragraphs and should be devoid of technical terms or legalese if at all possible. If you are taking more than two paragraphs, then you either need to figure out how to be more concise or maybe you are covering too much ground with just one policy. Do not be surprised when you write your problem statement that you figure out ways to consolidate topics or better define topics. For example, why write separate electronic mail, letter writing, facsimile and texting policies when they are all forms of business communications and then just write a communication policy.
• A bullet point or numbered list of the objectives of the policy. Are you protecting the assets of the organization? Are you minimizing the potential for fraud? Are you informing employees of their rights? Document the objectives you are trying to achieve with this policy.
• Policy statement. Define the organization’s position and solution(s) regarding the problem documented from the problem statement.
• Define who is responsible for what. Explain the responsibilities of boards, committees, all personnel, corporate officers of the organization and anyone else that is affected by this policy such as contractors or temporary help.
• Policy management information. This is a block of information such as the date of issue, the last date of review, board approval date and other information that might be required to prove that policies are updated and reviewed.

The Guru’s rule of thumb is that a policy should be no longer than two to three pages in length. Actually the shorter the policy the better. Anything longer than that and it is not a policy.

As an example, here is that Communication Policy.

Problem Statement:

The organization provides employees with a variety of communication capabilities. As with any form of communication, care must be taken to ensure that the organization is represented appropriately and intellectual property is appropriately protected.

Objectives:

1. Ensure the appropriate use of organization assets.
2. Ensure the protection of the organization’s intellectual property and sensitive information.
3. Notify employees of their rights when using organization-provided communication systems.

Policy Statement:

The organization provides a variety of communication systems including, but not limited to, written, pager, telephone, cellular telephone, facsimile, voice mail, electronic mail and instant messenger systems. These communication systems are for employee use in conducting organization business. The personal privacy of these communication systems is not guaranteed by the organization, as the organization may, from time to time, find it necessary to monitor communication systems and traffic to protect its intellectual property, sensitive information and other critical assets.

As with any method of communication, employees are to conduct such communication in a dignified and business-like manner. Failure of an employee to communicate with other persons in a dignified and business-like manner will result in disciplinary action and possibly termination.

While the use of the communication systems are specifically for conducting the business of the organization, management recognizes that personal use of the communication systems will occur. Employees are to minimize personal usage of the organization’s communication systems. Should personal usage become a problem, the organization will take steps to restrict personal communication that include, but are not limited to, disciplinary action and technical measures to limit or restrict personal communication.

Responsibilities:

The Corporate Security Officer (CSO) is responsible for development, implementation, dissemination, and monitoring of appropriate communication policies, standards and procedures. The CSO is also responsible for the development and implementation of an internal training program to educate personnel on the communication policies, standards and procedures.

Employees, contractors and temporary personnel will be required to attend a policy training course as well as sign an acknowledgement statement that refers to the organization’s policies regarding the use of the organization’s communication systems at time of on-boarding and annually thereafter. Failure to sign this statement will be grounds for termination of employment/contract.

Information systems management is responsible for implementing, maintaining and monitoring appropriate methods for securing and monitoring automated communication systems.

Internal Audit is responsible for periodic audits of the organization’s automated communication systems capabilities to ensure compliance with the communication policies, standards and procedures.

The head of Human Resources is responsible for the management oversight of this policy.

There are a number of other policies, standards and procedures that support this simple policy. All of those support and facilitate this document. But hopefully this provides you an example of what a policy should look like.

STANDARD

To continue with definitions, Webster’s defines a standard as:

“something established by authority, custom, or general consent as a model”

The key word with this definition is “model”. Standards define for example how device names will be formed, how IP address ranges will be defined and where those addresses will be used, how to properly code in various programming environments, network architecture for where and how to use firewalls and other security devices and the obvious how devices will be configured.

It is allowable to put hyperlinks to Internet documents or other reference documents so that you do not have to constantly update those documents. Where I encounter this the most is with device configuration standards. An organization that for example has Cisco equipment can provide hyperlinks to the relevant Cisco configuration and security standards for the various versions of IOS or Nexus standards on Cisco’s Web site so that the organization can leverage Cisco’s documentation.

Standards can be long or short, but the key is that a standard needs to address the model you are trying to establish.

PROCEDURE

Webster’s defines a procedure as:

“a series of steps followed in a regular definite order”

A proper procedure is a checklist or a numbered list that tells anyone how to complete some process. Examples of procedures are:

• Checklists for configuring a device that proves that the standard(s) involved were followed.
• Daily operations checklists to document that all daily procedures were performed.
• Monitoring procedures for ensuring that all devices are properly monitored.
• Incident response procedures documenting how to respond correctly to particular alerts that could be an incident.

The key though with procedures is that they must be complete so that anyone can perform them. And when I say anyone, I mean anyone. If you have never been through procedure writing, the best example I can give you is to write down instructions for tying a pair of shoes and then give them to a co-worker and have them follow those instructions. You should find that it is not as easy as you might think and will take many revisions to get a set of working instructions.

When I was a CIO, the way I tested procedures was to perform them myself. What started this practice was an extended power outage one night and our UPS systems required us to shut down the data center. When the power came back on around 4AM, the night operator was not able to get the systems back up and running because he had no procedures to follow. As a result, when I got in at 6AM systems were still powered down and the day operator was waiting for some key people to get everything back up. I gave the IT staff three days to prepare start up and shut down procedures for all systems and then came in on a Sunday and tried them out myself. Needless to say, that Sunday did not go as well as people expected and a lot of updates and changes to those procedures were made. However, once those procedures were complete, I could have gotten the Chairman of the Board to restart the data center.

Hopefully this gives you the guidance you need to properly write policies, standards and procedures. I think you will find as I have that properly written, such documentation can be very useful in clearly communicating with everyone involved in your organization.

Advertisement