Incident Response Plan Template: What Your Business Should Document

Make the first ten minutes easier

During an incident, an employee should not need to search a policy library to learn whom to call. Put an immediately usable contact and escalation sheet at the front of the plan. Keep an offline copy where the response team can reach it if company email or the identity provider fails.

Write the plan for the business you operate. A cloud software company, a dental practice and a regional distributor have different dependencies, expertise and consequences. NIST's current SP 800-61 Revision 3 connects incident response with ongoing cybersecurity risk management rather than treating it as an isolated technical procedure.¹ The template below is an original planning aid, not a reproduction of a standard or a declaration of compliance.

Start with scope, authority and a real contact list

Name the services, locations and information the plan covers. State what it excludes and which other plan covers those exclusions. Explain who can declare an incident, authorize disruptive action, approve restoration and communicate externally. Assign a deputy for each critical decision; a title without a reachable person is insufficient.

Record primary and alternate contact methods for the incident lead, technical responder, operations lead, legal/privacy adviser and communications owner. Include the cloud host, critical software suppliers, insurer and retained response provider if those relationships actually exist. Verify contractual contacts and service hours rather than assuming every supplier provides emergency support.

Do not put passwords or recovery codes in the plan. Record the approved secure access method and the person responsible for it. Test that the backup decision-maker can obtain authorized access without sharing someone else's credentials.

Original incident response plan template

Copy these fields into a controlled document and replace every bracketed item before approving it.

The front-page reporting prompt can be simple: “What did you observe? When and where? Which service or account? Is business activity affected? What actions have already occurred?” Tell staff to report promptly and avoid experimenting with a suspicious system to confirm their theory.

Define severity using consequences

Use severity to prioritize decisions and resources. Do not equate every alert with a major incident or wait for perfect attribution before escalating a credible disruption.

For example, an organization might use three internal levels:

1. Limited: contained to a noncritical service, with no identified sensitive-data exposure. The lead documents the basis and reassesses as facts change.
2. Significant: a critical workflow is disrupted, a privileged account may be compromised, or sensitive-data exposure remains credible and unresolved. Business and privacy leadership join the response.
3. Critical: widespread service loss, safety impact or confirmed significant compromise requires executive decisions and specialist support.

These are illustrative categories, not legal thresholds. Include triggers for moving upward or downward, and record the evidence behind each change. “No evidence found yet” and “evidence proves no exposure” are different conclusions.

Containment needs approval and evidence precautions

Containment options might include disabling a session, isolating a device, restricting a compromised integration or temporarily suspending a service. State who may take each action and what business impact must be considered. Coordinate potentially destructive changes with qualified responders; indiscriminate shutdowns or cleanup can destroy evidence or disrupt essential operations.

FTC breach guidance recommends assembling appropriate technical, legal and business expertise and assessing notification obligations.² Your plan should therefore contain a decision process, not a universal instruction to notify everyone within an invented deadline. Requirements can depend on jurisdiction, data, sector, contracts and confirmed facts.

Keep a restricted incident log. Record time zone, observation, source, confidence, action, authorizer and resulting status. Preserve relevant logs before their retention window expires. Do not circulate customer records in a general chat channel to make the incident easier to discuss.

Worked example: a compromised supplier account

Fictional scenario: A distributor sees unusual exports from its ordering system using a supplier-support account. Orders still work, and it is not yet clear what the export contained.

The employee reports the account, export time and alert source. The incident lead assigns a significant severity because privileged access and possible customer information are involved. A technical responder preserves the account's activity logs and disables its sessions under the documented containment authority. Operations confirms whether disabling support will interrupt order processing.

The lead records three separate questions: Was access authorized? Which records were accessed? Were any records altered? A clean malware scan on a laptop does not answer those questions. The supplier is contacted through a previously verified channel, and the privacy adviser assesses the data and notification duties once facts are available.

The team restores supplier access only after validating the account controls and approving its permissions. It then creates follow-up work for support-account expiry and export-alert review. The plan does not claim that resetting a password automatically completes recovery.

Recover the business workflow, not only the server

Specify the order in which dependencies return: identity, network access, data, applications, integrations and customer-facing workflows as appropriate. Agree on what a successful restoration means before executing it.

A recovery checklist could require a known-good recovery point, integrity checks, access review, a tested sample transaction, reconciliation of missing or duplicate work, and a monitored period after reopening. State who approves each result and how the team returns to a safe state if validation fails.

Continuity arrangements may keep essential activity running while technical recovery is incomplete. Link the response plan to the continuity and disaster recovery plans, but preserve their different responsibilities.³

Test the decisions before relying on them

Run a short tabletop using an unfamiliar but plausible scenario. Ask participants to use only the plan and normal authorized resources. Record how long it takes to reach the incident lead, decide severity, authorize containment and locate recovery instructions.

Vary the exercise: the primary lead is unavailable; email cannot be used; the supplier denies involvement; a restored file fails validation. Do not test with live customer records or disruptive production actions unless separately approved.

Keep evidence of what the exercise actually demonstrated. A meeting attendance sheet establishes attendance, not recovery capability. Assign every gap an owner and acceptance criterion, such as “Deputy successfully reaches the alternate supplier contact,” rather than “Update contact list.”

Questions teams ask

How long should the plan be?

Keep the operational core short enough to use under pressure. Put detailed runbooks, contact lists and legal references in maintained appendices. Length is less important than whether people can make the next decision.

How often should it be updated?

Choose a review cadence the owner can sustain, and review after material changes, exercises and incidents. An acquisition, new critical supplier or changed recovery architecture can invalidate assumptions immediately.

Does a template make us incident-ready?

No. A template organizes decisions. Readiness also needs trained people, accessible contacts, working controls and tested recovery. Use the readiness assessment as an informational starting point, then validate your own response arrangements with appropriate expertise.

Sources and references

1. NIST. SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025-04-03). Current NIST incident-response guidance; replaces Rev. 2 and connects response with CSF 2.0. ↩

2. Federal Trade Commission. Data Breach Response: A Guide for Business. Business breach-response guidance on response teams, evidence and notification assessment. ↩

3. NIST. SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems, updated November 2010 (2010-11-11). Federal-system guidance used here as a planning reference, not a private-business mandate. ↩