How to Write an Incident Response Plan That Your Team Will Actually Follow

An incident response plan gives your team a calm, known sequence for the moment something goes wrong: who takes charge, where the response happens, and what the first hour looks like. The plans that get followed share one trait: they are short enough to use under pressure. The build:

• Define severity levels and name the people who respond
• Write a first-hour runbook plus short runbooks for your likely scenarios
• Test the plan with a tabletop exercise and put reviews on the calendar

Verified against NIST SP 800-61 Rev. 3 on 2026-09-18.

The same plan structure serves a 5-person startup and a 120-person company. Write it for scale from day one, and if your company has operated for years without one, the steps below are the same and none of them require a security team to complete.

Prerequisites

• A list of your core systems: identity provider, email, main SaaS apps, anywhere customer data lives
• The names of the people who administer those systems, including your IT provider if support is outsourced
• Two to three hours to draft, and one hour later for the tabletop test

Step 1: Define What Counts as an Incident, in Tiers

1. Write one sentence defining an incident: an event that threatens the confidentiality, integrity, or availability of your systems or data.
2. Define three severity tiers with concrete examples from your own stack. High: compromised account, ransomware, confirmed data exposure. Medium: lost laptop, phishing message a user interacted with. Low: phishing reported and not clicked, a policy violation with no exposure.
3. State who can declare each tier. Anyone should be able to raise a suspected incident; a named person confirms the tier.

Tiers keep a lost laptop from triggering the same response as ransomware, which is what makes the plan credible enough to follow.

Step 2: Name the Roles, With Backups

1. Assign an incident commander per tier: the person who runs the response and makes the calls. For high severity this is typically a founder or your IT provider's escalation contact.
2. Assign a communications owner: the one voice for internal updates and any customer or legal notices.
3. Assign a technical lead per core system, using the administrator list from your prerequisites.
4. Name a backup for each role, and record phone numbers, since the incident may take email or Slack down with it.

Names, not titles. A plan that says "the security team" in a company that has no security team is the plan nobody follows.

Step 3: Pick the Channel Where Response Happens

1. Create a dedicated channel in your chat tool, such as #incident-response, and pin the plan there.
2. If you run a ticketing tool such as Jira Service Management, add an incident type so every response leaves a record with timestamps.
3. Agree on a fallback channel outside your primary stack, such as a phone bridge, for the case where the incident affects the chat tool itself.

Step 4: Write the First-Hour Runbook

1. Declare: post what is known in the incident channel and page the incident commander for the tier.
2. Contain: disable the affected account in the identity provider, isolate the device, or revoke the exposed credential. One containment action per likely scenario.
3. Preserve: note times, save screenshots, and keep affected machines powered on for evidence rather than wiping them.
4. Escalate: list the outside contacts with numbers, including your IT provider, cyber insurer, and counsel, and state which tiers trigger each call.

Keep the runbook to a single page of atomic actions. Under pressure, people execute checklists and skim paragraphs.

Step 5: Add Short Runbooks for Your Likely Scenarios

1. Cover the incidents an SMB most plausibly meets: a compromised account, a phishing campaign, a lost or stolen device, ransomware, and a breach at a SaaS vendor you depend on.
2. For each, write the specific first moves in your stack with exact paths, for example: Google Admin console → Directory → Users → the user → Suspend user.
3. Note the evidence to capture for each scenario before any cleanup begins.

Step 6: Write the Closing Loop

1. Set the rule that every high and medium incident ends with a short retrospective: what happened, the timeline, what changes.
2. Turn each retrospective's changes into tickets with owners, so the plan and the settings improve after every use. NIST SP 800-61 Rev. 3 frames incident response as continuous improvement across the whole risk management cycle rather than a document that sits on a shelf, and the retrospective is where that improvement happens.
3. Store the plan where everyone can reach it, keep an offline copy with the phone list, and link it from your channel topic.

Verify the Plan Works

• Run a one-hour tabletop exercise: pick a scenario, walk the roles through the runbook aloud, and note every step that stalls on a missing name, access, or number
• Confirm each named person can open the plan and reach the fallback channel from a personal device
• Check that every containment action has an owner who holds the admin access it requires

Fix what stalled, then put a recurring review on the calendar for twice a year and after every real incident.

Troubleshooting

• The plan keeps growing past usable length. Move scenario detail into the per-scenario runbooks and keep the core plan to the tiers, the names, and the first hour.
• Roles went stale after a departure. Tie the plan to offboarding: when an admin leaves, the same checklist that revokes access reassigns their incident role.
• Nobody can run the tabletop. That is the signal the work has outgrown the additional-duty owner, and it is a normal point to hand incident response to a managed IT provider rather than a reason to skip testing.

Would you like an incident response plan drafted, tested, and kept current without owning the project yourself? ScaleIt builds and runs this as part of managed IT support for startups and SMBs. Book a free call and we will map the plan to your stack.

Verified against NIST SP 800-61 Rev. 3 (April 2025) on 2026-09-18. Vendor docs: https://csrc.nist.gov/pubs/sp/800/61/r3/final, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf.