What to do in the first hour after a suspected security breach

If you are reading this because you think something has just gone wrong, you are in the right place. Much of the lasting damage from a security incident is done in the first hour, and often not by the attacker. It is done by well-meaning people acting in the wrong order: switching machines off, deleting things, logging back in, or waiting quietly to see whether it resolves itself. The first action is the simplest. Disconnect the affected device from the network and leave it switched on. Then work down the list below.

First, a quick gut check: is this actually a security incident?

You do not need a formal definition. You need to recognise the shape of it. Treat any of the following as a suspected incident until somebody qualified says otherwise.

A ransom message on a screen, or files renamed and no longer opening.
A sudden run of password reset emails or “unusual sign-in attempt” alerts, or staff locked out of accounts that worked yesterday.
A customer, supplier or your bank reporting strange emails, invoices or payment requests that appear to come from you.
A member of staff who clicked a link or typed their password into a page they now think was fake.
Company information appearing somewhere it has no business being.

If any of that sounds familiar, keep reading. A false alarm costs you one phone call. The opposite mistake costs a great deal more.

What to do in the first hour (do these, in order)

Disconnect the affected device from the network, but leave it switched on. Unplug the network cable, or turn off that machine’s Wi-Fi. Think of it as pulling a car out of the traffic rather than crushing it: you want it stopped, not destroyed. Shutting a computer down clears what is held in its memory, and that is frequently where the evidence of what happened is sitting.

Tell whoever manages your IT immediately, internally or externally. Do not wait until you are sure. A wasted call costs a few minutes of someone’s time. An hour’s delay can be the difference between one compromised mailbox and the whole tenant.

Do not sign in again from that machine, and stop using the affected password anywhere else. If a password has been captured, every other place it was used is exposed too, in the way one key might open the office, the stockroom and the filing cabinet. Changing it on the compromised account alone leaves the other doors open. Make the changes from a different, known-good device.

Preserve everything, and do not tidy up. Do not delete files, empty mailboxes, download a “cleaner” tool found through a search engine, or attempt a repair before anyone qualified has looked. Screenshots of what you can see, including any ransom note or odd email, are genuinely useful. Take them with a phone if the machine is off the network.

Start a simple written timeline as you go. A note on paper is enough: what was noticed, when, by whom, and what was done. It takes two minutes now and is close to impossible to reconstruct later. Your insurer will ask for it, the ICO expects a record of the facts if the incident proves reportable, and whoever investigates will start here.

Establish what is affected, in broad terms, without guessing. Which systems, which accounts, and whether personal information about customers, staff or suppliers may be involved. Broad and accurate beats detailed and speculative. If you do not know, write that down rather than filling the gap with an assumption.

What not to do

This list matters as much as the one above, because these are the actions that turn a contained problem into an expensive one.

Do not wipe, reformat or rebuild the machine. It feels decisive and it destroys the only record of how the attacker got in. Without that, you cannot be confident you have closed the route they used, so the same thing can happen again next week.

Do not pay a ransom demand without advice. Setting the ethics aside, payment does not guarantee your data is returned or that stolen copies are deleted, it marks you as a business that pays, and depending on who is behind the demand it can carry legal consequences in the UK. It also affects any insurance claim. Never decide it alone, and never in the first hour.

Do not assume it is contained because it looks contained. One locked account or one odd email is usually the visible corner of something larger, and attackers commonly sit quietly inside an environment before anyone notices. “It seems fine now” and “it is fine” are different statements.

Do not announce it widely before you know what you are dealing with, and do not cover it up either. A short factual holding line is enough for the first hour: something has been flagged, it is being looked at, report anything unusual rather than acting on it.

Who to call, in what order

First, your IT or security provider, or your internal IT team. Containment is the priority and they are the only people who can do it. Tell them what you have seen, what you have done, and what you have not done.

Next, your cyber insurer, if you hold a policy. Many policies require early notification, and some make incident response specialists available directly as part of the cover, so qualified help can arrive faster than you could arrange it. Late notification can affect a claim. If you are unsure what your policy requires, our guide to what cyber insurers expect from your IT provider covers the ground in plain English.

Then Action Fraud, if the incident looks criminal, which includes ransomware, fraudulent payment requests and data theft. Action Fraud is the UK’s national reporting centre for fraud and cyber crime, and reports are made online at reportfraud.police.uk. Businesses in Scotland report to Police Scotland instead.

And the ICO, if personal data is or may be involved. The next section explains when that obligation applies and how the 72-hour clock works.

One observation: a business with round-the-clock monitoring does not have to work this order out under pressure, because the first call has already been made, in advance.

Talk to someone now

Or call 020 7123 4910

Do you have to report it to the ICO? A plain-English guide to the 72-hour question

This section is factual signposting, not legal advice. Read it as general information and take proper advice on your own situation.

Under UK GDPR, the obligation is triggered by a personal data breach, which the Information Commissioner’s Office defines as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. In everyday terms: information about identifiable people being lost, changed, seen by the wrong people or made unavailable. It is broader than “someone stole our data”. Ransomware that locks records so nobody can reach them counts, and so does an email sent to the wrong recipient.

Two things follow, and they cut in both directions. Not every IT incident is a personal data breach, because plenty touch no personal information at all. And not every personal data breach has to be reported: the duty applies where the breach is likely to result in a risk to people’s rights and freedoms. Where that risk is unlikely, the ICO does not need to be told, though you should still record the breach and be able to justify the decision.

