Business continuity plan basics for UAE IT teams.

Continuity is about the business, not the servers

When a core system fails, the first question from the board is rarely "which server?" It is "can we still serve customers, pay suppliers and issue invoices today?" A business continuity plan answers that. It identifies what the business must keep doing, how long it can go without each activity, and what the team will do in the meantime. Our guide to the disaster recovery plan covers the technical restoration side. This guide covers the layer around it, the decisions and workarounds that apply while recovery is still under way.

Step 1: list what the business actually does

Start with activities, not systems. Sit down with each department head and ask what they must be able to do each day or week. Typical answers include taking orders, raising quotations, approving payments, issuing delivery notes, answering customer calls, running payroll and submitting regulatory documents. For each activity, record which people, applications, data, devices and suppliers it depends on. The result is a simple table that links business activities to the technology behind them. It also exposes dependencies people forget, such as a single shared mailbox, a licence server or a mobile number used for approvals.

Step 2: rank them with a business impact analysis

A business impact analysis sounds formal, but the idea is plain. For each activity, ask how long the business could cope without it before the consequences become serious, and what those consequences would be: lost sales, missed deadlines, contractual penalties, safety concerns or regulatory exposure. Let the people who run the activity answer, not IT guessing on their behalf. Group activities into tiers such as "needed within hours", "within a day or two" and "can wait". Those tiers then set the recovery order and feed the recovery time and recovery point targets in your disaster recovery plan. Our downtime cost guide can help you frame the conversation without inventing numbers.

Step 3: plan the workarounds

For each critical activity, write down the fallback. It might be paper order forms, a spreadsheet copy of the customer list kept in a separate location, a mobile hotspot for a branch whose line is down, or a call-forwarding rule that sends the main number to named mobiles. Workarounds should be realistic for the staff who will use them. Ask three questions of every one:

• Can it be started without IT help?
• Where is the information it needs stored, and is that location itself available during the outage?
• How will the work done on the workaround be entered back into the main system afterwards?

The last question is the one most plans skip, and it is where data gets lost or duplicated.

Step 4: decide roles and decision rights

During an incident, time is lost to uncertainty about who decides. Name an incident lead and a deputy, a technical lead, a communications lead and someone who speaks for the finance and operations side. Record how each can be reached out of hours, and what happens if they are unavailable or abroad. Make clear who may authorise emergency spending, who may invoke a workaround, and who may call the provider's emergency line. If you use an outside provider, write their escalation route into the plan and check that it matches the support contract, as discussed in the AMC contract checklist.

Step 5: prepare communications

Most continuity failures are communication failures. Prepare, in advance, short holding statements for staff, customers and suppliers, and a way to reach people that does not depend on the failed system. If email and Teams are down, how will you contact staff? A call tree on paper, a group on a messaging app approved for business use, or an emergency contact sheet kept offline can fill that gap. Think also about regulators, insurers and landlords, who may need to be told promptly. The first hour of an incident is covered in our first-hour checklist.

Step 6: cover people, premises and suppliers

Continuity is not only IT. Consider what happens if the office is inaccessible, if a key person is unavailable, or if a critical supplier such as an internet carrier, software vendor or logistics partner has its own outage. For premises, decide whether staff can work from home, from another branch or from a temporary space, and check that devices, remote access and phone numbers support that. For suppliers, record contract contacts, support routes and any alternative. Multi-site organisations should read our multi-site IT guide alongside this, because a branch is often the weakest link.

Step 7: test, then keep it alive

An untested plan is an assumption. Start with a tabletop exercise: gather the incident team, describe a scenario such as a ransomware infection, loss of the main internet link or a failed core application, and walk through what each person would do. Record gaps, assign owners and fix them. Later, test the technical pieces, including restoring from backup, as set out in the backup restore test checklist. Review the plan at least annually and after any significant change, and keep a copy that can be read when your network and cloud storage cannot.

A short structure to copy

• Purpose, scope and owner, with a review date.
• Critical activities, their tiers and dependencies.
• Workarounds per activity, with data re-entry steps.
• Roles, contact details and escalation route.
• Communication templates and contact lists.
• Links to the disaster recovery plan and supplier contacts.
• Test log and change history.

Where to start

You do not need a large project. Pick your five most important activities, write down what each depends on and what you would do without it, and run one tabletop session. Missan's disaster recovery service and backup and recovery service can support the technical side, and the free IT health check is a practical way to surface single points of failure. Missan Global has supported UAE organisations since 2004 from its head office in Al Majaz, Sharjah.