Incident response plan template for a team of five: a security incident response template you can fill in today

An incident response plan template is the fill-in document that says who leads, who talks to customers and what gets written down when a security incident or an outage starts. For a team of five it fits on two pages: three roles, four response phases, a contact list, a customer message and a four-field record. The whole template is below.

The incident response plan template: two pages for a team of five

An incident response plan template for a small team has nine parts on two pages: purpose, three roles, the declare sentence, severity, the contact list, the phases as a checklist, the customer message, the incident record, and the next rehearsal date. Everything else in the enterprise versions is governance a team of five can skip.

A security incident response template is the same document, named for the security case, and this one treats an outage the same way as a breach. It is the people half of hardening SaaS applications for resilience: the part that decides what happens once the code has already failed. The template assumes a small business where the same small team that builds the product also handles incident response and writes the plan, so every part names a person rather than a department.

INCIDENT RESPONSE PLAN
Company: [name]    Version date: [date]    Plan owner: [name]

1. PURPOSE AND WHAT COUNTS
   Purpose: when something breaks or leaks, one named person leads,
   customers hear it from us first, and we keep a record we can learn from.
   An incident is: anything that stops customers using the product,
   exposes customer data or a secret, or spends money nobody approved.

2. ROLES (a backup for every hat)
   Incident lead: [name]   backup: [name]   decides; may approve spend up to [amount]
   Comms:         [name]   backup: [name]   the only voice to customers
   Scribe:        [name]   backup: [name]   keeps the incident record

