Skip to main content
RoadmapStatusChangelogStart Building Now

Introduction

An incident response plan is a set of tools and procedures that your security team can use to identify, eliminate, and recover from cybersecurity threats. 

It is designed to help your team respond quickly and uniformly against any type of external threat. Incident response plans ensure that responses are as effective as possible. These plans are necessary to minimize damage caused by threats, including data loss, abuse of resources, and the loss of customer trust. 

This guide will help you create an Incident Response Policy for your organization. We suggest that you work with your applicable internal team to assist with development of the policy. See below for the sections you should include when creating your firm’s policy.

Please note that policies set some parameters for decision-making but leave room for flexibility. They show the “why” behind an action. Procedures, on the other hand, explain the “how.” They provide step-by-step instructions for specific routine tasks. They may even include a checklist or process steps to follow.

Key Elements ​

Incident Response Policies typically include:

  • A description the purpose and scope of the policy/plan
  • The organization’s strategy for detecting incidents
  • Roles and responsibilities involved in incident response
  • Procedures for the incident response process
  • Documentation and tracking
  • Policy review and approval

Developing the Policy​

Purpose and Scope

Use this section to explain why an Incident Response Policy is needed and what systems, departments, data it applies to. It can be as simple as one sentence or more detailed according to the complexities of your organization. See examples below to get you started:

  • Example 1: This procedure defines the proper procedure for handling Information Security Events at CLIENT NAME. 
  • Example 2: This document describes the overall plan for responding to information security incidents at CLIENT NAME. It defines the roles and responsibilities of participants, characterization of incidents, relationships to other policies and procedures, and reporting requirements. This plan applies to the Information Systems, Institutional Data, and networks of CLIENT NAME and any person or device who gains access to these systems or data.

Detecting Events

Use this section to explain how your organization plans to identify/detect potential threats to your Information Security. Get as detailed as needed in order to cover specifics that pertain to your organization. See example below to get you started:

  • Sample: Information security events can be detected by CLIENT employees, business partners or customers. These events may be security incidents or system/service weaknesses and vulnerabilities. Information security events shall be reported to the CTO, heading CLIENT’s Incident Response Team, immediately as they are seen or experienced. The CLIENT Incident Response Team will log the event immediately when it is noted and assign it with a unique event number. The log will include the following details:

    • Detection Time
    • Notification Origin: CLIENT employee / customer / other
    • Short description of the event.

Roles/Responsibilities

Use this section to name those people in your organization that will be responsible for every part of the policy. It is recommended that you use job titles and not names of employees (keeps the document current instead of updating each time there’s a change in staffing). Get as detailed as needed in order to cover specifics that pertain to your organization. See example below to get you started:

  • Stakeholders key to the success of an Incident Response Policy: Chief Information Security Officer (CISO), Chief Compliance Officer (CCO), Chief Technology Officer (CTO), Incident Response Team, Security Team 

Responding to Events

Use this section to explain how your organization plans to handle or respond to threats, breaches, and other types of events. Get as detailed as needed in order to cover specifics that pertain to your organization. See example below to get you started:

  • Immediately upon receiving a report of an information security event or weakness, the CLIENT Incident Response Team shall assess and categorize the event. 
  • Include possible categories in a chart and detail how each category would be handled including a list of which categories (events) are priority or have the most critical impact. Examples of categories: Incidents, Vulnerabilities, Events, Unknowns.
  • Explain exactly what the response plan is for each category. For example: run reports, investigate, confirm affected systems, activity considered necessary to contain and recover, corrective actions, communication internally and externally, reports/notifications to regulators, vendors, etc.
  • Be sure to also include a plan for a data breach (data breach is an event that involves customer data, including personally identifiable information or PII.)

Documentation & Tracking

Use this section to explain how your organization will document, track and retain information pertaining to an incident. Get as detailed as needed in order to cover specifics that pertain to your organization. See example below to get you started:

  • Provide a list of what documents need to be retained. 
  • Where will they be retained, including the pathway to location.
  • Establish folder structures and naming conventions for ease of access for auditing purposes
  • It’s also helpful to have a post-mortem meeting with key stakeholders to discuss the effectiveness of the procedures.

Policy Review & Approval

Use this section to explain how your organization will structure a regular review of the Incident Response Policy so it stays current. Get as detailed as needed in order to cover specifics that pertain to your organization. See example below to get you started:

  • Determine a cadence for review of the policy for updates (at least annually is a suggested minimum)
  • Keep an audit trail of policy changes and approvals
  • Establish a testing program to test the effectiveness of your policy (in the event you don’t have any incidents but want to ensure the policy is “working”