A free, editable incident response plan — roles, severity levels, containment steps, and notification obligations. The document assessors and auditors ask to see first, not just a description of what it should contain.
This is a generic starting point, not legal advice. A plan is only useful if it reflects your real systems, real roles, and real escalation contacts — every bracketed section needs to be filled in accurately, and the roles need to be real people who know they hold them.
A plan that only exists as good intentions in someone's head isn't a plan — when an incident actually happens, decisions need to be fast and roles need to be unambiguous. At minimum, a usable plan defines: who's in charge, how severity is judged, how staff report a suspected incident, the containment steps for your systems, and exactly when you're legally required to notify someone.
The template below covers each of those, in the order most assessors expect to see them.
Incident Response Plan — [Company Name]
This plan sets out how [Company Name] detects, responds to, and recovers from information security incidents affecting our systems, data, or services. It applies to all staff, contractors, and third parties with access to our systems.
An "incident" is any event that compromises the confidentiality, integrity, or availability of our information or systems — including a suspected data breach, malware infection, unauthorised access, denial of service, or lost/stolen device.
Incident Lead: [Name/role] — owns the response, makes containment decisions, and coordinates communication.
Technical Lead: [Name/role] — investigates, contains, and remediates the technical cause.
Communications Lead: [Name/role] — handles internal updates, customer notification, and regulator contact where required.
[If you have a Data Protection Officer:] DPO: [Name] — assesses whether the incident is a reportable personal data breach.
Every member of staff is responsible for reporting a suspected incident immediately — see Section 4.
Critical — active data breach, ransomware, or complete loss of a critical system. Immediate response required, Incident Lead notified within 15 minutes.
High — confirmed unauthorised access or malware with no evidence of data exfiltration yet. Response within 1 hour.
Medium — suspicious activity requiring investigation, no confirmed compromise. Response within 4 hours.
Low — policy violation or minor issue with no security impact. Response within 1 business day.
[Adjust these thresholds and response times to match your business — a critical system for one organisation may not be for another.]
Any member of staff who suspects an incident must report it immediately to [reporting channel — e.g. security@yourcompany.com or a named person], including what was observed, when, and any systems or accounts involved.
Do not attempt to independently investigate, delete evidence, or power off affected systems before the Incident Lead is engaged — this can destroy evidence needed for the investigation.
On confirmation of an incident, the Technical Lead: isolates affected systems from the network where possible without destroying evidence; revokes or resets compromised credentials; preserves logs and evidence for investigation; identifies the root cause before systems are restored.
[Add your specific containment procedures per system — e.g. how to isolate a compromised laptop, how to revoke cloud account access, who holds emergency admin credentials.]
Systems are restored from a known-clean backup or rebuild only after the root cause is identified and remediated. [State your backup restoration process and who authorises systems being brought back online.]
Affected accounts have credentials reset and multi-factor authentication re-verified before being reactivated.
If the incident involves a personal data breach likely to result in a risk to individuals, we must notify the ICO within 72 hours of becoming aware of it (UK GDPR Article 33). If the risk is high, affected individuals must also be notified without undue delay (Article 34).
[List any sector-specific or contractual notification obligations — e.g. client SLAs, cyber insurance notification windows, NIS2 reporting for essential/important entities, PCI-DSS card scheme notification.]
The Communications Lead maintains a log of every notification made, to whom, and when.
Within [5–10] business days of an incident being closed, the Incident Lead runs a review covering: root cause, what worked, what didn't, and any follow-up actions needed to prevent recurrence.
Follow-up actions are logged, assigned an owner and due date, and tracked to completion — auditors will ask to see this, not just the incident report itself.
This plan is tested at least [annually] via a tabletop exercise or simulated incident, and reviewed after every real incident and whenever there is a significant change to our systems. Last tested: [Date]. Next review due: [Date].
Is an incident response plan required for Cyber Essentials Plus?
CE+ doesn't mandate a written plan for the base certification, but assessors and cyber insurers increasingly expect one, and it becomes a hard requirement once you're also pursuing ISO 27001 or handling any NIS2-in-scope services. Even outside a specific framework, it's the document that determines how fast — and how well — you actually respond when something goes wrong.
What's the difference between this and a Business Continuity Plan?
An incident response plan is specifically about detecting, containing, and recovering from a security incident. A business continuity plan is broader — it covers keeping the business running through any major disruption (a fire, a supplier failure, a pandemic), of which a cyber incident is only one cause.
Do we have to report every incident to the ICO?
No — only personal data breaches likely to result in a risk to individuals' rights and freedoms. A contained incident with no personal data involved, or one assessed as genuinely low-risk, doesn't need reporting — but you should still document the assessment showing why you decided not to report.
Who should be the Incident Lead in a small business?
It's usually whoever has the authority to make fast decisions — often the founder, ops lead, or IT manager — not necessarily the most technical person. The Technical Lead role can sit with an outsourced IT provider if you don't have in-house technical staff, as long as they're contractually on-call for this.
Fortify's Policy Engine generates an Incident Response Policy tailored to your systems and regulation scope, and the portal's Incidents module actually runs your response against it — logging every step, follow-up action, and notification for the audit trail you'll be asked for later.