Incident response plan template for startups and small teams

An incident response plan template gives a small team the decisions it needs before something breaks. It settles who leads, how serious the problem is, how to contain it, who must be told and by when, and how the team learns from it. This security incident response plan template is written for startups and small engineering teams. It follows NIST's April 2025 incident response guidance rather than the older four-phase cycle that many templates still copy.

Copy the template below, fill in the blanks and test it once before you need it. If production is down right now, our production incident response work stabilizes the live system first and fixes the cause after.

What an incident response plan template covers

A useful template covers eight things: scope, roles, contacts, severity levels, response steps, notification rules, evidence and records, and testing. Each one answers a question the team would otherwise argue about in the middle of an incident.

• Scope. Which systems, data and vendors the plan covers, and what counts as an incident rather than a normal bug.
• Roles. The incident lead, the person who talks to customers, the people who fix and the person who writes things down.
• Contacts. How to reach each person out of hours, with a backup for every role.
• Severity levels. A short scale that decides who joins and how fast.
• Response steps. Detect, triage, contain, recover and review, with first actions written out for the incidents you are most likely to have.
• Notification rules. Which regulators, customers, insurers and partners must hear about which incidents, and by when.
• Evidence and records. Where logs are kept, who may wipe or rebuild a machine, and where the incident log lives.
• Testing and review. When the plan is exercised and who updates it afterwards.

The plan is a short document, not a binder. Most of its value sits in decisions made in advance: who can take the product offline, who can rotate production credentials and who speaks to customers. A team that has made those calls once does not have to make them under pressure.

What changed in NIST's 2025 incident response guidance

In April 2025, NIST published SP 800-61 Revision 3, which supersedes the 2012 Revision 2. It organizes incident response around the six Functions of the NIST Cybersecurity Framework (CSF) 2.0: Govern, Identify, Protect, Detect, Respond and Recover. NIST withdrew Revision 2 on 3 April 2025.

Revision 2 described a four-phase life cycle: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Many templates in search results still follow it. The NIST SP 800-61 Revision 3 publication maps those old phases onto the CSF 2.0 Functions, and the table below simplifies that mapping.

Two ideas change how you write the plan. First, preparation is no longer a phase you finish: in NIST's model, Govern, Identify and Protect are ongoing risk management work that helps a team prevent some incidents and prepare for the rest. Second, lessons learned are not saved for the end. NIST places them in the Improvement Category of the Identify Function, fed from every Function, and says lessons should often be shared as soon as they are identified.

NIST also says organizations should use the life cycle model that suits them best. The template below keeps a simple order of steps, because that is how an incident feels from the inside, and labels each section with the Function it serves.

Roles: who does what during an incident

Every incident needs one incident lead who makes the decisions, one person who handles communication, the people who fix, and someone who keeps a written log. On a small team one person may hold two roles, but the incident lead should not also be the main fixer.

The table shows a typical way to fill each role on a team of about ten people. Adjust it to the people you actually have on call.

Write a name and a backup for each role, plus how to reach them out of hours. Add the outside contacts you would need on a bad day: your cloud and hosting providers' support routes, your lawyer, your cyber insurer if you have one, and any incident response help you have arranged. NIST lists roles, responsibilities and authorities under the Govern Function (GV.RR), which is why the template starts with them.

Severity levels: a SEV1 to SEV4 matrix

A severity scale describes how big an incident is in one word, and that word decides who joins and how fast. Four levels are enough for a small team to start with: SEV1 for a full outage or confirmed exposure of customer data, down to SEV4 for a minor issue worth a look.

The response targets are blank on purpose. They depend on your customers, your contracts and how many people you have on call, and a number copied from another company's template becomes a promise you may not keep. Agree them with the founders, then write them in.

When you cannot tell a SEV1 from a SEV2, call it a SEV1 and lower it once you know more. Standing people down costs less than calling them in late.

The incident response plan template, ready to copy

The template below is plain text, so it pastes into a wiki, a shared document or your repository. Each section names the CSF 2.0 Function it serves, so the plan lines up with NIST's 2025 guidance when an auditor or a customer's security review asks. Replace every line in brackets, delete what does not apply and keep it short enough to read during an incident.

INCIDENT RESPONSE PLAN: [Company name]
Version [1.0], approved by [name] on [date]. Next review: [date].

1. SCOPE (Govern)
Systems: [production app, databases, cloud accounts, code repository, email]
Data: [customer personal data, payment data, credentials]
Vendors: [hosting, payments, email, analytics, AI APIs]
An incident is: [any event that harms or threatens customers, data or service]

2. ROLES AND CONTACTS (Govern)
Incident lead: [name], backup [name], out of hours via [channel]
Comms lead: [name], backup [name]
Scribe: [first person who is not fixing]
Decision maker for legal notices and public statements: [name]
Outside contacts: [cloud support route], [lawyer], [cyber insurer], [incident response help]

3. ASSETS AND BACKUPS (Identify, Protect)
Critical systems, in restore order: [1], [2], [3]
Backups: [what, where, how often]. Last restore test: [date]
Logs kept: [which logs, where, for how long]

4. SEVERITY LEVELS (Respond)
SEV1: [trigger]. Response target: [your target]
SEV2: [trigger]. Response target: [your target]
SEV3: [trigger]. Response target: [your target]
SEV4: [trigger]. Response target: [your target]

