Business Continuity and Disaster Recovery in the UAE: A Practical Guide

Frequently asked questions

• What is a recovery time objective in plain English?

  It is how long your business can be without a system before the damage becomes serious. NIST describes it as the maximum amount of time a system can remain unavailable before there is an unacceptable impact on the business processes it supports. If you decide two days of downtime is survivable for a particular system, that system has a two day recovery time objective. Anything faster to recover costs more to build and more to run.

• What is a recovery point objective in plain English?

  It is how much recent work you can afford to lose. NIST describes it as the point in time, before the outage, that your data can be recovered back to using the most recent backup copy. If your system backs up once a night and it fails at four in the afternoon, your recovery point objective is effectively last night, and everything entered today is gone. Shortening that gap means backing up more often, which costs more.

• What is the difference between a recovery time objective and a recovery point objective?

  One is about time and the other is about data. The recovery time objective answers how long until we are working again. The recovery point objective answers how much recent work disappears when we get there. A system can have a short recovery time and a long recovery point, or the reverse. You set both separately, and you set them separately for each system, because not every system deserves the same treatment or the same budget.

• Why do these two numbers decide what disaster recovery costs?

  Because they decide the technology, and the technology decides the bill. A one day recovery time with a one day recovery point can usually be met with a nightly backup and a documented rebuild. An hour of recovery time with almost no data loss needs continuous replication and standby capacity running all the time, whether you use it or not. NIST publishes a cost curve for exactly this reason. Faster recovery is not a setting, it is a spend.

• Is having a backup the same as being able to recover?

  No, and this is the single most common gap we find. A backup is a copy of data sitting somewhere. Recovery is the proven ability to get that data back into a working system, in the right order, within a time you have agreed is acceptable. The only thing that turns the first into the second is a restore test that someone actually performed. Everything else is an assumption with a green tick next to it.

• Why do untested backups fail when you finally need them?

  Because a backup job reports on itself, not on the restore. The job can finish successfully while the data inside it is incomplete, corrupted, already encrypted by an infection that started weeks earlier, or written in a format your current hardware and software cannot read back. None of that shows up on a dashboard. It shows up on the worst day of your year, at the moment you have the least time to work around it.

• What does CISA actually recommend for backups?

  The joint CISA, FBI and MS-ISAC ransomware guide is direct about it. Keep offline, encrypted backups of critical data, and regularly test the availability and integrity of those backups in a disaster recovery scenario. Offline matters because attackers hunt for reachable backups and delete or encrypt them first, often using stolen credentials or unpatched backup software to reach them. Testing matters because it is the only evidence the copy is usable.

• Is the 3-2-1 backup rule an official government standard?

  No. It is a widely used industry rule of thumb, and it is a reasonable one, but it is not published by CISA or NIST. A full text search of the CISA ransomware guide and of NIST Special Publication 800-34 finds no mention of it. Use it as a memory aid if it helps you, but do not present it to a client or an auditor as a government requirement, because it is not one.

• Are cloud backups automatically safe from ransomware?

  Not automatically. CISA warns that automated cloud backups may not be sufficient, because if an attacker encrypts your local files, those encrypted files can sync to the cloud and overwrite the good copies already there. Sync keeps two places identical, which is exactly the wrong behaviour during an attack. A backup needs to be separate and versioned, so that yesterday still exists after today has been ruined.

• What are immutable backups and are they recommended?

  Immutable storage cannot be changed or deleted for a set period, even by an administrator account. CISA notes that some cloud vendors offer immutable storage that protects stored data without needing a separate environment. It also cautions that immutability does not automatically satisfy every compliance regime and that misconfiguration can be expensive. It is a strong control when it is set up deliberately, and an expensive surprise when it is switched on without thought.

• Why do ransomware attackers go after backups first?

  Because your backup is the reason you might not pay them. CISA states that most ransomware actors try to find and then delete or encrypt any accessible backups, so that restoration is impossible unless the ransom is paid. They collect credentials from the environment and use them against the backup system, and they exploit backup software that has not been patched. Anything reachable from the network they have compromised should be assumed reachable by them.

• How often should we test a restore?

  NIST makes testing, training and exercises step six of its seven step contingency planning process, and says testing is what validates recovery capability while exercises expose gaps in the plan. It does not set a universal frequency, because the right interval depends on how critical the system is and how quickly it changes. What matters is that the interval is written down, owned by a named person, and short enough that the plan never drifts far from reality.

• What is the difference between a business continuity plan and a disaster recovery plan?

  NIST separates them clearly. A business continuity plan focuses on sustaining the organisation's business processes during and after a disruption, so it covers people, suppliers, premises and communication. A disaster recovery plan is the IT specific one, aimed at major disruptions that deny access to the primary infrastructure, and at restoring systems at an alternate site. Most small businesses need both, but they usually start with the IT half because that is where the immediate pain sits.

