What Should a Business Continuity Plan Cover for a UAE Company?

A business continuity plan should set out which activities you must keep running, how quickly each one has to come back, what they depend on, who takes decisions and communicates during a disruption, how your technology is recovered, and how all of it is tested. In the UAE, the national standard for this is AE/SCNS/NCEMA 7000:2021, issued by the National Emergency, Crisis and Disasters Management Authority (NCEMA). IT disaster recovery is one part of that plan, not a substitute for it.

What is NCEMA 7000, and does it apply to your company?

NCEMA 7000:2021 is the third version of the UAE's national standard for business continuity management systems, and it updates the 2015 edition. It comes as three publications: the Specifications, which set the requirements, the Guidelines, which explain them, and a Toolkit with templates. NCEMA states that the requirements are consistent with ISO 22301:2019 and ISO 31000:2018, and that organisations can use the Specifications for self-assessment or for an external audit to seek certification.

On scope, the standard says its requirements are relevant to all organisations regardless of type, size and nature, with the extent depending on each organisation's operating environment and complexity, and that it is applicable to all UAE entities. NCEMA is responsible for monitoring its implementation at federal and local level.

Applicable is not the same as legally required. The Specifications do not cite a law that makes the standard compulsory for private companies, so do not assume either way. The standard does say that legislative, licensing and regulatory bodies will often set further requirements, and that where they do, you must comply with them. If you are licensed or regulated, ask your regulator what it expects.

What does the business impact analysis have to produce?

The business impact analysis (BIA) is where the plan starts, because it decides what gets protected first. Under clause 8.2 of NCEMA 7000, your BIA process has to:

• Use impact categories and timeframes that fit your business to analyse what happens when activities are disrupted.
• Find the point at which not resuming an activity becomes unacceptable, and set a recovery time objective (RTO) within it.
• Decide the capacity at which each activity needs to come back, which may be lower than normal.
• Identify your prioritised activities, which then need continuity strategies to bring them back within their RTO.
• List the dependencies of each prioritised activity: people, other resources, external providers and other activities.

Two further requirements are easy to miss. Where a prioritised activity depends on a single external provider, you must evaluate that provider's own continuity arrangements and decide how to deal with the weakness. And the BIA output has to be in a form top management can use to make decisions. Clause 8.3 then adds a risk assessment of your prioritised activities, and NCEMA publishes a BIA template on its business continuity page.

NCEMA 7000 asks for RTOs. For IT you also need a recovery point objective (RPO), which NIST defines as the point in time to which data can be recovered after an outage, in other words how much data loss the process can tolerate. Our guide to setting RPO and RTO covers those numbers in detail.

Where does IT disaster recovery fit in the plan?

Inside the response part of the plan. Clause 8.5.2 requires your response structure to cover recovery of technology systems alongside command and control, incident detection, communication, resumption of prioritised activities and the return to normal. The standard's idea of technology systems is broad: equipment and hardware, network and voice services, software and the links between applications, data, and the physical environment the equipment sits in.

Clause 8.5.3.4 then requires you to define how technology is recovered during a disruption, including:

• Invoking the technology response and deploying people.
• Accessing backup data and acquiring alternative service provision.
• Restoring data, information services, communications and support.
• When, and at what capacity, each technology requirement will be available, tied back to the BIA.

NIST's contingency planning guide makes the same link from the other side: because business processes use information systems, the continuity planner must coordinate with system owners so that what the plan expects and what IT can deliver match. In practice that means:

• Map every prioritised activity to the systems, data, accounts and suppliers it needs.
• Set a restore order that follows the RTOs, with identity and sign-in early, because users reach cloud services through them.
• Keep backups that an attacker cannot easily destroy. The UK NCSC warns that ransomware attacks may try to prevent recovery by destroying backups, and its principles call for backups that resist malicious editing, overwriting and deletion.
• Remember what moving to the cloud does not change. Microsoft states that whatever the deployment type, you keep responsibility for your data, endpoints, accounts and access management.
• Prove the timings with a restore test rather than a vendor specification.

Our disaster recovery and business continuity service is built around agreed recovery targets, written runbooks and rehearsed procedures.

Who does what during a disruption?

NCEMA 7000 makes top management responsible for the continuity policy and accountable for the management system meeting the standard. For the response itself, it requires:

• Response teams made up of identified people with the responsibility, authority and competence for their role, each guided by a documented response structure.
• A central team with the capability and authority to make prompt decisions and communicate them, fed with information in a timely and secure way.
• Alternates for people in key roles, in case the designated person is not available.
• A defined way of recording actions taken and decisions made.

For IT, name who can declare a disaster and invoke recovery, who deals with Microsoft and your other cloud vendors, and who approves putting restored systems back into use. Write the names down, with deputies.

How should you communicate when systems are down?

Clause 8.5.3.3 asks you to define what you communicate, when and to whom, who has authority to communicate, and how contact details for everyone in your response procedures are kept up to date. It also requires predefined means of communication that stay available during a disruption, plus procedures and approved templates for dealing with the media.

That is where IT and continuity meet. If your plan assumes email and Teams, decide what happens when the incident is in Microsoft 365 itself, or when a ransomware attack has locked your accounts. Keep a copy of the plan and the contact list somewhere that does not depend on the systems being recovered, and agree a fallback channel in advance.

How often should you test the plan, and what counts as a test?

NCEMA 7000 separates exercises from tests. Exercises build teamwork, competence, confidence and knowledge. Tests check whether a specific outcome is achievable, for example whether a computer system can be recovered within a set time. The standard calls team walk-throughs of the response structure a good starting point, and accepts that a full programme may be spread over several years.

Under clause 8.6, exercises and tests must:

• Use appropriate and realistic scenarios with clearly defined objectives.
• Decide how far your external providers need to be involved.
• Produce post-exercise reports with recommendations, and set criteria for judging success.
• Run at planned intervals and whenever there are significant changes in the organisation or its context.
• Avoid harming normal business operations.

A workable first year is one tabletop walk-through with the management team, one restore test of a prioritised system, and one test of your fallback communication channel.

What documents should the plan include?

Clause 7.3 sets the minimum documented information. Use it as your table of contents:

• Roles and responsibilities, and management system planning.
• Context: issues, interested parties and attitude to risk.
• Policy, scope and objectives.
• Support: people, other resources, external providers, communication and control over changes.
• The BIA, the risk assessment and the continuity strategies.
• Team structure, response requirements, and the exercise plan with post-exercise reports.
• Monitoring, compliance and audit, management review, nonconformities and corrective actions.

Our business continuity planning service covers the framework, the BIA, plan documentation, a drill cadence and ongoing maintenance. To talk through where your plan stands, contact us.