A suspicious sign-in alert at 8.15am, a member of staff unable to open shared files, or an email sent from a director’s account without their knowledge can quickly stop being an IT issue. It can interrupt sales, payroll, customer service and day-to-day confidence. This guide to incident response planning explains how small and mid-sized businesses can prepare for those moments, so people know what to do before pressure takes over.

An incident response plan is not a folder full of technical procedures that nobody reads. It is a practical business plan for containing a cyber security or technology incident, making informed decisions and returning to normal safely. The best plans are clear enough for an office manager to use, detailed enough for technical support to act on, and tested often enough that they work when needed.

What counts as an IT incident?

An incident is any event that could compromise the confidentiality, integrity or availability of your systems and data. That includes a successful phishing attack, ransomware, a lost laptop, an unauthorised user account, a supplier portal breach, or a cloud system that has been configured incorrectly.

Not every technical fault is a security incident. A failed internet connection may simply be an outage, while a printer problem is usually an operational support request. However, the line is not always clear. If staff cannot access files because they have been encrypted, or a connectivity failure coincides with unusual account activity, treat it seriously until the facts say otherwise.

For a small business, the impact matters as much as the technical label. A brief issue affecting a receptionist may be manageable. The same issue affecting a garage’s diagnostic platform, a charity’s donor database or an accounts team on payday may need an immediate, coordinated response.

Why incident response planning protects the business

The first few hours of an incident shape its cost. Without a plan, staff may reset passwords too broadly, restart affected machines before evidence is captured, or delay reporting because they are unsure whether an alert is genuine. Each reaction is understandable. Each can make investigation and recovery harder.

A workable plan reduces uncertainty. It sets out who has authority to make decisions, how to contact the right people, what systems take priority, and when customers, insurers or regulators may need to be informed. It also gives employees permission to report concerns quickly without worrying that they are causing a fuss.

There is a balance to strike. A 10-person business does not need the same incident command structure as a national organisation. Equally, a one-page document saying “call IT” is not enough. Your plan should reflect the systems you rely on, the information you hold and the people who must keep operating during disruption.

The essential parts of an incident response plan

Define roles before an incident happens

Name an incident lead and a deputy who can make business decisions if the lead is unavailable. This person does not need to be your most technical employee. Their job is to coordinate people, approve key actions and keep the business focused on priorities.

Your plan should also identify who contacts your IT support provider, who communicates with staff, and who handles external communication. Include out-of-hours numbers, not just email addresses stored in an inaccessible mailbox. If you use a managed IT partner, agree in advance how incidents are raised and which actions they can take immediately to protect your environment.

For some incidents, you may also need your cyber insurance provider, legal adviser, data protection lead, bank or specialist forensic support. Record those details in a secure place that can be accessed without relying on the affected network.

Identify the systems and data that matter most

Recovery decisions become much easier when you have already agreed your priorities. Start with the services your business cannot operate without: email, phones, line-of-business software, customer records, finance systems, file storage, internet access and backups.

For each one, document the owner, where it is hosted, who supports it and what a realistic recovery target looks like. A business may be able to work around a file-sharing problem for a day, but not a telephone outage or loss of access to its booking system. The right order depends on your operations.

Also record where sensitive data lives. Personal data, payment information, employee records and commercially confidential files may trigger additional reporting and communication requirements if exposed. You do not need to turn the plan into a legal manual, but you do need to know when to involve the right advisers.

Create simple actions for the first hour

The first-hour checklist should be short and unambiguous. Staff need to know that they should report suspicious activity promptly, preserve relevant information and avoid trying to fix an issue themselves unless directed.

In many cases, the first technical action is to isolate an affected device from the network without turning it off. This can limit further spread while preserving useful evidence. But there are exceptions, particularly where safety, active fraud or critical operational systems are involved. Your IT team should guide the containment decision based on the situation.

Make it clear what information to capture: the time the issue was noticed, the user involved, screenshots, suspicious email details, affected devices and any recent changes. A simple timeline is often more useful than pages of assumptions.

Set communication rules

Silence creates rumours, especially when email or shared systems are unavailable. Decide how you will communicate internally if normal channels fail, such as through a pre-agreed messaging group, SMS or personal phone calls. Keep messages factual: what is known, what staff should do now and when the next update will be given.

External communication requires more care. Do not make promises about the cause, scale or duration of an incident before it has been investigated. If personal data may have been compromised, seek advice promptly on your obligations under UK data protection law. If a supplier platform is involved, coordinate with that supplier rather than issuing conflicting information.

A practical response process

Most incidents follow the same broad sequence: identify, contain, investigate, recover and learn. The steps can overlap, and the pace depends on the severity of the incident.

Identify and assess. Confirm what has happened as far as possible. Is it one account, one device, a cloud service or the wider network? Assess the potential effect on business operations, data and customers. At this stage, it is better to state what is unknown than to assume the problem is contained.

Contain. Prevent further damage. This may mean disabling accounts, blocking a malicious sign-in, isolating devices, restricting remote access or pausing a risky system integration. Containment can affect productivity, so it should be proportionate, but speed usually matters when there is evidence of an active compromise.

Investigate and remove the cause. Your technical team should establish how access was gained, what systems were affected and whether any data was accessed or removed. Removing malware alone is not enough if the original weak point remains, such as a compromised password, missing update or poorly configured access rule.

Recover carefully. Restore systems from clean backups or rebuild them where necessary. Before bringing services back online, check that security controls are working, passwords have been reset where required and the original route of attack has been closed. Rushing recovery can reintroduce the problem.

Review and improve. Once the immediate pressure has passed, hold a short, blame-free review. What worked? Where did communication slow down? Did the backup restore as expected? Turn the answers into actions with owners and dates, rather than letting lessons disappear into meeting notes.

Test the plan when the business is calm

A plan that has never been tested is an assumption. You do not need to simulate a major cyber attack every quarter. Start with a 30-minute tabletop exercise: describe a realistic scenario, ask each person what they would do, and note where the process becomes unclear.

Good scenarios include a finance user entering credentials into a phishing site, a stolen laptop containing access to business systems, or files becoming unavailable after a suspected ransomware attack. For businesses in Sussex that rely on a small number of key staff, test what happens if the usual decision-maker is on holiday or unreachable.

Technical testing matters too. Check that backups can be restored, emergency contacts are current, multi-factor authentication is in place for important accounts and monitoring alerts reach someone who can act. Testing may reveal inconvenient gaps, but finding them during a planned exercise is far better than finding them during an outage.

Keep the plan useful, not perfect

Review your incident response plan after significant changes, such as moving to a new cloud platform, opening another site, changing IT support arrangements or adopting new business software. At a minimum, revisit it annually and after every real incident.

Store the plan securely, with an offline or independently accessible copy. If it lives only on the file server that becomes unavailable, it will not help when it is needed most. Keep the language plain, assign clear ownership and make sure new managers know it exists.

Technology incidents are stressful, but they do not have to become chaotic. A clear plan gives your people a calm starting point, protects the decisions that matter most and helps your business get back to serving customers with confidence.