Where reporting is required, the deadline is without undue delay and not later than 72 hours after becoming aware of the breach. “Aware” means the point at which your organisation reasonably established that a breach had occurred, not the moment the attacker got in, which may have been far earlier. The ICO accepts that a full picture is often impossible inside 72 hours and asks organisations to report early and update later. If the breach is likely to result in a high risk to the people affected, they must be told too, without undue delay.

That makes it a judgement call on the facts, best made with advice rather than assumed either way in the first hour. Gather the facts and keep the timeline, because the assessment is made from those. The authority here is the ICO, not us: see Personal data breaches: a guide.

What happens after the first hour

The first hour is about stopping the bleeding. What follows is more methodical. Containment is completed across the whole environment, not just the machine you noticed. An investigation establishes how entry was gained, what was reached and whether anything was taken. Notifications go out where required, to the regulator, to affected individuals, to your insurer and sometimes to customers under contract. Systems are recovered from backups that have themselves been checked for tampering. Finally, and this is the part most often skipped once the pressure lifts, the conditions that allowed it are reviewed and closed: the unpatched server, the account without multi-factor authentication, the permissions nobody had revisited. That last stage is ordinary cyber security work, and far cheaper before an incident than after one.

Why businesses without 24×7 monitoring struggle most in this first hour

The businesses that come off worst in the first hour are not usually the ones with the weakest defences. They are the ones with nobody to call at two o’clock on a Sunday morning, or nobody who already understands how their systems fit together. Searching for an incident response firm at that hour, in that state of mind, is a poor way to choose one, and the first stretch of any new relationship goes on explaining your environment to a stranger while the clock runs.

That is the gap a 24x7x365 managed detection and response service and security operations centre exists to close. Someone is already watching, so the incident is often spotted before anyone in the business notices. They already know the environment, so containment starts immediately. And they are reachable at the moment it matters, which for most of these incidents is not during office hours.

How Lanmark can help

Lanmark provides managed detection and response backed by a 24x7x365 security operations centre, built and priced for businesses of 20 to 500 users rather than sold as an enterprise add-on. Our support is billed per user per month, with no per-device charges and no per-incident charges, which removes a question no one should be weighing up at midnight: whether this is serious enough to be worth calling in. If it looks wrong, you call.

We are a Microsoft Direct CSP, and we hold Microsoft’s Support Service Designation, an accreditation held by only a handful of companies worldwide and awarded on the quality and consistency of support delivered. We also hold Cyber Essentials. If you are reading this page in the middle of an incident, call us and we will tell you honestly whether we can help, including if the answer is that you need someone else first.

Speak to our security team

Or call 020 7123 4910

Frequently asked questions

What is the very first thing I should do if I think we’ve had a security breach?

Disconnect the affected device from your network, by unplugging the network cable or turning off its Wi-Fi, and leave it switched on. That stops anything spreading further while preserving the evidence of what happened. Then tell whoever manages your IT immediately, even if you are not certain anything is wrong. Acting in the wrong order causes more damage than acting slightly slowly, so contain first and investigate second.

Should I turn the affected computer off?

No. Disconnect it from the network instead, and leave it powered on. Shutting a computer down clears what is held in its memory, and that is often exactly where the evidence of how the attack worked is stored. Think of it as pulling a car out of the traffic rather than crushing it: you want the machine stopped and isolated, not destroyed. Powering off can make the investigation that follows considerably harder.

Do I have to report a data breach to the ICO, and how quickly?

If personal data is involved and the breach is likely to result in a risk to people’s rights and freedoms, you must report it to the Information Commissioner’s Office without undue delay and not later than 72 hours after becoming aware of it. The ICO asks organisations to report early and update later rather than waiting for a complete picture. Where a risk is unlikely you need not report, but you should record the breach and your reasoning.

Should I pay a ransom if we get a ransom demand?

Not without advice, and never as a decision taken alone in the first hour. Payment does not guarantee your data is returned or that stolen copies are deleted, it identifies your business as one that pays, and depending on who is behind the demand it can carry legal consequences in the UK. It also has implications for any insurance claim. Involve your IT or security provider, your insurer and a legal adviser before anyone considers it.

Who should I call first after a suspected cyber attack?

Call your IT or security provider, or your internal IT team, first, because containment is the immediate priority and they are the only people who can do it. Then your cyber insurer if you hold a policy, as many require early notification and some provide incident response specialists directly. Then Action Fraud if the incident looks criminal, and the ICO if personal data may be involved and the reporting threshold is met.

How do I know if a data breach involves personal data?

Personal data is information about identifiable living people: customers, staff, suppliers, applicants or patients. If the systems, mailboxes or files affected contained names, contact details, payroll records, customer databases, HR files or anything similar, personal data is likely to be involved. It is broader than theft alone, because losing access to records, altering them, or sending them to the wrong recipient all count. If you are unsure, assume it may be involved and take advice quickly.

What should I not do in the first hour after a breach?

Do not wipe, reformat or rebuild the affected machine, because that destroys the evidence of how entry was gained. Do not delete files or run a downloaded cleanup tool. Do not sign back in from the compromised device or reuse the exposed password. Do not pay a ransom without advice. Do not assume the problem is contained just because it looks contained, and do not announce it widely before you know what you are dealing with.

What is the difference between an IT incident and a reportable data breach?

An IT incident is any security event affecting your systems, and many involve no personal data at all. A personal data breach is a security failure that destroys, loses, alters, exposes or blocks access to personal data. It becomes reportable to the ICO only when it is also likely to result in a risk to people’s rights and freedoms. So one is a subset of the other, and the reporting threshold is a further judgement made on the facts.