Disaster recovery planning for a Dubai bank used to start with a simple promise: replicate to a second site and fail over when the first degrades. Events in 2026 made that promise look incomplete, and the data problem was never simple. What happens to transactions in flight, and where may recovery legally run? This guide covers what the regional disruption changed, the patterns available, the decisions each one forces, and what to rehearse. Our note on building data resilience across hybrid estates covers hybrid cloud disaster recovery in more depth.

Key Takeaways

• Plan for a whole cloud region failing, because the events of March 2026 showed that several zones can be impaired together.
• Choose the failover pattern by data consistency requirement, then check that your regulator allows the location you are failing over to.
• Rehearse the parts nobody wants to test: failback, partial region degradation, and the identity platform the rest of recovery depends on.

What 2026 Changed for Disaster Recovery Planning

AWS's public status history records that two of its facilities in the UAE were directly struck on 1 March 2026, and it later attributed damage in its UAE and Bahrain Regions to drone strikes. Two of the three Availability Zones in the UAE Region were impaired. In September, AWS said it could not restore data held exclusively in one affected UAE zone or in the Bahrain Region.

For a bank in Dubai, this changes the failure a plan has to assume. Multi-zone design protects against the loss of a facility. It does not protect against an event affecting several zones in one region, and nearby regions may also be affected. A plan that stops at a second zone has not addressed that scenario.

The obvious answer, failing over abroad, is constrained by regulation. Press reports in March 2026 described the Central Bank allowing case by case approval for offshore disaster recovery as an exceptional measure and not a permanent policy change. We found no published circular confirming those terms, so treat them as reported and ask your supervisor directly.

The permanent rules point the other way. According to Trowers and Hamlins' summary, the Central Bank's operational risk Circular 1 of 2026 took effect on 14 September 2026, keeps the Master System of Record in the UAE and sets notification steps at 4, 24 and 72 hours. Dubai banks should review their plans against the current text. Firms licensed in the DIFC, and groups with teams in Abu Dhabi, should check the position with each of their regulators.

Disaster recovery planning therefore needs a tested option for each scenario: a zone failing, a region failing, and the rare event where staying in country is not possible. Decide in advance what each option requires, who has to approve it and which workloads could run in a reduced form. Disaster recovery services bought from a provider should state how they support each option.

Disaster Recovery Planning Starts With Data

Every disaster recovery planning exercise answers one question first: how much data may be lost. Synchronous replication commits a write in both regions before acknowledging it, which bounds loss to effectively zero and imposes a latency cost proportional to the distance between them. Asynchronous replication acknowledges locally and copies afterwards, which removes the latency cost and creates a window in which committed transactions exist in one region only.

For core banking and payments that window is rarely acceptable, which pushes the design toward synchronous replication and therefore toward region pairs close enough for the latency to be tolerable. That constraint, rather than any feature comparison, is what shapes most BFSI multi-region architectures.

The complication is that not every workload needs the same treatment. A payments ledger and a marketing analytics store have entirely different consistency requirements, and applying one policy to both means paying synchronous costs for data that does not need it or accepting asynchronous loss on data that does.

Distance is the constraint teams find hardest to accept. Synchronous replication over a long distance adds latency to every write, and in a payments path that latency is felt by customers rather than absorbed quietly by infrastructure. The honest options are a nearer region pair, a lower consistency tier for parts of the workload, or an application redesign that reduces the number of synchronous writes on the critical path.

Classify workloads by consistency requirement before selecting any replication technology. Three tiers usually suffice: zero data loss, minutes of acceptable loss, and hours. Each tier gets a different pattern, and the classification exercise takes a workshop rather than a project.

Contingency planning guidance such as NIST SP 800-34 provides a defensible structure for recording these decisions in a form supervisors recognise.

The Three Patterns and What Each Costs

Provider architecture guidance is worth reading before committing to a pattern; the reliability material in the AWS Well-Architected Framework and the Azure equivalent both describe these trade-offs in the vocabulary supervisors already accept.

Active-passive with warm standby keeps a scaled-down copy of the environment running in the second region, with data replicating continuously. Failover means scaling up and redirecting traffic, which takes minutes rather than hours. It is the most common BFSI pattern because it balances cost against a recovery time most supervisors accept.

Active-active runs production traffic in both regions simultaneously. Recovery time approaches zero because there is nothing to start, but the application must handle concurrent writes across regions, which is a significant engineering constraint and rules out most packaged core banking systems without vendor support.

Pilot light keeps only data replication and minimal infrastructure running, with the environment built on demand from infrastructure as code. It is the cheapest option and the slowest, and it is appropriate for tier three workloads rather than for anything customer-facing.

