- The asset inventory and system boundary worksheet, so containment decisions start from a known map
- Contact details for the MSP, counsel, and insurer — and, where a contract requires it, the DIBNet reporting arrangements
- Knowledge of which systems production depends on, from the people who run them
ATL-021PLANEDITORIAL REVIEW COMPLETE
Incident Response Plan Template
A working incident response plan skeleton with real substance already in it: activation criteria and severity levels, named roles with backups, concrete actions for each response phase, a verified contact table, evidence-preservation basics, and an OT coordination section that puts the process owner in the room and safety ahead of forensics.
Using this artifact
Purpose, inputs, and completion
Purpose. An incident response plan exists so that the worst hour of the year is spent acting instead of deciding who decides. This template is a skeleton with real substance: severity levels, roles with backups, phase-by-phase actions, and the contact table that turns a plan into phone calls. Completed and exercised, it becomes the operational plan the incident timeline worksheet (ATL-022) and the 72-hour reporting decision worksheet (ATL-023) plug into.
When to use it. Work through the sections in order with the people named in them present — a plan written about people instead of with them gets ignored under pressure. Replace every EXAMPLE row with your own reality and keep the severity definitions small enough to act on. Print a copy and store it where a ransomware event cannot encrypt it; a plan that lives only on the file server it is meant to protect is a punch line, not a plan.
- Fill in names, not just roles — a plan that says 'the IT lead' fails at 2 a.m. when nobody remembers who holds that hat this week.
- Write severity definitions your own size can act on; a template calibrated for a 24×7 security operations center will misfire in a 40-person shop.
- Walk the contact table with a phone in hand: every number dialed, every after-hours path confirmed, and the verification date recorded.
- Run one tabletop exercise against the completed plan before filing it; the first walkthrough always finds a missing name or an impossible step.
Keeping it honest
Evidence, validation, and failure modes
- A dated, approved incident response plan with named roles and backups
- A contact table with a recorded verification date
- A record of exercises and activations feeding plan revisions
- Call one number from the contact table this week; if it does not reach the named person, the table has failed its only job.
- Hand the severity table and a scenario ('ransomware note on one machine at 6 a.m.') to someone outside IT and confirm they land on the same severity you do.
What looks done but is not
- Roles are named but backups are not, and the one person who can act is on a plane when the incident starts.
- Severity levels are copied from a large-enterprise template and assume capabilities — a security operations center, a forensics retainer — the company does not have.
- The DIBNet row is treated as universal; whether and how to report is contract-dependent, and the plan never records which contracts carry the clause.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain superseded versions and the record of every activation and exercise; the plan's history is what shows a reviewer the capability is real rather than aspirational.
Full document
Preview — exactly what prints
PLAN · INCIDENT RESPONSEv1.0 · REVIEWED 2026-08-06
Incident Response Plan Template
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
An incident response plan exists so that the worst hour of the year is spent acting instead of deciding who decides. This template is a skeleton with real substance: severity levels, roles with backups, phase-by-phase actions, and the contact table that turns a plan into phone calls. Completed and exercised, it becomes the operational plan the incident timeline worksheet (ATL-022) and the 72-hour reporting decision worksheet (ATL-023) plug into.
How to use it
Work through the sections in order with the people named in them present — a plan written about people instead of with them gets ignored under pressure. Replace every EXAMPLE row with your own reality and keep the severity definitions small enough to act on. Print a copy and store it where a ransomware event cannot encrypt it; a plan that lives only on the file server it is meant to protect is a punch line, not a plan.
Activation criteria and severity levels
Severity decides who gets woken up and how fast. Define each level by what is true, not by how it feels, so two different people reach the same answer at 6 a.m.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Severity | Definition — what is true | Example triggers | Activation and first move |
|---|---|---|---|
| EXAMPLE: SEV-1 — Critical | Production, safety, or contract data is affected now, or ransomware is active | Ransomware note on any machine; line-control system behaving abnormally; confirmed exposure of contract data | Full plan activation any hour; incident lead and decision authority engaged immediately |
| EXAMPLE: SEV-2 — Serious | A compromise is confirmed but appears contained to one system or account | One account takeover; malware blocked but persistence suspected | Plan activated during business hours or via on-call; technical lead contains while the incident lead decides on escalation |
| EXAMPLE: SEV-3 — Minor | Suspicious activity with no confirmed compromise | Phishing reported and quarantined; a spike in failed logins | Handled in normal operations, logged on the timeline, and watched for escalation |
Calibrate to your size
A severity ladder only works if the top rung is reachable with the people you actually have. If SEV-1 assumes a forensics team you do not employ, rewrite it around the calls you can really make: isolate, phone the MSP, phone counsel, start the timeline.
Roles and backups
Four roles cover a small organization's incident: someone runs it, someone speaks for it, someone works the systems, and someone can authorize the expensive decisions. Every role gets a named backup, because incidents check the vacation calendar first.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Role | Responsibilities during an incident | Primary (named person) | Backup (named person) |
|---|---|---|---|
| EXAMPLE: Incident lead | Owns the response end to end; declares severity; runs the update cadence | A. Rivera, operations manager | T. Chen, controller |
| Incident lead | Owns the response end to end; declares severity; runs the update cadence | ||
| Communications lead | The single voice to employees, customers, and the prime; nobody else speaks for the company | ||
| Technical lead | Directs containment and evidence preservation; coordinates the MSP's hands-on work | ||
| Decision authority | Authorizes disconnection, shutdown, spending, and external reporting decisions |
Response phases and actions
Each phase carries a handful of concrete actions. Tailor the details, but keep the shape: prepare, detect, analyze, contain, recover, and learn.
Phase actions
- Prepare
- Keep the contact table verified and a printed copy of this plan reachable if systems are down.
- Run at least one tabletop a year and record what it changed.
- Know where backups are and when a restore was last tested (ATL-024).
- Detect
- Write down what triggers this plan: which alert sources, and how an employee reports something odd.
- Start the incident timeline (ATL-022) at the first credible observation, with a timestamp.
- Analyze
- Establish what is affected and whether it is spreading, citing sources on the timeline rather than memory.
- Declare severity from the table above and revisit it as facts change.
- Contain
- Isolate affected machines from the network rather than powering them off, where that is safe to do — memory and disk state are evidence.
- Disable compromised accounts and reset credentials in scope.
- Preserve before you wipe: no reimaging until the evidence decision is recorded.
- Recover
- Restore from backups verified clean of the intrusion, not merely the most recent ones.
- Watch restored systems closely; reinfection within days is the classic sequel.
- Post-incident
- Hold a blameless review within two weeks while memories are fresh.
- Update this plan, the contact table, and the severity definitions with what the incident taught.
Contact table
The plan's most-used page. Every row needs a name, a number that works after hours, and a verification date — a stale phone number is a silent plan failure.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Party | Named contact | Primary contact method | After-hours method | Notes |
|---|---|---|---|---|
| EXAMPLE: MSP security desk | T. Osei, case intake | +1 555 0101 / soc@msp.example | Same line, 24×7 per contract | Contract commits a one-hour response for SEV-1 |
| Incident lead (internal) | ||||
| Decision authority (internal) | ||||
| MSP / security provider | ||||
| Outside counsel | Engage before any external reporting decision | |||
| Cyber insurer / broker | The policy may name a required forensics panel — check before hiring anyone | |||
| DIBNet reporting (contract-dependent) | Only where a contract requires it — see the 72-hour worksheet (ATL-023); the medium-assurance certificate must exist before the incident | |||
Evidence preservation basics
Preservation decisions made in the first hour determine what counsel, the insurer, and any later investigation have to work with. These basics cost little and are hard to undo if skipped.
Preservation basics
- Isolate, do not power off, where safe
- Disconnecting from the network preserves memory and disk state; pulling the plug destroys both. Where safety demands shutdown, note it on the timeline and move on.
- No wiping or reimaging before the preservation decision is recorded
- The urge to 'just rebuild it' erases the only record of how the attacker got in.
- Export logs before they rotate
- Firewall, identity, email, and endpoint logs often keep days, not months — export early and store copies off the affected systems.
- Track every action on the timeline
- Who touched what, when, and why goes into the incident timeline worksheet (ATL-022) as it happens.
- Control the copies
- Record who holds evidence copies and where; a copy nobody can account for is a copy nobody can rely on.
OT coordination
Incidents that touch production are decided on the plant floor, not in the IT office. This section is completed with the plant leader before it is ever needed.
Process owner in the room; safety over forensics
No isolation, shutdown, or restoration of live production equipment happens without the process owner present and agreeing. Where forensic best practice conflicts with safe operation — a controller that must be power-cycled to reach a safe state, a line that cannot pause mid-batch — safe operation wins, and the timeline records what was done and why. Vendor-supported equipment gets the vendor on the phone through the pre-arranged support path, not an improvised remote session in the middle of the night.
Manual-operation fallback
- Know which lines can run manually, for how long, and what that costs
- A line that can run a shift on manual buys the response team a shift of calm.
- Decide the fallback trigger in advance
- Write down who calls for manual operation and on what condition — deciding this during the incident wastes the option.
- Practice the switchover at least once
- A fallback that has never been exercised in a maintenance window is a theory.
OT coordination record
| Production system or line | Process owner (named) | Manual fallback exists? Duration? | Vendor support path and window arrangements |
|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or incident response lead |
| Approval authority | Executive sponsor |
| Review frequency | Annual, after every incident or exercise that uses it, and at every provider or key-person change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded versions and the record of every activation and exercise; the plan's history is what shows a reviewer the capability is real rather than aspirational. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.