A staff member clicks a convincing invoice attachment at 9.12am. By 9.20am, shared files are unavailable, customers are ringing for updates, and someone needs to decide whether to switch off systems. Knowing how to create a cyber incident plan means those decisions are not made from memory, guesswork or a hurried group chat.
For a small business, an incident plan is not a large technical document written for the sake of compliance. It is a practical set of instructions that helps people contain a problem, communicate clearly and return to normal operations with the least possible disruption. It should work whether the issue is ransomware, a stolen laptop, a compromised Microsoft 365 account, a supplier breach or a system outage with suspicious signs.
Start with the business impact, not technical jargon
A useful plan begins by identifying what your business cannot afford to lose. For a garage, that may be access to diagnostic equipment, booking systems and customer records. For a charity, it may be donor data, email access and the ability to process donations. For an office-based company, payroll, shared documents, mobile phones and cloud applications may be the priority.
Write down your critical systems, the information they hold and the consequence of losing each one for an hour, a day or a week. This gives you a sensible order for recovery. There is little value in restoring a rarely used application first while your team cannot access email, take card payments or speak to customers.
Be realistic about dependencies too. A cloud application may be available, but staff still cannot use it if their internet connection, identity system or multi-factor authentication is affected. Your plan needs to reflect how work is actually done, not how the technology diagram says it should work.
How to create a cyber incident plan with clear ownership
During an incident, uncertainty over who can make decisions causes avoidable delay. Assign named roles, then nominate a deputy for each. In a smaller business, one person may hold more than one role, but the responsibilities should still be clear.
Your plan should identify who can authorise urgent IT changes, who speaks to staff, who contacts customers or suppliers, and who engages your cyber insurer, legal adviser or external IT support. It should also state who has authority to approve downtime, replacement equipment or specialist investigation costs.
Keep the contact details outside the systems they rely on. If email is unavailable, a contact list stored only in a shared mailbox is no use. Maintain a printed copy in a secure location, along with a protected offline version that authorised people can access from a personal device if necessary.
For most businesses, the core incident contacts include:
- The business owner or senior decision-maker
- The internal IT lead or managed IT provider
- A deputy decision-maker
- Your cyber insurance incident helpline
- Key software, telecoms and internet suppliers
- Legal, data protection and communications contacts where required
Avoid giving everyone permission to investigate. Well-meaning staff can overwrite evidence, spread an infection further or send an inaccurate update. The plan should make it clear that staff report concerns quickly, while a small response group coordinates the action.
Define what counts as an incident
Not every technical issue is a cyber incident. A failed router may be an operational fault, while an unexpected password reset request could be the first sign of account compromise. Set simple triggers so people know when to escalate.
Examples include unusual sign-in alerts, unexpected multi-factor authentication prompts, files that suddenly become encrypted, suspicious payments, data sent to the wrong recipient, lost devices, or a supplier notifying you of a breach. If there is any doubt, treat it as a potential incident until it has been checked.
Create severity levels that match your organisation. A single suspicious email reported before it is opened may need monitoring. A compromised director’s account, a ransomware alert or possible exposure of personal data needs an immediate, coordinated response. The aim is not to create bureaucracy. It is to ensure the right people are involved early enough.
Write the first-hour actions in plain English
The most valuable part of a cyber incident plan is often the first-hour checklist. This should be short enough to use under pressure and specific enough to prevent harmful delays.
For a suspected compromise, the initial actions usually involve isolating affected devices or accounts, preserving evidence, recording what has happened and contacting the responsible support team. Isolation may mean disconnecting a computer from Wi-Fi and the network, not simply turning it off. Switching a device off can sometimes remove useful evidence, so staff should follow the agreed instruction rather than improvise.
Your plan should also say what not to do. Do not pay a ransom, notify customers, delete files, reset every password or contact the attacker without advice from the people managing the response. These steps may eventually be necessary, but the order matters. A rushed action can make containment, recovery or insurance support more difficult.
A short incident log is equally useful. Record the time the issue was discovered, who reported it, systems affected, actions taken and decisions made. This is essential when several people are involved, and it helps later if you need to demonstrate what happened to insurers, regulators or customers.
Build playbooks for likely scenarios
You do not need a separate manual for every possible threat. Start with the incidents most likely to affect a small business: phishing or account takeover, ransomware, lost or stolen equipment, payment fraud, data sent to the wrong person, and a critical supplier breach.
Each playbook should answer the same practical questions. How is the incident reported? Who investigates? What should be isolated? What evidence should be kept? Who needs to be told? What conditions must be met before normal service resumes?
For example, a suspected Microsoft 365 account takeover may require the account to be disabled, active sessions revoked, sign-in activity reviewed, mailbox forwarding rules checked and the password reset from a known-clean device. A lost mobile phone may require the device to be remotely locked or wiped, access tokens revoked and a check of what data was available on it. The actions differ, but the decision process remains familiar.
Plan communications before you need them
Silence can damage trust, but an inaccurate message can do the same. Prepare simple templates for staff, customers and suppliers that can be adapted once the facts are known. They should explain what is affected, what people need to do and when they can expect another update. Avoid speculation about the cause or scale of an incident before it is confirmed.
If personal data may have been exposed, you may need specialist advice on data protection obligations and notification timeframes. The Information Commissioner’s Office expects organisations to assess breaches promptly, and some serious cases must be reported within 72 hours of becoming aware of them. Your plan should therefore include a route to get timely legal or data protection guidance, rather than assuming the decision can wait until the next working day.
Make backups part of the response plan
Backups are only useful if they are protected from the same incident and can be restored within the time your business can tolerate. Check whether backups are isolated from your everyday network, how long restoration will take and whether key applications can be brought back in the right order.
Test restores regularly. A successful backup report does not prove that your team can restore a database, access the recovered data or continue trading. It also does not guarantee the backup is free from ransomware or corruption. Your incident plan should state who approves restoration and how you confirm systems are safe before reconnecting them.
There is a trade-off here. Restoring quickly is vital, but restoring an infected system too soon can restart the problem. Where a serious compromise is suspected, contain and investigate first, then recover from a known-clean point.
Test the plan with a realistic exercise
A plan that has never been tested is an assumption. Run a short tabletop exercise at least once a year and after major changes to your systems, suppliers or staff. Use a believable scenario, such as a finance employee receiving an urgent bank detail change request or a member of staff being unable to open shared files after clicking an attachment.
Talk through the first hour. Can staff find the plan? Can they contact the right people out of hours? Does anyone know how to isolate a device? Are supplier numbers current? Where are the recovery credentials held? The exercise should expose gaps without blaming individuals.
Afterwards, update the plan and assign owners to outstanding actions. If your business uses a managed provider, involve them in the exercise. At My Tech Team, we see the strongest results when business leaders, staff and technical support agree the process together before an incident tests it for real.
Keep it current and easy to use
Review your cyber incident plan after any genuine incident, near miss, major software change, office move or change in key personnel. Remove former staff from the contact list, update suppliers, and check that new services are included in your critical systems list.
Store the full plan securely, but make the first-page actions easy to reach. Under pressure, your team should be able to answer three questions quickly: what has happened, who is leading the response, and what should we do next. That clarity will not prevent every cyber incident, but it can turn a confusing morning into a controlled recovery.
