Quick Answer
In Dubai, telemedicine data hosting is governed by the Dubai Health Authority (DHA) Standards for Telehealth Services, which keep patient data, including backups, inside the UAE. In 2026 that rule met a hard test. Drone strikes damaged AWS facilities in the UAE and Bahrain, and AWS later told customers that some data held only in the affected zones could not be recovered.
The lesson is not to move data out of the UAE, which the rules generally restrict. It is to spread copies across separate UAE sites and providers, keep encryption keys somewhere that survives the same event, and test recovery before you need it. Several zones inside one cloud region are no longer enough on their own.
This guide covers what to confirm with DHA, how to design resilience inside the UAE, and what to ask your hosting provider and platform vendor.
What DHA requires for telemedicine data hosting in the UAE
In Dubai, telehealth is regulated under the DHA Standards for Telehealth Services (reference ST-14). Version 4 took effect on 26 November 2025. Only a DHA-licensed facility can deliver telehealth, and the platform must meet DHA’s data centre and hosting requirements.
At the federal level, UAE Federal Law No. 2 of 2019 on the use of ICT in health fields is commonly summarised as requiring health data generated in the UAE to be hosted in the UAE, with cross-border transfer allowed only by specific exception. Legal summaries differ in detail, so confirm the current position with DHA or a UAE healthcare lawyer. This article is not legal advice.
For hosting, the points that matter most are:
- Patient data stays on UAE infrastructure, and that includes backups, logs and failover servers.
- The hosting meets DHA’s data centre and cloud certification requirements (our checklist summarises these as Tier 3 data centres and a DESC-certified cloud provider; verify against the DHA document).
- Records connect to NABIDH, Dubai’s health information exchange.
- Encryption, multi-factor authentication and ISO 27001 certification are expected.
We cover the full requirement list in our DHA telehealth standards checklist, so this article does not repeat it. It deals with the question the checklist leaves open: what happens when a compliant data centre is physically lost?
Abu Dhabi is regulated by the Department of Health (Malaffi exchange) and the Northern Emirates by MOHAP, so a platform serving several emirates needs to check each regulator.
What the 2026 AWS outages showed

The facts below are attributed to the outlets that reported them, and the reports do not fully agree on details.
- On 1 March 2026, AWS facilities in the UAE and Bahrain were damaged. According to Data Centre Magazine, AWS confirmed drone strikes as the cause the following day. News reports attribute the strikes to Iran.
- Silicon UK reported that most customers in the Bahrain region had moved their data elsewhere before a second Bahrain zone became unavailable in April.
- In mid-September 2026, Reuters, as carried by Khaleej Times, reported that AWS could not restore access to its Bahrain facility and one of three UAE availability zones.
- Other reports citing the Wall Street Journal say the UAE region lost two of its three zones and that some data stored only in the Bahrain and UAE facilities cannot be recovered. Help Net Security reported the permanent loss on 17 September.
The count of affected UAE zones differs between reports, so check AWS’s own status updates before quoting a number. The Free Press Journal, citing the Wall Street Journal, noted that cloud infrastructure is normally built to survive the loss of a single zone, not coordinated strikes across several.
We are not aware of public reporting on which healthcare providers, if any, were affected. The point for telemedicine operators is the design assumption that failed, not any one company.
Why several zones in one region may not be enough
Multi-zone deployments protect against power cuts, hardware faults and a single building failing. They assume zones fail independently. A physical event across a city or country breaks that assumption, and so does a provider-level problem that stops the provider from restoring your resources.
Telemedicine adds a second constraint. A retailer can fail over to Frankfurt. A DHA-licensed provider generally cannot, because patient data, backups included, has to stay in the UAE. The real design question becomes how to get independence inside the UAE.
Options to evaluate:
- A second site in a different emirate, for example Dubai and Abu Dhabi.
- A second cloud or hosting provider in the UAE, so one provider’s failure does not take every copy.
- Backups held with a different provider from production.
Before relying on any combination, confirm with DHA that each provider and region meets its data centre and cloud requirements. We have not verified the DHA or DESC status of specific providers, and whether any cross-border backup is acceptable should be confirmed in writing, not assumed.
A telemedicine hosting design that stays inside UAE rules

