Cyber Incident Response for UK Businesses
When something has gone wrong, the first hour matters more than the next month. We help you contain it, understand it, meet your legal obligations, and get trading again.
What should a business do first after a cyber attack?
Contain before you investigate. Disconnect affected devices from the network without powering them off, reset and revoke sessions for compromised accounts, and stop any outbound payment. Then preserve logs and evidence, and get expert help before wiping anything. If personal data is involved, the ICO clock starts at 72 hours.
The first hour: what to do right now
If you are reading this during a live incident, do these things in order. Disconnect affected machines from the network — pull the cable or turn off Wi-Fi — but do not power them off, because volatile memory often holds the evidence that explains what happened. Reset passwords and revoke active sessions for any account you suspect is compromised, and check for mailbox forwarding rules you did not create.
Stop any pending payments and warn your finance team, because invoice fraud frequently accompanies email compromise. Do not pay a ransom before taking advice. Do not wipe and rebuild machines yet — that destroys the evidence you will need both to understand the breach and to satisfy the ICO. Then call us on +44 7424 967568.
- Disconnect from the network — do not power off
- Reset passwords and revoke active sessions on compromised accounts
- Check for and remove unauthorised mailbox forwarding or inbox rules
- Halt pending payments and alert finance to possible invoice fraud
- Preserve logs and do not rebuild anything yet
- Record a timeline of what was noticed, when, and by whom
Your legal obligations under UK GDPR
If the incident involves personal data and poses a risk to the people it relates to, you must notify the Information Commissioner's Office within 72 hours of becoming aware of it. That clock starts when you become aware, not when the investigation completes — so a partial notification followed by an update is expected and acceptable.
If the risk to individuals is high, you must also tell those individuals without undue delay. Getting this wrong compounds the damage: the ICO has been consistently clearer about penalising poor breach handling than about penalising the breach itself. We help you make an evidence-based decision about whether the threshold is met and, where it is, draft the notification.
- Assess whether personal data was accessed, altered, lost or exfiltrated
- Determine whether the risk threshold for ICO notification is met
- Notify the ICO within 72 hours of awareness where required
- Notify affected individuals where the risk to them is high
- Maintain an internal breach record even where notification is not required
Investigation and recovery
Once containment holds, the questions become: how did they get in, how long were they there, what did they touch, and are they still there? We answer those from evidence — sign-in logs, endpoint telemetry, mail audit records, firewall data and disk artefacts — rather than assumption, because the answers determine both your notification duties and whether your recovery actually removes the attacker.
Recovery then runs in a controlled order: rebuild from known-good sources, restore data from backups verified to pre-date the compromise, rotate every credential and secret that was reachable, close the weakness that allowed entry, and only then reconnect.
- Establish the initial access vector and the full timeline
- Identify every account, device and dataset that was touched
- Verify backups pre-date the compromise before restoring
- Rotate credentials, API keys, certificates and service account secrets
- Close the underlying weakness before reconnecting anything
Preparing before it happens
Incident response is dramatically cheaper and faster when it is planned. We write incident response plans for clients that name who decides what, list the contacts that will be needed at 6pm on a Friday, and set out the first-hour actions in a form someone can follow under pressure.
We then run a tabletop exercise — a facilitated walkthrough of a realistic scenario — so the plan gets tested before reality tests it. It typically takes half a day and reliably surfaces problems such as the backup administrator being the only person with the password.
- Written incident response plan with named roles and decision authority
- Contact tree covering insurers, legal, ICO, bank and key customers
- Offline copy of the plan — because it is useless on an encrypted file server
- Half-day tabletop exercise against a realistic scenario
Included in every engagement
Fixed scope, agreed in writing before we start. If the scope changes, we stop and re-quote rather than invoicing the difference.
Service Level Agreement (SLA) — Managed Security & IT Support
Response and resolution targets, service hours, escalation path, maintenance windows, service credits and reporting for managed support.
UK Electronic Communications Act 2000 · eIDAS (EU) No 910/2014 · SHA-256 Verified
Incident Response — your questions answered
We think we have been hacked. What do we do first?
Should we pay a ransomware demand?
Do we have to tell the ICO about a breach?
Do you offer emergency response outside business hours?
How long does incident recovery take?
Question not answered here? Call +44 7424 967568 or email support@cipherknights.com.
You might also need
Ready to talk about incident response?
Book a free, no-obligation consultation with our Leicester team, or call us and we will point you in the right direction whether or not you become a client.