• What is ISO 22301?

  It is the international standard for a business continuity management system. It sets out a framework for planning, implementing, operating, reviewing and improving a documented system for protecting against disruption and recovering from it. It applies to organisations of any type, size or complexity, so it is not written only for large enterprises. You can follow its structure to build a sensible plan without ever going through a certification audit.

• What is ISO 27031 and how does it differ from ISO 22301?

  ISO/IEC 27031 is the information and communications technology companion to ISO 22301. It covers what the standard calls ICT readiness for business continuity, meaning the technical side of keeping systems available and recoverable. It uses the same improvement cycle as ISO 22301 and is positioned to work alongside ISO/IEC 27001 for information security. In practice, ISO 22301 is the business plan and ISO 27031 is the systems plan underneath it.

• Do I need ISO 22301 certification to have a good continuity plan?

  No. Certification is optional and is mostly pursued when a client, an insurer or a tender asks for evidence in that specific form. The framework itself is useful whether or not you certify, and a business with clear objectives per system and a restore it has actually tested is in better shape than one with a certificate and an untested backup. Certify when someone is asking for it, not as a substitute for the work.

• Is there a UAE law requiring my business to have a continuity or disaster recovery plan?

  Not a general one for ordinary private companies. The UAE National Information Assurance Framework states that compliance is mandatory for all UAE government entities and for other entities identified as critical by NESA, and that for all other UAE entities the guidelines are highly recommended on a voluntary basis. So an ordinary Dubai trading company is not under a legal continuity mandate. The commercial risk of being down for a week is unchanged by that.

• Does the UAE Central Bank require banks to have continuity plans?

  Yes. The Central Bank of the UAE Rulebook requires a bank to have disaster recovery and business continuity plans in place so it can keep operating and limit losses during a severe business disruption, sized to the bank's risk profile, nature, size and complexity. It also requires the board to ensure a periodic independent review of those plans. This is a binding obligation on licensed banks, and it does not extend to businesses in general.

• Does Dubai's DESC require continuity plans from private businesses?

  Only from organisations it designates as critical information infrastructure. The Dubai Electronic Security Centre describes an initiative to identify those organisations so that it can ensure they all have proper business continuity and disaster recovery systems in place. If your business has been designated, you will know, because designation comes with direct engagement. For everyone else in Dubai, DESC's continuity expectations are not a licensing condition.

• Does UAE data protection law require backups to be stored inside the country?

  The official UAE government portal page on data protection law does not state a residency requirement, and it does not set out any backup specific obligation. It confirms that the Personal Data Protection Law applies to processing of personal data inside or outside the country and that it governs cross border transfer. That is a negative finding worth stating plainly, because plenty of sales material implies a residency rule that the primary source does not contain.

• Does the Personal Data Protection Law say anything specific about backups?

  Nothing backup specific appears on the official government summary of the law. The general obligations around protecting personal data apply to that data wherever it sits, and a backup is one of the places it sits, so the duty follows the copy. But there is no separate backup clause published there, and anyone quoting one to you should be asked for the article number. Take legal advice on your own obligations rather than relying on a general guide.

• What does recovering from ransomware actually involve?

  More than restoring files. The CISA checklist puts restoration late in the sequence, after the environment has been cleaned, systems rebuilt from known good images and credentials reset. The guide's own wording is to reconnect systems and restore data from offline, encrypted backups based on a prioritisation of critical services. That prioritisation is the plan you wrote in advance. Without it, you are deciding what matters most while the business is already stopped.

• What does a failed server need from a continuity standpoint?

  A recovery time and recovery point objective agreed for that specific system, a backup taken using one of the standard methods NIST names, which are full, incremental and differential, and storage of that backup somewhere geographically separate from the server itself. Then you need the recovery route: spare hardware, a standby environment, or a rebuild procedure written down clearly enough that someone other than the author can follow it under pressure.

• What happens if our cloud provider's region goes down?

  It behaves much like the loss of a primary site in NIST's disaster recovery scenario, because your infrastructure is unreachable even though nothing you own has broken. Two questions decide how bad it is. Can your workload fail over to another region or availability zone, and do your backup copies live outside the region that just failed. If both answers are no, a provider outage becomes your outage for exactly as long as theirs lasts.

• What does a lost or stolen laptop require?

  Encrypted device storage so the data is unreadable to whoever has it, a backup of anything that existed only on that machine, and fast revocation of the credentials and sessions it held. It is more a data loss and access control problem than an availability one, which is why it often falls outside a plan written purely around servers. Include devices in the plan, because a laptop is where a surprising amount of unique work lives.