The example below uses a common stack for illustration: a Flutter app calling a Laravel API backed by PostgreSQL. It is a pattern, not a description of a specific Sigosoft project. The same logic applies to any stack.
| Layer | What to do | Why it matters |
|---|---|---|
| Primary production | Run in a UAE site with multiple zones | Handles ordinary failures |
| Warm standby | Keep a second UAE site (other emirate or provider) with streaming database replication and an application tier that can be deployed from infrastructure-as-code | Shortens recovery from hours to minutes or less |
| Backups | Encrypted, immutable copies held by a different UAE provider from production | One compromised or unrecoverable account does not erase every copy |
| Encryption keys and secrets | Store them where they survive the loss of the primary site, still inside the UAE | Backups are useless if the keys die with the region |
| Images, code and pipelines | Keep container images, source repositories and deployment tooling outside the primary site | You cannot rebuild if the tooling is down too |
| DNS and traffic routing | Use health-checked DNS with a low TTL, hosted independently of your primary provider | Moves users to the standby quickly |
| Video | Run WebRTC TURN and signalling servers at both sites | Consultations can restart without waiting for full recovery |
| Documented targets | Write down the recovery point (data you can afford to lose) and recovery time for each service, agreed with clinical governance | Turns “resilient” into something you can test |
A warm standby costs more than a cold backup. The right level depends on how much downtime your clinical service can tolerate, which is a decision for your clinical and technical leads together.
What should keep working when a site is down
Plan the degraded mode, not just the recovery. For a telemedicine platform that usually means:
- Consultations: Video can restart on the standby, and patients have a phone fallback with a clear number.
- Prescriptions and consent records: These are read and written from the standby, with audit logs preserved.
- NABIDH submissions: Queued and retried automatically, so records are not lost while the connection is down.
- Patient communication: Notifications go out through a channel that does not depend on the failed site.
Our post on reliable telemedicine video calls with WebRTC covers the video side in more depth.
Questions to ask your hosting provider and platform vendor
If you run or buy a telemedicine platform in the UAE, ask for written answers to these:
- Exactly where are production data, replicas, backups, logs and encryption keys hosted (provider, city, facility)?
- Can you show the data centre and cloud certifications DHA expects?
- What are the documented recovery point and recovery time, and when was recovery last tested end to end?
- Are backups held with a different provider or in a different emirate from production?
- Where are keys and secrets stored, and do they survive the loss of the primary site?
- Are NABIDH submissions queued and retried during an outage?
- Does a change to hosting need to be reported to DHA, and who will do it?
Vague answers to questions 1, 3 and 5 are the clearest warning signs.
Beyond Dubai: Abu Dhabi, Saudi Arabia and the rest of the GCC
Each regulator sets its own rules. Abu Dhabi uses the Department of Health and Malaffi, and the Northern Emirates fall under MOHAP. Saudi Arabia, Qatar, Bahrain, Oman and Kuwait each have their own health ministries and data requirements. We have not verified every country’s current data residency rules for this article, so confirm them with the relevant regulator before designing hosting for a multi-country platform.
One practical warning: the damaged AWS region in Bahrain shows that a neighbouring GCC country is not automatically a safe place for failover, and moving health data across borders may not be permitted at all.
Common mistakes
- Treating multi-zone as disaster recovery. It protects against small failures, not a regional event.
- Keeping backups in the same account, region or provider as production. One failure then removes every copy.
- Storing encryption keys only in the primary region. The backups become unreadable.
- Never testing a restore. An untested backup is an assumption.
- Moving data offshore for recovery without DHA confirmation. This can create a compliance problem while solving a technical one.
- Forgetting dependencies outside the database. Container registries, deployment pipelines, DNS, secrets, and third-party video, SMS and payment services can all be single points of failure.
- Confusing compliance paperwork with resilience. A certificate shows requirements were met, not that you can recover.
Fix, extend or migrate: what to do with an existing platform
If your hosting is in the UAE but runs from a single site, the fix is usually a standby, separate backups and a tested runbook. If your vendor cannot tell you where data and keys live, cannot show restore tests, or hosts any patient data outside the UAE, migration deserves serious consideration.
Our enterprise system modernisation and migration service covers moving a platform without losing data, and our telemedicine app development page describes what we build.
Choosing a telemedicine development partner