Mixing patterns across tiers is normal and correct. What causes problems is mixing them within a single business service, where the ledger fails over in minutes and a dependent service takes hours, leaving the service partially available and producing exactly the reconciliation problems the design was meant to prevent.

Orchestration: The Order That Matters

Disaster recovery planning produces a sequence rather than a switch, and the order is determined by dependency. Identity services first, because nothing else authenticates without them. Then data tier promotion. Then application tiers in dependency order. Then network and traffic redirection. Then external integrations, which frequently require the counterparty to be notified rather than simply reconnecting.

Write that sequence as code rather than as a runbook. A documented procedure executed manually under pressure at three in the morning by whoever is available produces errors at exactly the moment they are most expensive. Orchestration that is scripted, version controlled and tested behaves the same way every time.

Keep the invocation decision human. Automatic failover triggered by a health check has caused more incidents than it has prevented in regulated environments, because a network partition or a monitoring fault produces the same signal as a regional failure. Automate everything up to the decision, then require a named person to authorise.

Define who that person is and how they are reached, including on public holidays. Undefined invocation authority is one of the most common findings in resilience reviews, and the hours lost deciding whether to invoke are added to every recovery objective in the plan.

Our note on recovery as a service for BFSI ransomware scenarios covers the scenario where the trigger is compromise rather than failure.

External Dependencies and the Parts You Do Not Control

Banking workloads rarely fail over cleanly because they rarely run alone. Payment networks, clearing systems, correspondent banks, credit bureaus and regulatory reporting interfaces all sit outside the estate, and several of them authenticate by source address or require a scheduled change to accept traffic from a different location.

Enumerate every external integration and record, for each, whether it can accept traffic from the second region without notice, with notice, or not at all. That register is the single most useful artefact in a multi-region programme and it is almost never produced until the first rehearsal fails.

Where an integration requires notice, the recovery plan must include the notification step with a named contact and an expected turnaround, because a technically successful failover that cannot settle payments is not a successful failover.

Third-party software with region-bound licensing is a related trap. Licences tied to a specific host or region can block a recovery entirely, and the discovery usually happens during the event. Check licence portability as part of the design rather than during the rehearsal.

For managed services consumed from the provider, confirm the regional failure behaviour of each. Some are genuinely regional and some have a global control plane whose failure affects both of your regions simultaneously, which changes the risk picture materially.

Rehearsing What Nobody Wants to Test

Most organisations rehearse the pleasant scenario: a clean regional loss during a planned window, with everyone available. Real events are less tidy, and three scenarios reveal far more.

The first is partial degradation, where a region is slow rather than down. This is the hardest case to detect and the one where automatic triggers behave worst, because health checks pass intermittently and the decision to invoke is genuinely ambiguous. Rehearsing it exercises judgement rather than tooling.

The second is failback. Returning to the primary region after it recovers requires reconciling data written in the second region during the outage, and this is where most real reconciliation problems originate. Teams that have rehearsed failover and never failback have tested half the process.

The third is identity platform failure. Because every other recovery depends on it, a rehearsal that assumes identity is available is not testing the realistic worst case. Give the identity platform its own recovery tier and its own rehearsal.

Rehearse with the people who would actually be on shift rather than with the architects who designed the system. A failover executed flawlessly by the design team proves the design works and says nothing about whether the operations team can run it at three in the morning, which is the only condition under which it will ever be needed.

Track findings from every rehearsal to closure like audit findings, and treat a rehearsal that produced none as a signal that the scenario was too easy. Effective disaster recovery planning improves through findings, not through clean reports.

Evidence, Governance and Next Steps

Supervisors examining a multi-region design tend to ask for the same four things: the consistency tier for each business service with the reasoning, recovery objectives with the date each was last demonstrated, the external dependency register, and rehearsal reports with findings and closure evidence. Capture these as outputs of the programme, because assembling them later is much harder.

Report to the committee that reviews operational risk, and include deferred rehearsals as well as completed ones. A pattern of deferrals is the earliest visible sign that recovery capability is drifting from its stated objectives.

Review the plan when the estate changes. A new payment integration, a core system upgrade or a provider region change each invalidates part of it immediately. Our note on testing whether backups survive ransomware covers one of the checks to repeat, and a sound disaster recovery strategy should be revisited whenever these changes occur.

If you want an independent review of your disaster recovery planning or help running a realistic rehearsal, our Dubai and Abu Dhabi resilience team can work through it with you. You can also see how Unicorp protects business data and applications in regulated estates, including managed disaster recovery services under agreed service levels.