• What if the only person who knows our systems leaves with the passwords?

  That is a single point of failure, and it is one of the most common ones we find. CISA's emphasis on least privilege and separation of duties applies directly. No single person, internal or outsourced, should be the only holder of administrator credentials, backup system access, or domain and registrar control. The fix is a shared credential vault with controlled access, and an offboarding checklist that revokes and rotates everything on the day someone leaves.

• If our IT is outsourced, who is responsible for testing the backups?

  Whoever the contract names, and if the contract names nobody then in practice nobody does it. CISA is explicit that where a third party or managed service provider maintains your backups, you should ensure they follow the applicable best practices, and it recommends using contract language to formalise your security requirements. Ask your provider for the date and result of the last restore test. The quality of that answer tells you most of what you need to know.

• How much does a business continuity and disaster recovery review cost in the UAE?

  No official body publishes a rate for this work, so any number you see is somebody's own pricing rather than a market survey. Ours starts from around AED 7,500 for a focused review that sets recovery time and recovery point objectives per system, documents the plan and runs a first restore test. Larger estates, more systems and tighter objectives cost more. Final pricing depends on scope, and building the recovery capability itself is scoped separately.

• Why will nobody quote a flat price for a disaster recovery plan?

  Because the objectives you choose change the work by an order of magnitude. A plan that accepts a day of downtime and a day of data loss is a modest piece of documentation and testing. A plan that accepts an hour and almost no data loss is an infrastructure project. The number of systems in scope moves it again. Anyone quoting a flat price before asking about your objectives has not understood what you are buying.

• Roughly what does cloud backup storage itself cost?

  It is usage based, so it scales with how much you keep and how long you keep it. As a published anchor, Amazon's own AWS Backup pricing page lists warm backup storage at about 0.05 US dollars per GB per month and restores at about 0.02 US dollars per GB in its US East examples, with a separate cold tier carrying a longer minimum retention. Regional rates differ, so check the live pricing pages for the region you actually use before budgeting.

• Is archive storage cheaper than standard cloud storage?

  Substantially, but with conditions. Google Cloud's published US multi region rates work out at roughly 0.02 US dollars per GB per month for standard storage against roughly 0.0012 for archive. The catch is minimum retention, which is 365 days for archive and 90 days for coldline, plus retrieval charges. That suits a long term compliance copy you rarely touch. It does not suit the working backup you would restore from tomorrow morning.

• Why does this article not quote a statistic about businesses closing after data loss?

  Because we could not trace one to a primary source. Figures of the form a given percentage of businesses that lose data close within a year circulate widely in backup marketing and are attributed to bodies that do not appear to publish them. We only publish numbers we can point at. The argument for continuity planning does not need a scary statistic, it needs an honest look at what a week of downtime would cost you.

• Do we need different plans for a cyber attack and a physical disaster?

  The framework is the same and the procedures are not. Both start from the same impact analysis and the same objectives per system, which is why NIST and the Central Bank rulebook both talk about planning for the different scenarios an organisation is vulnerable to. What differs is the response. Ransomware recovery leans on clean rebuilds and credential resets. Physical disruption leans on alternate sites and physical access. Write one plan with different branches.

• What is the first step in building a continuity plan?

  NIST puts the policy statement first, meaning a short written mandate that says this work is happening, who owns it and what authority they have. Step two is the business impact analysis, which identifies which processes and systems actually matter enough to plan around. Most businesses want to skip both and start buying backup software. Skipping them is how you end up protecting the file server well and the thing that takes payments badly.

• Is we have backups a good enough answer on a client security questionnaire?

  Increasingly not. Backups answer the data loss half of the question and say nothing about how fast you would be working again. A complete answer states a recovery time and recovery point objective for the systems that touch the client, describes where copies are held and how they are protected, and gives the date of the last successful restore test. Enterprise procurement teams are asking for that last item more often than they used to.

• How many systems should be in scope for a first plan?

  Fewer than you think. Pick the handful of systems the business genuinely cannot trade without, usually something like the finance or point of sale system, email, the customer database and the one operational tool your team lives in. Set objectives for those, test a restore on those, then widen. A short plan covering four systems that has been tested beats a comprehensive document covering forty that has never left the shared drive.

• Can we do any of this ourselves without hiring anyone?

  Yes, and you should start. Write down your five most important systems. For each one, agree how long you could be down and how much recent work you could lose. Find out how each is currently backed up and where the copy lives. Then pick one and restore it somewhere safe to see whether it works. That exercise costs nothing but a day of attention, and it usually reveals more than a purchase would.

• What is the most common continuity mistake you see in UAE businesses?

  Confidence based on configuration. Someone set up backups two or three years ago, the dashboard has been green ever since, and nobody has attempted a restore in that time. Meanwhile the systems have changed, retention has quietly shortened, or a critical database was never included in the job. The problem is not carelessness, it is that backup software reports on its own activity and never on the outcome you actually care about.