Backups are the easy half of disaster recovery

Ask a small business whether it has backups and the answer is almost always yes. Ask when a restore was last tested and the room goes quieter. Ask who would actually start the restore if the server died at four on a Friday afternoon, and you usually get a name, then a pause, because that person is on holiday until Wednesday.

Only the first of those is a backup question. The rest are a recovery plan, and the government's own survey puts the number of UK businesses with a continuity plan covering cyber security at 33 per cent. Among small businesses it fell over the last year, from 53 per cent to 44.

What a backup answers, and what it does not

A backup answers one question: does a copy of this data exist somewhere it cannot be destroyed by the thing that destroyed the original. That is a real question and most of an answer to it fits in the 3-2-1 rule, which we covered in three copies, two media, one offsite.

Recovery is a different problem wearing similar clothes. A backup is a file. A recovery is a project with an order of work, a person in charge, a definition of finished, and a clock running on it from the moment it starts. None of that is stored in the backup.

Here is the shape of the gap. Two hundred gigabytes restore perfectly and the business still cannot trade, because the licence key for the line-of-business software was on the server, the person who knows the supplier's account number is unreachable, and nobody agreed whether to bring back the accounts system or the booking system first. Every one of those is a planning failure that no amount of backup fixes.

The two numbers, agreed before anything else

Everything in a recovery plan hangs off two figures, and both of them are business decisions rather than technical ones.

How much data can you afford to lose. This is the gap between your last good copy and the moment it went wrong. A nightly backup means up to a day of work, which for one office is an afternoon of re-keying and for another is a legal problem. You set the number, then the schedule gets built to meet it. Our backup and recovery page says the same thing in one line: agree that number with you first, then set schedules to meet it.

How long you can be down. Not how long you would like it to take. How long before the cost of being down exceeds the cost of whatever would have prevented it. Most owners have never done this sum, and it is worth doing badly on the back of an envelope rather than not at all. Take a day's turnover, divide by the hours you trade, and ask how many of those hours you could absorb.

Now the uncomfortable part. We do not publish a blanket recovery time, and I would be wary of any provider who does. Restoring a deleted file takes minutes. Rebuilding a failed server takes as long as that server's particular construction demands, and the honest answer before anyone has tried is that nobody knows. That is exactly why the Complete plan carries an annual disaster-recovery test with a written findings report. The test is not a formality. It is the thing that turns an estimate into a measured figure you can plan around.

What comes back first is a business decision

NCSC published new response and recovery guidance on 28 July 2026, and one line in it should be pinned above the desk of anyone who has ever run a restore. The needs of the business must drive prioritisation for recovery, not solely IT considerations.

The same guidance introduces a phrase worth stealing: minimum viable operations. Not everything back. The least that lets you function, brought back first, with the rest following once you are no longer bleeding. For a building firm that might be quoting and invoicing, with the shared photo archive waiting a fortnight. For a dental practice it is appointments and clinical records, and nothing else comes close.

Write the order down. Three or four lines is enough, and it should read like a business, not like an inventory:

• What stops you taking money if it is gone
• What stops you delivering what you have already sold
• What stops you paying staff and suppliers
• Everything else, which can wait longer than you think

NCSC's small business guide adds a step people skip: work out where each of those things actually lives. On a machine in your office, on a server somewhere, or inside a third party's platform. The last one matters most, because a recovery plan for something you do not host is mostly a list of phone numbers and a contract you should read before you need it.

Who decides, and who is allowed to say so

The technical work in a recovery is rarely the bottleneck. Authority is.

NCSC's small business guidance calls these trigger points, and gives an example that lands: an employee might spot that there is a problem with the website, but who decides whether the website gets taken offline? At what point does that stop being an IT decision and become the owner's? In a large organisation this is formalised as a command structure with strategic, tactical and operational layers. In a nine-person business it is two names, a deputy for each, and one sentence about who can authorise spending money at midnight.

Write down the deputy. The guidance is explicit about shared responsibility so there is cover when somebody is away, and incidents have an unkind habit of arriving during half term.

The same list should carry your external contacts and what each of them is actually contracted to do: web host, IT provider, cloud platform, and your insurer with the policy number. On insurance, NCSC is blunt in a way brokers sometimes are not. It will not protect you from an attack, though it may give you resources during and after one. We went through what underwriters actually ask for in what insurers check before they pay out.

The plan has to exist somewhere the incident cannot reach

A recovery plan stored on the file server is not a recovery plan. Neither is a contact list that lives only in a mailbox, when the reason you need it is that nobody can sign into anything.