A reliable telemedicine platform requires more than patient and doctor applications. It needs a considered technical scope, secure infrastructure, healthcare integrations, testing, deployment planning, and support after launch.
At Sigosoft, we approach telemedicine development as a complete product engineering process. Our focus is on helping healthcare businesses plan and build platforms that support real operational needs—not simply delivering a set of applications.
Comprehensive deliverables and integrations
A successful launch may involve patient and doctor apps, an administration panel, appointment scheduling, video consultations, e-prescriptions, payment gateways, notifications, and integrations with healthcare systems such as EMR/HIS and health information exchanges. The exact scope depends on the facility, regulatory requirements, and project needs. Planning these dependencies early helps reduce gaps that can become costly after launch.
Explore our telemedicine app development capabilities.
Cost-effective development from India without compromising quality
Building a telemedicine platform for the Dubai market does not necessarily mean paying Dubai-based development costs. By working with an experienced India-based development team, healthcare businesses may benefit from competitive development costs while accessing experienced developers, structured project management, quality assurance, and ongoing technical support.
For example, a project budgeted at approximately $50,000 with a Dubai-based development provider might have the potential to be delivered for around $25,000 through an India-based team, depending on the scope, integrations, infrastructure, and support requirements. These figures are illustrative, not guaranteed market rates or a direct comparison of equivalent quotations.
Cost efficiency should not come at the expense of security or reliability. Sigosoft combines India-based development capabilities with ISO/IEC 27001:2022-certified information security management practices, structured development processes, and defined support arrangements. This gives businesses another option for managing their development budgets while keeping quality, security, and long-term maintainability in focus.
Long-term support after delivery
A telemedicine platform continues to evolve after launch. User feedback, operational changes, integration updates, and technical issues all require attention. For all Delhi Medicines apps, Sigosoft provides 12 months of support from delivery. This is a project-specific commitment, not a universal support term for every engagement.
Longer-term support can help teams address issues, maintain integrations, and respond to operational needs as the product is used in real-world conditions.
Quality, security and defined service levels
Sigosoft holds ISO/IEC 27001:2022 certification. Our Legal & Compliance page explains our information security approach and the scope of the certification.
We also use service-level agreements to define support expectations, including response times and escalation procedures. The applicable coverage and service levels should be confirmed in the agreement for each project. ISO certification is not a substitute for DHA approval or a guarantee of regulatory compliance.
Dedicated consultants and direct communication
Clear communication is important throughout a healthcare technology project. Sigosoft’s dedicated-consultant approach gives clients a direct point of contact for project discussions, coordination, progress updates, and technical guidance. This helps keep business requirements and technical decisions aligned.
On-site assistance when needed
Some situations benefit from in-person support, including go-live activities, technical troubleshooting, team training, and operational discussions. Sigosoft can discuss on-site assistance where required, subject to availability, project scope, location, and agreed commercial terms.
Human-led engineering with AI-assisted tools
AI-based development tools can improve productivity, but speed alone does not guarantee a dependable healthcare platform. Architecture decisions, security reviews, integration testing, regulatory understanding, and accountability still require experienced people.
Our approach combines modern development tools with human technical oversight, structured quality checks, and an understanding of the client’s business requirements. The objective is not simply to develop faster, but to build software that can be maintained, tested, and supported over time.
For more guidance before starting a telemedicine project, read What We Tell Every Founder Before They Build a Telemedicine App.
Frequently asked questions
Does DHA require telemedicine data to be hosted in the UAE?
The DHA Standards for Telehealth Services and Federal Law No. 2 of 2019 are commonly summarised as requiring it. Confirm the current wording with DHA.
Can I back up UAE patient data to a region outside the UAE?
Do not assume so. The rules generally keep health data in the country, with exceptions granted by the authorities. Get written confirmation from DHA before sending any copy abroad.
Is a multi-zone deployment enough?
It is a useful resilience measure but not a complete disaster recovery plan, and it is not what the compliance requirements measure. The 2026 outages showed that several zones in one region can be lost together.
What is NABIDH?
NABIDH is Dubai’s health information exchange, run by DHA. Telehealth providers connect their records to it through a certified vendor.
How often should we test recovery?
We found no regulator-set interval. Many teams test restores at least quarterly and after any major architecture change. Set the schedule according to your risk and your clinical service’s tolerance for downtime.
Get your telemedicine hosting reviewed
If you run a telemedicine platform in Dubai or elsewhere in the UAE and cannot answer the questions above with confidence, talk to Sigosoft. Tell us where your data lives today and what you run, and we will discuss a scoped roadmap: fix, extend or migrate.
Get my free roadmap | Chat on WhatsApp
Sources
- Dubai Health Authority, Standards for Telehealth Services (confirm this is the version 4 document).
- Sigosoft, DHA Telehealth Standards 2026: A Developer’s Checklist.
- Data Centre Magazine, Iran Conflict: More Drone Strikes hit AWS Gulf Data Centres.
- Khaleej Times (Reuters), AWS unable to restore access to Bahrain, one UAE cloud data zone.
- Help Net Security, 17 September 2026 report.
- Free Press Journal (citing the Wall Street Journal), Amazon says some data from damaged AWS facilities in Bahrain and UAE is gone for good.
- Silicon UK, AWS Reports Data Loss After UAE, Bahrain Drone Strikes.
- Kayrouz & Associates, Licensing and data rules for telehealth providers in the UAE.
- ClinicsOnCloud, DHA vs DOH vs MOHAP telehealth rules.
Thanks for the feedback!
Start the discussion
Questions or experiences to share? Our team reads and replies.




