# Incident Response Plan Template (Free DOCX)

v1.0, October 2026, Brandefense, CC BY 4.0 with attribution

> An incident response plan template is a document you fill in once, so your team knows who decides, what counts as an incident and what to do first. This one follows NIST SP 800-61 Rev. 3 and CSF 2.0, and it adds the signals that start outside your network: leaked logins, lookalike domains, data leaks and supplier warnings.

## How do you use this template?

Copy the tables into your own document, or download the DOCX or Markdown file above. Replace every [bracket] with your own answer. Delete what does not apply. Keep the plan short enough that a tired person can use it at 3 a.m.

1. Fill in Parts 1 to 3 once, with your security lead, IT, legal and communications.
2. Fill in Part 4 with the alert sources you really have, including the ones outside your network.
3. Print Parts 5 to 7 and keep a copy outside your own systems, in case they are down.
4. Test the plan with a tabletop exercise, then fix what did not work (Part 9).

NIST SP 800-61 Rev. 3 (April 2025) replaces the older four-phase model with the six functions of NIST CSF 2.0. Govern, Identify and Protect are preparation. Detect, Respond and Recover are the incident response itself. Lessons learned feed back into all of them. The table shows where each part of this template sits.

| Part of this template | CSF 2.0 function | What it answers |
|---|---|---|
| 1 Scope and owner, 2 Roles, 3 Severity | Govern (GV), Identify (ID) | Who is in charge and what counts as an incident |
| 4 Alert sources | Detect (DE) | Where we hear about trouble, inside and outside the network |
| 5 Triage, 6 Contain and recover | Respond (RS), Recover (RC) | What we do, in what order |
| 7 Notify | Respond (RS), Recover (RC) | Who must be told, and when |
| 8 Record and learn, 9 Maintain | Identify: Improvement (ID.IM) | What we keep and what we change |

