Most businesses have backups. Fewer can prove they’ll work when needed.
A backup job showing “successful” only tells us that a copy was created. It doesn’t confirm that the copy is complete, usable, secure or quick to restore.
That distinction matters. Data may become unavailable after ransomware, accidental deletion, hardware failure, a failed update or a cloud service problem. When it does, we need more than a reassuring status message. We need a tested route back to normal working.
The National Cyber Security Centre (NCSC) recommends regular backups and regular restore testing. The Information Commissioner’s Office (ICO) also expects organisations to test recovery arrangements and keep them fit for purpose.
Here are seven questions every business should ask.
1. Do we know exactly where our backups are stored?
“Somewhere in the cloud” isn’t a recovery plan.
We should be able to identify where each backup is held, which systems it covers and how we access it. This may include:
- A local backup appliance or server
- An off-site cloud backup service
- External storage
- Virtual machine snapshots
- Backups for individual applications
- Copies held by a third-party provider
We also need to know whether the backup is in the same building, network or cloud account as the live data. If a fire, flood, power problem or ransomware attack affects the main environment, a nearby or connected backup may be affected too.
A simple backup register can help. For each system, record:
- What data is protected
- Where the backup is stored
- How often it runs
- How long copies are retained
- Who can access it
- How it can be restored
This gives business leaders a clear view instead of relying on assumptions. Our business IT support team can help review this information across servers, desktops, networks and cloud services.
2. Who owns the backup and recovery process?
A backup can fail quietly if nobody is responsible for checking it.
Ownership doesn’t have to sit with one internal IT employee. It may sit with a managed IT services provider, an internal team or a shared arrangement. What matters is that responsibilities are clear.
We should know:
- Who receives alerts when a backup fails
- Who checks backup reports
- Who approves changes to backup policies
- Who can start a restore
- Who decides which systems return first
- Who contacts suppliers or insurers during a major incident
- Who is accountable if a restore fails
It’s also sensible to avoid dependence on one person. If the only person who knows the backup password is unavailable, recovery may be delayed when every minute matters.
Access should be protected with strong passwords, multi-factor authentication and limited permissions. People who need to restore data may not need permission to delete every backup. Separating these roles reduces risk.
A reliable IT helpdesk should support this process, not simply wait for someone to report a problem.
3. When was the last time we tested a real restore?
This is the uncomfortable question.
If we’ve never restored a file, mailbox, application or server from backup, we don’t yet know whether the backup works. We only know that a backup task ran.
A sensible testing programme should include different levels of recovery:
- A small file restore to confirm everyday recovery works.
- A folder or mailbox restore to check user data.
- A critical application restore to confirm important business information is usable.
- A server or virtual machine restore to test a wider failure.
- A recovery exercise to check what happens during a serious incident.
The restored data should be checked by someone who uses it. Technical completion isn’t enough. A finance user should confirm that financial records open correctly. A department manager should confirm that documents and workflows are available.
The NCSC recommends checking that backups can be restored, not just that they exist. A test from two years ago is useful history, but it doesn’t prove that today’s environment is recoverable.
We should repeat tests after major changes, such as a new server, application, cloud service or backup platform.
4. How quickly can we restore, and how much data could we lose?
A working restore may still be too slow for the business.
We need to set realistic recovery expectations for important systems:
- How soon must email be available?
- How quickly must finance systems return?
- How long can staff work without shared files?
- Which systems can be restored later?
- How much recent data can we afford to lose?
These decisions are often described using two simple measures:
- Recovery Time Objective (RTO): how quickly a system needs to return.
- Recovery Point Objective (RPO): how much recent data we could lose.
For example, a business may decide that its finance system must return within four hours, while losing up to one hour of recent data is acceptable. That decision affects backup frequency, storage and recovery design.
During a restore test, we should record the time from starting the process to confirming that the system is usable. We should then compare the result with the agreed target.
If the business expects recovery within four hours but the last test took two days, the backup may be technically valid but operationally unsuitable. That gives us a clear improvement to make.
5. Are our backups off-site, separated and protected from ransomware?
Keeping a second copy in the same place as the first isn’t enough.
A resilient approach keeps at least one copy away from the main environment. It should also be protected from unauthorised changes or deletion.
Depending on the business, this may involve:
- Off-site storage
- A separate cloud account
- A separate network
- Offline backup media
- Immutable backup copies
- Version history and delayed deletion
- Restricted administrator access
An immutable backup is designed so that it can’t be changed or deleted during its protected retention period. This can help if an attacker gains access to the main network or an administrator account.
The NCSC’s ransomware-resistant backup guidance recommends designing backups to withstand destructive actions, retain earlier versions and support safe recovery.
We should also ask whether backup administration uses separate credentials. If the same account controls both live systems and backups, one compromised password may create a much larger problem.
No backup design removes every risk. The aim is to ensure that one incident can’t remove every recovery option.
6. Do our backups cover cloud applications?
Cloud services are not automatically the same as cloud backups.
Microsoft 365, Google Workspace, online accounting platforms, CRM systems and other SaaS applications may have retention or recovery features. These can be useful, but they may not provide the level of protection or control we expect.
We should check:
- Which cloud services are included
- Which data types are covered
- How long deleted data is retained
- Whether earlier versions can be restored
- Whether individual mailboxes, files or records can be recovered
- Whether configuration and user information are protected
- Where backup copies are stored
- Who controls the backup account
For Microsoft 365, for example, we shouldn’t assume that email, SharePoint, Teams, OneDrive, user accounts and settings all have identical recovery options.
The right question isn’t “Is Microsoft 365 backed up?” It’s “Can we restore the specific information the business needs, at the point in time we need it?”
A review of cloud applications should form part of wider managed IT services, especially when new applications are added without a central review.
7. Is the recovery process documented and regularly reviewed?
Recovery is harder when everyone is under pressure.
A short, clear recovery document gives the team something practical to follow. It should include:
- The systems covered
- The order in which systems should return
- Backup locations
- Access instructions
- Restore steps
- Supplier contact details
- Internal decision-makers
- RTO and RPO targets
- Data validation checks
- Escalation steps
- The date of the last successful test
The document should be stored somewhere available during an outage. If it only exists on the file server that is unavailable, it won’t help much.
After each test, record what happened:
- What was restored
- When it was tested
- How long it took
- Who checked the result
- What went wrong
- What needs to change
The process should be reviewed after major IT changes and at regular intervals. A recovery plan that matched the business three years ago may no longer cover its current systems.
Move from assumed recovery to proven recovery
Backups are important, but recoverability is the real measure.
If we can’t say where our backups are, who owns them, whether they’ve been tested, how quickly they can restore, whether they’re protected from ransomware, what cloud data they cover and where the recovery steps are documented, we have an assurance gap.
That gap is fixable.
Start with one critical system. Check its backup, run a restore test and record the result. Then work through the rest of the environment. This approach is more useful than buying another tool without checking whether the current one works.
Your IT Specialist provides impartial IT support, backup reviews and recovery guidance for businesses using Windows, Linux, virtualisation, networks and cloud applications.
We’ll ask the questions that are easy to postpone, then help turn the answers into a practical recovery plan.
Because the best time to discover a backup problem is during a controlled test : not during a business-critical outage.
