# Incident Response Plan — [Organisation name]

Version: [1.0] · Approved by: [name, role] on [date] · Next review: [date, at most 12 months later]
Owner: [role responsible for keeping this plan up to date]

Template by ClevSec (https://clevsec.one/blog/incident-response-plan-guide/). For informational purposes only,
not legal advice. Adapt it to your organisation and check the rules that apply to you.

---

## 1. Purpose and scope

This plan describes how [Organisation name] detects, responds to, recovers from and reports cybersecurity
incidents and personal data breaches.

- Systems in scope: [all IT systems, cloud services, endpoints, OT systems...]
- Locations and entities in scope: [...]
- Related documents: [information security policy, business continuity plan, backup procedure, crisis
  communication plan]

## 2. Definitions

- **Security event:** an observed occurrence that may indicate a security problem.
- **Incident:** an event that compromises the availability, authenticity, integrity or confidentiality of data
  or services.
- **Personal data breach:** a breach of security leading to the accidental or unlawful destruction, loss,
  alteration, unauthorised disclosure of, or access to, personal data (GDPR Article 4(12)).
- **Significant incident** (if NIS2 applies): an incident that has caused or can cause severe operational
  disruption or financial loss, or considerable damage to others (NIS2 Article 23(3)).
- **Major ICT-related incident** (if DORA applies): an incident classified as major under DORA Article 18 and
  its delegated regulation.

## 3. Incident response team

| Role | Name | Deputy | Phone | Out-of-band contact |
|---|---|---|---|---|
| Incident lead | | | | |
| IT / technical lead | | | | |
| Security lead (CISO) | | | | |
| Data protection officer / privacy lead | | | | |
| Legal | | | | |
| Communications | | | | |
| Management representative | | | | |

Out-of-band channel (works if email and chat are down): [e.g. a phone conference bridge, a separate messaging group]

## 4. External contacts

| Party | Organisation | Contact | Contract / reference |
|---|---|---|---|
| Forensics / incident response firm | | | |
| External legal counsel | | | |
| Cyber insurance (claims line) | | | Policy no. |
| National CSIRT / competent authority (NIS2) | | | |
| Data protection authority (GDPR) | | | |
| Financial supervisor (DORA) | | | |
| Police / cybercrime unit | | | |
| Key IT suppliers and cloud providers | | | |

## 5. Severity levels

| Level | Criteria | Respond within | Escalate to |
|---|---|---|---|
| P1 Critical | Essential services down, large-scale data breach, active attack | Immediately | Management, legal, DPO within 1 hour |
| P2 High | Major system compromised, sensitive data at risk | 4 hours | Security lead and IT management within 4 hours |
| P3 Medium | Limited impact, compromise contained | 24 hours | Security lead |
| P4 Low | Minor event, no data affected | 72 hours | Logged and reviewed |

Every P1 and P2 incident is also checked against the reporting criteria in section 8.

## 6. Response phases

### 6.1 Detection and analysis
- How incidents are reported: [service desk, security mailbox, phone number]
- Confirm the incident, record the time you became aware of it, set the severity level, open an incident log.

### 6.2 Containment
- Short term: [isolate systems, disable accounts, block addresses]
- Preserve evidence before wiping or rebuilding: [disk images, logs, memory]
- Record every action with a timestamp in the incident log.

### 6.3 Eradication and recovery
- Remove the root cause: [malware, compromised credentials, vulnerability]
- Restore from backups verified as clean; check integrity before going live.
- Recovery targets: [RTO / RPO per critical system, or a reference to the business continuity plan]

### 6.4 Post-incident review
- Within [5] business days of closing a P1 or P2 incident: timeline, root cause, what worked, what to
  improve, actions with owners and deadlines.

## 7. Communication

| Audience | Who informs them | When | Channel |
|---|---|---|---|
| Management | Incident lead | P1/P2: within 1 hour | Phone |
| Employees | Communications | When action is needed | [...] |
| Customers / affected people | Communications + DPO | GDPR: without undue delay if high risk | [...] |
| Media | Approved spokesperson only | As needed | Prepared statement |

## 8. Regulatory reporting (delete what does not apply)

- **GDPR:** notify the data protection authority within 72 hours of becoming aware of a personal data breach,
  unless it is unlikely to result in a risk to people (Article 33). Inform affected people without undue delay
  if the risk is high (Article 34). Record every breach, reported or not (Article 33(5)).
- **NIS2:** early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant
  incident; incident notification within 72 hours; final report within one month (Article 23(4)).
- **DORA:** initial notification within 4 hours of classifying an incident as major, and no later than 24 hours
  after becoming aware of it; intermediate report within 72 hours of the initial notification; final report
  within one month of the latest intermediate report (Delegated Regulation (EU) 2025/301).
- Notification templates are stored at: [location]

## 9. Testing and maintenance

- Tabletop exercise at least once a year; next exercise: [date, scenario]
- Contact details reviewed every quarter.
- Plan reviewed after every P1/P2 incident and at least yearly.

## 10. Incident log (one per incident)

| Time (UTC) | What happened / action taken | By whom |
|---|---|---|
| | | |