A backup nobody has restored is a theory, not a backup.
Almost every organisation we assess has backups running and green reports arriving. Far fewer have restored anything, and fewer still have restored under the conditions that would apply in a real incident. We test yours against your own recovery objectives and tell you what actually comes back.
- Restore testedNot a success report
- Against your RTOMeasured, not assumed
- Ransomware caseBackups are the first target
- We do not sell itThis is an audit of what you have
Eight questions, and a green dashboard answers none of them.
Has a restore actually been performed, and how recently?
This is the first question and it settles more than any other. A backup job succeeding proves data was written somewhere. It does not prove that data is readable, complete, consistent, or usable by the application it came from. The gap between those two things is where organisations discover, during an incident, that the thing they were paying for does not do what they assumed.
What are your recovery objectives, and does anyone know them?
The recovery point objective is how much data you can afford to lose, and the recovery time objective is how long you can afford to be down. Both should be business decisions, and in most organisations we assess neither has been decided, so the answer defaults to whatever the backup schedule happens to produce. Once they are set, the audit becomes concrete: does the system actually meet them.
Is everything that matters actually being backed up?
Scope drifts constantly. A new application arrives and nobody adds it. A server is rebuilt and the agent does not come back. Somebody moves data to a cloud service that has no backup at all. We reconcile what is protected against what the business actually depends on, and the gap is almost never zero and almost never known in advance.
Could ransomware reach and destroy your backups?
The most important change in this area over the last decade. Attackers now look for backups first, because destroying them removes your alternative to paying. A backup reachable with the same credentials that administer the systems it protects is not a safe backup. We look specifically at whether yours could be encrypted or deleted by somebody who has already compromised your environment.
Immutability, and whether it is real or configured on
Many platforms offer immutable or write-once retention, and enabling it is not the same as having it enforced against every path. We test the property that matters: can a backup within its retention period be deleted or altered by an administrator, by the backup software itself, or by somebody with access to the underlying storage. The answer is more often yes than people expect.
Copies, locations and the single point of failure
The widely used convention is three copies of your data, on two different types of media, with one held off site, and it endures because it addresses distinct failure modes rather than because any standard mandates it. What we look for is simpler than the formula: is there any single event, a fire, a failed storage array, a compromised administrator account, that takes out both your data and every copy of it.
Whether anybody notices when it stops working
Backups fail quietly. A job that has been failing for eleven weeks looks exactly like one that has been succeeding, unless somebody is reading the alerts. We check not just whether monitoring exists but whether a human acted the last time it fired, because an alert nobody responds to is indistinguishable from no alert at all.
Evidence, because auditors and insurers now ask
External financial auditors testing IT general controls, cyber insurers, enterprise clients and sector regulators all ask about backup, and increasingly they ask for evidence of a tested restore rather than for a policy. A documented restore test with dates, scope and results is a small artefact that answers a question you will otherwise be answering awkwardly.
Ransomware attacks your backups before it attacks your data.
A backup design that was entirely sensible ten years ago can be worthless today, because it was built to survive hardware failure and fire rather than an attacker who is already inside and specifically looking for it.
- The mechanism is simple. An attacker who reaches administrative credentials looks for the backup system, deletes or encrypts what it holds, and only then encrypts production. Removing your alternative is the point, because it is what converts an incident into a payment decision. This is why backup security now matters as much as backup coverage.
- The practical test is one question: could somebody holding your domain administrator credentials, right now, delete your backups. If the backup console authenticates against the same directory, if the storage is reachable from the same network with the same credentials, or if the retention can be shortened from within the console, then the answer is yes and the backup is not protecting you against the scenario that most threatens you.
- What changes the answer is separation and immutability: credentials that do not overlap with production administration, storage that cannot be reached with production credentials, and retention that cannot be shortened within the window even by an administrator. Most platforms support this. Far fewer estates have it configured, and fewer still have tested that it holds.
- The other thing worth testing is how long a clean restore actually takes when the environment you are restoring into is also compromised. Recovery in that situation is not restoring a file, it is rebuilding, and organisations that have only ever tested a single file restore have not tested the case that matters.
Four things that make this an audit rather than a sales call.
We will tell you when your existing setup is fine
Some estates we assess are in genuinely good shape and the honest report says so, with a couple of small improvements and no reason to change supplier. We would rather deliver that report than manufacture urgency, and we say up front that we also sell backup services so you can weigh our findings accordingly. An auditor who never reports a clean result is not auditing.
We restore something, we do not just read your configuration
A configuration review is worth having and it is not the same as evidence. The core of this engagement is performing an actual restore, into an isolated environment, timed, with the result documented. That is the artefact you can hand to an auditor or an insurer, and it is the only thing that answers the question the whole exercise exists to ask.
We test the compromise scenario, not just the hardware one
Most backup designs handle a failed disk perfectly well. Far fewer handle an attacker with administrative credentials, which is the scenario that actually threatens UAE businesses today. We test whether your backups could be reached and destroyed from a compromised production environment, because that is the failure mode that turns an incident into a payment decision.
You get evidence you can hand to somebody else
A dated record of what was restored, how long it took, what the recovery objectives were and whether they were met. That single document answers questions from external auditors testing IT general controls, from cyber insurers at renewal, and from enterprise clients doing supplier due diligence. Producing it once a year is much cheaper than improvising an answer each time.
Six situations where an untested backup becomes a real problem.
After ransomware hits a peer or a supplier
A rational and very common trigger. Somebody senior reads about a comparable UAE business losing a week of operations and asks whether we would be alright. The honest answer requires testing rather than reassurance, and the test is genuinely quick compared to the cost of being wrong. This is the best possible moment to do it, because the budget conversation is already won.
A cyber insurance renewal or application
Insurers ask increasingly specific questions about backup: frequency, isolation, immutability, and whether restores are tested. These are answered on a proposal form that you sign, which makes accuracy more than a matter of good practice. Establishing the real position before completing the form is straightforward and considerably better than discovering the gap at claim time.
An external audit that tests IT general controls
Backup sits inside IT operations for the purposes of a financial statement audit, and auditors have learned to ask for restore evidence rather than accepting backup success reports. A dated restore test performed during the period is a small artefact that closes this cleanly, and its absence is a routine finding.
A healthcare or regulated organisation
Sector frameworks treat information systems continuity as its own control area, and expect recovery to be evidenced against defined objectives rather than assumed. For entities working to ADHICS in Abu Dhabi or under national information assurance requirements, a tested restore is part of the evidence base rather than an optional good practice.
A business with operational technology or long-lived systems
Manufacturing, logistics and site-based operations often depend on systems that are old, poorly documented and impossible to rebuild from scratch, where the backup is genuinely the only route back. These are exactly the systems least likely to have been tested, because testing them is inconvenient, and most likely to fail when it is attempted.
After changing IT provider, or inheriting an estate
A new provider inherits a backup configuration built by somebody else, with assumptions nobody documented and a scope that may not match reality. An independent restore test at handover establishes what is actually true, and it protects both parties, because the alternative is discovering the previous arrangement was inadequate during an incident on your watch.
Backed up, protected, or recoverable.
| Feature | Recoverable | Backed up | Assumed |
|---|---|---|---|
Backup jobs run and report success | Probably | ||
Scope reconciled against business systems | Partly | ||
RPO and RTO decided by the business | |||
Full system restore tested and timed | |||
Backups survive an administrator compromise | Unlikely | ||
Immutability tested, not just enabled | |||
Recovery documented and not held by one person | Rarely | ||
Failures noticed and acted on | Eventually | ||
Evidence available for auditor or insurer | Policy only | ||
Outcome in a real ransomware event | Recovery | Uncertain | Payment decision |
The evidence people offer, and what it actually demonstrates.
| Evidence offered | What it actually proves | |
|---|---|---|
| Backup job success report | Data was written. Not that it is readable or complete | |
| Backup software dashboard is green | Jobs ran. Nothing about restorability | |
| A backup policy document | Somebody decided what should happen | |
| Retention is set to a long period | Intent. Not that the data is still there | |
| A single file was restored once | One file worked. Not a system, not an application | |
| The vendor says it is immutable | The feature exists. Not that it is enforced everywhere | |
| Backups replicate off site | A copy exists elsewhere. Not that it is recoverable | |
| A full system restore, tested and dated | That the system can be recovered | |
| A restore timed against your RTO | That you can recover fast enough | |
| A restore performed with production credentials revoked | That you can recover from a compromise |
Five stages, and the restore is the point of all of them.
- 1
Establish what recovery actually needs to achieve
Recovery point and recovery time objectives per critical system, decided by the business rather than inferred from the current schedule. This is a short conversation with real consequences, because it converts a vague expectation that things will be fine into a measurable target the rest of the audit can be judged against.
- 2
Reconcile scope against what the business depends on
What is being backed up, against what the business would actually need to operate. We work from the business side rather than the server list, which is how we find the cloud service nobody protects, the application added last year and never included, and the server rebuilt without its agent coming back.
- 3
Assess whether the backups would survive an attack
Credential separation, network reachability, immutability tested rather than assumed, retention that cannot be shortened within its window, and whether an offline or logically isolated copy genuinely exists. This is the section that most often produces a serious finding in an otherwise well-run estate.
- 4
Perform an actual restore, timed and documented
Into an isolated environment, at a scale agreed with you, measured against your stated recovery time objective. Where it is safe and useful we also test recovery under the conditions of a compromise, with production credentials treated as untrusted, because that is the scenario the plan is really for.
- 5
Report, fix, and leave you with the evidence
Findings prioritised by what would actually prevent recovery, with what to change and roughly what it takes. Plus the dated restore evidence for your auditor, your insurer or your clients. Where you want it we set a recurring test cadence, because a restore tested once and never again decays into an assumption within about a year.
What organisations ask about backup audits.
Fifteen questions to ask your own team this week.
Coverage and objectives
- What is your recovery time objective, and who decided it?If nobody decided, you do not have one, you have a schedule.
- What is your recovery point objective for each critical system?How much data you can afford to lose, per system.
- Is every business-critical system in the backup scope?Reconcile against what the business depends on, not the server list.
- Are cloud services and SaaS data backed up?Commonly assumed to be the provider job. Usually it is not.
- When did the scope last get reviewed against reality?Drift is guaranteed. New systems rarely get added.
Would it survive an attack
- Could a domain administrator delete your backups today?The single most revealing question on this page.
- Does the backup system authenticate separately from production?Shared identity means shared compromise.
- Is retention immutable within its window, even to an admin?Enabled is not the same as enforced. Test it.
- Is there a copy that is genuinely offline or logically isolated?Reachable from production is reachable by an attacker.
- Would you notice backups being deleted?Deletion is usually the first sign of a serious intrusion.
Could you actually recover
- When did you last perform a full system restore?Not a file. A system, end to end.
- How long did it take, measured rather than estimated?Compare it honestly to your stated RTO.
- Does anyone besides one person know how to do it?Recovery knowledge concentrated in one head is a risk.
- Is the recovery procedure documented somewhere reachable during an outage?A runbook on the server you are restoring is no runbook.
- Has a restore ever been evidenced for an auditor or insurer?They are increasingly asking for exactly this.
The pages around this one.
Disaster recovery and business continuity
The wider plan this audit tests one component of: what happens, in what order, who decides and how the business keeps operating.
IT general controls
Where backup evidence is tested for a completely different purpose, by your external financial auditor, on a fixed annual timetable.
IT audit services in Dubai
The wider audit practice, and how to tell which kind of engagement your situation actually calls for before anybody quotes for one.
Two questions for your team, and neither costs anything to answer.
When did we last perform a full restore, and could somebody with domain administrator credentials delete our backups today. If the answers are uncomfortable, a restore test is a short piece of work that replaces an assumption with a measured fact and leaves you with evidence you can hand to somebody else.
Related Services
Explore more solutions that work great with this service
Disaster Recovery & BC
Business continuity and disaster recovery planning
IT General Controls
What your external auditor tests, and the evidence they sample
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
Backup as a Service
M365, endpoint, server backup, immutable
Veeam Backup Dubai
Immutable repositories and tested, evidenced restores
Active Directory Audit
Privilege paths, service accounts and local admin passwords
Managed Security Services
MSS on Microsoft Defender XDR and Sentinel
NIST CSF 2.0 Assessment
Know where you stand, without committing to certification