The recovery time objective in the document is four hours. Nobody has ever measured how long it actually takes.
A disaster recovery audit compares the stated objectives against the demonstrated capability. That means examining what is protected, what is not, whether a restore has ever been performed end to end, and what the measured elapsed time was rather than the one somebody agreed in a workshop.
- Stated versus provenThe gap the audit measures
- What is not protectedReliably the largest finding
- Measured elapsed timeNot the objective in the document
- CIS Control 11Data recovery, in the eighteen
Seven questions, and the last three are the ones that matter.
What is protected, and what turns out not to be
The most common serious finding, and it is almost never deliberate. A system commissioned after the last review, a database moved to a new platform, a cloud workload assumed to be covered by the provider, a file share migrated during a project. Establishing coverage against the actual estate rather than against the protection configuration is the first step and it reliably produces the largest gap.
Whether the objectives were ever agreed with the business
Recovery time and recovery point objectives are business decisions expressed in technical terms. Where they were set by IT without the function that would suffer the outage, they tend to be either impossibly ambitious or quietly generous, and in both cases nobody outside IT has ever validated them. That conversation is part of the audit rather than an assumption behind it.
Whether anybody has measured the actual elapsed time
This is the central question. Not whether a restore has been tested, but whether one was performed end to end with the clock running, from the decision to recover through to the business confirming the system was usable. The measured number is frequently a multiple of the stated objective, and knowing the multiple is the entire value of the audit.
What a restore actually does to current data
Recovery mechanisms differ in ways that matter under pressure. Microsoft states, for example, that a full SharePoint site or OneDrive restore rolls back to the state at the prior point in time, overwriting all content and metadata created since. That is correct for a mass encryption event and wrong for recovering one deleted folder, and the runbook needs both procedures.
Dependency order, which is where recovery plans fail
Systems are recovered in an order determined by dependency rather than by importance. Identity before applications, database before application server, name resolution before anything. A plan that lists systems by business priority without expressing dependencies produces a recovery that stalls partway through while somebody works out what is missing.
Whether the recovery path survives the incident that caused it
A recovery mechanism reachable with the same credentials as production, on the same network, from the same directory, is not a recovery mechanism against a ransomware event. The audit examines whether the protected copies can be deleted or encrypted by an identity compromised in the primary environment, which is the specific scenario most plans were not written for.
Whether recovery depends on specific people
Documented well enough that somebody other than the person who built it could execute it. In practice most recovery capability lives in one or two heads, and the audit is frequently the first time anybody has tried to follow the written procedure without that person in the room. That test is uncomfortable and it is exactly the point.
Ask how long a full restore of your largest system would take. Then ask who measured it.
Almost every organisation has a stated recovery time objective. Very few have a measured recovery time, and the two are usually different by a factor rather than a margin.
- The stated objective is a target agreed in a document. The measured time is what happened when somebody performed the recovery end to end with the clock running. Only the second one tells you anything about what would happen in an incident.
- The measured time includes everything the objective usually excludes: the decision to invoke, locating the right restore point, the restore itself, dependency systems recovering in the right order, validation, and the business confirming the system is usable rather than merely running.
- Recovery duration also frequently depends on something other than data volume. Microsoft states for its own backup service that restore performance follows the number of protection units and the restore point type rather than the amount of data, with published median expectations ranging from thirty minutes for a single unit to a rate of protection units per hour at large scale.
- The audit produces the measured number. Where it exceeds the stated objective, and it usually does, the organisation then has a real decision to take: invest to close the gap, or change the objective to something honest. Both are legitimate. Continuing to publish an objective nobody has ever met is not.
Four things that make a recovery audit useful rather than reassuring.
We assess coverage against the estate, not the console
A protection console shows what is protected. It cannot show what is not, because it does not know about it. Comparing the protected list against the actual system inventory is how the gap appears, and it is reliably the largest and least expected finding in this audit.
We measure, because a stated objective proves nothing
The audit performs or observes a recovery end to end with the clock running, from the decision to invoke through to a business person confirming the system is usable. The resulting number is frequently a multiple of the stated objective, and having it converts an unresolvable argument into a specific investment decision.
We test the recovery path against the incident that would use it
The specific question is whether an identity compromised in production can reach, delete or encrypt the protected copies. Most recovery arrangements predate ransomware as the dominant scenario, and were designed for hardware failure and site loss where that question did not arise. It arises now and it is rarely asked.
We run the procedure with the usual person absent
Recovery capability that lives in one person head is a single point of failure that no amount of redundant infrastructure addresses. Asking somebody else to follow the written procedure, while the person who wrote it stays out of the room, is uncomfortable, quick and the most informative hour of the engagement.
Six UAE situations where the audit changes what the organisation believes.
A regulated firm with a stated recovery obligation
Where a regulator or a contract specifies recovery capability, the obligation is to demonstrate it rather than to document it. A measured recovery time from an observed test, with a business person confirming usability, is evidence. A recovery time objective in a policy document is a statement of intent, and the difference matters when it is examined.
A business whose exposure is hours rather than data
For retail, hospitality and logistics the cost of an outage accrues by the hour and is straightforward to quantify. That makes the gap between the stated and measured recovery time directly expressible in money, which is the version of this finding that reliably produces a decision rather than a discussion.
An operator where recovery order is genuinely complex
Production environments have dependency chains that nobody has fully written down: identity, name resolution, licensing servers, historians, control systems and the applications above them. A recovery plan that lists systems by business priority rather than dependency order will stall, and the audit is where that becomes visible cheaply.
An organisation whose estate has changed since the last review
Migrations, new platforms, cloud adoption and acquisitions all change what needs protecting, and protection configuration follows change slowly. Coverage verified against the current estate rather than against the last review consistently finds systems commissioned in the intervening period that nobody added.
A healthcare organisation with clinical systems in scope
Where recovery affects patient care, the validation question becomes clinical rather than technical: who confirms the restored system is safe to use, and on what basis. That decision has to be identified in advance and named in the procedure, because it cannot be improvised by an engineer during a recovery.
A business that has adopted a new backup product
New products change recovery mechanics in ways the runbook may not reflect. Microsoft, for example, states that a full site or account restore in its backup service rolls back to the prior point in time, overwriting content and metadata created since. That is the right behaviour after mass encryption and the wrong one for a single deleted folder, and both procedures need to exist.
How UAE organisations know whether they could recover.
| Feature | Audited and measured | Backups monitored, restores untested | Backups assumed to work |
|---|---|---|---|
Coverage verified against the estate | Yes | Against the console | No |
Objectives agreed with the business | Yes | Set by IT | None |
Full recovery performed end to end | Yes | No | No |
Elapsed time measured | Yes | No | No |
Dependency order documented | Yes | Partly | No |
Recovery copies isolated from production | Yes | Sometimes | No |
Procedure executable by somebody else | Yes | No | No |
Business validates the restored system | Yes | No | Not applicable |
Objective is honest | Yes | Unknown | No |
Position after a ransomware event | Known | Unknown | Poor |
Nine questions per system, and where organisations usually stop.
| Question | What a good answer looks like | |
|---|---|---|
| Is it protected at all? | Confirmed against the live estate, not against the protection console | |
| What is the recovery point objective? | Agreed with the business function, not set by IT alone | |
| What is the recovery time objective? | Agreed the same way, and expressed to the business in hours | |
| When was recovery last performed end to end? | A date, with a measured elapsed time attached | |
| What was the measured elapsed time? | A number, from decision to business confirmation | |
| What are the dependencies, and in what order? | A sequence, not a priority list | |
| Can the recovery copies be reached from production? | No, ideally, and demonstrably so | |
| Could somebody else execute the procedure? | Tested with the usual person absent | |
| Who confirms the system is usable? | A named business person, not the engineer who restored it |
Five steps, and one of them involves actually recovering something.
- 1
Build the system inventory from the estate, not the backup console
Every system that matters, with a business owner, drawn from the asset inventory, the application register, the network and whoever knows what runs where. Coverage is then assessed against that list. Everything protected but not on the list, and everything on the list but not protected, is a finding.
- 2
Establish the objectives and who agreed them
Recovery time and recovery point objectives per system, and whether the business function that would suffer the outage was involved in setting them. Where they were set by IT alone, that conversation happens now, because an objective the business has never validated cannot be assessed against anything meaningful.
- 3
Review the mechanism, the isolation and the dependency order
How recovery works per system, what a restore does to current data, whether recovery copies can be reached or destroyed by an identity compromised in production, whether retention is long enough for an incident discovered weeks later, and whether the recovery order reflects dependencies rather than business priority.
- 4
Observe or perform an end to end recovery, with the clock running
From the decision to invoke through to a named business person confirming the system is usable. Performed by somebody other than the person who designed the recovery, following the written procedure. The output is a measured elapsed time and a list of every point at which the procedure was insufficient.
- 5
Report the gap and give the organisation a real choice
Measured time against stated objective, coverage gaps, isolation weaknesses and procedural gaps, each with an owner. Where the measured time exceeds the objective, the recommendation is explicit: invest to close it or revise the objective to something honest. Both are defensible. Publishing an unmet objective is not.
What organisations ask about disaster recovery audits.
Fifteen things to have ready, and the gaps are the findings.
Documentation
- A list of systems with ownersThe audit starts from the estate, not the backup job list.
- Stated recovery objectives per systemAnd who agreed them.
- A written recovery procedureDetailed enough for somebody else to follow.
- A dependency mapOrder matters more than priority.
- The last test recordWith a date and a measured duration.
Technical position
- Coverage verified against the live estateNot against the protection configuration.
- Retention long enough for late discoveryIncidents are often found weeks later.
- Recovery copies isolated from production identityThe ransomware question.
- Immutability or equivalent protectionCan the copies be deleted, and by whom.
- Restore target capacity availableRecovering to where, exactly.
Operational reality
- Who declares a recovery?The same decision problem as incident response.
- Is the procedure accessible if systems are down?Not only on the file share.
- Has anybody executed it who did not write it?The real test.
- Who validates the restored system?A business person, not the engineer.
- When is the next test scheduled?Booked, not intended.
The pages around this one.
Ask when somebody last recovered a whole system and how long it took.
If the answer to the first is that individual file restores happen regularly, and the answer to the second is that nobody timed it, you have both of the findings this audit exists to produce. Neither is unusual and both are addressable.
Related Services
Explore more solutions that work great with this service
IT Infrastructure Audit
What you run, how much is supported, what fails
Backup and Restore Audit
We test whether your backups actually restore
DRaaS
Tested disaster recovery on Azure
Business Continuity Planning
BCP, RPO/RTO design, and DR runbook authoring
Disaster Recovery & BC
Business continuity and disaster recovery planning
Microsoft 365 Backup
Ten minute restore points, mass restore in hours
Veeam Backup Dubai
Immutable repositories and tested, evidenced restores
Ransomware Protection
Defender XDR and Sentinel-driven ransomware defense