If your incident is ransomware, use this plan with the [ransomware response playbook and checklist](https://brandefense.io/knowledge-hub/guides/ransomware-response-playbook-checklist/). For a longer explainer on the topic, read [What is incident response and how to build it](https://brandefense.io/blog/what-is-incident-response/).

## 1. What does the plan cover and who owns it?

NIST lists the usual parts of an incident response policy: management commitment, purpose, scope, definitions, roles and authorities, how to rank incidents, and performance measures. This table covers the same ground in one page.

| Field | Your answer |
|---|---|
| Plan name and version | [Plan name], [v1.0] |
| Plan owner (one person) | [Name, role] |
| Approved by and date | [Name, role], [date] |
| Purpose | [Example: limit harm, restore service and meet our legal duties after a cyber incident] |
| Scope: systems, sites, subsidiaries | [List] |
| Scope: data we hold for others | [Customers, partners, employees] |
| Out of scope | [Example: physical safety events, handled by the facilities plan] |
| Definition of an event | [Example: any observable change that may matter to security] |
| Definition of an incident | [Example: an event that harms or threatens confidentiality, integrity or availability] |
| Who can isolate or shut down a system | [Role names and what they may do without asking] |
| Where this plan is stored offline | [Location, who has a copy] |
| Next review date | [Date] |

## 2. Who does what during an incident?

Name people, not only teams. Add a deputy for every role. NIST describes roles such as leadership, incident handlers, technology staff, legal, public affairs, human resources, physical security and asset owners. Use only the ones you need.

| Role | Main person | Deputy | Phone (out of hours) | What they decide |
|---|---|---|---|---|
| Incident lead | [Name] | [Name] | [Number] | Severity, who is called in, when we stand down |
| Technical lead | [Name] | [Name] | [Number] | Containment and recovery steps |
| Executive sponsor | [Name] | [Name] | [Number] | Big business decisions, such as shutting down a service |
| Legal and privacy | [Name] | [Name] | [Number] | Notification duties, evidence handling, contracts |
| Communications | [Name] | [Name] | [Number] | Words to staff, customers and press |
| Human resources | [Name] | [Name] | [Number] | Cases that involve staff |
| Asset or business owner | [Name] | [Name] | [Number] | Recovery priorities for their systems |
| Scribe | [Name] | [Name] | [Number] | Keeps the time-stamped log (Part 8) |

### Outside help

| Party | Contact | Contract or agreement | What they do for us |
|---|---|---|---|
| Incident response retainer | [Company, number] | [Reference] | [Example: forensics, extra hands] |
| Cyber insurer | [Company, number] | [Policy number] | [Notice rules] |
| Law enforcement contact | [Name, number] | [None] | [When we call] |
| Critical suppliers (cloud, ISP, managed services) | [Names, numbers] | [Clauses] | [Who acts for us, what they may do] |
| Takedown and domain abuse partner | [Name, number] | [Reference] | [Lookalike domains, fake pages] |

## 3. How do you decide what counts as an incident, and how bad it is?

Agree the rules before you need them. An event becomes an incident when it meets your written criteria. Then you give it a level, and the level decides who is told and how fast you start. The wording below is a starting point. Change it to fit your business, and set your own time targets.

| Level | Meaning (edit) | Who is told | Start work within |
|---|---|---|---|
| Critical | [Example: confirmed data theft or loss of a core service] | [Executive sponsor, legal, communications] | [Minutes] |
| High | [Example: confirmed compromise of an account or system with sensitive access] | [Incident lead, technical lead, legal] | [Minutes] |
| Medium | [Example: credible threat with no confirmed harm yet] | [Incident lead] | [Hours] |
| Low | [Example: single user issue, blocked attempt] | [Security queue] | [Next working day] |

| Question to ask for every alert | Yes / No |
|---|---|
| Is sensitive data or a critical service involved? | [ ] |
| Is the activity still going on? | [ ] |
| Is a privileged or shared account involved? | [ ] |
| Does a supplier, customer or partner hold the same data or access? | [ ] |
| Could a legal or contract notice duty apply? | [ ] |

## 4. Where do alerts come from, including outside your network?

Inside signals come from your own tools: endpoint alerts, logs, email reports, staff reports. Outside signals come from places you do not control: criminal forums, leak sites, stealer logs, domain registrations and supplier news. Both must reach one queue, with one owner.

### Inside signals (fill in)

| Source | Who watches it | How it reaches the queue | Hours covered |
|---|---|---|---|
| Endpoint and server alerts | [Name or team] | [Ticket, email, chat] | [24/7 or hours] |
| Email and phishing reports | [Name or team] | [Mailbox, button] | [Hours] |
| Identity and sign-in logs | [Name or team] | [Alert rule] | [Hours] |
| Staff and customer reports | [Name or team] | [Phone, form] | [Hours] |

### Outside signals (fill in)

The CSF has no category named after these signals. The mapping below is our reading: the closest CSF 2.0 categories. DE.AE-07 asks you to bring cyber threat intelligence into your analysis of events. DE.CM-06 covers monitoring external service providers. GV.SC-08 asks that suppliers are part of incident planning.

| Outside signal | What it looks like | First check | Closest CSF 2.0 items | Response page |
|---|---|---|---|---|
| Leaked credentials and infostealer logs | Company or customer logins in a stealer log or combo list | Is the account active, does it have MFA, any sign-in from new places? | DE.AE-02, DE.AE-07 | [Leaked credentials](https://brandefense.io/knowledge-hub/how-to-defend/leaked-credentials/) and [infostealer log exposure](https://brandefense.io/knowledge-hub/how-to-defend/stealer-log-exposure/) |
| Lookalike domains and phishing kits | New domain close to your name, with mail records or a copy of your login page | Is it live, can it send mail, did anyone in the company visit it? | DE.AE-03, DE.AE-07 | [Lookalike and phishing domains](https://brandefense.io/knowledge-hub/how-to-defend/lookalike-domains/) |
| Data leak | A post, paste or leak site listing that claims to hold your data or source code | Is the sample real, is it ours, which system could it come from? | DE.AE-04, DE.AE-07 | [Leaked databases and source code](https://brandefense.io/knowledge-hub/how-to-defend/data-leaks/) and [ransomware leak site listings](https://brandefense.io/knowledge-hub/how-to-defend/ransomware-leak-site-listings/) |
| Supplier signal | A supplier named on a leak site, or a new exposure at a supplier | Do they hold our data or have access to us? Has the supplier confirmed? | DE.CM-06, GV.SC-08 | [Supplier on a leak site](https://brandefense.io/knowledge-hub/how-to-defend/supplier-ransomware-listing/) and [supplier exposure changes](https://brandefense.io/knowledge-hub/how-to-defend/vendor-exposure-changes/) |

Fill in who owns each outside signal today, and how often it is checked.

| Outside signal | Owner | Checked how often | Tool or service | Goes to queue |
|---|---|---|---|---|
| Leaked credentials and stealer logs | [Name] | [Daily] | [Tool] | [Queue] |
| Lookalike domains and fake pages | [Name] | [Daily] | [Tool] | [Queue] |
| Data leaks and leak sites | [Name] | [Daily] | [Tool] | [Queue] |
| Supplier signals | [Name] | [Weekly] | [Tool] | [Queue] |

> **An outside signal is a lead, not yet an incident.** Validate it with the checks in Part 5. Then declare an incident only if it meets your written criteria (CSF DE.AE-08). Write down the reason either way.

More on each signal: [leaked credential monitoring](https://brandefense.io/use-cases/leaked-credential-monitoring/), [phishing and lookalike domains](https://brandefense.io/use-cases/phishing-lookalike-domains/), [data leak detection](https://brandefense.io/use-cases/data-leak-detection/) and [supply chain and vendor risk](https://brandefense.io/use-cases/supply-chain-vendor-risk/).

## 5. How do you triage an alert in the first hour?

Triage means deciding fast what you are looking at. In CSF terms, reports are triaged and validated (RS.MA-02), then categorised and prioritised (RS.MA-03). Use the checklist for every alert, and copy the record table into your ticket.

**First-hour triage**

- [ ] **Write down time and source.** Who or what raised it, and exactly what was seen.
- [ ] **Validate.** Check a second source. Is it real, and is it about us?
- [ ] **Scope.** Which accounts, systems, data and suppliers could be involved?
- [ ] **Check the outside view.** Search for the same account, domain or data in leak and stealer sources.
- [ ] **Set the level.** Use the table in Part 3.
- [ ] **Declare or close.** Write the reason in one line.
- [ ] **Name the lead and open the log.** Start Part 8 now, not later.
- [ ] **Notify.** Use the list in Part 7.

| Triage record | Entry |
|---|---|
| Ticket or case number | [ID] |
| Time first seen, time reported | [Date and time], [Date and time] |
| Source (inside or outside signal) | [Source] |
| What was seen (facts only) | [Text] |
| Validated by, and how | [Name], [method] |
| Assets, accounts, data and suppliers involved | [List] |
| Level | [Critical / High / Medium / Low] |
| Declared as incident | [Yes or No], [reason] |
| Incident lead | [Name] |

## 6. How do you contain, remove and recover?

Contain first, then remove the cause, then restore. In CSF terms: contain and eradicate (RS.MI-01, RS.MI-02), then recover (RC.RP). Check that backups are sound before you restore from them (RC.RP-03). Do not wipe a system before you have kept the evidence you need.

| Situation | First containment steps | Done by | Done at |
|---|---|---|---|
| Leaked or stolen credentials | Reset the password, end active sessions, check multi-factor settings, review recent sign-ins | [Name] | [Time] |
| Infostealer on a device | Isolate the device, reset every login used on it, then rebuild | [Name] | [Time] |
| Lookalike domain or phishing page | Keep screenshots and page source, block the domain in mail and web filters, report it to the registrar and host | [Name] | [Time] |
| Data leak claim | Keep the sample safely, confirm the source system, close the access path, take legal advice on duties | [Name] | [Time] |
| Supplier incident | Ask the supplier for facts, limit their access, rotate shared secrets | [Name] | [Time] |
| Ransomware | Isolate affected systems, protect backups, follow the ransomware checklist | [Name] | [Time] |

For a lookalike domain or fake page, the [takedown service evaluation checklist](https://brandefense.io/knowledge-hub/guides/takedown-service-evaluation-checklist/) helps you judge how a takedown partner works. Recovery steps:

- [ ] Eradication confirmed: the cause is closed, not only the symptom
- [ ] Backups tested and clean before restore
- [ ] Restore in the order the business owners set
- [ ] Passwords and keys changed where exposure is possible
- [ ] Monitoring raised on restored systems for [number] days
- [ ] End of recovery declared by [role], with the reason written down

## 7. Who must be told, and when?

Duties and deadlines depend on your country, your sector and your contracts. They are not the same everywhere, so list yours here with the help of legal. See [incident reporting deadlines under NIS2, CRA, SEC and CIRCIA](https://brandefense.io/security-news/incident-reporting-deadlines-nis2-cra-sec-circia/) for an overview, and the glossary entries for [NIS2](https://brandefense.io/knowledge-hub/glossary/nis2/) and [DORA](https://brandefense.io/knowledge-hub/glossary/dora/).

| Audience | Owner | Trigger (edit) | Deadline | Approved by | Channel |
|---|---|---|---|---|---|
| Executive team | [Name] | [High or Critical] | [Time] | [Name] | [Phone] |
| Legal and privacy | [Name] | [Any possible data exposure] | [Time] | [Name] | [Phone] |
| All staff | [Name] | [When action is needed] | [Time] | [Name] | [Email, chat] |
| Customers and partners | [Name] | [Their data or service affected] | [Time or legal limit] | [Name] | [Email, notice] |
| Regulators or authorities | [Name] | [Legal duty applies] | [Legal limit] | [Name] | [Portal, form] |
| Insurer | [Name] | [Policy terms] | [Policy limit] | [Name] | [Phone] |
| Law enforcement | [Name] | [Criminal activity] | [Time] | [Name] | [Phone] |
| Affected suppliers | [Name] | [Shared data or access] | [Time] | [Name] | [Phone] |
| Media | [Name] | [Public interest or leak] | [Time] | [Name] | [Statement] |

Prepare holding statements in advance, one for staff and one for outsiders. Keep them short and factual. Never say more than you have confirmed.

## 8. What do you record, and what do you learn afterwards?

Keep a time-stamped log from the first minute. Record who did what, and keep the evidence safe. CSF RS.AN-06 and RS.AN-07 ask that records and incident data keep their integrity and origin.

| Time | Who | Action or finding | Result | Evidence location |
|---|---|---|---|---|
| [Date and time] | [Name] | [Text] | [Text] | [Path or ticket] |
| [Date and time] | [Name] | [Text] | [Text] | [Path or ticket] |
| [Date and time] | [Name] | [Text] | [Text] | [Path or ticket] |

NIST Rev. 3 says lessons should be shared as soon as they are found, not held back until recovery ends. Hold a short review soon after the incident, and fill in this table.

| After-action question | Answer |
|---|---|
| What happened, in five lines? | [Text] |
| How and when did we first learn of it? Which signal came first? | [Text] |
| Which outside signal, if any, could have warned us earlier? | [Text] |
| What slowed us down? | [Text] |
| What worked well? | [Text] |
| Which parts of this plan need to change? | [Text] |

| Improvement action | Owner | Due date | Done |
|---|---|---|---|
| [Action] | [Name] | [Date] | [ ] |
| [Action] | [Name] | [Date] | [ ] |
| [Action] | [Name] | [Date] | [ ] |

## 9. How do you keep the plan alive?

A plan that is never tested fails when it is needed. CSF ID.IM-04 asks that incident response plans are established, communicated, maintained and improved. Set a rhythm and name the owner.

| Task | How often | Owner | Last done | Next due |
|---|---|---|---|---|
| Review the whole plan | [Interval] | [Name] | [Date] | [Date] |
| Check contacts and phone numbers | [Interval] | [Name] | [Date] | [Date] |
| Run a tabletop exercise | [Interval] | [Name] | [Date] | [Date] |
| Check outside monitoring covers our domains, brands, key people and suppliers | [Interval] | [Name] | [Date] | [Date] |
| Update after every real incident | Each time | [Name] | [Date] | [Date] |

Use the [tabletop exercise scenarios and injects](https://brandefense.io/knowledge-hub/guides/tabletop-exercise-scenarios-injects/) to test this plan. For suppliers, send the [vendor cyber risk questionnaire](https://brandefense.io/knowledge-hub/guides/vendor-cyber-risk-questionnaire-template/). To decide which questions your intelligence should answer first, use the [threat intelligence PIR template](https://brandefense.io/knowledge-hub/guides/threat-intelligence-pir-template/). If you are choosing how to source external intelligence, read [Threat Intelligence: Feeds, Platform or Managed Service](https://brandefense.io/knowledge-hub/guides/threat-intelligence-approaches-buyers-guide/). [Third-party risk](https://brandefense.io/knowledge-hub/glossary/third-party-risk/) deserves its own line in every exercise.

Sources: [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final), [NIST CSF 2.0](https://www.nist.gov/cyberframework) and the [CISA #StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide).

## Sources

- [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final): Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025). Basis for Parts 1 to 9
- [NIST CSF 2.0](https://www.nist.gov/cyberframework): Govern, Identify, Protect, Detect, Respond, Recover. Category ids used: DE.CM-06, DE.AE-02, DE.AE-03, DE.AE-04, DE.AE-07, DE.AE-08, RS.MA-02, RS.MA-03, RS.AN-06, RS.AN-07, RS.MI-01, RS.MI-02, RC.RP-03, GV.SC-08, ID.IM-04
- [CISA #StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide): Part 2, the response checklist, for ransomware cases

## Change log

- v1.0, October 2026: First release.

Source page: https://brandefense.io/knowledge-hub/guides/incident-response-plan-template/

Licence: CC BY 4.0. Please credit Brandefense and link to the page above.