Incident Response Plan Template

Most incident response plans fail on the first night because nobody can find the deputy's phone number, nobody knows who may take a system offline, and the regulatory clock has been running for hours before anyone looks at it. This template is a ready-to-adopt cyber incident response plan: scope, a severity matrix, roles with deputies, an escalation and communication matrix, response phases aligned to NIST SP 800-61 Rev. 3 and CSF 2.0, evidence handling, external parties, notification deadlines, a playbook index, and credential revocation for people and non-human identities. It is for CISOs, security operations leads and IT managers who need a plan the board can approve and the on-call engineer can follow.

How to use this template

• Replace text in square brackets, such as [Organisation], [Incident manager] and [30 minutes], with your own teams, tools and targets.
• "Must" is mandatory; "should" is recommended and may be skipped with a recorded reason. Target times run from incident declaration.
• This plan is the top-level document. Scenario playbooks (section 11) inherit its severity, escalation and communication rules.
• Keep printed and offline copies: the plan must be readable when email, the identity provider and the document store are down.
• For the capability behind this plan, see the Incident Response Guide.

1. Purpose

This plan sets out how [Organisation] prepares for, detects, analyses, contains, eradicates and recovers from cyber security incidents, and learns from them. It defines who leads, who decides and who must be told by when, so that incidents are handled consistently, evidence is preserved, obligations are met and business impact is limited. It implements [Information Security Policy] clause [X] and CIS Control 17 safeguards 17.1 to 17.9.

2. Scope

• All systems, networks, cloud tenants, SaaS applications and data owned, operated or processed by or for [Organisation] in [legal entities].
• All identities that access them: employees, contractors, third parties, service accounts, workload identities, API keys, tokens, certificates and AI agents.
• Supplier incidents that affect [Organisation] data or services, handled with the supplier under [contract terms].

3. Definitions and severity levels

• Incident: an event that actually or potentially jeopardises the confidentiality, integrity or availability of [Organisation] systems or data, or breaches security policy. CSF 2.0 DE.AE-08 states: "Incidents are declared when adverse events meet the defined incident criteria"; the matrix below is those criteria.
• Personal data breach: a security incident affecting personal data, assessed under section 10 by [DPO].
• Major incident: any SEV1, or a SEV2 the [Incident manager] elevates. NIST separates escalation ("increasing resources or time frames") from elevation ("involving a higher level of management").
• Incident manager: the single point of coordination. NCSC: "There must be a central point of co-ordination, no matter who is involved".

Severity is set on known and assumed facts. When in doubt, rate higher and downgrade later.

4. Incident response team: roles and contacts

Every role must have a named deputy. NCSC advises "at least 2 contact methods and 2 or more people" for each key contact, and the people escalated to must have authority to make decisions such as taking a critical service offline.

Out-of-band bridge: [conference number or alternate tenant], tested [quarterly]. Assume corporate email and chat may be watched by the attacker during a SEV1 or SEV2.

5. Escalation and communication matrix

Statements must not speculate on cause or attribution. Holding statements for [ransomware, data breach, outage] are kept at [location].

6. Response phases

NIST SP 800-61 Rev. 3 maps the earlier life cycle onto the CSF 2.0 Functions: Preparation to Govern, Identify and Protect; Detection and Analysis to Detect; Containment, Eradication and Recovery to Respond and Recover; Post-Incident Activity to the Identify Improvement category.

Containment that alerts the attacker can trigger destructive action. For SEV1 and SEV2 the technical lead decides whether to contain at once or observe briefly to scope, and records why. Synchronise recovery with the [business continuity plan]; see the Business Continuity and Disaster Recovery Guide.

7. Identity and non-human identity revocation

Disabling a user account does not end sessions, invalidate API keys or rotate the secrets an attacker copied from a server. The identity lead must run these steps for every identity in scope and log each action.

