The backup report is green. Somebody checks it every morning. That feels reassuring — right up until the day the business needs more than a few recovered files.
A backup is a copy. Recovery is the moment customers, employees and critical services can work again.
The NCSC says ransomware incidents have encrypted live data and the connected drives and cloud storage holding backups. Its guidance recommends regular copies, separation from live systems and — the part organisations often skip — testing that restoration works as expected.
That distinction matters because a successful backup job does not prove that a critical service can return in the right order, with the right settings, people and supplier help. Leadership needs evidence that the whole recovery process works.
Know what must recover first
Start with business services rather than servers. Which customer, payment, communication or operational processes must return first? How long can each be unavailable before the impact becomes serious?
Those answers set recovery priorities. Without them, technical teams may restore what is easiest rather than what the organisation needs most.
Understand what is included
A backup may cover application data but omit configurations, user permissions, encryption keys, integration settings or devices needed to use the system. Ask for a clear record of what is protected and what must be rebuilt another way.
Cloud services also need review. A supplier may make the platform available without protecting the organisation from accidental deletion, malicious changes or a problem introduced through its own account.
Check independence from the live environment
If attackers or administrators can reach both live systems and backups using the same access, one incident can damage both. At least one recovery copy should be protected from ordinary accounts and routine changes.
The organisation should know where copies are held, how access is controlled and how unusual deletion or encryption activity would be detected.
Test a real restore
A useful test restores a defined service into a safe environment and checks that people can use it. It records the time taken, missing information, manual steps and decisions required.
Small file restores are helpful for daily support, but they do not test the dependencies involved in a serious incident. Periodically test a complete critical service.
Include people and suppliers
Recovery often depends on specialists, credentials and supplier support. Ask who starts the process outside normal hours, who authorises emergency cost and what happens if a key employee is unavailable.
Confirm supplier response times and whether recovery help is included in the contract. An undocumented assumption about support can add hours or days during disruption.
Decide how the business will operate meanwhile
Some services cannot return immediately. Teams need simple alternatives for communicating, recording decisions, serving customers and protecting information while systems are unavailable.
These arrangements should be realistic, known to the people who will use them and tested alongside technical recovery.
Report recovery in business terms
Leadership reporting should show which critical services have been tested, the recovery time achieved, unresolved gaps and the person responsible for each action. A backup success percentage alone does not answer the board’s question.
The evidence to ask for
A credible recovery position includes a service priority list, documented backup coverage, protected copies, recent restore results, named roles and actions from the last exercise.
If that evidence is missing, begin with the most important service and run a controlled test. Finding a gap during an exercise is useful. Finding it during a live incident is expensive.