Start here
An untested recovery plan is not a plan
Most UAE companies have a disaster recovery document. Far fewer have ever proved it works. The gap between the two is where the damage happens: the backup that has been failing silently for eleven weeks, the failover runbook that still names an engineer who left in 2023, the recovery step that quietly depends on a licence key stored on the server that just died.
A disaster recovery drill closes that gap. It is a controlled rehearsal in which you simulate a failure, execute your recovery procedure, time it, and write down everything that went wrong while the stakes are still zero. Every issue you find in a drill is an issue you do not find at 03:00 on a Sunday with the finance team locked out of the ERP.
This guide covers the full cycle: the objectives to set, the systems to test, the people to involve, a worked Dubai example, the UAE compliance expectations, and a checklist you can run against next quarter.
RTO and RPO, in plain language
RTO: how long you can be down
Recovery Time Objective is the maximum time a system can stay offline before the business starts taking real losses. If your clinic booking system has a 4 hour RTO, it must be usable again within 4 hours of the outage being declared. RTO drives your technology spend: sub-hour targets need replication and orchestrated failover, not a nightly tape.
RPO: how much data you can lose
Recovery Point Objective is the maximum acceptable data loss, measured in time. A 15 minute RPO means you must be able to restore to a copy no older than 15 minutes, so you need snapshots or replication at least that often. If you back up once a night, your real RPO is up to 24 hours of invoices, patient records and orders, whatever the policy document claims.
That is not a failed drill. That is the drill doing its job. You now have a choice backed by evidence: invest to close the gap, or agree a realistic target with the business and stop pretending.
The five kinds of DR test, and what each one proves
| Test type | Disruption | What it actually proves | Typical effort |
|---|---|---|---|
| Checklist review | None | That contact lists, runbooks, asset inventory and vendor escalation paths are current | 1 hour |
| Tabletop exercise | None | Decision-making, escalation, who declares a disaster, what you tell customers | 90 minutes |
| Backup restore test | None (isolated sandbox) | That the backup is complete, readable and usable, and that RPO is real | Half a day |
| Parallel test | Low | That the DR environment runs the application correctly while production stays live | 1 day |
| Full failover | High | The whole thing: RTO, RPO, network, identity, dependencies, people, and failback | Planned weekend |
These form a ladder, not a menu. A team that has never run a tabletop should not open with a live failover. Climb one rung per quarter and each test builds on the fixes from the last one.
The process
How to run a disaster recovery drill, step by step
Eight stages. The first four take longer than the drill itself, which is exactly the point: a good drill is mostly preparation, and the execution window is short, timed and boring.
-
Stage 1
Pick one scenario and one scope
Name the failure: ransomware encrypts the file server, the Bur Dubai office loses power for 12 hours, the primary Azure region is unavailable, the finance database is corrupted by a bad update. Then name the systems in scope. One scenario, two or three systems. Broad drills produce confusion, not evidence.
-
Stage 2
Write the success criteria before you start
Target RTO and RPO per system, plus the functional checks that count as "recovered": users can log in, a test invoice posts, email sends and receives, the shared drive opens. Agree these in writing with the business owner, not the IT team alone.
-
Stage 3
Assign roles and a rollback plan
Every drill needs an incident commander who can call it, a scribe who timestamps every action, technical leads per system, and a business observer. Decide up front what triggers an abort, and how you get back to normal if it does.
-
Stage 4
Freeze changes and notify
Put a change freeze on the systems in scope for the drill window. Tell the service desk, the affected departments, and any vendor whose support you may need. A drill that surprises your own helpdesk generates real tickets and real panic.
-
Stage 5
Execute, and let it fail
Start the clock. The team follows the runbook exactly as written, with no shortcuts and no help from the one engineer who "just knows". If a documented step does not work, that is the finding. Do not fix it live and pretend it never happened.
-
Stage 6
Capture evidence as you go
Timestamps for declaration, first action, service restored, and full validation. Screenshots of the restored system. The scribe's log of every deviation. Without timestamped evidence, you cannot prove RTO was met and an assessor will not accept the drill as tested.
-
Stage 7
Fail back cleanly
Returning to the primary environment is a procedure in its own right, and it is the step teams skip. Test it. Reconcile any data written during the drill, confirm replication has resumed, and verify monitoring is pointing at the right place again.
-
Stage 8
Run the review within 48 hours
While memory is fresh. What was met, what was missed, what surprised you, and one named owner plus a due date for every gap. A review that produces no owners produces no improvement.
Scope
Which systems to test first
Rank by what stops revenue, care or compliance within a working day. Then test top-down. Most SMEs find their real Tier 1 list is shorter than they assumed, and that one forgotten dependency sits underneath all of it: identity.
- Identity and access (Entra ID / Active Directory, MFA, conditional access)
- Email and collaboration (Microsoft 365, Exchange, Teams, SharePoint)
- ERP, accounting and the finance database
- Line-of-business apps (HIS/EMR, LMS, POS, CRM)
- File servers and shared drives
- Cloud workloads and their region failover (Azure, AWS, Huawei Cloud)
- The backup platform itself, restored into a sandbox
- Network, firewall rules, VPN and site-to-site links
- Telephony, and the number customers actually call
- DNS, certificates and licence servers
- Physical access: door controllers, CCTV, server room cooling
- The out-of-band comms channel you will use when email is down
Two of these deserve a specific flag. Identity is the dependency nobody lists and everything needs: if directory services do not come back, nothing else logs in. And the backup platform is a system that must itself be recovered, which is why a restore into an isolated environment belongs in every drill. If you have never restored from your cloud backup into a clean environment and watched an application start, you have a backup job, not a recovery capability.
People
Who needs to be in the room
A drill run only by the IT team tests only the IT team. The failures that hurt most in a real incident are handoffs: who authorises the failover, who tells the customers, who decides the branch stays closed.
If your day-to-day support sits with an external provider under an IT AMC, that provider is not an observer. They hold half the runbook, so they take a seat and an action list like everyone else.
Incident commander
One person, senior enough to declare the disaster, authorise the failover and abort the drill. Not the person doing the technical work.
Scribe
Timestamps every action and every deviation. This log is your RTO evidence and, later, your audit artefact. The role sounds junior. It is not.
System owners
One named engineer per system in scope. Rotate them between drills so recovery knowledge does not live in a single head that might be on leave.
Communications lead
Drafts and sends the holding message to staff, customers and, where required, the regulator. Test the message, not just the mailbox.
Business observer
From finance, clinical operations or the branch, whoever bears the loss. They confirm the system is genuinely usable, not just pingable.
Vendors and MSP
Cloud provider, ISP, application vendor, managed service partner. If their SLA is part of your RTO, their response time is part of your drill.
How often to run drills
Tier 1, quarterly
Systems that stop revenue or care within hours. Quarterly tabletop or restore test, plus one full failover a year.
Tier 2, twice a year
Systems you can work around for a day. Restore tests and walkthroughs, no production disruption needed.
Tier 3, annually
Archives, internal reporting, low-impact tools. A documentation check and a spot restore is enough.
After every change
New ERP, cloud migration, office move, new branch, new MSP. Any of these invalidates the last drill's result.
A UAE scheduling note that matters more than it sounds: pick the window with the calendar in front of you. Friday to Sunday is the natural low-traffic slot for a disruptive failover, but avoid running one against a month-end close, during reduced Ramadan working hours, or in the week either side of a public holiday when half the team and most vendor support desks are thin. Announce the window a fortnight ahead.
A realistic drill: ransomware in a Dubai office
A 60-person company across two Dubai sites. Microsoft 365 for email, an on-premise ERP with a SQL database, a file server, and cloud backups replicated to a second region. Stated targets: 4 hour RTO and 1 hour RPO for the ERP. This is a half-day functional drill run on a Saturday, and it is the shape of exercise most SMEs should be running before they attempt anything larger. The scenario is deliberately the most probable one, which is why it pairs well with a broader read on protecting a Dubai business against ransomware.
-
09:00
Injection
The facilitator declares: overnight, ransomware encrypted the file server and the ERP database. Backups from the last 48 hours are assumed suspect. The team may not use the production ERP for the rest of the exercise.
-
09:10
Declaration and comms
The incident commander declares a disaster and the comms lead sends a holding message. First finding: the staff distribution list lives on the mail platform, and nobody has an offline copy of mobile numbers.
-
09:30
Isolate and identify a clean restore point
The team isolates the affected segment and picks a recovery point older than the assumed dwell time. Second finding: choosing that point takes 40 minutes because nobody has ever mapped backup retention against incident timelines.
-
10:10
Restore the ERP into a clean environment
Database restored into an isolated network that mirrors production subnets. Third finding: the application server needs a licence reactivation that requires a portal login held by one person, who is on annual leave.
-
12:45
Validation by the business
Finance logs in, posts a test invoice, runs a report. It works. Elapsed time from declaration to business validation: 3 hours 35 minutes. RTO met, with less headroom than anyone expected.
-
13:15
RPO check
The restore point is 55 minutes before the simulated encryption. RPO met on paper. But the file server replicates only every 6 hours, so the same incident would have cost most of a working day of documents. That system's stated RPO was never real.
-
13:45
Debrief
Four findings, four owners, four due dates. The drill "passed" on its headline metric and still produced a month of remediation work. That is a good drill.
What most UAE companies get wrong
- The DR plan was written for a tender, approved, and never opened again.
- Backups are monitored for job success, never for restore success.
- The drill is announced, rehearsed and run by the same two engineers who wrote the runbook.
- Microsoft 365 is assumed to be "backed up by Microsoft", so it is never in scope.
- Findings are logged in a document with no owner and no due date.
- Nobody tests failback, so the drill ends with production in a half-migrated state.
- The MSP is expected to handle it, but the contract never defined a recovery time.
- Recovery depends on one person, one laptop, and one licence portal password.
- The plan is a living document, versioned, and updated after every drill.
- Every quarter, one real restore into a sandbox, validated by the business.
- Roles rotate, so recovery knowledge is not a single point of failure.
- Cloud workloads and SaaS data are explicitly in scope with their own RPO.
- Findings become tickets with a name and a date attached before the room empties.
- Failback is timed and rehearsed like any other stage.
- Recovery targets are written into the service contract and tested against it.
- Credentials, runbooks and licence keys are held out-of-band and offline.
One structural mistake underlies most of the left column: treating recovery as an in-house side project with no dedicated capacity. That is the practical case for Disaster Recovery as a Service, where replication, orchestration and the DR target environment are run as a service with contractual recovery objectives, and drills become a scheduled routine rather than an event nobody has time for.
Compliance
UAE compliance: what assessors actually ask for
International DR guides talk about SOX and FFIEC. Neither is what a UAE assessor will open your file to. Which framework applies depends on your sector, your emirate and your clients, and most mid-sized UAE organisations end up inside two or more at once. If you are still mapping which ones bite, start with the cybersecurity frameworks that apply to UAE businesses.
The consistent thread across all of them: business continuity and recovery capability must be documented, tested, and evidenced. A policy PDF with no test record behind it does not satisfy anyone.
UAE Information Assurance Regulation / NESA IAS
The federal baseline for critical infrastructure and government-adjacent entities, and increasingly a pre-qualification condition in tenders. Business continuity controls require a business impact analysis, defined RTO and RPO, and tested BCP and DR plans. Assessors expect dated test evidence, typically from within the last twelve months, not the plan alone.
DESC ISR (Dubai)
Applies to Dubai government entities, semi-government bodies, and the suppliers and cloud providers that serve them. Business continuity sits among its security domains, and supply-chain requirements mean private companies selling into Dubai government are increasingly asked to demonstrate their own alignment as a contract condition.
Sector standards: healthcare, finance, education
Abu Dhabi healthcare providers work to ADHICS. Banks and financial institutions answer to CBUAE technology-risk expectations, and DIFC firms to DFSA. The recovery obligation is the same in every case: prove the systems that hold patient or client data can be brought back, and show when you last proved it.
UAE PDPL and data residency
Personal data of UAE residents carries protection obligations wherever it is processed, and that includes the copy sitting in your DR environment. Two practical drill questions: where does the failover region physically hold the data, and is the recovered environment protected to the same standard as production, with encryption, access control and logging intact?
Design the drill so that its output doubles as audit evidence: a dated test report, the scribe's timestamped log, the RTO and RPO results against target, the findings register with owners, and the sign-off. Collect it during the drill, because reconstructing it afterwards is painful and unconvincing.
How to tell whether the drill passed
| Measure | What you record | Pass condition |
|---|---|---|
| Recovery time | Minutes from declaration to business validation, per system | Within target RTO |
| Data loss | Age of the restore point actually used | Within target RPO |
| Functional validation | Business user completes a real transaction in the recovered system | Confirmed by the owner |
| Runbook accuracy | Number of documented steps that failed or needed improvisation | Every deviation logged |
| Team readiness | Whether the drill ran without the one person who "always does it" | No single point of knowledge |
| Communication | Time to first holding message, and whether it reached everyone | Within the agreed window |
| Failback | Clean return to primary, replication resumed, no data reconciliation left open | Completed and verified |
| Remediation | Findings with a named owner and a due date | 100% assigned |
A drill that finds nothing is not a triumph, it is a warning that the scenario was too gentle. Score the drill on what it taught you, then make the next one harder: remove a key person, take the primary internet link down, assume the last two backups are compromised.
Print this
Disaster recovery drill checklist
Run it top to bottom. Anything you cannot tick is either a drill finding or a reason to postpone the drill until you can.
Before the drill
- Scenario chosen, written down, and realistic for your risk profile
- Systems in scope listed, with target RTO and RPO for each
- Success criteria and functional checks agreed with the business owner
- Roles assigned: incident commander, scribe, system owners, comms, observer
- Runbooks printed or stored somewhere that survives the scenario
- Abort criteria and rollback plan agreed
- Change freeze in place for the drill window
- Service desk, affected departments and vendors notified of the window
- Isolated test environment prepared, with network parity to production
- Evidence capture ready: log template, screenshots, clock synchronised
During the drill
- Declaration timestamped, clock started
- Runbook followed exactly, no undocumented shortcuts
- Every deviation, delay and failure logged as it happens
- Holding message sent through the out-of-band channel
- Restore point identified and its age recorded
- Business user validates the recovered system with a real transaction
- Failback executed and verified, replication resumed
After the drill
- Review held within 48 hours, while detail is fresh
- Actual RTO and RPO recorded against target, per system
- Findings register created, each with an owner and a due date
- DR plan, runbooks and contact lists updated with what you learned
- Test report signed off and filed as compliance evidence
- Next drill scheduled, with a harder scenario
The post-drill action plan: first 30 days
Days 1 to 2
Hold the review. Publish actual RTO and RPO against target. Convert every finding into a ticket with a name and a date. No ticket, no fix.
Days 3 to 7
Close the cheap gaps immediately: stale contact lists, wrong credentials, missing licence keys, undocumented steps. These cost nothing and cause most of the delay.
Days 8 to 21
Tackle the structural gaps: replication frequency, DR region capacity, orchestration, and any RTO target the drill proved to be fiction. Take the budget case to the board with the drill data attached.
Days 22 to 30
Re-test the specific steps that failed, not the whole drill. File the signed test report. Book the next drill in the calendar before this one fades.
Six tips from engineers who run these drills
- Run it during working hours. A 2am failover on an empty network hides the problems that only appear when 60 people try to log in at once.
- Remove your best engineer from the room. If the drill only succeeds when one specific person is present, you have documented a dependency, not a capability.
- Keep an offline copy of everything you need to recover. Runbook, contact list, licence keys, vendor account numbers. If it only exists on the system you are recovering, it does not exist.
- Measure to the business, not to the ping. A server that responds is not a recovered service. The clock stops when finance posts an invoice, not when the VM boots.
- Test the vendor, not just the technology. Raise a real ticket during the drill and time the response. Your RTO includes their SLA whether you planned for it or not.
- Change the scenario every time. A team drilled only on ransomware becomes very good at ransomware and helpless in a regional cloud outage.
FAQ
Questions we get asked
The practical questions that come up when a UAE business schedules its first drill.
How often should we run a disaster recovery drill?
At an absolute minimum, once a year, and most UAE assessors will want to see evidence of a test within the last twelve months. In practice, tier your systems: quarterly exercises for anything that stops revenue or patient care within hours, twice-yearly for systems you can work around for a day, annually for the rest. Also drill after any major change: a cloud migration, a new ERP, an office move, or a change of IT provider all invalidate your last result.
What is the difference between a tabletop exercise and a full failover test?
A tabletop is a discussion. The team sits in a room, works through a scenario, and explains what they would do at each step. Nothing is touched, nothing breaks, and it usually takes about 90 minutes. A full failover actually shifts production to the recovery environment and runs the business from there before failing back. It is the only test that truly proves your RTO, and it carries the most risk, so it belongs at the top of a testing ladder rather than at the start.
Can we run a drill without disrupting production?
Yes, and you should start that way. Checklist reviews, tabletop exercises, backup restores into an isolated sandbox and parallel tests all validate real parts of your recovery capability without touching live systems. Cloud platforms make this straightforward: you can spin up a test failover into an isolated network that mirrors your production subnets, verify the applications come up, and tear it down afterwards.
What is a realistic RTO and RPO for a UAE SME?
There is no universal number, because the right target is the one the business can afford to miss. Work it out backwards: how much revenue, clinical capacity or contractual penalty does an hour of downtime cost, and how much data can you re-enter by hand? A finance system might justify a sub-hour RTO with continuous replication, while an internal reporting tool can happily sit at 24 hours. The mistake is copying an aspirational number from a template and never testing it.
Which UAE regulations require disaster recovery testing?
It depends on your sector and your clients. The UAE Information Assurance Regulation and the NESA Information Assurance Standards cover critical infrastructure and increasingly appear in government tender pre-qualification. Dubai government entities and their suppliers face DESC ISR. Abu Dhabi healthcare providers work under ADHICS, banks under CBUAE technology-risk expectations, and DIFC firms under DFSA. All of them share the same core demand: a documented, tested recovery plan with defined RTO and RPO, backed by evidence of an actual test. The UAE PDPL adds obligations around the personal data sitting in your recovery environment.
Who should take part in the drill?
An incident commander with authority to declare and abort, a scribe who timestamps everything, a named owner for each system in scope, a communications lead, and a business observer who confirms the recovered system is genuinely usable. If an external provider handles your day-to-day support, they participate too, because they hold part of the runbook and their response time is part of your recovery time.
What happens if the drill fails?
Then it worked. A drill that misses its RTO has told you something a policy document never would, and it has told you at zero cost. The failure mode to worry about is the drill that passes with no findings, which usually means the scenario was too soft or the team quietly worked around the runbook. Record the gap, assign owners, fix it, and re-test the specific steps that broke.
Pick a date before you close this page
The drill you keep meaning to schedule is the one that never happens. Choose one system, one scenario and one Saturday morning, and run the checklist above. The first drill will be uncomfortable. That is the whole value of it.