5. RESPONSE STEPS
Detect (Detect): alerts from [monitoring tool]; reports to [address or channel]
Triage (Respond): the incident lead sets the severity, opens the incident channel and starts the log
Contain (Respond): first actions for likely incidents
  Leaked secret: revoke and rotate it, then check where it was used
  Compromised account: suspend it, end its sessions, reset its password and second factor
  Bad release: roll back to [last known good version]
  Malware or ransomware: disconnect the machine from the network; do not wipe it
Recover (Recover): restore in the order of section 3, confirm with [checks], watch for a repeat
Communicate (Respond, Recover): updates every [interval] to [audience]

6. NOTIFICATION (Respond)
Regulators: [for each place your users are: who to tell and the deadline]
Customers: [contract terms that require notice, and by when]
Insurer and partners: [policy or contract notice terms]
Nothing is sent until [decision maker] approves it

7. EVIDENCE AND RECORDS (Respond)
Keep: logs, screenshots, disk images or snapshots, the incident log
Never wipe or rebuild an affected system before [incident lead] approves
Breach records kept in: [location], for [the period required where you operate]

8. AFTER THE INCIDENT (Identify: Improvement)
Review within [period] of every SEV1 and SEV2: what happened, why, what changes
Each fix has an owner and a date, tracked in [tool]
Plan updated by: [name]

9. TESTING (Identify: Improvement)
Tabletop exercise: [schedule], led by [name]
Last test: [date]. Changes made: [summary]

Section 5 holds first actions for the incidents you are most likely to have, not every possible one. NIST notes that detailed procedures cannot cover every situation and suggests documenting procedures for the most common types of incidents. Start with three or four that match your product, such as a leaked secret, a bad release and a compromised account.

Who to tell after a breach, and by when

Notice deadlines depend on where your users are, not only on where your company is registered. Under the EU's GDPR, a controller tells the data protection authority about a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to put people at risk.

The table compares three common cases for a startup with users in several countries. Each row comes from the regulator's own guidance, checked in October 2026.

The European Data Protection Board's guide for small businesses also says a controller must document every personal data breach. Canada's Office of the Privacy Commissioner requires a record of every breach of security safeguards, reported or not, kept for two years. In the US, the Federal Trade Commission's breach response guide notes that all states, the District of Columbia, Puerto Rico and the Virgin Islands have breach notification laws.

The table is a starting point, not legal advice. Sector rules, customer contracts and your insurance policy can add their own notice terms. List the ones that apply in section 6 of the template and have a lawyer check them once, before an incident rather than during one.

Incident response plan example: a leaked API key

Here is the template at work on a common startup incident: a production API key committed to a public repository. The scenario is invented for illustration, and the steps follow sections 4 to 8 of the template.

1. Detect. A secret-scanning alert or an outside report names the key. Whoever sees it posts in the incident channel and pages the incident lead.
2. Triage. The key can read customer records, so the incident lead calls it a SEV2 and starts the log. If the logs show use from outside the company, it becomes a SEV1.
3. Contain. A fixer revokes the key, issues a new one through the provider's console and removes it from the code. Deleting the commit alone is not enough, because anyone may already have copied a public repository.
4. Investigate. The fixers read the provider's access logs for the key between the leak and the revocation, and keep a copy of those logs as evidence.
5. Notify. If the logs show customer data was read, the decision maker works through section 6: which authorities, which customers and by when.
6. Recover. Services that used the old key get the new one from the secrets store, and the team checks that every job and integration works again.
7. Review. The review asks why a secret could reach the repository at all. The fixes might be a pre-commit secret scan and a move of every key into a secrets manager, each with an owner and a date.

Most of the hard calls in this example happened before the incident: who could revoke the key, where the logs were and who decides on notices. That is the work a plan does. Leaked secrets in dependencies follow the same path; our update on the npm supply chain attack wave shows what changed for startup teams this year.

Incident response plan testing: run a tabletop

The simplest way to test a plan is a tabletop exercise. The team meets, a facilitator presents a realistic scenario, and each person says what they would do, using the plan as written. It finds missing contacts, unclear authority and steps that do not work before a real incident does.

NIST's exercise guide, SP 800-84, describes tabletops as discussion-based sessions in which participants talk through their roles and responses to a scenario. A one-hour version for a small team looks like this:

• Pick a scenario. Use one of the first actions in section 5, such as a leaked secret or a bad release.
• Name a facilitator. Someone who is not the incident lead runs the clock and adds new facts as the scenario unfolds.
• Read the plan at each step. Ask who acts, what they open and whom they call, then compare the answer with what the plan says.
• Write down every gap. A missing contact, a login only one person has or a backup nobody has restored.
• Update the plan the same week. Record the date and the changes in section 9.

With no review after the exercise, the same gaps return in the next one. Revision 3 lists "improvements are identified from security tests and exercises" as an outcome under Improvement (ID.IM-02), which is why the template ends with testing. A tabletop tests people and process, not your systems; for that, see our guide to penetration testing for startups. If a customer or an auditor asks for evidence, a dated exercise record is part of the preparation our SOC 2 for startups guide describes.

How we run incident response with startup teams

When something breaks, we join your incident channel, take the technical lead and keep one written log of what we see, try and decide. The first goal is to stop the damage; after service is back we trace the cause, fix it with a test or an alert, and leave you a postmortem and a runbook. That is our software project rescue work.

Before anything breaks, we can review your plan against your real systems and accounts, or check the code and cloud setup it depends on with a code audit. The work is led by Thanos Gkanas, our co-founder and head of engineering. Every engagement is under an NDA, and the IP is always yours.

Frequently asked questions