A suspected cyber incident can look like many things: an unavailable website, unexpected administrator accounts, a warning from a hosting provider, unusual email activity or files that have changed without explanation. The first job is to establish what is happening and protect the organisation while the right people investigate. Acting quickly matters, but rushed changes can erase useful evidence or make recovery harder.
Record what you can see
Write down the symptoms, when they began, who noticed them and the timezone used. Note recent changes such as software updates, new accounts, staff departures or configuration edits. Save relevant alerts and take screenshots if that is safe to do. Keep a simple timeline of actions and decisions, including who authorised them.
The UK National Cyber Security Centre (NCSC) recommends identifying what systems and information are affected, then working through a response plan with named responsibilities. Its Small Business Guide: Response & Recovery includes steps for identifying, resolving and reporting an incident.
Contact the people who can establish scope
Contact your hosting provider, IT support or cloud service provider using a known contact method. Ask whether the issue affects other systems or customers, whether they have relevant logs or backups, and what containment actions they recommend. If you use a managed service, check your contract and escalation contacts. For a significant or live attack, use the appropriate national reporting and incident-response channels; in the UK, the NCSC’s guidance explains how organisations can report significant attacks.
Do not rely on an email or phone number included in a suspicious message. Use details already held in your records or independently verified on the provider’s official site.
Contain carefully and preserve evidence
Containment depends on what is affected. A compromised account may need its sessions revoked and credentials reset; a server actively causing harm may need to be isolated with help from the hosting provider. Avoid deleting files, wiping machines or restoring a backup before you understand what evidence is needed and which systems are involved. A snapshot of an affected system can help an incident responder compare it with a clean state.
If customer or employee information may be involved, limit access to the details and involve the people responsible for privacy, legal and communications decisions. Reporting duties depend on the data, jurisdiction and circumstances, so avoid making promises about notification timelines until the right advice is in hand.
Recover from a known-good state
Work out the likely entry point before bringing a system back online. Restoring an old backup without fixing the cause can reintroduce the same problem. Confirm that the backup is clean and recent enough, then rebuild or restore in coordination with your provider or an incident-response professional. Patch exposed software, remove unauthorised accounts and keys, rotate credentials that may have been exposed, and check logs as the service returns.
The NCSC advises small organisations to make regular backups of essential information and test that they can restore it. A backup that has never been checked is an assumption, not a recovery plan.
Prepare before an incident happens
List critical systems, business owners, suppliers and out-of-hours contacts.
Keep provider support details and recovery instructions somewhere accessible if your email is unavailable.
Back up essential data regularly and rehearse a restore.
Agree who can isolate a service, contact customers or approve emergency spending.
Run a short scenario exercise and update the plan when services change.
Communicate from a verified picture
Keep confirmed facts separate from assumptions. For example, record that a server was unavailable at a particular time separately from a conclusion about how it happened. This makes it easier for technical responders, managers and external advisers to work from the same account. Limit the incident notes to the people who need them and preserve provider notices, logs and relevant messages.
Decide who is responsible for internal updates, customer communications and any required external reporting. The NCSC guide includes a step for reporting to stakeholders and a later review after the incident. Whether a particular regulator, customer or law-enforcement agency must be notified depends on the facts and jurisdiction, so use qualified advice where required. Once services are stable, review what worked, what delayed recovery and which contacts or instructions need updating.
A concise response plan will not predict every attack. It gives staff a reliable place to start, reduces guesswork and helps the organisation make better decisions while the technical picture is still developing.
