Seven in ten UK employees have used unapproved AI tools at work, while only around a third of organisations have any policy. Shadow AI is a data and contract problem rather than a technology one, and banning it makes it worse. Here is what to do instead.
When did you last test your backups?
Most businesses can answer the question “do you have backups?” without hesitating. Yes. There is a licence, there is a schedule, there is a green tick somewhere.
Far fewer can answer the follow up. When did somebody last take a backup, restore it onto different hardware, open the files and confirm the data was actually usable? For a lot of organisations the honest answer is never, or not since the system was installed.
That gap is where incidents turn into disasters. Veeam’s Data Trust and Resilience Report 2026 surveyed more than 900 senior IT, security and risk leaders and found that 90% were confident they could recover from a cyber incident, while among organisations actually hit by ransomware only 28% recovered all of their affected data. Forty four per cent got back less than three quarters of it.
That is not a gap in software. It is a gap between having a backup and having a tested restore.
The lesson the JLR shutdown made expensive
We wrote about the Jaguar Land Rover cyberattack and its cost of around £50 million a week as a case study in what a shutdown does to an organisation and its suppliers.
The part that gets skipped in most coverage is the recovery. Attacks are the dramatic bit. Recovery is where the money actually goes, and recovery time is decided months in advance by decisions nobody thought were important at the time. Whether the backup server sits on the same domain. Whether anyone knows which systems need to come back first. Whether the restore process has ever been run by a person rather than described in a document.
Nobody discovers those answers at a convenient moment.
Recovery time and recovery point, in plain English
Two numbers decide what an incident costs you. They sound technical and they are not.
Recovery time objective is how long you can be down. If your production line stops, or your care rostering system goes dark, or nobody can access client files, how many hours before that becomes a serious problem rather than an annoying one?
Recovery point objective is how much data you can afford to lose. If the last usable backup is from midnight and the incident happens at four in the afternoon, you have lost a day’s work. Everyone re-enters it, from memory and paper, while also dealing with the incident.
Write both numbers down as a business decision, not a technical one. Four hours and one hour costs meaningfully more than twenty four hours and twenty four hours, and there is no correct answer, only the one you have chosen deliberately.
The point of writing them down is that they become testable. A restore test either meets the number or it does not. Without the numbers, a test just tells you the restore “worked”, which tells you nothing about whether the business would have survived it.
A backup on the same network is not a backup
This is the single most common failure, and it is almost always the result of a reasonable decision made years ago.
The backup server sits in the same building, on the same domain, reachable with the same credentials. It is convenient, it is fast and it is exactly what ransomware operators go looking for first. Modern attacks target backup repositories deliberately, because a victim with working backups does not pay.
The NCSC has been explicit about this for years. Its guidance on ransomware resistant backups sets out what a backup service needs to do to survive a destructive attack, and its accompanying advice on offline backups makes the practical point plainly. Never have all your backups connected at the same time.
Two properties do most of the work here.
Immutable means the backup cannot be altered or deleted for a defined retention period, by anyone, including an administrator with valid credentials. That last part matters, because most serious incidents involve stolen credentials rather than broken encryption. An attacker who is inside your systems as a domain admin can delete a conventional backup. They cannot delete an immutable one.
Offsite means a copy somewhere that a compromise of your office network cannot reach. Cloud storage counts, but only if it is properly separated, with its own credentials and its own MFA. A cloud drive mapped as a network location on your file server is not offsite in any meaningful sense.
What a documented restore test actually looks like
“We checked the backups” is not a test. Here is what one involves.
Pick a real scenario in advance. Not “restore a file”, which always works, but something like “the file server is gone and we need it back”. Scenarios that hurt are the useful ones.
Restore to different hardware or a different environment, not over the top of the live system. This is where people discover that the backup depends on a licence key, a driver or a piece of infrastructure that no longer exists.
Time it, from decision to working. Then compare that number to the recovery time objective you wrote down earlier. If it is four hours over, that is your finding.
Open the data and check it. Have somebody who uses the system daily confirm the restored copy is genuinely usable, that the database opens, that the last week of records is there.
Write down what went wrong, because something always does. A missing password, an undocumented dependency, a step that only one person knows. That list is the actual value of the exercise.
Then do it again, at least annually, and after any significant change to your systems.
Where this bites hardest
In manufacturing, downtime has a per hour cost that everyone in the building can quote. Production scheduling, stock and quality records are usually the systems nobody has ever restored, because they are old and slightly frightening. They are also the ones that stop the line.
In the charity and social sector, budgets are tight and IT often runs on goodwill, which makes an untested restore particularly likely. Our work with YMCA North Tyneside is a good example of how organisations in that position can get properly resilient infrastructure without enterprise budgets.
For everyone, this sits alongside the more mundane continuity questions. We covered a related one in what happens when your internet goes down, and the thinking is the same. Decide in advance, in writing, what happens.
Two things worth knowing
Backups are not one of the five Cyber Essentials technical controls, and they still are not in the current requirements. What changed in the April 2026 update is that the backup guidance was moved earlier in the requirements document to underline how much recovery depends on it. So a certificate does not prove you can restore, and anyone treating it as evidence of that is mistaken. We covered the related traps in what is catching people out with Cyber Essentials.
The second thing is reporting. If you are hit, cyber incidents and fraud should be reported to Action Fraud, and depending on the data involved you may have a separate obligation to the ICO within seventy two hours. That clock starts whether or not your restore is going well, which is another argument for knowing in advance how long it takes.
Where to start
If it has been more than a year, or you cannot name the date, it has been too long.
Our managed datacentre service covers immutable and offsite backup with restore testing built in rather than bolted on, so the test happens on a schedule instead of when someone remembers. If you would rather the whole thing sat with a team who monitor it daily, our IT service management service wraps around it.
Either way, the useful next step is small. Pick one system, restore it somewhere safe and time it.
Get a quote or call us, and we will run the first test with you.