A backup dashboard showing green status is not evidence that the business can recover. It shows that scheduled jobs completed according to the configuration in place. A backup recovery review asks the harder operational question: if a cyber incident, deleted workload, failed server or site outage happens this week, can your organisation restore the right data, to the right location, within a timeframe the business can accept?
For corporate IT teams, that distinction matters. Recovery affects revenue, client service, regulatory obligations, legal records and staff productivity. The issue is rarely whether an organisation owns backup software. It is whether recovery requirements are defined, tested and owned across Microsoft 365, Azure, on-premise infrastructure and critical SaaS platforms.
What a backup recovery review should establish
A useful review is not a generic check of storage capacity or job history. It should connect technical recovery capability to the systems the organisation relies on to operate.
Start with the business services, not the backup tool. Finance, document management, line-of-business applications, file services, identity systems, collaboration platforms and customer-facing services can each have very different recovery priorities. A two-hour outage in a document repository may be manageable for one team, while an unavailable application database may stop operations immediately.
The review should establish three things. First, what data and systems are protected. Secondly, what recovery point and recovery time each workload requires. Thirdly, whether people, access rights, infrastructure and documented procedures are in place to deliver that recovery under pressure.
Recovery Point Objective, or RPO, is the maximum acceptable amount of data loss measured in time. Recovery Time Objective, or RTO, is the maximum acceptable time to restore service. These are business decisions with technical consequences. A requirement to lose no more than one hour of transactions and resume service within four hours demands a different design from a workload that can be restored the following day.
A backup recovery review is not a backup status report
Many organisations receive automated reports confirming successful backups. Those reports remain useful, but they do not answer whether an application can be recovered in a clean, usable state.
A recovery review tests the complete chain. Is the protected data consistent? Is the restore point available? Can authorised staff access the backup platform during an identity or tenant issue? Is there sufficient network capacity and compute resource at the recovery destination? Does the application require a particular restore sequence? Can business users validate that the restored information is current and usable?
The distinction becomes more significant during ransomware response. An attacker may have access to production systems for some time before detection. Restoring the latest backup without validation can reintroduce encrypted, altered or compromised data. Teams need a process for selecting an appropriate restore point, isolating recovered systems, checking for signs of compromise and obtaining application-owner approval before returning services to use.
Immutable or protected backup copies can materially improve resilience against deletion and encryption attempts, but they are not a complete recovery strategy. Retention settings, privileged access controls, separation of duties, monitoring and recovery testing still determine whether those copies are genuinely useful in an incident.
Microsoft 365 requires its own recovery decision
Microsoft 365 provides service availability, retention features and recycle bins that can address certain accidental deletion and governance scenarios. These capabilities should not automatically be treated as an independent backup and recovery plan.
The right approach depends on the data, the retention configuration, legal or contractual needs, recovery granularity and the consequences of losing SharePoint, OneDrive, Exchange or Teams content. Native retention is designed around Microsoft 365 governance and lifecycle controls. An independent backup service may be required where the organisation needs separate copies, longer retention, more flexible recovery options or clearer operational control.
A review should map the actual Microsoft 365 configuration rather than relying on assumptions. Confirm what is retained, for how long, who can restore it, what happens when accounts are removed, and whether the organisation can recover content at the required level of detail. Security, compliance and licensing decisions should be considered separately from backup requirements.
Azure and on-premise recovery need different runbooks
Azure workloads may involve virtual machines, managed databases, storage accounts, application configurations, identities and network dependencies. Restoring a virtual machine alone may not restore a business service. Infrastructure-as-code, configuration management and documented dependencies can be as important as the backup copy itself.
On-premise environments introduce further considerations: replacement hardware, hypervisor capacity, network configuration, site access and the availability of specialist application support. Where a secondary location or cloud recovery environment is intended, confirm that it has been designed, funded and maintained for the expected workload.
A practical runbook should state what is restored first, who makes the decision to begin recovery, who has administrative access and how the business confirms success. It should not live solely with an individual engineer or supplier contact.
Questions that expose recovery gaps
A focused review will usually identify gaps faster than a long technology inventory. Ask whether each critical system has a named business owner and an agreed RTO and RPO. Confirm whether the backup platform uses separate administrative credentials, whether recovery documentation is current, and whether an attacker with domain or tenant administration could affect backup copies.
Then look at restore evidence. Has the organisation restored a representative file, mailbox, database, virtual machine and application service recently? Was the result validated by the application owner? Were timings recorded? A successful file restore does not prove that a complex application can be recovered within the required window.
It is also worth testing uncomfortable scenarios. What happens if the primary identity service is unavailable? What happens if the backup administrator is on leave? Can a critical SaaS data set be recovered without waiting for a vendor support process? What happens if a recovery requires large volumes of data over a constrained connection?
These questions are not designed to create unnecessary complexity. They establish where the recovery plan depends on assumptions that have never been tested.
Turn review findings into a recovery programme
The output should be a prioritised action plan, not an unread technical report. Critical systems with no proven restore path should be addressed first. For other workloads, the organisation may decide that existing retention, manual rebuild processes or longer recovery targets are proportionate to the business impact.
Typical actions include defining service tiers, correcting backup scope, adding protected copies, separating backup administration, documenting application dependencies and scheduling recovery exercises. The exercise should involve IT, security, application owners and relevant operational leaders. Finance and procurement teams should also understand the cost of the desired recovery objective, because tighter recovery targets can require additional storage, licences, infrastructure and engineering capacity.
Illustrative workflow: an organisation identifies its finance platform, document repository and customer service systems as priority services. IT maps their dependencies, agrees RTO and RPO targets with business owners, verifies backup coverage and performs controlled restores. Results show that the data is available but the recovery sequence is undocumented. The resulting plan addresses runbooks and test frequency before committing to further technology spend.
Testing should be scheduled rather than triggered only after an audit or incident. The right frequency depends on change rate, business criticality and regulatory expectations. Major platform changes, acquisitions, new sites and application upgrades should prompt a targeted review because they can change backup scope and recovery dependencies.
Establish clear service ownership
Recovery fails when responsibility is fragmented. Internal IT may own production systems, a managed provider may operate backups, an application vendor may control database support, and business teams may own validation. Those roles can work well, but only if the hand-offs are explicit.
WestTech can assess backup and recovery arrangements across Microsoft 365, Azure, SaaS and on-premise environments, then help organisations define a practical remediation and testing plan. Service scope, onsite engineering and out-of-hours coverage should be agreed around the locations, workloads and recovery objectives that matter to the engagement.
If your organisation has never timed a full recovery of a critical service, arrange a recovery review before the next disruptive event turns an assumed capability into a business interruption.
