Case Study
Discovering that backups existed but recovery did not
A distribution business believed it was protected against ransomware. A recovery test showed the backups were running, but the business could not have restored its core system within an acceptable timeframe.
Client situation
A distribution business running an on-premises ERP system alongside Microsoft 365, with a nightly backup job that had reported success for several years.
The problem
The board had been told the business was protected against ransomware. It had never been tested, and the assumption did not survive contact with a recovery exercise.
What we found
- The nightly backup completed successfully, but covered the ERP database only — not the application server, its configuration or its integrations.
- Backup credentials were a domain administrator account, and the backup storage was reachable from the production network with those credentials, meaning a ransomware event would likely have encrypted the backups too.
- Microsoft 365 data was not backed up at all; the business had assumed Microsoft's replication was a backup.
- No recovery test had ever been performed. The estimated recovery time in the continuity document was a figure someone had written down in 2021 with no basis.
- Nobody could produce a current list of which systems the business genuinely could not operate without, or in what order they would need to come back.
What we changed
- Rebuilt the backup design around immutable, credential-isolated storage that production domain accounts cannot reach or delete.
- Extended coverage to the full ERP application layer, integrations and the Microsoft 365 tenant, including mailboxes, SharePoint and Teams.
- Ran an actual restore of the ERP system into an isolated environment, timed it, and documented every step that was missing or wrong.
- Produced a ranked list of critical systems with realistic recovery time and recovery point figures, agreed with operations rather than imposed by IT.
- Wrote a short incident response plan naming decision-makers, communication routes and first-hour actions, and ran a tabletop exercise with the senior team.
Outcome
- Recovery of the core system has been performed end to end and timed, so the figure the board relies on is measured rather than assumed.
- Backups can no longer be destroyed by a compromise of the production environment, which is the failure mode that turns a ransomware incident into an existential one.
- Microsoft 365 data is protected independently of Microsoft, closing a gap the business had not known existed.
- The senior team has rehearsed the first hour of an incident and knows who makes which decision.
The gap between backup and recovery
Backup is a job that runs. Recovery is a business capability. They are related, but they are not the same thing, and a green tick on a backup console tells you almost nothing about the second one.
In this case every individual component was defensible. The backup job was configured correctly for what it had been asked to protect. The problem was that nobody had ever asked the question in the other direction: if the ERP system were encrypted at 3am on a Tuesday, what precisely would we do, and how long would it take?
What the test actually revealed
The technical findings mattered, but the most valuable output was the timing. The documented assumption was a four-hour recovery. The measured figure, once the missing application-layer components had been rebuilt by hand, was closer to three days — and that was with the person who knew the system available and awake.
Once the board saw a measured number instead of an aspirational one, the investment decision took about ten minutes.
Relevant services
Make your technology safer — and more useful.
A short conversation is usually enough to establish whether there is something worth doing, and what it would involve. No obligation, and no sales script.