What Should a Small Organisation Do in the First 24 Hours After a Cyber Incident?

Introduction

A cyber incident is one of those situations where time suddenly feels compressed. What started as a strange login alert, an inaccessible mailbox or an unusual pop-up can quickly become a wider concern about data, operations and business continuity. For smaller organisations, the difficulty is often not just the incident itself. It is the uncertainty that follows it.

Who needs to know? What should be switched off? Should staff be told straight away? Is this a technical fault or a security issue? The first 24 hours matter because early decisions can either contain the problem or allow it to spread further. But those decisions are hard to make if there is no plan and no clear ownership.

The aim of this article is to offer a calm, practical view of what smaller organisations should focus on during the first day of a cyber incident. It is not legal advice or a substitute for specialist support, but it will help you think about priorities in the right order.

Recognise the signs and avoid denial

Not every technical issue is a cyber incident, but it is safer to treat suspicious activity seriously until you know otherwise. Common warning signs include unusual login alerts, emails sent from accounts without the user’s knowledge, files becoming inaccessible, systems running unexpectedly slowly, security tools being disabled or staff reporting suspicious messages at the same time.

One of the most common mistakes in the early stage is waiting too long because no one wants to overreact. That delay can give an attacker more time to move around, access more information or maintain persistence. It is usually better to investigate promptly and discover it was a false alarm than to minimise warning signs until the situation worsens.

In short, the first step is to acknowledge the issue and switch the organisation into a more deliberate response mode.

Containment comes before tidy explanations

In the first few hours, your priority is not writing a perfect incident narrative. It is reducing the chance of further harm. That may mean disabling a compromised account, isolating a device from the network, resetting credentials, pausing certain processes or restricting access to affected systems until you understand more.

Containment decisions should be proportionate. You do not want to create unnecessary disruption, but neither do you want to leave the door open while everyone debates what is happening. If you are working with an IT partner or managed service provider, this is the point to involve them quickly.

Keep a record of what is being observed and what actions are taken. Even brief notes are useful. They help with investigation, internal communication and any later reporting obligations.

Set roles and communication early

During a live incident, confusion often comes from too many people acting without a clear structure. Even in a small organisation, it helps to define a simple response group. Who is coordinating? Who is making technical changes? Who is approving internal messages? Who is responsible for external communication if required?

Staff communication is particularly important. If people hear about the issue informally or receive partial updates, rumours fill the gaps. A short, calm message is usually better than silence. Tell staff what is known, what they should do, what they should not do and where to direct questions or suspicious activity.

This is also the stage where senior leaders need enough information to make decisions without becoming a bottleneck. Good incident handling balances speed with accountability.

Protect evidence and avoid making matters worse

In the rush to fix things, it is easy to make changes that remove useful evidence or complicate later investigation. That does not mean you should leave systems exposed, but it does mean changes should be logged and handled carefully. Random reboots, mass deletions or poorly coordinated password resets can all create new problems.

If email compromise is suspected, preserve relevant messages and logs where possible. If a device is behaving suspiciously, avoid letting multiple people “have a look” without coordination. If ransomware is involved, take advice before assuming recovery options or next steps.

A measured response is always more valuable than a frantic one. The aim is to stabilise the situation, not create a second incident in the process.

Think beyond the technology

A cyber incident is also a business continuity issue. What operations are affected? Are customer, donor or staff services disrupted? Are deadlines, payroll, finance or safeguarding functions at risk? Smaller organisations sometimes focus so heavily on the technical detail that they forget the wider operational picture.

This is where continuity planning matters. If systems are unavailable, what can continue manually? Which activities need to be paused? Which stakeholders may need to be informed if disruption continues? These questions are easier to answer if they have been discussed before an incident happens, but they can still be worked through during the first day if necessary.

The key is to treat operational impact as part of the response from the beginning, not as an afterthought once the technical team has finished.

Know when to escalate and ask for help

Smaller organisations do not need to handle serious incidents alone. If the impact is unclear, sensitive data may be involved or systems are significantly affected, external support should be brought in early. That may include your IT provider, cyber security specialists, legal advisers or insurers depending on the situation.

What matters most is not pretending certainty where it does not exist. There is no advantage in delaying support just to avoid difficult conversations. Incidents tend to become more manageable when experienced people are involved promptly.

Even if the incident turns out to be smaller than first feared, bringing in support early is usually a sensible decision rather than an overreaction.

Final thoughts

The first 24 hours after a cyber incident are rarely neat, but they do not have to be chaotic. If your organisation can recognise warning signs, contain risk quickly, communicate clearly and focus on both technical and operational impact, you will already be in a much stronger position than many smaller organisations.

The best time to prepare for an incident is before one happens. A short response checklist, clear ownership and an understanding of what matters most to your organisation can make a huge difference when pressure hits.

Preparedness is not about expecting the worst every day. It is about making sure that if something does go wrong, your team is not starting from zero.

If you do not yet have a practical incident response plan, TeamTech4 can help you build one before you need it, so that your team is not making critical decisions under pressure with no clear starting point.