A small-business cyber incident response plan: who does what?
Your team cannot open the shared order list. Someone thinks it is a cyber attack; someone else thinks the internet is down. The owner is in a meeting, and nobody knows who should call IT or update customers.
A small-business cyber incident response plan should settle those responsibilities before you need them. Start with a short coordination summary: who makes decisions, who provides technical advice, who keeps essential work moving, and who records and communicates what is known.
An outage alone does not confirm a cyber incident. The plan needs to work while the cause is still being investigated. If something is happening now, use your agreed IT support or incident-reporting route promptly. Do not wait to finish a planning exercise or book a discovery call.
Assign responsibilities, with cover for each one
You do not need five extra people. In a small team, one person may hold several functions. What matters is that each responsibility has an agreed owner, a deputy and enough authority to act.
Decisions: The owner or delegated manager agrees business priorities and approves consequential actions, taking technical advice into account. Record what the deputy can approve when the owner is unavailable.
Technical response: Your agreed IT contact assesses the issue and advises on containment, investigation and safe recovery. Check their scope, availability and out-of-hours arrangements in advance; a support agreement does not automatically cover every incident service.
Business operations: A manager identifies which activities must continue, which can wait and which approved fallback arrangements are usable.
Communications and the record: A named person keeps a factual timeline and coordinates updates. Separate confirmed information from assumptions, record decisions and arrange the next update.
Specialist advice: Identify who will obtain insurer, legal or data-protection advice where needed. Reporting obligations depend on the circumstances; this summary is not a compliance assessment.
The NCSC's guidance on preparing your people covers delegated authority, alternative communications and records. Use it to check the gaps in your own arrangements.
Make your cyber incident response plan usable
Keep the detailed technical procedures with the people qualified to use them. Your short summary should help a colleague find the right person and understand who can decide what. It is not a complete incident response plan.
Copy these fields into a document and complete them together:
Plan owner and last checked: Name, deputy and review date.
First reporting route: Trusted IT or incident contact, alternative contact method, agreed hours and escalation route.
Decision authority: Primary decision-maker, deputy and the decisions each may approve.
Essential work: The business process that matters most, its dependencies and any approved fallback.
Communications: Who approves staff or customer updates, and the alternative channel to use if normal email is unavailable or untrusted.
Specialist contacts: Insurer and relevant advisers, with instructions for finding any required policy or agreement information securely.
Incident record: Time reported, observed facts, unknowns, advice received, decisions, action owners and next review time.
Keep a protected copy accessible if your usual systems are unavailable. Restrict access appropriately, keep contacts current and do not put passwords or recovery secrets in a shared planning sheet.
The NCSC's small-business preparation guide starts with the systems, information and processes your organisation depends on. That is a useful starting point for the “essential work” field.
Worked example: the shared order list is unavailable
This is a fictional rehearsal for a small office, not a customer story or a diagnosis of an attack.
The starting information: At 09:10, two staff members report that they cannot open the order list. The cause is unknown. The owner is away, but the office manager is the agreed deputy. Today's deliveries depend on knowing which orders have been confirmed.
The actions: The office manager records those observations and calls the existing IT contact using the trusted number in the plan. The technical contact investigates and advises on safe next steps. The manager checks whether the pre-agreed fallback for delivery coordination is suitable; nobody moves customer records to an unapproved personal account to get around the problem.
The communication: The named communications owner gives staff a factual update: the list is unavailable, IT is investigating, and the manager is coordinating priorities. They do not call it a data breach or promise a restoration time without evidence. Any customer message goes through the agreed approval route.
The working record: “09:10: order list unavailable; cause unconfirmed. Office manager owns the business decision. IT contact owns technical assessment. Communications owner will provide the next update at 10:00, or sooner if verified information changes.” The time is an example of an agreed update, not a recovery commitment.
The human review: The manager reviews the advice and the business impact. They authorise only an appropriate, approved fallback. Technical recovery and a return to normal working wait for the relevant technical clearance and business decision.
The useful output is a shared record of facts, responsibilities and decisions. It gives the team a way to coordinate without guessing who is in charge or presenting assumptions as facts.
Rehearse the hand-offs before an incident
Try the example above as a short discussion with the people named in your summary. Ask someone other than the plan's author to find the contact details and explain the first reporting route.
Then change one condition: the owner cannot be reached, email is unavailable, or the usual IT contact is outside their agreed hours. Can the team still identify the deputy, find a trusted alternative route and agree who will give the next update?
Write down each gap, its owner and the action needed to close it. A discussion rehearsal checks coordination; it does not prove that backups restore or systems can be recovered. Those need separate technical testing. Our guide to testing recovery of the files your business needs covers that separate question.
The NCSC's business-continuity preparation guidance distinguishes discussion exercises from testing technical recovery. Keep both in view rather than treating one meeting as proof that everything works.
Keep the plan connected to your support arrangements
Revisit the summary when people, suppliers, systems or responsibilities change, and after a rehearsal or real incident. Confirm that your provider understands the reporting route and that your team understands the agreed scope of support.
For ongoing preparation, explore our managed cyber security for small businesses and discuss how your existing security and support arrangements fit the way your business needs to work.
A discovery call is for that planning conversation. If you are dealing with a suspected incident now, use your existing agreed support or incident-reporting route instead.
Comments