Incident response plan for UK SMEs

An incident response plan lets an SME agree responsibilities and initial actions before an incident occurs.

A compromised account, ransomware infection or accidental disclosure can require different actions. Agree the escalation route and authority to limit harm before staff have to make those decisions under pressure.

An incident response plan can help businesses of any size coordinate their response. This guide shows you how to build one that is proportionate to your size and actually usable when you need it.

What is an incident response plan?

An incident response plan is a documented set of instructions that tells your team how to detect, respond to, and recover from an IT security incident. It covers who does what, when, in what order, and who needs to be told.

Without one, incident response tends to be ad hoc: whoever is around when something happens makes it up as they go. That approach works for minor incidents. For a serious incident, such as ransomware, a data breach or a compromised account with customer data access, it can produce delays, missed notifications, and preventable damage.

The goal of an incident response plan is to replace panic with process. Not to anticipate every possible scenario, but to ensure your team knows how to act quickly and correctly even when the situation is unclear.

What smaller teams need to prepare

An SME may rely on one IT lead or an external provider. The plan should name deputies, explain who can isolate systems and identify where specialist help comes from. A small team still needs a clear way to assess personal data breaches and meet applicable reporting duties.

The six phases of incident response

The six workstreams below organise the plan. They overlap during an incident: containment and notification assessment must not wait for a complete investigation. Even a quickly contained incident needs an appropriate record and review.

1. Preparation

Preparation establishes the contacts, authority and recovery options responders will need. Test those arrangements before relying on them during an incident.

Preparation includes:

Documented response procedures. Use a concise runbook that answers: who is the first point of contact, what are the escalation criteria, who has authority to take systems offline, who notifies the ICO if needed, and who contacts external legal counsel.

Contact list. A current list of everyone who needs to be reached in an incident, including internal IT leads, external IT support, legal counsel, insurance broker, ICO (for UK GDPR breaches), and your cyber insurance provider's incident response line.

Backup verification. Test usable recovery copies and their logical separation from production administration. Check whether a compromised production identity could delete or overwrite every copy, and protect a recovery route against that failure.

Legal counsel on retainer. Finding a solicitor who specialises in cyber incidents at 2am during an active breach is not the time to discover they are unavailable. Establish the relationship before you need it.

The NCSC describes Cyber Incident Response as a commercial scheme. Certified providers can offer help, but availability, eligibility, scope and fees depend on the service. Confirm terms beforehand rather than assuming a free response.

2. Identification

The first sign of an incident is not always obvious. It might be a user reporting they cannot log in. A finance team member flagging a suspicious invoice. An antivirus alert. An unexpected file being modified at 3am.

Identification is about recognising that something abnormal is happening and treating it as a potential incident until you know otherwise.

Key indicators that warrant investigation:

• Unexpected system behaviour or performance degradation
• Unauthorised access attempts or successful logins from unusual locations
• Unusual outbound network traffic
• Files modified or deleted without a known cause
• Users locked out of accounts they did not change
• Ransom notes or encryption warnings on any system

When something looks wrong, the instinct is to try to explain it away. Train your team to err on the side of escalation. The cost of investigating a false alarm is low. The cost of missing a real incident is not.

3. Containment

When there is credible evidence of active harm, authorised responders should contain affected systems while investigating. Do not wait for full confirmation of every detail. Consider safety and critical-service dependencies when choosing the action.

Short-term containment actions:

• Isolate affected systems from the network under the response plan. Avoid unnecessary shutdowns because they lose volatile evidence; if disconnection is impossible, shutdown may be needed to stop spread
• Revoke compromised credentials immediately
• Block identified malicious network destinations at the appropriate network control and restrict affected accounts through identity controls
• Preserve relevant logs and system evidence with trained help, without delaying necessary containment

Longer-term containment:

• Apply patches or configuration changes to prevent re-entry via the same vector
• Reset affected credentials and revoke relevant sessions/tokens from a trusted environment; coordinate service-account dependencies
• Notify neighbouring systems that may share the same exposure

The goal of containment is to stop the incident from spreading while you assess the full scope. Do not try to fully resolve the incident during containment. Prioritise limiting further harm.

4. Eradication

With the incident contained, you can work on removing the threat from your systems.

Eradication means eliminating the root cause by removing malware, closing the vulnerability that allowed access, closing compromised accounts, and ensuring the attacker can no longer re-enter through the same path.

For ransomware, this often means rebuilding affected systems from known good backups rather than attempting to clean infected machines. For data breaches, it means identifying and closing the access vector and ensuring no additional data is at risk.

Eradication is complete when you are confident the attacker no longer has access. This can take hours or weeks depending on the complexity of the incident.

5. Recovery

Recovery is the process of restoring normal operations. This is where a tested backup policy pays off. Clean, tested backups help, but recovery time also depends on compromise scope, dependencies, data validation and the ability to rebuild safely.

Recovery priorities:

