Use this template to create an organisation-specific incident response plan. Replace every bracketed field, connect it to technical runbooks and legal decision records, obtain approval, control access, and exercise it. The template does not by itself establish GDPR, NIS2 or sectoral compliance.
NIST SP 800-61 Rev. 3 is the current NIST incident response publication. It integrates preparation, detection, response, recovery and improvement into Cybersecurity Framework 2.0 rather than retaining Rev. 2 as the current model.
1. Document control
| Field | Entry |
|---|---|
| Organisation and covered entities | [LEGAL ENTITIES] |
| Systems, locations and services in scope | [SCOPE] |
| Owner | [ROLE / NAME] |
| Approver | [MANAGEMENT BODY / EXECUTIVE] |
| Version and approval date | [VERSION / DATE] |
| Next review trigger or date | [TRIGGER / DATE] |
| Controlled storage and offline access | [LOCATIONS] |
Purpose: coordinate detection, containment, investigation, notification, recovery and improvement for cybersecurity incidents affecting the defined scope.
2. Activation and classification
Activate this plan when [ROLE] confirms one or more of these conditions:
- suspected compromise of privileged or administrative access;
- material loss of confidentiality, integrity or availability;
- malware, extortion, destructive activity or unauthorised persistence;
- significant interruption of a priority service;
- a supplier event that could affect the organisation; or
- facts that require assessment under data-protection, NIS2, sector, contract or insurance rules.
| Severity | Business and security criteria | Required escalation |
|---|---|---|
| Critical | [SAFETY, WIDESPREAD OR MATERIAL IMPACT] | [IMMEDIATE ROLES] |
| High | [SERIOUS, CONTAINED OR POTENTIALLY REPORTABLE IMPACT] | [ROLES / TIME] |
| Moderate | [LIMITED CONFIRMED IMPACT] | [ROLES / TIME] |
| Low / event | [NO CONFIRMED INCIDENT IMPACT] | [MONITOR / CLOSE] |
Do not use severity alone to decide legal reporting. Record a separate assessment against every applicable definition and threshold.
3. Response roles and authority
| Function | Primary / alternate | Authority and duties |
|---|---|---|
| Incident commander | [NAMES] | Set severity, coordinate decisions, approve stand-down |
| Technical lead | [NAMES] | Preserve evidence, contain, eradicate, recover |
| Business lead | [NAMES] | Assess service impact and continuity options |
| Legal / privacy | [NAMES] | Direct legal and notification assessments |
| Communications | [NAMES] | Prepare approved internal and external messages |
| Recorder | [NAMES] | Maintain chronology, decisions, actions and costs |
| Executive liaison | [NAMES] | Escalate material risk and obtain approvals |
Emergency authority: [WHO MAY ISOLATE SYSTEMS, DISABLE ACCESS, ENGAGE PROVIDERS AND APPROVE SPEND].
Out-of-band communications: [CHANNEL, ACCESS METHOD, TEST DATE].
4. First-response checklist
- Record detection source, time, reporter and initial facts.
- Assign incident ID, commander, recorder and severity.
- Preserve original alerts, logs, images and relevant volatile evidence.
- Identify affected assets, identities, data, services and third parties.
- Start one authoritative UTC-normalised chronology.
- Select containment actions and document risk trade-offs.
- Contact [LEGAL / PRIVACY / INSURER / PROVIDERS] when criteria are met.
- Open separate regulatory and contractual notification assessments.
- Establish the next briefing time and decision owners.
5. Investigation and containment record
| Question | Finding / evidence / owner |
|---|---|
| What happened and how was it detected? | [ENTRY] |
| Which systems, accounts and data are affected? | [ENTRY] |
| Is the activity ongoing? | [ENTRY] |
| What is confirmed versus assumed? | [ENTRY] |
| What containment was chosen, by whom and why? | [ENTRY] |
| What evidence must be preserved and where? | [ENTRY] |
| Which services and users are affected? | [ENTRY] |
| Which suppliers or customers require contact? | [ENTRY] |
6. Notification decision record
For each regime or contract, complete a separate row. “Not reportable” still needs facts, reasoning, owner and review time.
| Track | Threshold and awareness point | Decision / deadline / recipient | Owner / evidence |
|---|---|---|---|
| NIS2 / national law | [SIGNIFICANT-INCIDENT TEST; AWARENESS TIME] | [EARLY WARNING / NOTICE / REPORTS] | [ENTRY] |
| GDPR | [PERSONAL-DATA-BREACH AND RISK TEST; AWARENESS TIME] | [AUTHORITY / PEOPLE / NO NOTICE] | [ENTRY] |
| Sector rules | [TEST] | [ENTRY] | [ENTRY] |
| Contracts | [TEST] | [ENTRY] | [ENTRY] |
| Insurance | [POLICY TEST] | [ENTRY] | [ENTRY] |
Under NIS2 Article 23, in-scope entities report significant incidents in stages, generally including a 24-hour early warning, 72-hour incident notification and one-month final report, with qualifications in the Directive and national implementation. Under GDPR Article 33, a controller's 72-hour supervisory-authority period starts after awareness of a personal data breach and is subject to the risk exception. Verify all facts and applicable local rules rather than copying the headline times into a deadline calendar.
7. Recovery and stand-down
- Remove the identified cause and close exploited access paths.
- Rotate affected credentials and secrets.
- Restore from verified sources in the approved service order.
- Validate security, data integrity and business functionality.
- Increase monitoring for recurrence.
- Confirm outstanding notifications and stakeholder updates.
- Obtain incident-commander and business-owner approval to stand down.
8. Post-incident review
Hold the review after facts stabilise. Record root and contributing causes, what worked, control and response gaps, actual service impact, reporting performance and supplier issues. Assign corrective actions with owner, due date, risk priority and retest method. Update this plan, continuity arrangements, risk records and training as needed.
9. Exercise record
| Field | Entry |
|---|---|
| Scenario and objectives | [ENTRY] |
| Participants and alternates | [ENTRY] |
| Decisions tested | [ENTRY] |
| Evidence observed | [ENTRY] |
| Gaps and corrective actions | [ENTRY] |
| Retest owner and date | [ENTRY] |
For customisation and tabletop facilitation, see our incident response services.
Sources and review
This template was substantively reviewed on 8 August 2026. It avoids promising compliance from a generic document and separates operational severity from legal reporting tests.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.