The Cost of Not Backing Up: A Real-World Cautionary Tale
Monday 16th June 2025
In the early hours of a July morning, a minor hardware failure—a tiny piece of metal crashing into a hard disk—triggered a major crisis for a well-known organisation. What should have been a three-hour fix turned into a nine-day recovery effort involving 20 people across three companies. The root cause? A lack of basic IT hygiene, especially around backups.
This incident, though dramatic, is not unique. Many organisations still fail to implement dependable backup strategies. Common issues include:
- No backups or storing them in the same location as the primary system
- Incomplete or outdated backup data
- Lack of tested recovery procedures
- Unclear ownership and access protocols
The blog stresses that backups are not just an IT concern—they’re essential to business continuity and cybersecurity resilience. It recommends aligning with standards like ISO 27001:2022 Annex A Clause 8.13 and exploring strategies like 3-2-1, grandfather-father-son, and FIFO.
________________________
The soft glow coming from the clock gently shifted as the display marked the passing of another minute. The night operators in the Network Operations Centre were oblivious to the change, but this particular 3:52AM one pre-dawn Thursday morning in July was one they would remember as, fifty miles away, a piece of metal almost too small to see crashes into the surface spinning beneath it at 350 km/h. The cause of this event would never be fully determined, but it set the organisation that owned the server in which this hard disk had hitherto uneventfully lived on a collision path with national news headlines, severe reputational damage and hundreds of thousands of customers affected.
It may sound like the start of an early Dan Brown techno-thriller, but it's based on real events. In the end, the public never found out about the events of that July morning, despite the organisation being a household name, but it took a team of 20 people from three organisations nine days to restore the services provided by the server. What makes this story even more noteworthy is that it could have - should have - been a three-hour fix.
It's also, unfortunately, not a unique tale.
In many ways, this is a good case study for organisations I talk to on how not to do things. The issues with corporate policies uncovered during the cleanup operation equally reads like fiction: not taking backups, not having redundant hardware for business-critical services, not keeping change request logs up-to-date, not having in-case-of emergency documentation and named owners. But, whilst each of these is important, I want to discuss just one of these today: backups.
The reasons for backing up data should not need an explanation. Not only can all storage media fail, the rise of cyber threats mean that any organisation can suddenly find themselves facing lost, corrupt or inaccessible data. And yet, I routinely hear of customers that suffer unnecessary disruption due to not having a backup. The fact that there is a World Backup Day – March 31st if you didn’t know – raises a red flag. Although it was created with the consumer in mind, reference to it has crept into organisations over the years which, although well meaning, perhaps sends the wrong message. In business, every day should be backup day.
Perhaps another challenge is that, by most definitions, cybersecurity focusses on the prevention of a cyber incident or limiting its scope should one occur whilst recovering systems after an incident generally falls under business continuity planning. This separation can have the effect of making system backups “someone else’s concern” in many organisations as responsibility for business continuity and cybersecurity fall under different EXCO members (COO/CRO vs. CISO/CIO), despite that fact that taking routine system backups is fundamental to surviving a cybersecurity breach.
Here in the Bytes Network Security team, we see about one case per month where a customer suffers business-affecting disruption and, in some cases, reputation damage that could have been avoided had they had a dependable backup to hand. In a recent case, a customer suffered an outage of two days where they could not communicate between sites, or serve their remote access community which totalled 50% of their staff – one that could have been avoided altogether even after the failure occurred, had they a backup. In another, the customer had a backup – which may have worked – but we’ll never know as the backup server was also compromised in the ransomware attack.
The key phase in the above is “dependable backup”. For example, here are some questions to consider:
- Where is it? Is it stored online or offline? In the same room as the server? The same rack? Backups should be away from the same physical environment as the server from which it came. And really, the question should be “Where are they?”: there should be more than one copy of a system backup.
- What does it include? Is it a complete disk image? OS and application data, or just application? Log data included? If it is just the data, do you have the original OS and application build media to hand?
- What form it is in? Encrypted or not?
- Is it accessible and who has access to it? Can backups be easily and quickly retrieved whilst still protecting them from unauthorised access?
- How old it is? Does the backup adequately cover the frequency with which changes are made. It might be recent changes can be recreated from change request logs, but what delay in service restoration would that incur?
- How do you recover it? Having a backup is one thing. Do you have a documented, tested process for recovery. If you’ve got to the point you’ve needed to recover a backup, it’s likely that people are under pressure. Clear, concise, dependable instructions are crucial.
- Do you know it will actually work? Imagine needing a backup only to find it does not work as expected. It does happen. It’s important to test the backups periodically – and the backup and restore processes – to ensure they’ll work when you really need them to.
I recommend that organisations wanting to take better control of their backup strategy – or indeed organisations that believe that they are already fully in control – take a look at ISO 27001:2022 Annex A Clause 8.13. It’s a great starting point. I’d also suggest looking into 3-2-1, grandfather-father-son and first-in, first-out backup strategies.
Naturally, here in the Bytes Network Security team, we can assist clients in creating tailored backup regiments for our vendors’ security products, creating In Case of Emergency (ICE) recovery documentation and testing backups. Please contact your Bytes Account Manager, or [email protected] for more details.
Want to keep informed? Sign up to our Newsletter