NCSC's recovery guidance has a specific instruction here that goes further than availability: establish whether your communications channels are available and can be trusted for use. Trusted is the sharper word. In an incident where an attacker may still be reading internal email, the question is not only whether Teams is up. It is whether you are willing to plan your response in a system the intruder might be sitting in.

So: a printed copy, a copy on somebody's phone, and an agreed way to talk to each other that does not run through the compromised estate. And the maintenance job nobody does, which the guidance also names. Check the contact details every couple of months. Suppliers change numbers, staff leave, and the day you need that list is the worst possible day to discover it is two years old.

Restoring quickly is not the same as restoring well

Every instinct in a crisis says get it back now. The guidance published in July says something different, and it is worth quoting closely: investigation should take place before systems are restored where possible, because rushing recovery before understanding the incident can significantly increase risk.

Two concrete reasons sit behind that. The first is reinfection. If the attacker was inside your network for three weeks and you restore from last night's copy, you restore their access along with your data. The second is evidence. NCSC sets out the trade-off plainly: disconnecting a system from the network can limit the spread and preserve forensic evidence, while powering it down may be faster and may halt what is running, but can lose the evidence you would have needed to work out how they arrived and whether they have really gone.

That is a decision to make while calm, not at nine on a Sunday evening. Our article on the first hour of a ransomware attack covers the same ground at incident speed.

One thing we say without hedging: for a genuinely disruptive attack, NCSC recommends securing an NCSC-assured Cyber Incident Response provider, and Alpha IT is not one. We are the people who get you back on your feet, who know where everything was, and who will work alongside a response firm. We are not the forensic investigators, and any IT company that blurs that line is doing you no favours.

The law already has an opinion about this

UK GDPR Article 32 does not say "disaster recovery plan". It says two things that add up to one.

Article 32(1)(c) requires the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational measures. Copies alone satisfy neither limb. Timely restoration is a capability you can only claim if you have exercised it, and the testing requirement is written into the statute rather than implied by it.

There is a second consequence people miss. The ICO describes a personal data breach as a security incident affecting the confidentiality, integrity or availability of personal data, and says there is a breach where data is made unavailable and that unavailability has a significant negative effect on individuals. Ransomware that encrypts and steals nothing is still capable of being a reportable breach on availability alone. We set out the clock in the 72-hour rule.

To be clear about our own role. We are an IT company. We are not a law firm, nobody here is your data protection officer, and we submit nothing to the ICO on your behalf. What we can do is hand whoever makes that call the technical facts of what happened, quickly and in writing, which is usually the thing they are short of.

Almost nobody has one, and most that exist are untested

The Cyber Security Breaches Survey published by the government on 30 April 2026 puts numbers to this, and the pattern is entirely about size.

The written findings are harder reading than the percentages. Plans, the survey says, continued to be largely untested or incomplete, and only a minority of organisations reported testing theirs properly. One participant is quoted describing where the plan lives. In the staff handbook, never tested.

One figure in the same survey looks reassuring and should be read carefully. Eighty-seven per cent of affected businesses said they restored operations within 24 hours after their most disruptive breach. That covers every kind of breach, including the very large number that never touch a server at all. It is not evidence that a ransomware event resolves in a day.

What we do, and what it costs

Our backup and recovery service has four parts, and only two of them are backup. Automated backup of servers, endpoints and Microsoft 365 data with alerting on failure. Test restores performed and verified on a schedule. A written plan naming what gets recovered, in what order and by whom. And on the Complete tier, a full disaster-recovery test once a year with a findings report, after which the plan gets updated to match what actually happened.

The prices, from our published rate card and excluding VAT. Managed backup with tested restores starts on Professional at 77 pounds per user per month. Complete is 108 and adds the annual test and compliance reporting. Essential is 50 and covers monitoring, patching and antivirus, but not managed backup, which is worth saying out loud rather than leaving in a comparison table. Backup for one specific server or dataset can be quoted separately, and server management is 162 pounds per server per month.

If you have no agreement at all, the relevant rate is 126 pounds an hour, or 167 out of hours with a two-hour minimum. That is what an unplanned recovery is billed at, by us or by anyone else, and it is the least efficient money in IT.

One thing has changed the design of all this in the last few years and it is worth stating. Modern ransomware goes for the backups first. So recovery copies now live somewhere the protected environment has no ability to reach or delete, as a default rather than as an upgrade. If your current arrangement has a drive plugged into the server it is protecting, that is the first conversation, and it does not require buying anything from us.

Start with the free IT health check if you want a picture of where you stand. It is ten questions and it will not see inside your backup schedule, but it is a better place to begin than a quote.