What Should a Cyber Incident Response Plan Include for a UK SME?

A member of staff receives an unexpected call from someone claiming to be IT support. They allow remote access, then realise something is wrong. Who do they call, what should they stop doing, and who can decide whether an affected system is disconnected?

That is not a question to settle during the incident.

In our previous article, we looked at who owns cyber security when IT support is outsourced. Naming the business, provider and supplier responsibilities is essential. The next step is to turn those responsibilities into a sequence people can follow under pressure.

A cyber incident response plan does not need to be a 60-page manual. For a small or medium-sized UK organisation, it needs to be clear, accessible, rehearsed and connected to the way the business actually works.

Start with the events that trigger the plan

People need to know when an oddity becomes something to report. Examples include an unexpected login or MFA prompt, a lost device containing business data, suspected phishing that led to a password being entered, unexplained encryption or deletion of files, a supplier warning, or a message from someone claiming to be your helpdesk who asks for remote access.

The employee's job is to raise the alarm promptly through a known channel, not to decide whether the whole business has been breached. Give staff one memorable reporting route and a fallback that does not depend on corporate email or Teams being available.

The person receiving the report should record when it was discovered, what was observed, which people or systems may be affected and what has already been done. Keep facts and assumptions separate.

Name a decision-maker and an operational lead

An IT provider can investigate and contain a technical problem. It cannot, by itself, decide every commercial, legal and operational consequence for the client.

The plan should identify a business incident lead with authority to set priorities and approve consequential decisions, plus a technical lead at the provider or internal IT team. Name deputies, out-of-hours contact routes and an escalation point if the first call is unanswered.

Record who may authorise an account suspension, device isolation, service shutdown, emergency supplier spend, external communication and a switch to manual operations. Agree those boundaries with the provider before an incident. A contact list without decision rights is not a response plan.

Write down the first actions, without prescribing a universal switch-off

The initial sequence should be short enough to use under stress:

1. Report and acknowledge the concern using a trusted channel.
2. Protect people and preserve relevant information, including the time and nature of the first observation.
3. Bring the business and technical leads together; decide what is known, what is still uncertain and what help is needed.
4. Assess containment options with the technical lead, including the business effect of each option.
5. Establish a secure way to coordinate, document decisions and set the next update time.

Do not tell every employee to power off every device or delete suspicious messages. The right containment step depends on the incident, evidence preservation and what services the business needs to keep running. The NCSC's immediate-activities guidance, published as part of its 28 July 2026 guidance on disruptive attacks, calls for deliberate decisions about isolation and power-off, incident command, critical functions and specialist help. An SME plan should adapt those principles to its own scale.

Decide what the business must keep doing

Technical restoration order is not always business recovery order. Restoring a convenient server first may do little for a company that cannot fulfil orders, pay staff or answer customers.

Identify the few activities that must continue, their dependencies and acceptable interruption. Include people, applications, identity, connectivity, data, suppliers and manual workarounds. Then agree who decides which services return first and what minimum viable operations look like.

This is where backup and disaster recovery meet incident response. A successful backup job is not proof that data can be restored safely, quickly or in the right order. Know where clean copies are, who can access them and how a restore has been tested.

Include communications and reporting, not just technical recovery

Employees need a reliable place for instructions, particularly if email or Teams is affected. Someone should own updates to customers, suppliers, insurers and advisers, with a separate route for urgent approvals. A draft holding statement and contact list can save time, but communications should reflect verified facts rather than guesses.

Consider early whether personal data is involved and bring in the person responsible for data protection or legal advice. The ICO's small-organisation guidance explains that not every personal data breach must be reported, but a qualifying breach must be reported without undue delay and, where feasible, within 72 hours of becoming aware. Record the assessment and the reasoning even if a report is not required. Other contractual, sector, insurance or regulatory duties may also apply. If the incident is reported to the NCSC, that report does not replace any separate legal or regulatory duty.

Do not wait for a complete forensic picture before deciding who needs specialist advice. The plan should say how to reach your IT provider, insurer, legal adviser and, where appropriate, a qualified incident response specialist.

Make the provider boundary explicit

If your IT is outsourced, the response plan must line up with the service agreement. Ask your provider:

• What is monitored, and at what times?
• Who receives and triages a serious alert outside normal hours?
• Which containment steps can you take immediately, and which require our approval?
• Who preserves logs and other evidence?
• When would you bring in external incident response expertise?
• Who coordinates Microsoft 365, endpoint, backup and other suppliers?
• How will we communicate if our normal systems are unavailable?

These are service-delivery questions as much as security questions. A managed IT support contract, a cyber security service and an incident response retainer are not automatically the same thing. Confirm the scope rather than inferring it from a service name.

Rehearse the plan and improve it

Start with a 45-minute discussion: a suspicious helpdesk call has resulted in remote access to a finance user's laptop. Who notices, whom do they contact, what could they decide, and how would payroll continue if access were restricted? Introduce one complication, such as the incident lead being away or Teams being unavailable.

The purpose is not to catch people out. It is to find missing phone numbers, unclear authority, untested recovery steps and assumptions between suppliers. Record actions, owners and dates. Revisit the plan after organisational changes, a significant incident, or a test that exposes a weakness.

The NCSC's 28 July 2026 recovery guidance emphasises minimum viable operations and practising actual recovery. For an SME, even a modest tabletop exercise can turn an attractive document into a workable response.

A one-page starting checklist

Before you call the plan ready, check that it identifies:

• the signs people should report and two ways to report them;
• a business incident lead, technical lead, deputies and decision rights;
• a first-actions checklist and a secure decision log;
• essential services, dependencies, recovery priorities and tested backups;
• contacts for the provider, insurer, advisers and specialist responders;
• an alternative communications route and owners for external updates;
• who assesses reporting duties and documents the decision;
• the date of the next exercise and the person who will close its actions.

No plan removes every risk. A good one makes it less likely that uncertainty, missing contacts and untested assumptions will turn a contained event into prolonged business disruption.

FAQs

Does a small business need a cyber incident response plan?

Yes. The plan can be short and proportionate, but staff need a reporting route, decision-makers, provider contacts, a way to coordinate if normal systems fail, and recovery priorities before an incident occurs.

Is our managed IT provider's plan enough?

Usually not on its own. The provider should have a technical response process, but the business must still decide operational priorities, approve certain actions, manage communications and assess its obligations. Align the two plans and check the contract.

What is the first thing to do after a suspected cyber incident?

Report it promptly through the agreed trusted channel, record what is known and bring the designated leads together. The precise containment action should be decided with qualified technical advice, not assumed to be the same for every incident.

How often should we test the plan?

Set a regular review and exercise cycle proportionate to your risk, and retest when key people, systems, suppliers or business processes change. A short tabletop exercise is a useful first step; test restoration separately where recovery depends on backups.

Does every cyber incident need to be reported to the ICO?

No. Assess whether personal data was breached and the likely risk to individuals. Record the decision; report qualifying breaches in line with the ICO's guidance, including its 72-hour timeframe where applicable. Seek appropriate advice for other reporting obligations.