Building a basic incident response plan for a growing team

Why this matters to you

Your 2-minute quick win

Open your shared contacts list or team wiki now. Add one entry called 'Cyber incident call list'. Put in the name, mobile number, and backup contact for your IT lead, senior decision maker, legal contact, and main IT supplier. You have done it right when another team member can find that list fast, even if your normal chat tool is down.

A growing team moves fast. New systems appear, suppliers change, and key knowledge often sits with one person. That is fine until a cyber incident starts on a busy day.

The first hour matters because confusion spreads damage. If nobody knows who can take a website offline, restore a backup, or call a cloud provider, the team loses time that it cannot get back.

The UK National Cyber Security Centre says incidents can hit cost, productivity, and reputation. It also says a practised plan helps people make good decisions under pressure and lowers the impact when an incident happens.

An incident response plan is not a huge policy file. For a growing business, it is a short set of roles, contacts, trigger points, and first actions that people can follow when they are stressed.

The aim is not to predict every attack. The NCSC says that would be impractical. Instead, prepare for the common threats and build a response that works when systems, email, or normal communications are disrupted.

What you are protecting

Start with the information that keeps the business moving. The NCSC gives simple examples: contact details, emails, calendars, and essential documents. If staff cannot reach those, work slows at once.

Then list the systems and processes that matter most. That may be the website where customers place orders, the cloud service where staff store files, or computer-controlled equipment used in operations.

You also need to know where each item lives. The NCSC suggests asking whether it sits on a single office machine, a remote server, or a cloud service run by a third party. That one detail changes who you call first.

Backups belong in this section too. A plan is weak if nobody knows what data is backed up, how often it is copied, or who knows how to restore it.

Your reputation is another asset. The NCSC advises thinking in advance about key partners you would need to contact after different incident types. Good relationships make those calls smoother when pressure is high.

Finally, protect decision paths. A small team often depends on one founder, one office manager, or one technical lead. If that person is away, you need a deputy with shared responsibility and current documents to cover the gap.

What it costs you if you skip this

Without a plan, the first problem is delay. Staff spot something odd, but alerts do not reach the right people for assessment and triage. The technical team waits while managers work out who owns the next move.

The second problem is poor containment. The NCSC warns against over-reacting during containment. If you shut down the wrong system too early, you may cause more damage than the incident itself.

You can also lose evidence. If nobody records decisions, actions taken, or data that was missing, the team has little to learn from later. That also makes regulatory questions harder to answer.

Communication suffers too. Customers, suppliers, and staff hear mixed messages when there is no agreed owner for updates. That confusion can harm trust long after the technical issue is fixed.

Backup problems often appear at the worst time. Teams assume data can be restored, then discover nobody has tested the process. The NCSC specifically says to practise restoring files from backups and to copy back only clean data onto clean systems and networks after an incident.

There is also a hidden cost in management time. A short plan built now can save hours of debate later about contracts, insurer details, legal duties, and who is allowed to authorise disruptive actions.

Step by step

1. Create a one-page incident plan file. Open your shared document space and create a page called 'Incident response plan'. Put the date at the top and add headings for roles, contacts, trigger points, critical systems, backups, suppliers, communications, and legal or regulatory notes. Done correctly, any manager can open one page and see the first-hour plan without hunting through folders.
2. List your critical information and systems in plain words. Under 'Critical systems', write the exact service or asset name and why it matters, such as customer order website, shared email, payroll files, or manufacturing controller. Add where each one is stored or accessed: office machine, remote server, or cloud service. Done correctly, a reader can tell what would stop the business fastest.
3. Add backup details next to each critical item. Write whether the item is backed up daily or weekly, where the backup is kept, and the name of the person who knows how to restore it. Done correctly, the plan shows not just that backups exist, but who can use them.
4. Name primary and deputy owners for each role. Create a small table with incident lead, senior decision maker, technical lead, legal contact, HR contact, PR or customer communications contact, and supplier contact owner. The NCSC says roles and responsibilities should be defined and understood, and deputies should be identified if the primary contact is not available. Done correctly, every role has two names and two phone numbers.
5. Write the authorisation line for disruptive actions. In a section called 'Who can approve what', list actions such as taking the website offline, isolating a device, pausing a cloud account, or sending a customer notice. Add the name of the person who can approve each action and the backup approver. Done correctly, the technical team knows exactly who can say yes.
6. Set clear trigger points for escalation. Under 'Trigger points', write short if-then rules such as: if customer ordering stops, call the senior decision maker; if personal data may be involved, alert legal; if the main website is suspected to be compromised, contact the web hosting provider. The NCSC says your plan should identify when ownership of an action or decision transfers between people. Done correctly, handoffs are visible and simple.
7. Build an external contact list you can use when normal tools fail. Add your web hosting provider, IT support service, cloud service provider, cyber insurer if you have one, and any trade association help line if relevant. Include what each contract covers and when to engage them. Done correctly, the list includes mobile numbers, contract references, and a place outside normal email, such as a printed copy or offline file.
8. Link the plan to wider business plans. Add a short note that says where your disaster recovery, business continuity, and crisis management documents live. The NCSC says the incident response plan should be linked to those plans because serious incidents can cause major disruption. Done correctly, a reader can move from first-hour actions to wider recovery actions without guessing.
9. Define how incidents are detected and routed. In a section called 'How we hear about incidents', list staff reporting, supplier reporting, logging and monitoring alerts, and reports from partners or third parties. The NCSC says all alerts should be sent to the team responsible for assessment and triage. Done correctly, staff know one inbox, one phone number, or one named team for reporting.
10. Add a simple incident log template. At the bottom of the page, place fields for time, who reported the issue, systems affected, actions taken, decisions made, missing data, and next update time. The NCSC says careful records are useful for post-incident reviews and if you need to show evidence to a regulatory body. Done correctly, someone can start logging within minutes.
11. Record your legal and regulatory notes in brief. Add a section headed 'Reporting duties' with the types of data you hold and a short reminder to check the legal or regulatory requirements that apply to your organisation. The NCSC says the plan should include basic guidance on legal or regulatory reporting requirements. Done correctly, the team knows where to look before sending statements or filing reports.
12. Test one recovery action and one decision path. Ask the backup owner to show the steps to restore a non-critical file from backup. Then run a short team exercise: an employee spots a website issue, who checks it, who approves shutdown, and who calls the host. The NCSC points to 'Exercise in a Box' as a free way to practise response plans. Done correctly, the team completes the scenario and updates the plan the same day.