3. HOW TO DECLARE
   Anyone may post in [#incidents]: "I'm declaring an incident: [what I see]."
   The first person to reply "I'm lead" leads until they hand over.

4. SEVERITY
   Sev1: customers cannot use the product, or data or a secret is exposed.
   Sev2: part of the product is degraded and a workaround exists.
   Full ladder: [link to your severity guide]

5. CONTACTS (stored outside the app and outside company sign-in)
   Hosting provider:   [support link]  [status page]  [support on our plan]
   Database provider:  [support link]  [status page]  [support on our plan]
   Payment provider:   [support link]  [status page]  [support on our plan]
   Model provider:     [support link]  [status page]  [support on our plan]
   Domain registrar:   [account owner] [support link]
   Large accounts:     [customer]  [their contact]  [notice period in contract]
   Copies kept at:     [printed copy]  [a place that works when the app is down]

6. PHASES (tick as you go)
   [ ] Prepare: plan current, alerts reach a phone, backups restorable
   [ ] Detect and analyze: declared, lead named, severity set, triage done
   [ ] Contain: first move for this incident type taken
   [ ] Recover: service restored, credentials rotated, customers told, record closed
   [ ] Learn: review booked, every action has an owner

7. MESSAGES
   Internal update: in [#incidents], each time: status, next step, next update time
   First customer message: pre-written (see the message block), sent by comms
   First message within: [target] of declaring. Then an update every: [interval]

8. INCIDENT RECORD
   Header, then four fields: timeline, impact, actions, decisions

9. REVIEW AND REHEARSAL
   Plan last checked: [date]   Next tabletop: [date]   Run by: [name]

Part 4 fills in two levels only. The full ladder, and what Sev1 means in practice, is a bigger subject than a plan for five people needs on day one.

Part 5 is the part teams skip and later regret. Write the support channel each plan actually includes beside each provider, because the plan tier decides what help you get and how fast: Supabase’s pricing page, for example, lists “Community support” on the Free plan and “Email support” on Pro. Keep the list somewhere that still works when the app and the company sign-in are down. CISA’s Incident Response Plan Basics gives the reason in one line: “During an incident, your internal email, chat, and document storage services may be down or inaccessible.”

Parts 5 and 6 assume that an alert exists and reaches someone. In my audits, 17 of the 21 third-party apps had no error tracking or alerting: when a user hits an error, nothing records it. Those are the 21 third-party apps I audited in June and July 2026, 11 public vibe-coded apps audited exhaustively across all 12 pillars and 10 held-out apps audited blind, a selected set of audited apps rather than a random sample or a rate for all AI-built apps. In an app like that, the first report of an incident is likely to come from a customer, which is why the contact list and the alert sit in the template at all.

NIST’s 2012 guide treats the policy, the plan and the procedures as separate documents. An incident response policy template gives you the commitment, one paragraph saying that incidents get declared, led and written down, while the plan is the block above. The incident response procedures sit one layer below this template: NIST describes standard operating procedures (SOPs) as “a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team”, and the working format for those is a runbook template.

The same guide lists “Mission” first among a plan’s elements and asks for “a formal, focused, and coordinated approach to responding to incidents, including an incident response plan”. Part 1 is that incident response mission statement cut to two lines, which is as much formality as a plan at this size can use. Part 6 turns the template into an incident response checklist, and the phases section below explains each tick box.

There is no download and nothing to sign up for: this incident response plan template is free to paste into your own document editor, and that editor exports the Word file or the PDF.

Incident response, incident handling, incident management: the same event, three words

Incident response, incident handling and incident management describe one process in a small team: notice, take charge, contain, recover, tell people, learn. Handling is the word in the title of NIST’s 2012 guide, management is the operations word that includes outages, and response is, in my reading, the word customers put in questionnaires.

Set incident response against incident handling and the difference is the date of the document: NIST’s 2012 guide says handling, and the revision that replaced it in 2025 says response. Incident management is the wider word in my reading, since it covers outages as well as security events, and incident response is the part of it that happens while the incident is open, with the communication and the review wrapped around it. For five people, incident response is the work from the moment someone notices a problem to the moment customers hear it is fixed and the record is closed. Security incident management is what a security team calls that whole loop; at this size it is one process with one document.

Why incident response is important at this size comes down to one thing, in my reading: the cost of an incident grows while nobody is in charge, and a named lead plus a declared channel close that gap in the first minute. An outage with no security angle runs the same plan, and what to do first when your app is down covers the first hour of that case.

How to fill it in: phases, roles, messages, the record

An incident response plan is written in this order: the three roles with names and backups, the contact list, the pre-written customer message, the record, then the phases. The first three are what nobody can invent during an incident.

I’d write an incident response plan in that order because roles, contacts and the first message depend on facts only you know, while the phases are close to the same for everyone. Most of the time it takes to build an incident response plan goes into part 5, where each support link and plan tier has to be looked up once. If you develop an incident response plan from an enterprise template instead, keep the same order and delete every line that names a department you do not have.

Five fill-in rules make an incident response plan usable, and they are my working rules rather than a standard:

1. Name people, not titles. A role that says “engineering” has nobody in it at night.
2. Write the declare sentence and the one channel it goes in, so nobody waits for permission to raise the alarm.
3. Keep the contacts outside the app, on paper and in a second place that does not use the company sign-in.
4. Pre-write the first customer message, so comms fills three blanks instead of drafting under pressure.
5. Put a date on the next tabletop, because a plan with no rehearsal date drifts out of date without anyone noticing.

These are the incident response plan best practices I’d hold any team to, and they double as an incident response plan checklist each time you review the document. CISA’s basics set the review rhythm plainly: “Review this plan quarterly.”

The NIST incident response framework, cut down to a team of five

The NIST incident response framework in SP 800-61 Revision 2 has 4 phases: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. NIST withdrew that revision in April 2025 for Revision 3, which ties its recommendations to the Cybersecurity Framework 2.0. For five people the four phases still describe the work.

NIST SP 800-61 Revision 2, the Computer Security Incident Handling Guide, dates from August 2012, and its publication page now reads “Withdrawn on April 03, 2025” above a line naming Revision 3 as the replacement. NIST SP 800-61 Revision 3, published April 2025, “seeks to assist organizations with incorporating cybersecurity incident response recommendations and considerations throughout their cybersecurity risk management activities as described by the NIST Cybersecurity Framework (CSF) 2.0”. It says all six framework functions play a part, and it places the response itself on three of them: “Incident response is shown in the top level of the figure: Detect, Respond, and Recover.”

Anyone after NIST’s current view of incident management should read Revision 3. My reading is that the four-phase NIST incident response cycle from 2012 is still the clearest way to split a small team’s work, so the template keeps it and says where it comes from. SANS’s incident response framework has 6 steps, in its own words “Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned”, which by my mapping splits NIST’s third phase into three. Lists with five, six or seven incident response steps cut the same work finer; whichever count a list uses, its steps map onto NIST’s four phases, and the process steps in this plan follow them.

These four are the stages of incident response, and part 6 of the incident response plan template above ticks off the same NIST phases, with containment and recovery as two separate boxes. The table below cuts each phase of the NIST incident response process down to what a small team actually does and the evidence it leaves behind.

The NIST column is NIST’s wording; the other columns are my working rules, not NIST’s.

Preparation is this template plus two things that must already exist: alerts that reach a person, which starts with error logging best practices and alerts routed to Slack or a phone someone carries, and backups you have restored at least once.

Detection and analysis begins at declaration. In this template the incident response process should start the moment someone says the declare sentence; waiting for a confirmed cause spends time the customer message needs. Triage, in its cyber security meaning, is three quick decisions: what this is, how bad it is and who leads, and my working rule is to have all three within about 15 minutes of declaring.

How to respond to a security incident in its first minutes depends on its type, so part 6 only points to where each first hour is written up:

• A leaked key: rotation comes first, as in what to do when an API key leaked.
• A compromised app: the first 30 minutes after a vibe-coded app got hacked are about containing it without erasing the evidence.
• An outage: the app-down guide above, starting with whether the failure is yours or your platform’s.

The recovery phase ends on the incident recovery checklist in part 6: four items, with the closed record last. Post-incident activity is the review, written from the record: what RCA means in software and how to run one without blame.

Who is on the incident response team when the whole team is five people

A computer incident response team in a company of five is three hats, not a department: an incident lead who decides, a comms person who is the only voice to customers, and a scribe who keeps the record. One person can wear two hats; avoid wearing all three.

NIST’s 2012 guide was written for computer security incident response teams (CSIRTs), a name you will also see as cyber incident response team, and of its team models the central one is described as “effective for small organizations”: “A single incident response team handles incidents throughout the organization.” CISA’s basics name three roles for the response: an Incident Manager, a Tech Manager and a Communications Manager.

The template swaps CISA’s tech manager for a scribe, which is my working rule: in a team of five, whoever knows the broken system is already working on it, and without a scribe nobody is writing anything down. The incident lead is the security incident manager of job postings, and CISA’s basics say that person “does not perform any technical duties”. My working rule for smaller teams: with two people, lead and scribe merge and comms stays separate; with one person, the record is a voice memo and the customer message is already written. A SOC incident response process assumes a staffed monitoring function that a team of five does not have, so in this template the alert channel plays that part.

A low blame environment is key to effective incident response, and CISA’s basics put it in four words about the review: “Retrospectives must be blameless.” In practice the scribe records what happened and when, never who was at fault, so the next person who spots something odd reports it at once. Name a backup for each hat, and write down who can approve spending money during an incident, because a bigger database plan or an emergency contractor should not wait for a meeting.

The communication half of the plan: who tells customers, and when

An incident response communication plan names four audiences, a channel for each, and a clock: by my working rule, the first customer message goes out within about 30 minutes of declaring, then an update about every hour until it closes. The first message is written before any incident.

The times in the table are my working rules, not a standard. Below is the incident response communication template for the first customer message, with three blanks:

Subject: [Product] incident: [what is affected]

We are investigating a problem affecting [what is affected].
Right now we are [what we are doing].
Our next update will be by [time and time zone], sooner if anything changes.

[Name], [role]

What a first update should include and what it should leave out belong to whether a small SaaS needs a status page, so the template stops at the three blanks. Incident response and reporting are separate duties: the response is the team’s work, and the reporting goes to whoever has a right to know. The security incident reporting checklist has four lines: who must be told, by when, by whom, and with what evidence kept.

Legal reporting, in brief. Under Article 33 of the UK GDPR, paragraph 1, the controller notifies a personal data breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, “unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons”; the UK text names the recipient as “the Commission”, meaning the Information Commission, which replaced the Information Commissioner; the word was substituted on September 30, 2026. The EU GDPR text, in its adopted version, sends the same notice to “the supervisory authority competent in accordance with Article 55”, under the same condition. Telling the people affected is a separate duty under Article 34 of the UK text, which applies when the breach “is likely to result in a high risk to the rights and freedoms of natural persons”.

When the incident is a GDPR breach, the notice has its own rules, and none of this is legal advice. The regulator notice is a legal duty with a condition attached; an early message to customers is good practice either way. A contract with a large customer may set its own notice period, and that period goes in the customer’s row of the contact list.

The incident record: what to write down while it is still happening

The incident record is a header plus 4 fields filled in while the incident is open: a timestamped timeline, the impact, the actions taken in production, and the decisions with who made them. Exported, it is the report customers ask for.

INCIDENT RECORD
Name:         [short name, e.g. "webhook secret exposed"]
Declared at:  [UTC time]       Declared by: [name]
Lead: [name]    Comms: [name]    Scribe: [name]
Severity:     [Sev1 / Sev2]

TIMELINE (UTC, one line per event, including what was tried and did not work)
[time]  ...

IMPACT (which customers, which data, which money, and how we know)
...

ACTIONS (what changed in production and by whom: the commit, the setting, the rotated key)
...

DECISIONS (what was decided, by whom, on what information)
...

The block is the whole incident response report template: one header and four fields. Export it to PDF when the incident closes and you have the incident response report to send a customer who asks. If your team prefers a form, the same header and fields make an incident response form template in any form builder. Keep the finished record next to the plan, because incident response documentation that lives inside the app’s own admin panel disappears with the app, which is also why this template stays outside it. What to preserve before any cleanup is set out in the hacked-app guide above; the record only notes where each item was saved.

In one of my own apps I audited, a live-format GPU provider API token was written as a constant in a helper script and sent as a bearer token. Anyone with read access to the code (a contractor, a fork, a backup) could run paid GPU jobs on the account with no record of who did it. The report’s fix: rotate now and move it to the secret store. The lesson I take from it is that a credential anyone with the code can use leaves the record’s by-whom column with no answer, so shared credentials belong in the secret store before an incident rather than during one.

In cyber security, as anywhere else, root cause analysis comes after the incident closes and is written from this record.

When the failure is in an AI feature

An AI incident response plan is the same plan with 2 extra questions in the record: what did the model see, and what did it write or do. They apply alike to a provider outage, a prompt-injection report, a harmful output and a runaway bill.

The first-move column is my working rule. The fallback or kill switch for a provider outage is something to rehearse before you need it, which is what chaos testing is for. For a runaway bill, which of a provider’s controls block requests and which only send an alert differs by provider, so check yours before you rely on it.

In the same June and July 2026 audits, 8 of the 14 AI apps had a live prompt-injection path, with untrusted text flowing straight into the model’s instructions. And 12 of the 14 AI apps had a confirmed denial-of-wallet path, where a stranger or free account can burn the owner’s paid AI or compute bill without limit. Those 14 are the third-party apps with an AI feature among the ones I audited, chosen rather than sampled, so the counts describe that group and nothing wider.

The two extra record fields come from the request log: what did the model see (the prompt, the retrieved context, the tool results) and what did it write or do (the output, the tool calls, the rows it changed). If the app does not log those, that gap is the first action item after any AI incident.

Put the model provider’s status page in the contact list, with a subscription set up before you need it. OpenAI’s status page offers updates by email, Slack and RSS. Anthropic’s status page offers email, SMS, Slack, Microsoft Teams, webhook, Atom and RSS.

Do you need an incident tool, or is a shared document enough?

Incident response automation tools do 4 jobs: paging, a channel per incident, the timeline and the status page. A team of five covers all four with an alert channel, a shared document and a hosted status page until an on-call rotation exists.

My working rule, as the first row says: buy paging once three or more people share on-call, or once a contract promises a response time. The alerts only help if the app raises errors worth routing, which starts with API error handling best practices.

A short incident response tools list for when that day comes: PagerDuty, incident.io, Rootly and FireHydrant, and Jira Service Management, where Atlassian moved Opsgenie’s alerting and on-call features. Opsgenie itself reached its end of sale on June 4, 2025 and “will be shut down” on April 5, 2027, so it is not an option for a new team.

Incident response as a service means a retainer with a security firm that answers the phone during a breach, in my reading. It is worth pricing when the app holds regulated data such as health or payment records.

A filled example: a payment webhook incident at a five-person SaaS

What follows is an incident response plan example for a fictional company: an illustration, not a real incident and not a client story. It is a sample incident response plan for a five-person B2B SaaS on a managed host and Supabase, taking payments with Stripe, with one AI feature. As an example of incident response for a small team, the roles are named by job, and the incident is a Stripe webhook signing secret pasted into a public issue.

INCIDENT RESPONSE PLAN (illustration: fictional five-person B2B SaaS)

1. PURPOSE AND WHAT COUNTS
   As in the template. An incident here includes any exposed secret.

2. ROLES
   Incident lead: founder        backup: engineer one
   Comms:         support lead   backup: founder
   Scribe:        engineer one   backup: support lead

3. HOW TO DECLARE
   In #incidents: "I'm declaring an incident: our Stripe webhook signing
   secret is in a public issue."

4. SEVERITY
   Sev1: a secret is exposed.

5. CONTACTS (rows used)
   Payment provider:  Stripe Workbench > Webhooks > endpoint > Roll secret; Stripe support
   Database provider: Supabase; support on our plan: Email support (Pro)
   Hosting provider:  [support link]; [status page]

6. PHASES
   [x] Prepare   [x] Detect and analyze   [x] Contain   [x] Recover   [ ] Learn

7. MESSAGES: FIRST CUSTOMER MESSAGE
   Subject: [Product] incident: payment confirmations delayed
   We are investigating a problem affecting payment confirmations.
   Right now we are replacing a leaked credential and resending the
   payment events that were missed.
   Our next update will be by [time and time zone], sooner if anything changes.
   Support lead, [Product]

8. INCIDENT RECORD: TIMELINE (UTC)
   [time]  Declared by engineer one; founder is lead; Sev1.
   [time]  Webhook signing secret rolled in Stripe and updated in the app;
           old secret set to expire now.
   [time]  Missed events resent from the Stripe Dashboard; handler checks each one.
   [time]  Customers told on the status page and by email.
   [time]  Record closed by the scribe; all four fields filled.
   [time]  Review booked with founder, engineer one and support lead.

9. REVIEW AND REHEARSAL
   Review: [date]   Next tabletop: [date], scenario: a leaked secret

The illustration expires the old secret at once because it was public; Stripe also lets you delay the old secret’s expiry for up to 24 hours when a server needs time to switch, and its Dashboard Resend button works for up to 15 days after an event is created. For an app like this one, the table below sets out incident response for common attack types and failures: the first move, and where the first hour is covered.

A leaked secret is a fair first scenario to rehearse for an app like this: in the same audits, 6 of the 21 third-party apps shipped a real secret.

How to verify the plan: a 45-minute tabletop

An incident response plan is verified, by my working rule, with a tabletop of about 45 minutes: read a scenario aloud, time the declaration, dial the contact list, send the first message to a test recipient, produce the record, and write down everything that failed.

1. 01 Read a scenario aloud and time how long it takes until someone says the declare sentence and names the lead. Evidence: the time, written in the record.
2. 02 Open or dial every phone number and support link in the contact list, treating the app and the company single sign-on as down. Evidence: each row marked worked or failed.
3. 03 The comms person sends the pre-written first message to a test recipient inside the template target. Evidence: the sent message and its timestamp.
4. 04 The scribe produces a record with all four fields filled from the exercise. Evidence: the record itself.
5. 05 Fire a test alert out of hours and confirm it reaches a person on their phone. Evidence: a screenshot of the notification.
6. 06 The backup for each hat runs one step while the main holder watches. Evidence: who ran which step.

Keep three things from each tabletop: the dated record, the list of what failed, and the next date. For scenarios, CISA’s tabletop exercise packages are “a comprehensive set of resources designed to assist stakeholders in conducting their own exercises”, and each one “includes template exercise objectives, scenarios, and discussion questions as well as a collection of references and resources.” A plan that has never been rehearsed is still a draft.

Deliverable 8.4 of the Production Hardening Sprint, actionable alert routing, is verified this way: “Send test alerts and verify their destination, context, and response instructions.”

Where the sprint fits

Seven deliverables in the published scope bear on incident response. In it, deliverable 8.4 routes alerts to the designated Slack or email destination and tunes thresholds to reduce noise. 8.7 provides a status page for service availability and incident communication. Under 13.3 we document deployment, rollback, key rotation, backup restoration, and the response to each operational alert. For 2.6 we document how to rotate each key, update its dependents, verify the change, and recover from a failed rotation. Deliverable 6.10 simulates AI or payment-provider failure in staging and verifies the expected recovery behavior. With 3.9 we publish security.txt and a monitored disclosure contact for vulnerability reports. And 6.3 installs error tracking such as Sentry with protected source maps, environment labels, and alerts. Legal advice and certification are separate services; we implement and document the technical data-handling controls. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables.

Common questions about incident response plans for small teams

What are the 7 steps of incident response?

The seven steps vary by author: NIST’s 2012 guide has four phases and SANS’s framework has six steps, so a seven-step list is, in my reading, one author’s finer cut of the same work. Map it onto the four phases (preparation; detection and analysis; containment, eradication and recovery; post-incident activity) and every step lands in one of them.

What makes a good incident response plan?

A good incident response plan, by my working rules, names people with backups, keeps contacts outside the app, has the first customer message written in advance, uses a four-field record and carries a dated rehearsal. To check coverage against a public reference, compare it with CISA’s Incident Response Plan Basics, which splits its advice into before, during and after an incident.

What is the difference between a CSIRT and a SOC?

A SOC watches continuously, while a CSIRT assembles to run an incident once something has happened; that is my reading, and NIST’s 2012 guide describes the CSIRT side through team models such as a central team for small organizations. A team of five has neither: an alert channel does the SOC’s watching and three hats do the CSIRT’s work.

Can you give me some examples of tabletop exercises?

Yes: three scenarios sized for a small SaaS are a leaked API key found in a public repository, the model or payment provider going down at a busy hour, and a customer reporting that they can see another customer’s data. CISA’s tabletop packages add more, with cybersecurity scenarios that include ransomware, insider threats and phishing.

What are the 5 elements of a good incident report?

In this template the five elements are the header plus the four fields: timeline, impact, actions and decisions. Five is this template’s count rather than a standard’s, and the header carries the name, the declaration time, the three hats and the severity.