Remove the access path and persistence before rotating, or the attacker simply collects the new secret. Hybrid identity components need special care: in the Storm-0501 hybrid cloud attacks, stolen Entra Connect Sync credentials carried ransomware operators into the cloud. See the Leaked Credential Response Playbook and the Service Account Security Guide.

8. Evidence handling

1. Collect evidence before destructive containment where safety allows. CISA: "When an endpoint requires forensic analysis, capture a memory and disk image for evidence preservation."
2. Log each item: what it is, how, when and by whom acquired, its hash and storage location. Use chain-of-custody forms where legal action, an insurance claim or [HR proceedings] may follow.
3. Collect volatile data first, then disk images, cloud snapshots, and identity, EDR, network and SaaS audit logs. Extend log retention for affected sources at once.
4. Record all times in UTC. Store evidence in [evidence store], restricted to the IR team and legal, for [period].
5. Do not upload samples or indicators to public services during an active incident without technical lead approval.

See the Digital Forensics (DFIR) Guide.

9. External parties

See the Cyber Insurance Guide.

10. Regulatory notification clocks

This is an overview, not legal advice. Clocks generally start at awareness or determination, not at the end of the investigation, so record the time of awareness and engage legal early.

See the GDPR Compliance Guide for Security Teams and the NIS2 Directive Guide.

11. Playbook index

NCSC advises that playbooks hold "a set of simple instructions which will cover at least the first few hours of each incident".

12. Incident log and post-incident report

The scribe records, for every incident: ID; severity and changes; detection, declaration and awareness times (UTC); affected systems, identities and data; each action and decision with owner, time and reason; notifications; and evidence references. The post-incident report covers summary, timeline, root cause and entry point, what worked in the response and what did not, notifications, impact, and actions with owners and due dates. Reviews are blameless and held within [10 business days] for SEV1 and SEV2, in line with CIS safeguard 17.8, Conduct Post-Incident Reviews.

13. Testing and maintenance

• Contact check: every [quarter], call each primary and deputy and test the out-of-band bridge.
• Tabletop: at least [annually] with executives, using a ransomware or identity compromise scenario.
• Technical drill: at least [annually], rehearse section 7, including a service principal and a cloud key, and time it.
• Review: after every SEV1 or SEV2, after organisational or regulatory change, and at least [annually].

14. Source references

1. NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
2. NCSC: Incident management, cyber incident response processes
3. CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
4. CIS: Controls Assessment Specification, Control 17
5. GDPR: Article 33 Notification of a personal data breach to the supervisory authority
6. EUR-Lex: Directive (EU) 2022/2555 (NIS2)
7. SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
8. Microsoft Learn: Revoke user access in Microsoft Entra ID
9. AWS: Revoke IAM role temporary security credentials
10. NCSC: Cyber Incident Response scheme

Implementation guidance

1. Fill sections 3, 4 and 9 first: severity criteria, named people with deputies and the retainer contract are what responders need in the first hour.
2. Pre-approve containment: agree which actions the technical lead may take alone (isolate a host, disable a user, revoke a cloud session) and which need the executive sponsor (shutting down a revenue service).
3. Build the identity inventory: section 7 only works if you can list the service accounts, keys and app registrations a compromised system holds. See the Secrets Management Guide.
4. Map notification duties: agree with legal which section 10 regimes apply to each entity and who decides materiality.
5. Exercise, then fix: run a tabletop within [90 days] of approval and update the plan.

Small organisations can combine roles (incident manager and technical lead) but still need a deputy for each, and should rely on a retainer or managed detection provider for forensics. Large or regulated organisations should keep the plan in a crisis management tool with offline export and track: time from detection to declaration, time to revoke compromised credentials, contacts verified in the last quarter, and post-incident actions closed on time. For ransomware, see the Ransomware Response and Recovery Guide.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Incident Response Guide · Ransomware Response and Recovery Guide · Digital Forensics (DFIR) Guide · Leaked Credential Response Playbook · SOC Guide