A Business Continuity Plan for Mid-Size Companies: What If Everything Stopped Tomorrow

A business continuity plan answers one question: if a core system, office or key person stopped tomorrow, how would the company keep serving customers and collecting revenue until everything is back? Disaster recovery is the technical part inside it, focused on restoring systems and data. A mid-size company does not need an 80-page document. It needs five practical steps: an impact analysis that prices each system's downtime in riyals per hour, a priority ranking of systems with a recovery time objective (RTO) and recovery point objective (RPO) for each, a safe location for backups and passwords that stays reachable even if the office and email are down, a contact list with clear roles so everyone knows what to do in the first 60 minutes, and a two-hour annual exercise that exposes gaps before a real incident does. Companies that follow these steps usually resume work within hours, while those that improvise can need 3 to 10 days to restore a single ERP and lose data they never get back along the way. This article walks through each step with examples and figures you can apply this week.

Business Continuity vs Disaster Recovery

Mixing up the two concepts leaves plans incomplete. Disaster recovery (DR) asks how to bring the server and database back. Business continuity (BCP) asks how sales keeps taking orders while the server is being restored. A practical example: if the billing system goes down, the recovery plan restores it within 4 hours, and the continuity plan has the team issue manual invoices on a pre-approved form during those hours, then enter them once the system returns. Without that second part, revenue stops entirely even if the technical restore is fast.

Impact Analysis: What Each Hour of Downtime Costs

Start by listing your systems, then calculate the cost of an hour of downtime for each. A simple method adds three items: lost revenue, the cost of idle staff, and penalties or reputational damage. Here is an example for a mid-size distribution company:

System	Cost per hour down (SAR)	Target RTO	Target RPO
ERP and billing	12,000	4 hours	1 hour
Corporate email	3,000	8 hours	24 hours
Customer portal	5,000	4 hours	4 hours
HR system	500	3 days	24 hours
Company website	200	2 days	1 week

The numbers set the priorities on their own. One hour of ERP downtime in this example equals 24 hours of HR system downtime, so it makes no sense to back them up at the same frequency or restore them in the same order.

Turn RPO into real settings

A one-hour RPO means daily backups alone are not enough. For a MySQL database, enable the binlog and ship it to a separate site every hour:

# /etc/mysql/conf.d/binlog.cnf
[mysqld]
log_bin = /var/lib/mysql/binlog
binlog_expire_logs_seconds = 604800

# crontab: ship logs offsite every hour
0 * * * * rsync -a /var/lib/mysql/binlog.* backup@offsite:/srv/binlogs/

Combined with a full daily backup, you can restore to any point in the last 7 days with no more than an hour of loss.

Where Backups and Passwords Live During a Crisis

The most painful mistake we see is a backup that exists but sits on the same failed server, or a control panel password stored in an email account that is down. Apply the 3-2-1 rule: three copies of your data, on two different storage types, with at least one copy outside the primary site. On a cloud server you can add daily backups with 7-day retention for 800 SAR a year or 30-day retention for 2,000 SAR, and keep an extra logical export you ship to another location yourself. With managed cloud hosting, daily and weekly backups come included in every plan starting at 2,900 SAR a year.

For passwords, use a shared team password manager plus a printed copy in a sealed envelope inside a safe that at least two people know about. These items must be reachable without depending on any system that might fail:

• Provider panel credentials and SSH keys.
• Domain registrar and DNS panel access.
• Provider support numbers and contract number.
• Location of the latest backup and the steps to restore it.

Four Scenarios the Plan Must Cover

Most plans assume a single scenario, a failed server, while reality is broader. Write a short page for each of these four covering the impact, the fallback procedure and who runs it:

1. Ransomware encrypts your data

This is where an isolated backup proves its worth. If backups share the same network and credentials, an attacker encrypts them along with the originals. Keep at least one copy that cannot be deleted or modified from the primary server, and separate the backup account from day-to-day operating accounts.

2. The office becomes unreachable

A long power cut or a closed building takes office machines out of service. If your systems run on a cloud server in a data center, the team keeps working from home over a VPN or a secure portal, whereas a server in an office room stops along with everything else.

3. The key person is absent

A long leave or sudden resignation by the only person who knows the system. The remedy is a written runbook, a trained backup for every role, and privileges shared across at least two people.

4. An external service fails

The payment gateway, messaging provider or email service. Define a manual fallback or a backup provider for each external service, and know in advance how many hours you can run without it.

Contact List and Roles

In the first hour of an incident, confusion is more dangerous than the fault itself. Define four roles, each with a primary person and a backup:

Role	Responsibility
Incident lead	Declares the incident, activates the plan and assembles the team
Technical lead	Works with the provider and drives restoration by priority
Business lead	Activates fallback procedures such as manual invoicing
Communications lead	Informs customers and management with pre-written messages

Write customer messages now, not during the crisis. A two-line note saying the service is affected, orders are being taken on a backup phone number, and the next update comes within two hours protects your reputation far better than a full day of silence.

The Annual Exercise: Two Hours That Reveal the Gaps

A plan that has never been rehearsed usually fails within the first thirty minutes. Once a year, gather the team for two hours and run a specific scenario, such as: "9 a.m. on Sunday, the primary server is unresponsive and the technical lead is on leave." Then watch what actually happens and note every moment someone stops to ask "where is the password?" or "who calls the provider?"

Make part of the exercise hands-on by restoring the database backup to a test server and timing it. A Starter plan server (1 vCPU and 2GB RAM) at 3,450 SAR a year is usually enough to test a small system's restore, a small sum next to the cost of a single hour of ERP downtime in the example above. The restore and check look like this:

gunzip < erp_2026-10-01.sql.gz | mysql erp_restore_test
mysql -e "SELECT COUNT(*) FROM erp_restore_test.invoices;"

If the actual restore time exceeds the written RTO, the plan needs fixing before you truly need it. After the exercise, write a one-page report listing three things that worked and three gaps that surfaced, with an owner and a due date for closing each gap, then review that same report at the next exercise to confirm the gaps were actually closed.

Local Providers and Data Location

While writing the plan, ask where your data will sit during a crisis. If your systems connect to National Access (Nafath) or government integrations, temporarily moving them to a server outside the Kingdom may breach your requirements. Choose a provider with data centers inside Saudi Arabia, contractual uptime such as 99.99%, and latency close to your users, like roughly 8ms from Riyadh. Plans and add-ons are listed on the pricing page.

Start This Week

1. List your systems and calculate the cost of an hour of downtime for each using the table above.
2. Set an RTO and RPO for every system and confirm your backup settings actually meet them.
3. Move at least one copy off the primary server.
4. Set up the password manager and the sealed envelope.
5. Assign the four roles with names and backups, and write the customer messages.
6. Put the annual exercise on the calendar now.

Each of these steps takes one to three hours, adding up to less than two working days, while a single day of downtime without a plan can cost many times that.