Financial institutions in the UAE are rarely asked whether they have a continuity plan. They are asked to demonstrate that it works, that its recovery targets were set from a business analysis rather than from what the infrastructure happens to deliver, and that the last test produced findings which were then closed. Those three questions decide most supervisory reviews, and they are where otherwise well-documented business continuity solutions fall apart. This article sets out what supervisors actually look for, the evidence that satisfies each expectation, and the six gaps that appear in review after review across banking, insurance and payments. Our note on building enterprise resilience in the data centre covers the platform layer beneath the plan.

Key Takeaways

• Supervisors treat recovery objectives as claims that must be evidenced, not targets that can be asserted. An untested recovery time objective is treated as no objective at all.
• The business impact analysis is the document reviews turn on. Where recovery tiers were assigned by infrastructure capability rather than business loss, the whole plan is questioned.
• Third-party and intragroup dependencies now attract as much scrutiny as internal systems, and a plan that stops at the perimeter of your own estate will be sent back.

What Supervisors Are Actually Testing

A review of your business continuity solutions is an evidence exercise, not a document review. The reviewer assumes the plan exists and looks instead for the trail that shows it has been exercised: test schedules with dates, results with named participants, findings with owners, and closure records with evidence attached. A comprehensive plan with no test history scores worse than a modest plan that is demonstrably rehearsed.

The second thing under examination is the link between the business and the technology. Recovery tiers should trace to a business impact analysis that quantifies loss per hour of outage for each critical service. Where that trace is missing, the reviewer concludes that recovery targets were set by what the platform could deliver and then written down as requirements, which inverts the entire logic of the exercise.

Third is governance. Supervisors want to see that the board or a delegated committee reviewed and approved the plan within a defined period, that material changes were escalated, and that the accountable executive can describe the recovery posture without reading from the document. Continuity is treated as a board responsibility in the UAE financial sector, and reviews are conducted on that basis.

Finally, reviewers look at dependencies outside the institution. Cloud providers, payment processors, core banking vendors and intragroup service companies all sit on the critical path, and each needs its own recovery evidence. Business continuity solutions that stop at the boundary of the owned estate are consistently sent back for extension.

None of these expectations is unusual by international standards, and institutions that already align to structured contingency planning guidance such as NIST SP 800-34 will find most of the required artefacts already exist in some form. The work is usually assembling them into a reviewable trail rather than creating them from nothing.

The Business Impact Analysis Is the Foundation

Every part of your business continuity solutions depends on the business impact analysis, and it is the artefact most often produced late and reviewed never. Done properly it names every business service, quantifies the financial, regulatory and customer impact of losing it for one hour, four hours, one day and one week, and identifies the technology components each service depends on.

The hourly loss figures matter more than the tier labels. A tier one label tells a reviewer nothing; a statement that a four-hour outage of the retail payments service costs a defined amount and breaches a specific settlement obligation tells them everything. It also makes internal budget conversations tractable, because the cost of additional resilience can be weighed against a number rather than an adjective.

Dependencies must be mapped both ways. Most analyses record which systems a service depends on and stop there. Reviews increasingly ask the reverse question, which services depend on this shared component, because that is how a single database or authentication platform turns a contained incident into a group-wide one.

Refresh cadence should be annual at minimum and immediately after any material change to the service portfolio. An analysis that predates a core system migration is evidence that the plan has not kept pace with the business, and reviewers read it that way.

The output feeds directly into recovery objectives. Recovery time defines how long a service may be unavailable; recovery point defines how much data may be lost. Both should come from the analysis and both should be stated per service rather than as a single institution-wide figure, which is a common shortcut that reviewers reject.

Testing: What Counts and What Does Not

A tabletop walkthrough is a useful exercise and it is not a test. Reviewers distinguish sharply between discussion-based exercises and technical failover, and only the latter evidences a recovery time objective. Institutions that report an annual continuity test and produce a workshop attendance sheet routinely receive a finding on that point alone.

The strongest evidence is a full failover of a critical service to the recovery site with production traffic, held for long enough to prove the environment is genuinely operable rather than merely startable. Where a full failover is not feasible, a documented, phased approach with a stated path to full test is far better received than an assertion that testing is impractical.

