The backup that saved the data and lost the evidence
If something went badly wrong with your customer data tomorrow, you would want two things back. The data itself, obviously. Then the record of who had touched it, when, and what they did, because that is the only thing that answers the questions people will actually ask you: did anyone read this, who was it, and can you prove it.
Most small businesses can get the first one back. Far fewer can get the second, and almost nobody has ever checked which camp they are in. That is because the two things live in different places, and only one of them tends to be in the backup job.
A hospital trust has just demonstrated the difference in public.
What happened at Nottingham
On 18 August, staff at Nottingham University Hospitals NHS Trust were doing routine technical work: copying a radiotherapy database so it could be used for reporting. They ran a set of pre-written instructions that had been used before on a different hospital system. One setting needed changing first. Nobody changed it.
The process ran against the wrong database and overwrote the Trust's old maternity records system, which held information about women and babies treated between September 2011 and November 2022. According to the Trust's own statement, the error was escalated within minutes, external specialists were brought in, and the clinical information needed for patient care was restored: notes, observations, and test results. Current maternity patients were unaffected, and the Trust says no patient information was accessed or used inappropriately.
One part did not come back. The Trust has been unable to fully restore the history showing who viewed those maternity records over the 11-year period. In its own words, it may in most cases be unable to confirm whether a particular person looked at a particular record between those dates. The Information Commissioner's Office was notified inside the reporting deadline, and so was Nottinghamshire Police, who are assessing whether the loss affects Operation Perth, their investigation into deaths and serious injuries involving mothers and babies at the Trust's hospitals.
Read that last part again, because it is the whole lesson. The data was recoverable. The evidence about the data was not. And the evidence was the bit an active investigation needed.
Why this is not a story about the NHS
It is tempting to file this under large-organisation problems. It is not one. Strip out the scale and the subject matter and what is left is the most ordinary IT task there is: someone competent reused a script that had worked before, on a system they were authorised to touch, during planned work on a Tuesday.
No attacker. No phishing email. No unpatched server. Every security control you have ever been sold was pointed the wrong way, because this came from inside, wore the right credentials, and looked exactly like the work it was supposed to be.
Your business runs versions of this constantly. Someone migrates a mailbox. A developer runs a data fix on the live system because the test copy is out of date. An IT provider trials something on a Friday afternoon. Most of the time it is fine, which is precisely why nobody treats it as risky.
The other reason this matters to a smaller firm is that you are more exposed, not less. A trust like Nottingham can call in external specialists and spend weeks reconstructing what it can. If your line-of-business system is overwritten on a Tuesday, you have whatever your backup holds, and that is the end of the conversation.
The audit trail is a separate asset
Here is the part worth taking to whoever runs your systems.
Your data and your audit history are usually stored, retained, and protected differently. Access logs frequently live inside the application rather than the database, or in a cloud service's own event store with its own retention period. Microsoft 365 audit logs are the everyday example: they sit in the service, they expire on a schedule set by your licence, and no amount of backing up your files touches them.
So you can be in the unhappy position Nottingham is in without any of the usual warnings. The restore worked. The data is complete. And you still cannot say who looked at what, because that record was never yours to restore.
This matters commercially, not just technically. Under UK data protection law the burden is on you to show what happened when personal data goes wrong. If a client, an insurer, or the Information Commissioner's Office asks whether a departing employee downloaded the customer list, "we don't keep that information" is an answer with consequences. Being able to show you took reasonable steps is worth real money at exactly the moment you are least able to buy it.
What to do this quarter
Three things, all of them questions rather than projects.
Ask who signs off a change that touches live data. Not a policy document: a named person, and a rule about when it applies. For a small business, "anything that writes to a live system gets a second pair of eyes and a sentence in writing about what could go wrong" is enough, and it is exactly the control that would have caught a reused script pointed at the wrong database. Ask what happens when it is your IT provider making the change rather than your own people, because that is usually the gap.
Ask what your audit logs cover, and for how long. Name the systems that hold your sensitive data: the finance system, the customer database, email, the file store. For each one, ask what record exists of who accessed what, where that record is kept, how far back it goes, and whether it survives the system being restored from backup. You are looking for a number in days or months. If the answer comes back vague, that vagueness is the finding.
Ask when the last restore test was, and what was in it. Test restores tend to check that the data comes back, because that is the obvious thing to check. Add one question to the next one: is the access history there too. Testing your backups matters for ransomware and hardware failure as well, but this is the version of the test that most people have never run.
None of those three costs anything except somebody's attention. The alternative is finding out what your logs cover on the day somebody important asks you a question about them.
How Steelwise can help
Working out where your audit records actually live, how long they survive, and who is allowed to make changes to live systems is a short, well-defined piece of security advisory work. Get in touch if you would like a straight answer on yours.
Further reading
- ICO: Personal data breaches, a guide
- ICO: A guide to data security
- NCSC: Logging and monitoring
- NCSC: Backing up your data (small organisations guide)