• Restore systems according to business criticality and their technical dependencies, using an isolated clean recovery environment
• Verify restored systems are clean and not re-infected
• Monitor closely during the restoration period. Attackers sometimes leave dormant access for re-entry
• Restore data integrity by confirming that recovered data is complete and uncorrupted
• Resume normal operations gradually, not all at once

Assess UK GDPR reporting from the start of the response. Do not postpone that assessment until recovery. The technical recovery milestone and legal notification duties run on separate schedules.

6. Lessons learned

The final phase is the review. What happened? How did the response perform? What would you do differently?

Lessons learned is where your incident response capability improves. Without a structured review, the same gaps that allowed the incident to occur or slowed your response will persist.

Arrange a prompt lessons-learned session with the relevant responders; choose timing from the incident and evidence available rather than a universal two-week rule. Focus on what worked, what did not, and what needs to change in your documented procedures or technical controls.

Even if the incident was minor, treat the lessons learned seriously. Near-misses are learning opportunities.

Building your plan: what to include

A useful incident response plan for an SME does not need to be long. A concise document of five to ten pages covering the essentials is better than a complex plan that no one reads.

Include at minimum:

Incident classification. Define what constitutes a critical, major, and minor incident. This determines who is activated and how urgently.

Escalation criteria. Who is the first point of contact? When does the incident get escalated to senior leadership? When does legal counsel get involved? When is the ICO notified?

Contact list. Current, tested contacts for IT leads, external support, legal counsel, insurance, and the contracted incident response provider.

Response procedures by incident type. Ransomware, data breach, compromised account, DDoS each has different immediate actions.

ICO notification checklist. If personal data is involved, the 72-hour UK GDPR clock starts when you become aware of the breach. The checklist should include what to capture for the notification (nature of breach, categories and approximate number of data subjects, likely consequences, measures taken or proposed).

Evidence preservation guidance. What to do (and not do) with affected systems before forensics begin.

Assess notifications while containing the incident

For a UK GDPR personal data breach, the controller must notify the ICO unless the breach is unlikely to result in a risk to people's rights and freedoms. Notify without undue delay and, where feasible, within 72 hours of awareness. A late notification needs reasons for the delay. If the breach is likely to create a high risk, inform affected individuals without undue delay, subject to the applicable exceptions. A processor must notify its controller without undue delay.

The ICO's breach guide permits information in phases when full details are unavailable. An initial report does not pause a clock or remove the duty to provide further information without undue further delay. Record all personal data breaches, including the reasoning for a decision not to notify. Assess awareness and risk promptly; do not wait for recovery or a complete forensic report.

Assign one person to record obligations, awareness times, owners and deadlines. Sector rules, overseas operations and contracts may add separate duties. Use qualified advice for the organisation's circumstances.

Common SME mistakes

No usable plan. Without agreed roles and procedures, responders must improvise important decisions during the incident.

Plan is not tested. A plan that has never been walked through does not establish that the procedures work. Set a risk-based exercise schedule and review it after material changes or incidents. Use realistic scenarios, not theoretical ones.

Not keeping contact lists current. A missing out-of-hours contact can delay escalation. Test the route and its deputy.

Assuming backups will work. Test restoration at a frequency appropriate to the service and after material changes. A backup that has never been restored has not demonstrated that recovery will work.

Delaying notification while waiting for complete evidence. Record awareness, assess the risk promptly and provide the information available within the applicable reporting requirement. Add details without undue further delay. Connect the response plan to your IT governance framework so the reporting owner and deputy are clear.

Unclear insurance or support arrangements. Decide how response will be funded and supported. If insured, check limits, exclusions and approval requirements with the broker. Do not assume fines are insurable or covered; obtain appropriate advice on what is lawful and actually insured.

When to bring in help

Establish a response provider and legal contact before an incident. Confirm coverage hours, response commitments and fees. If you have cyber insurance, read the notification and approved-provider conditions and contact the insurer promptly alongside containment. Do not delay urgent protective action merely to wait for insurer dispatch, and do not assume there will be no excess or additional cost.

CISA's technical response checklist supports immediate isolation and recovery based on critical services and dependencies. Its US reporting contacts are not a substitute for the appropriate UK reporting routes. ICO guidance identifies UK options, including NCSC and the relevant fraud or police route.

A completed exercise example

In a hypothetical tabletop, an employee reports an unexpected MFA reset followed by customer-data access. The incident lead assigns identity containment immediately, asks the technical lead to preserve logs and appoints the privacy lead to assess whether personal data was compromised and when awareness arose. The team cannot reach its usual supplier, so the named deputy uses the alternate contract contact. The exercise reveals that nobody owned session revocation. Assign an owner, test the corrected procedure in a safe environment and repeat that part of the exercise.

This example tests a decision and a fallback. It does not require sending a real notification or changing a production account.

Prepare your response plan

My IT compliance support and IT management services can help define responsibilities, evidence requirements and recovery exercises.

Book a consultation with your current plan, supplier support terms and recent exercise findings. We can identify the gaps that would prevent your team from acting and agree a proportionate test plan.