Test scope should include the parts everyone avoids. Recovering the identity platform, restoring from immutable backup rather than replication, and operating without the primary network path are all uncomfortable and all necessary, because those are the scenarios in which the plan is most likely to fail. Our note on whether your backups survive a ransomware event goes into the backup dimension specifically.

Findings from each test must be tracked to closure with the same rigour as audit findings. A test that produced no findings is treated with suspicion, since a genuine failover of a complex estate almost always surfaces something. Recording the small issues honestly builds far more confidence than a clean report.

Third-Party and Concentration Risk

Outsourcing does not transfer accountability, and supervisory expectations in the region now reflect that explicitly. For each material service provider the institution should hold the provider's own recovery objectives, evidence that those objectives were tested, contractual rights to test or receive test results, and an exit plan that does not assume the provider's cooperation.

Concentration is the harder question. Where several critical services run on the same cloud region, the same payment gateway or the same core banking vendor, the institution carries a correlated risk that no individual contract addresses. Reviews increasingly ask what happens when that shared dependency fails, and the honest answer is often that nothing in the plan covers it.

Intragroup arrangements deserve the same treatment as external ones. A shared service company in another jurisdiction providing infrastructure or operations is a third party for continuity purposes, and informal group relationships are not accepted as a substitute for documented recovery commitments.

Where card payments are in scope, the resilience obligations in the payment card industry data security standard overlap substantially with continuity requirements, and evidence assembled for one review can usually serve both. Institutions that maintain these separately duplicate work for no supervisory benefit.

Practical continuity and resilience services planning should therefore produce a dependency register that spans internal systems, external providers and intragroup entities in a single view, with recovery evidence attached to each row.

The Six Gaps That Appear Most Often

Across the reviews we support, six gaps account for most of the findings issued against business continuity solutions. First, recovery objectives asserted without test evidence. Second, a business impact analysis that predates the current service portfolio. Third, tabletop exercises presented as technical tests. Fourth, no recovery plan for the identity platform, which almost every other recovery depends on.

Fifth, backups that are replicated rather than isolated, so that an event affecting production reaches them as well. Sixth, third-party dependencies with no recovery evidence and no exit plan. These six account for the majority of findings issued in the reviews we see, and none of them requires new technology to close.

The identity gap deserves emphasis because it is the least visible. Directory services, certificate authorities and privileged access systems are usually classified as infrastructure rather than as business services, so they receive no tier and no recovery objective, and then every service recovery stalls waiting for them. Give the identity platform its own tier and its own test.

Structured incident management guidance such as the NCSC incident management collection is a useful cross-check for the response side of the plan, which reviewers examine alongside recovery. A plan that recovers systems but has no defined communication path to customers and regulators is incomplete.

For institutions serving BFSI workloads specifically, our note on recovery as a service for ransomware scenarios covers how the technical layer supports these commitments.

Building a Review-Ready Programme

Start by assembling the evidence your business continuity solutions already generate into a single reviewable pack: the current impact analysis, the recovery objectives per service, the last two test reports with findings and closures, the dependency register, and the board approval record. Most institutions discover that three or four of these exist and one or two do not, which turns a vague concern into a defined gap list.

Then fix the sequence rather than the documents. The impact analysis drives the objectives, the objectives drive the test scope, the test produces findings, and the findings drive the next round of investment. Where that chain is broken at any link, the plan becomes a document exercise regardless of how well written it is.

Set a testing calendar that covers every tier one service across a rolling twenty-four months, with at least one full failover per year and identity platform recovery included explicitly. Publish the calendar to the board so that a deferred test becomes a visible decision rather than a quiet slip.

Treat data centre resilience solutions and recovery tooling as an outcome of this process rather than an input to it. Buying capability before the impact analysis exists produces a platform that recovers the wrong things quickly and the right things slowly, which is the most expensive way to fail a review.

If you are preparing for a supervisory review or rebuilding a plan that has drifted, our resilience team can assess your current evidence pack against these expectations. You can also see how our infrastructure and data platform practice supports the recovery objectives your analysis sets.