When it comes to workplace incidents, being prepared is your best defense. A set policy and response plan ensures that you address incidents of all types quickly, thoroughly, appropriately and consistently. From loose carpeting to a major data breach, all employees will know exactly what to do when an issue arises.

Use this guide to get started writing your organization's incident management policy.

Define the Purpose and Scope

First, state the purpose and/or objectives of your incident management policy. Why are you writing it? What do you hope to achieve with it? How will it help your employees, business partners, clients and/or customers?

For example, here is the purpose section from the United States Postal Service (USPS)'s policy:

"The purpose of this policy is to ensure that any incidents that affect the daily operations of the Postal Service Technology Environments are managed through an established process. USPS will utilize the best practice framework for the implementation of Incident Management within Postal Service Technology.

Incident Management is the process that defines an unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also considered an incident.

The goal of Incident Management is to restore the IT service to its normal operation within agreed service level targets and to manage unplanned events which result in the following:

• Interruption to the normal operation of an IT service.
• Report or notice of a reduction in the quality of an IT service.
• Failure of a Configuration Item (Cfg-Item) that has not yet impacted an IT service."

Next, define the scope of the policy. What types of incidents does it cover? Who must follow it? Where is it applicable? What equipment, tools and/or systems does it cover?

This example from the City of Delray Beach, Florida, covers just IT incidents:

"The Incident Management policy will govern the decisions and actions taken in the course of City of Delray Beach (CDB)’s IT Infrastructure standard services failures which causes, or may cause, an interruption to, or a reduction in, the quality of that service. The scope of this policy applies to all incidents reported by CDB’s IT analysts or engineers, to include vendors & third party contract personnel (consultants/contractors) regarding IT Infrastructure hardware, software, system components, virtual components, cloud components, networks, services, documents, and processes."

Alternatively, your policy might be broader, like this one from James Cook University: "This Policy covers all staff, students, affiliates contractors, volunteers, tenants, visitors, and controlled entities, when responding to, and dealing with, a range of incidents and emergencies that may impact on JCU campuses, remote sites, and residences."

RELATED: What is Incident Management Software?

Classify Incident Responses

Next, your incident management policy should discuss the different classifications of incidents and how to respond to each. This not only refers to incident types (if they fall within the scope) but different levels of urgency as well.

Include information on the responsibilities, reporting procedures and response time for each incident type and urgency level. List these either alongside the incident classifications or in a separate color code section, like in the example above.

Classifying incidents in your policy will help you respond quickly and consistently when something goes wrong.

RELATED: How Incident Management Software Protects Your Company

Discuss Drills and Testing

Having a good incident management policy on paper is one thing, but employees should know how to apply it in practice, too. Drills and testing help employees prepare so they know what to do if a real incident happens. In addition, drills highlight the strong aspects of your policy and what parts need to be changed.

While some types of incidents can't be tested, consider testing employees on:

• Cybersecurity incidents such as data breaches
• Physical security incidents such as break-ins
• Safety incidents such as a chemical spill or broken equipment

How will you test for each type of incident? How often? Who is in charge of running the drills and assessing the results?

Note Policy Reviews

Policies shouldn't be written once and never changed. They need to be reviewed regularly to ensure that they still meet your company's mission, mandate, image and needs.

In your incident management policy, include a reviewing schedule and procedures. Who will review the policy? How often will it be reviewed? What is the process when you're updating the policy after an incident occurs versus during a scheduled review?

At the bottom of the document, note updates and changes, as well as when these went into effect. This can help you learn from past mistakes and see how far your organization has come with its incident management process.