A plan you build before the crisis, not during it.
Every organisation will face a security incident. That is not pessimism. It is the operating reality of doing business in a connected world. The question is not whether an incident will occur, but whether your organisation will respond with clarity and control, or with confusion and panic. The difference between these two outcomes is almost never talent or technology. It is preparation.
This template provides a comprehensive framework for incident response that you can adapt to your organisation’s specific needs. It covers incident classification, step-by-step response procedures, contact lists for internal and external stakeholders, and a documentation template for recording every aspect of an incident from detection through to post-incident review.
The organisations that handle incidents well share a common trait: they rehearsed before it mattered. They had a written plan, tested it with tabletop exercises, and ensured that every person with a role in the response knew what was expected of them. The organisations that handle incidents badly also share a common trait: they assumed they would figure it out when the time came. They did not.
Why panicked decisions during a breach cause more damage than the breach itself
When an organisation discovers a security breach, the natural human response is fear. And fear drives poor decision-making. We have seen organisations wipe compromised servers before forensic images were taken, destroying the evidence needed to understand what data was actually accessed. We have seen IT teams reset every password in the company simultaneously, locking out staff and creating a secondary business continuity crisis on top of the original security event. We have seen senior leaders delay regulatory notification because they hoped the situation would resolve itself, turning a manageable incident into a regulatory investigation.
Every one of these mistakes stems from the same root cause: the absence of a pre-established plan. When people do not know what to do, they improvise. And improvisation under pressure, with incomplete information and high stakes, produces predictably poor results. An incident response plan removes improvisation from the equation. It replaces panic with procedure, speculation with structure, and gut feeling with documented, tested, rehearsed actions.
The cost of getting this wrong is significant. The UK Government’s Cyber Security Breaches Survey consistently finds that the average cost of a cyber incident for medium and large businesses runs into tens of thousands of pounds. But the financial cost of a poorly handled incident is always higher than the cost of the incident itself. Regulatory fines, legal action, customer churn, reputational damage, and the operational disruption of a chaotic response all compound the original harm.
“The time to build your incident response capability is before you need it. Every organisation that has been through a serious breach will tell you the same thing: the plan you had mattered more than the tools you owned.”
Incident classification
Not every security event demands the same response. A blocked phishing email does not require the same mobilisation as active ransomware. Classification ensures that your response is proportionate, that resources are allocated appropriately, and that escalation happens when it should. The four severity levels below provide a framework for consistent, repeatable triage decisions.
Critical
This is the classification that nobody wants to invoke, but everybody needs to be prepared for. A critical incident means an active breach is underway. Ransomware encrypting production systems. Data exfiltration confirmed and ongoing. Complete infrastructure outage affecting business operations. An attacker with live access to your environment. At this severity level, every minute of delay compounds the damage. The response must be immediate, coordinated, and decisive. External incident response specialists should be engaged without hesitation. Senior leadership must be notified within the hour. Regulatory obligations begin their countdown the moment you become aware of a personal data breach. This is not the time for internal debate about whether the situation is serious enough to escalate. If there is any doubt, classify upward.
High
A high severity incident represents a confirmed security event that poses a significant risk to the organisation but is not yet at the point of active, uncontrolled compromise. This includes confirmed malware on production endpoints, a compromised user account with access to sensitive data, successful phishing attacks where credentials have been entered, or significant service disruption caused by a security event. The distinguishing factor between high and critical is containment: if you can still take meaningful action to prevent escalation, you are likely dealing with a high severity incident. Response should begin within two hours of detection, with containment actions taking priority over root cause analysis.
Medium
Medium severity covers incidents that require investigation and a measured response but do not demand the immediate mobilisation of your entire response team. Suspicious login activity from an unfamiliar location. A phishing email that may have been opened but where credential entry is unconfirmed. Detection of a potentially unwanted application that your endpoint protection has quarantined. A vulnerability scan revealing an exposed service that should not be internet-facing. These events require attention within 24 hours. They need proper investigation, documentation, and resolution. The danger with medium severity incidents is complacency. Left uninvestigated, a medium event can quietly escalate into something far worse.
Low
Low severity incidents are security events that have been detected and contained by existing controls, or policy violations that do not pose an immediate threat. A blocked malware download. A phishing email caught by filters before delivery. A staff member using an unapproved cloud storage service. A failed brute force attempt against a single account. These events should still be logged, reviewed, and tracked for patterns. A sudden increase in low severity events, particularly of the same type, can indicate reconnaissance activity or a broader campaign that has not yet succeeded. Low severity does not mean no action. It means proportionate action.
Response procedure
A structured, sequential response procedure ensures that nothing is missed and that actions are taken in the right order. The sequence matters. Attempting to remediate before you have contained the threat means the attacker can undo your fixes in real time. Investigating before you have preserved evidence means critical forensic data may be lost. Each step builds on the one before it.
This six-step framework follows the widely accepted incident response lifecycle used by the NCSC, NIST, and SANS. Adapt the specific actions within each step to reflect your organisation’s technology environment, team structure, and regulatory obligations.
Identify and assess
The first minutes of incident response are about establishing facts, not fixing problems. What exactly happened? Which systems, accounts, or data sets are affected? When did the event begin, and is it still ongoing? How was it detected, and by whom? The quality of your initial assessment determines the quality of every decision that follows. Resist the urge to start remediating before you understand the scope. A common mistake is to see malware on one endpoint and immediately begin cleaning that single machine, only to discover hours later that the attacker had already moved laterally to six other systems. Take the time to classify the severity accurately using the framework above, and document your initial findings even if they are incomplete.
Contain the threat
Containment is about stopping the bleeding. The objective is to prevent the incident from spreading further while preserving evidence for investigation. Isolate affected systems from the network. Disable compromised user accounts. Block malicious IP addresses, domains, or email addresses at the perimeter. If an attacker has access to your environment, containment means cutting off their access paths without alerting them in ways that cause them to accelerate their attack. Critically, containment does not mean wiping machines or deleting files. Do not destroy evidence. Do not rebuild systems until the investigation phase has determined the full scope of compromise. The single most damaging action organisations take during incident response is premature remediation that destroys the evidence needed to understand what actually happened.
Notify stakeholders
Notification is both a practical necessity and, in many cases, a legal obligation. Internally, senior management, legal counsel, and the board (for critical incidents) need to be informed. Your IT support provider or managed security service must be engaged immediately. Externally, the requirements depend on the nature of the incident. If personal data has been compromised, the ICO must be notified within 72 hours of becoming aware of the breach under UK GDPR. Your cyber insurance provider needs early notification to activate coverage and provide access to their incident response panel. Law enforcement, through Action Fraud or the NCSC, should be considered for criminal activity. Communication with affected customers or data subjects may also be required. Every notification should be documented with timestamps, recipients, and content.
Investigate root cause
With the immediate threat contained, the focus shifts to understanding exactly what happened, how it happened, and the full extent of the impact. This is forensic work. It involves reviewing logs, analysing malware samples, tracing the attacker’s path through your environment, and identifying the initial point of compromise. Was it a phishing email? An unpatched vulnerability? A misconfigured cloud service? Stolen credentials from a third party breach? The root cause determines your remediation strategy. Without understanding how the attacker got in, you cannot be confident that closing one door does not leave three others open. For critical and high severity incidents, consider engaging specialist digital forensics support. Internal teams often lack the tools and experience for deep forensic analysis.
Remediate vulnerabilities
Remediation addresses the root cause and closes the vulnerabilities that were exploited. This is where you remove malware, revoke attacker access, patch the vulnerabilities that enabled the breach, reset all potentially compromised credentials, and rebuild systems from known clean backups where necessary. Remediation must be thorough. If the attacker gained access through a phishing email because MFA was not enforced on a particular set of accounts, remediation means enforcing MFA across every account, not just the one that was compromised. If a vulnerability in an internet-facing application was the entry point, remediation means patching that application and reviewing all internet-facing services for similar weaknesses. Partial remediation guarantees a repeat incident.
Recover and review
Recovery means restoring normal business operations with confidence that the threat has been fully eliminated. This includes bringing systems back online in a controlled manner, monitoring closely for any signs of recurrence, and verifying that all remediation actions have been effective. But recovery is not the final step. The post-incident review is arguably the most valuable phase of the entire process. Conduct a structured debrief with all involved parties. What worked well? What failed? Where were the gaps in detection, communication, or response? What would you do differently? Document the findings formally and use them to update your incident response plan, your security controls, and your training programme. An incident that teaches you nothing is an incident wasted.
“Preserve evidence first, remediate second. The instinct to immediately wipe and rebuild compromised systems is understandable, but it destroys the forensic trail you need to understand the full scope of a breach and satisfy regulatory investigators.”
Contact list template
During an active incident, you cannot afford to spend time searching for phone numbers, looking up policy documents, or debating who should be contacted. Your contact list must be pre-built, regularly updated, and accessible even if your primary systems are down. Print a copy. Store it in a secure location outside your IT environment. If ransomware encrypts your file server, the contact list on that file server is useless.
Every individual on this list should know they are on it, understand their role during an incident, and have participated in at least one tabletop exercise. A contact list that exists only on paper, where the named individuals have never been briefed, provides a false sense of readiness.
Internal contacts
Incident Response Lead
The designated individual responsible for coordinating the response effort. This person has the authority to make decisions about containment, escalation, and communication during an active incident.
IT Director or Manager
The senior technical authority who can authorise system changes, network isolation, and infrastructure modifications during response. Must be reachable outside business hours.
Senior Management Sponsor
A member of the leadership team with authority to approve expenditure on external support, make decisions about business continuity, and communicate with the board.
Legal and Compliance Lead
Responsible for advising on regulatory notification obligations, managing legal privilege over investigation documents, and liaising with external legal counsel.
Communications Lead
Manages internal and external communications, including staff updates, customer notifications, and any media enquiries. All public statements must be coordinated through this individual.
External contacts
IT Support Provider
Your managed service provider or outsourced IT team. They need to be engaged immediately for technical support during containment and remediation. Confirm their incident response SLA in advance.
Cyber Insurance Provider
Notify your insurer as early as possible. Most policies require notification within 24 to 48 hours. Your insurer may provide access to pre-approved incident response firms, legal counsel, and crisis communications support.
Specialist Incident Response Firm
For critical incidents, you may need digital forensics and incident response (DFIR) capabilities that go beyond your internal or MSP resources. Identify and pre-qualify a firm before you need them.
ICO (Data Protection Regulator)
If personal data has been compromised, the Information Commissioner’s Office must be notified within 72 hours. Helpline: 0303 123 1113. Have your Data Protection Officer’s details ready.
Action Fraud / NCSC
Report cyber crime to Action Fraud on 0300 123 2040. The NCSC provides guidance and may offer direct support for significant incidents affecting UK organisations.
Regulatory obligations you cannot afford to overlook
Incident response is not solely a technical exercise. It carries significant legal and regulatory dimensions that must be addressed in parallel with your technical response. Under UK GDPR, any personal data breach that poses a risk to individuals must be reported to the Information Commissioner’s Office within 72 hours of the organisation becoming aware of it. This is 72 hours from awareness, not from the completion of your investigation. The clock starts the moment you know.
If the breach is likely to result in a high risk to affected individuals, those individuals must also be notified directly and without undue delay. This means clear, plain language communication about what happened, what data was involved, what you are doing about it, and what they should do to protect themselves. Attempting to minimise or obscure the severity of a breach in public communications is both ethically wrong and strategically counterproductive. Regulators and customers respond more favourably to organisations that are transparent and proactive than to those that appear evasive.
Beyond data protection, sector-specific regulations may impose additional obligations. Financial services firms regulated by the FCA have mandatory reporting requirements. Organisations providing essential services under the NIS Regulations must report incidents to their relevant competent authority. Healthcare organisations must notify NHS Digital. Your incident response plan must identify which regulatory frameworks apply to your organisation and include the specific notification procedures, timelines, and contact details for each.
Incident documentation template
Thorough documentation during an incident serves multiple purposes. It provides the factual basis for regulatory notifications. It supports insurance claims with a clear timeline of events and actions. It enables effective post-incident review. And it creates an institutional record that helps your organisation learn and improve.
Begin documenting from the moment an incident is detected. Assign a dedicated scribe if possible, someone whose sole responsibility during the response is to record actions, decisions, and timestamps. In the pressure of an active incident, details that seem obvious in the moment are quickly forgotten. If it is not written down, it did not happen.
Incident identification
Unique incident ID. Date and time of detection. Name and role of the person who detected or reported the incident. Method of detection (automated alert, user report, third party notification). Initial severity classification.
Incident description
Clear narrative of what occurred. Systems, applications, and data sets affected. Number of users or records potentially impacted. Whether the incident is ongoing or contained. Initial assessment of business impact.
Response timeline
Chronological log of every action taken during the response. Each entry should include the date and time, the action taken, the person responsible, and the outcome. This timeline is critical for regulatory reporting, insurance claims, and the post-incident review.
Root cause analysis
How the incident occurred. The initial attack vector or point of failure. Contributing factors such as missing patches, misconfiguration, or human error. Whether this vulnerability was previously known or identified in risk assessments.
Impact assessment
Confirmation of whether personal data was compromised. Classification of data types involved. Number of data subjects affected. Financial impact including direct costs and business disruption. Reputational impact assessment. Whether regulatory notification is required and the deadline for doing so.
Remediation and lessons learned
Every remediation action taken, with status, owner, and completion date. Changes to security controls, policies, or procedures resulting from the incident. Training or awareness actions identified. Date of the post-incident review and attendees. Formal sign-off by the incident response lead and senior management.
Incident response maturity separates the prepared from the vulnerable
There is a measurable spectrum of incident response maturity across organisations, and where you sit on that spectrum determines how much damage an incident will cause. At the lowest level, organisations have no plan, no designated responders, and no tested procedures. They discover incidents by accident, respond reactively, and learn nothing from the experience. At the highest level, organisations have documented, tested, and continuously improved their response capabilities through regular exercises, real-world experience, and investment in both people and process.
Most small and medium-sized businesses sit somewhere in the middle. They recognise the need for incident response planning but have not yet formalised it. This template is designed to move your organisation from that middle ground toward genuine readiness. But a template alone is not sufficient. The document must be socialised across the organisation, tested through tabletop exercises at least annually, and updated whenever your technology environment, team structure, or regulatory obligations change.
The organisations that recover fastest from security incidents are not necessarily those with the largest budgets or the most sophisticated technology. They are the ones that practised. They ran through scenarios. They identified weaknesses in their plan before an attacker found weaknesses in their systems. They treated incident response as an organisational capability to be developed, not a document to be filed and forgotten.
Maximum time to notify the ICO of a personal data breach under UK GDPR
Average time to identify and contain a data breach globally (IBM, 2024)
of SMEs that suffer a major cyber attack cease trading within six months
Need help building your incident response capability?
We help UK businesses develop, document, and test incident response plans that work under real pressure. That includes defining your classification framework, building your contact lists and escalation procedures, running tabletop exercises with your team, and ensuring your plan meets regulatory requirements.
If you do not yet have a formal incident response plan, or if the one you have has never been tested, a readiness assessment will identify the gaps and give you a clear path to closing them.