Incident response plan template
An IT incident response plan template covering severity levels, roles, escalation and communication.
Eduardo Messuti, Founder and CTO Last reviewed September 4, 2026Most incident response goes wrong in the first ten minutes, not the last. Nobody is sure whether this counts as an incident. Nobody is sure who is in charge. Three people are debugging the same thing while nobody updates the status page.
An incident response plan settles those questions before anything breaks. It defines what an incident is, how severe it is, who does what, how people are paged, who says what to whom, and what has to happen before the incident is closed.
This IT incident response plan template is based on how five teams that publish their engineering handbooks actually run incidents: GitLab, PostHog, Sourcegraph, Login.gov and Fleet. Where they agree, the template follows them. Where they differ, the guide says so and leaves the choice to you. The sources are listed at the end.
The template
Incident response plan
Plan details
- Service or scope
- Plan owner
- Version
- Last reviewed
- Review cadence
What counts as an incident
Define the threshold in advance so nobody debates it mid-incident. When in doubt, declare.
- Always an incident
- Not an incident
Severity levels
Tie each level to impact criteria and a response expectation. Severity can be changed as the picture becomes clearer.
| Severity | Impact criteria | Response expectation |
|---|---|---|
Roles and responsibilities
One person leads. Roles are hats, not job titles — a small team can have one person wearing several, and they can be handed over mid-incident.
| Role | Responsibilities | Who fills it |
|---|---|---|
Declaring an incident
- Who can declare
- How to declare
- Where it is announced
First 15 minutes
The checklist the incident lead runs as soon as an incident is declared.
Escalation
| Trigger | Escalate to | Response time |
|---|---|---|
- On-call schedule
- Out-of-hours rule
Communication plan
Who hears what, where, from whom and how often. Internal detail never goes out unedited.
| Audience | Channel | Owner | Cadence |
|---|---|---|---|
- Status page
- Status page required for
- Communication templates
Resolution and follow-up
- An incident is resolved when
- Incident report required for
- Postmortem required for
- Postmortem due within
- Corrective actions tracked in
Tools and resources
- Alerting and paging
- Incident chat
- Status page
- Runbooks
- Monitoring dashboards
- Incident report template
- Postmortem template
What is an incident response plan?
An incident response plan is the standing document your team follows when production is degraded or down. It is written in calm conditions and read under pressure, so it has to be short, specific and unambiguous.
It is not a runbook. A runbook says how to fix a particular system. The plan says how the team organizes itself around any incident, whichever system is involved.
It is also not a security incident response plan in the compliance sense, although the two overlap. This IT incident response plan template covers operational incidents: outages, degradations, failed deployments, data-pipeline delays and the like. Security-specific incidents usually escalate into a separate process, and the plan should say where that handover happens.
Why you need one before you need one
These handbooks agree on one thing above all: lower the bar for declaring. GitLab's handbook defines incidents as "anomalous conditions that result in — or may lead to — service degradation or outages." PostHog's says "when in doubt, you should always raise an incident." Login.gov's guide puts it as "if it smells like an incident, declare an incident."
That only works if declaring is cheap and the next steps are obvious. A written plan is what makes a false alarm cost five minutes instead of an argument.
A plan also gives you something to measure against. Without one, every postmortem concludes that "communication could have been better." With one, you can say the first status page update went out at 22 minutes against a 15-minute target, and fix the specific thing that caused the delay.
What should an incident response plan include?
Definition and scope
Say what an incident is and, just as usefully, what it is not. PostHog's handbook lists both: complete unavailability, core features unusable and critical alerts are incidents. Incorrect data in a report, events a few minutes behind and scheduled maintenance are not. The negative list stops small bugs from being run through the full process.
Severity levels
Every handbook uses a small number of levels, each tied to impact and to a response expectation. GitLab runs S1 to S4. PostHog uses Minor, Major and Critical. Sourcegraph splits Severity 1 into Critical and Major and routes Severity 2 through normal support channels.
The labels matter less than two things. First, each level needs impact criteria that a responder can apply in seconds. Second, each level needs to change something about the response: who gets paged, whether the status page is updated, whether leadership is told, whether it is worked out of hours. GitLab's rule that only S1 and S2 are actively mitigated on weekends is a good example of severity doing real work.
Roles
Every plan names a single owner. GitLab calls it the Incident Lead and is explicit that "only one designated Incident Lead per incident" exists and only they can declare resolution. Sourcegraph calls it the incident lead, the directly responsible individual "tasked with driving it to resolution and keeping others informed."
PostHog adds the clarification that most teams miss: "The incident lead role is not responsible for fixing the incident, they're responsible for managing it." If the same person is doing both and it becomes too much, they hand the lead role to someone else.
Beyond the lead, the common roles are a technical responder, a communications owner and, in larger or regulated teams, a scribe. Login.gov's guide names all four: Situation Lead, Technical Lead, Messenger and Scribe. Sourcegraph only assigns a Messenger when there is customer-facing impact, and requires that they come from support so wording stays consistent. Small teams can collapse roles into one or two people. What matters is that the plan says which hats exist and who picks them up.
Declaring an incident
Say who can declare, how, and where it is announced. In every one of these handbooks, anyone can declare, and a Slack command opens a dedicated channel and posts to a shared incidents channel. Fleet is the exception in mechanism, not principle: incidents are declared by opening an issue from a template, which triggers the paging.
A short first-actions checklist belongs here. Confirm the lead, set an initial severity, page who is needed, post a first status page update, start the timeline. GitLab's status page flow of Investigating, Identified, Monitoring and Resolved is a sensible default for the public side.
Escalation
Write down the triggers and the targets. Fleet's handbook is precise: if a notification is unacknowledged after five minutes it escalates automatically, from infrastructure on-call to incident on-call to engineering managers to the CTO. GitLab pages infrastructure leadership for every S1, when the incident manager on call is unresponsive for 15 minutes, and when several high-severity incidents are open at once.
Include a separate line for suspected security or data incidents. Every handbook routes those to a dedicated process, and the plan should say who to call rather than assume responders know.
Communication plan
Decide who hears what, on which channel, from whom, and how often. Internal channels carry detail, theories and names. The status page carries confirmed impact and what customers should expect. PostHog's handbook draws the line at incidents causing partial or full non-operation, or ingestion delays over 30 minutes, for customer communication beyond the status page.
Set an update cadence and hold to it. A status page that says "Investigating" for two hours with no further update is worse than one that says "still investigating, next update in 30 minutes" every half hour.
Resolution and follow-up
State what "resolved" means. PostHog's criteria are concrete: root cause identified, fix implemented, customer-facing services confirmed normal, status page marked resolved. Then say which incidents get a written incident report, which get a postmortem, and by when. GitLab requires a review for every S1 and S2, makes it optional for S3 and S4, and tracks each corrective action as a labeled issue linked back to the incident. Fleet requires a postmortem for every outage and critical bug.
Tools
Link to the paging tool, the on-call schedule, the incident chat, the status page, runbooks, dashboards and the report and postmortem templates. Responders should never have to search for a link at 3 a.m.
The following abbreviated example shows how a small SaaS team might complete the template.
Plan details
Scope: The customer-facing web app, public API and data ingestion pipeline Owner: Platform Engineering Review cadence: Quarterly, and after every S1
What counts as an incident
Any unplanned event that degrades or interrupts the web app, API or ingestion for customers, or that exposes customer data. Suspected incidents are declared and downgraded later if needed. Scheduled maintenance and single-account bugs with a workaround are not incidents.
Severity levels
| Severity | Impact | Response |
|---|---|---|
| S1 | App or API down, or data loss or exposure | Page 24/7, all hands, CTO notified, status page within 15 min |
| S2 | Core feature unusable for many customers, or ingestion delayed over 30 min | Page 24/7, status page within 30 min |
| S3 | Limited impact or workaround available | Business hours, status page optional |
| S4 | Minor, little or no customer impact | Normal ticket |
Roles
| Role | Who |
|---|---|
| Incident lead | Whoever declares, handing over to the on-call engineering manager for S1 |
| Technical lead | On-call engineer for the affected service |
| Communications lead | Support on-call, required for S1 and S2 |
| Scribe | Any responder not actively fixing |
Declaring
Anyone can declare by running /incident in Slack. This opens a dedicated channel, posts to #incidents and pages the on-call engineer. The declarer is the incident lead until they hand over.
Escalation
| Trigger | Escalate to | When |
|---|---|---|
| Page not acknowledged | Secondary on-call, then engineering manager | After 5 min, then 10 |
| S1 declared | CTO | Immediately |
| Suspected data exposure | Security lead and legal | Immediately |
| No working theory | Service owners | After 30 min |
Out of hours, only S1 and S2 are worked. S3 and S4 wait for the next business day.
Communication
| Audience | Channel | Owner | Cadence |
|---|---|---|---|
| Responders | Incident channel | Incident lead | Continuous |
| Company | #incidents | Incident lead | Every 30 min for S1 and S2 |
| Customers | Status page | Communications lead | Within 15 min, then every 30 min |
| Support | #support | Communications lead | On every status change |
Resolution and follow-up
Resolved when customer impact has stopped, the mitigation is confirmed stable and the status page is marked resolved. Every incident gets an incident report. S1 and S2 get a postmortem within five business days, with corrective actions tracked as issues linked to the incident.
Incident response plan vs. runbook vs. incident report
These three documents are written at different times and answer different questions.
| Document | Answers | When it's written |
|---|---|---|
| Incident response plan | How does the team organize around any incident? | Before incidents, reviewed regularly |
| Runbook | How do we diagnose and fix this specific system? | Before incidents, per system |
| Incident report | What happened in this incident and what did we do? | During or right after the incident |
The plan points to runbooks and produces incident reports. It does not replace either. See our IT incident report template and root cause analysis template for what follows once the plan has been used.
Best practices
- Keep it short enough to read during an incident. If the plan is thirty pages, responders will work from memory instead. Put detail in linked runbooks.
- Make declaring cheap. One command, one channel, no approval. False alarms are a sign the threshold is right, not wrong.
- Separate managing from fixing. The incident lead coordinates. If they are also deep in the code, nobody is coordinating.
- Tie every severity level to a concrete response. A level that does not change who is paged or what is communicated is just a label.
- Prefer rollback to root cause under pressure. Sourcegraph's handbook makes this explicit. Restore service first, investigate afterwards.
- Set update cadences and keep them even when there is nothing new. Silence reads as absence.
- Write down the security handover. Responders should know who to call for a suspected breach without looking it up.
- Review the plan after every S1 and on a fixed schedule. A plan that has not changed in two years is describing a team that no longer exists.
- Rehearse it. Login.gov makes drill participation mandatory. A short game day once or twice a year finds gaps a review never will.
How detailed should an incident response plan be?
Detailed enough that a new on-call engineer could follow it alone at 3 a.m., and short enough that they would. Aim for a few pages. Everything system-specific belongs in runbooks the plan links to.
Who should own the plan?
Usually the team that runs on-call for production: platform, infrastructure or SRE. The owner keeps it current and runs the review after each major incident. The plan itself should be readable by anyone in the company who might declare an incident.
Do we need all four roles?
No. A small team might have one person acting as incident lead and technical lead, with support handling communications. The plan should say which roles exist and make clear that one person can hold several. The one rule that does not bend is a single incident lead per incident.
How is this different from a security incident response plan?
Security plans focus on confidentiality and integrity, involve legal and regulatory notification, and often follow a framework such as NIST. This template covers operational availability incidents. The two overlap and should reference each other, and this plan should say when an incident is handed to the security process.
How often should we review it?
After every S1 and at least once or twice a year. Check that named roles, on-call schedules, tool links and escalation contacts are still accurate, and fold in anything the last few postmortems suggested.
Write the plan before you need it
None of these teams wrote their plan during an outage. They wrote them in calm conditions, made declaring easy, named a single owner per incident, and reviewed the plan whenever an incident showed it was wrong.
Fill in the template above, link it from wherever your on-call rotation lives, and treat it as a living document. The plan's job is to make the first ten minutes of the next incident boring.
Sources
The template and guide draw on these publicly available incident response processes. Each takes a different position on the questions a plan has to answer, which is why the template leaves them open.
| Handbook | How their plan differs |
|---|---|
| GitLab: Incident Management | Four severity levels. One Incident Lead per incident, from an incident-manager on-call rotation, and only they can declare resolution. Only S1 and S2 are worked on weekends. Every S1 and S2 gets a review within five working days. |
| PostHog: Handling an incident | Three levels: Minor, Major, Critical, with explicit lists of what is and is not an incident. Whoever declares becomes incident lead, and the lead manages rather than fixes. A post-mortem for almost every incident. |
| Sourcegraph: Incidents | Two in-scope tiers, Critical and Major, both mapped to contractual Severity 1. A Messenger role drawn from support whenever customers are affected. Rollback to a known-good state is preferred over a root-cause fix during the incident. |
| Login.gov: Incident Response Guide | Four named roles including a Scribe. Five response phases from Initiate to Retrospect. A recoverability rating alongside severity. Participation in drills is mandatory. |
| Fleet: Engineering handbook | An incident is declared by opening an issue from a template, which also triggers paging. Unacknowledged pages escalate automatically every five minutes, up to the CTO. A postmortem for every outage. |