How to Write an Incident Response Plan Your Team Will Use

An incident response plan is a written agreement about how your organisation will react when something goes wrong. It names who does what, how decisions are made and how people are told. Its value is in the preparation: the decisions are made before the incident, when people are calm.

The most common failure is a plan that is too long. A forty-page document is not opened during an incident. Keep the plan to a few pages that can be read in minutes, and move detail into linked runbooks.

1. Purpose and scope

State what the plan covers: which services, which types of event and which teams. State what it does not cover, such as personal data breaches that follow a separate legal process, if that is the case in your organisation. Name the owner of the plan and the date it was last reviewed.

2. Definitions

Define what counts as an incident and the severity scale, with criteria for each level. Keep the definition operational: a responder must be able to decide in a minute whether to declare. See the guide to severity levels.

3. Roles and responsibilities

List the roles: incident commander, operations lead, communications lead, scribe and the others you use. For each, state the duties and name the people or the rota who fill it, with deputies. Say who may declare an incident. The best answer is anyone.

4. Detection and declaration

Describe how incidents are raised: monitoring alerts, customer reports and staff reports. State the channel for reporting and how to declare. Record where the incident record is kept so that all responders write to the same place.

5. Escalation and on-call

State who is on call and how to find out. Describe the escalation path: whom to page first, how long to wait for acknowledgement, whom to page next and what happens if nobody answers. See the guides to on-call management and to escalation paths.

6. The response procedure

• Acknowledge and assess. Confirm the symptom and set a severity.
• Open the coordination space and the incident record.
• Assign roles and state them aloud.
• Reduce customer impact first, then pursue the cause.
• Post updates on the agreed cadence.
• Decide when to escalate or roll back.
• Declare mitigation and resolution, and record how it ended.

7. Communication

Define the audiences, the cadence per severity, the channels, who may send customer communication and who must approve it. Attach the templates. See the incident communication guide.

8. Legal and regulatory obligations

Some incidents trigger notification duties, for example where personal data is involved or where you operate in a regulated sector. List the obligations that apply to you, who decides whether they are triggered and who is notified inside the organisation. This section should be written with your own legal advisers. A plan template cannot tell you which laws apply to you. Atlas offers regulatory notification clocks as a scheduling aid that counts from the event each regime names, and states that it is not legal advice.

9. Review and improvement

State that every incident above a given severity gets a blameless review within a set number of days, who runs it, and how follow-up actions are tracked to completion. See the post-incident review guide.

10. Drills and maintenance

• Run a tabletop exercise at least twice a year, using a realistic scenario and playing the roles.
• Check that contact details and the on-call schedule are current.
• Revise the plan after each real incident, and after each drill.
• Confirm that new joiners know where the plan is and what their part is.

Where Atlas fits

The plan is a document, and the incident record is where it is applied. In Atlas you declare the incident, assign the roles, keep the timeline, attach the conversations, send approved customer updates and write the review in one place. You can keep the plan itself in your workspace documents and link it from the incident process so that it is one click away.