Illustrative example

Maya runs operations for a growing online parts seller with thirty staff. The company has a customer order website, shared email, a cloud file service, and one external IT support provider. It has backups, but until now the response plan lived in people's heads.

On Monday morning, a sales colleague reports that the website home page looks wrong and some orders fail. Maya opens the new incident response plan in the team wiki. At the top, she sees the incident lead, the senior decision maker, and the web hosting provider contact with mobile numbers.

She starts the incident log and records the time, the report, and the systems affected. The plan tells her that if customer ordering stops, she must call the senior decision maker. She does that first, rather than debating in the team chat.

The technical lead checks the site while Maya calls the web hosting provider listed in the external contacts section. Because the contract note is in the plan, she can explain what support is covered and ask for urgent help without searching old emails.

The issue appears to affect only the website, not shared email or internal files. The plan says the senior decision maker can approve taking the website offline. Maya gets that approval, and the host places a maintenance page while the technical team investigates.

At the same time, Maya alerts the customer communications contact. That person drafts a short message for customers and partners, because the plan says clear communication helps reduce short-term impact and build trust over time.

The team then checks backups. The backup owner confirms when the latest website data copy was made and walks through the restore process for a test file. That check matters because the NCSC says teams should practise restoring files and ensure only clean data is copied back to clean systems and networks after an incident.

By early afternoon, the host and technical lead confirm the problem is limited to the website service. The company restores clean content, brings the site back, and keeps logging every action and decision. In the post-incident review, Maya notes one weak point: the deputy contact for PR had changed roles and the phone number was old. The plan is updated the same day.

The near-miss

Now replay the same morning with one key check missing. Maya has no written trigger point for who can approve taking the website offline. The technical lead sees strange changes on the site, but waits for the founder, who is on a train and not answering.

During that delay, staff argue in chat about whether the host should be called first or whether orders should keep running. Nobody starts a proper incident log. The customer team hears rumours before it gets facts.

When the founder finally replies, the company takes the site offline anyway. The lost time does not prove the incident was worse, but it does create extra confusion, more customer complaints, and weaker records for the later review. One missing authorisation line turned a manageable event into a messier one.

How to check it worked

A good plan is easy to find, easy to use, and easy to hand to someone else. If it takes more than a minute to locate the latest version, the plan is not ready.

Check whether every critical system has three things beside it: where it is stored, who owns it, and how it is backed up. If one of those is missing, the team may still be guessing during a real incident.

Call or message one deputy contact and ask them to confirm their role. Deputies only help if they know they are deputies and can access the same key documents as the primary owner.

Run a ten-minute scenario with no slides. Say: the website is failing, customers cannot order, and normal chat is unavailable. Watch whether the team can name the incident lead, the approver for shutdown, the host contact, and the place where the incident log starts.

Test one backup restore on a non-critical file. The goal is not to admire the backup status page. The goal is to prove that a named person can recover data when asked.

Finally, check the dates. Contact lists, contracts, and insurer details age fast in a growing business. The NCSC suggests checking these details every couple of months or as necessary.

Test yourself

Question: What should your plan name before an incident happens? Answer: It should name roles, contacts, critical systems, trigger points, backup details, suppliers, and who can approve disruptive actions.

Question: Why should you identify deputies for key roles? Answer: Because the primary contact may be away, and the team still needs someone who can authorise actions and access key documents.

Question: What is one simple way to test the plan? Answer: Run a short scenario and ask the team to show who they call, who decides, and how they would restore a file from backup.

Common mistakes

Making the plan too long. If the first-hour plan reads like a policy manual, people will not use it under pressure. Keep the core actions on one page, then link out to longer documents if needed.

Listing systems but not locations. Knowing that payroll matters is not enough. You also need to know whether it is on a local machine, remote server, or cloud service, because that changes the response path.

Forgetting non-technical roles. The NCSC explicitly says legal, HR, PR, suppliers, vendors, and senior management may all need to be involved. A technical-only plan leaves big gaps.

Depending on one person. Small teams often trust memory and goodwill. That breaks the moment the only knowledgeable person is on leave, in a meeting, or unavailable.

Assuming backups equal recovery. A backup that has never been restored is an assumption, not proof. Test restores are part of preparation, not a nice extra.

Over-reacting too early. The NCSC warns that rushing containment can cause more damage or push an attacker deeper into your environment. Gather enough information to choose the least harmful next action.

Skipping the incident log. If nobody writes down times, decisions, and missing data, the review later becomes guesswork. Good notes also help with any regulatory questions.

Level up

Your next practical step is to use the NCSC's Exercise in a Box style of rehearsal and schedule a short team exercise every quarter. Do not add more pages first. Repeat the same core scenario until people can find the plan, follow the trigger points, and start the incident log without prompting.