Disaster Recovery Plan for Hong Kong Firms: RTO and RPO, DR Site Options and Cost (2026)

Short answer: a disaster recovery (DR) plan for a Hong Kong firm answers three questions in writing: how much data you can afford to lose (RPO), how long you can afford to be down (RTO), and the exact steps, people and systems that get you back. There are four common patterns, from backup only to a hot standby site, and cost rises with every step towards faster recovery. Most 40 to 150 person firms land on warm or backup-plus-restore designs, then prove them with a test rather than a document. This guide explains the four patterns, how to choose a DR site, what a one-page runbook contains and how to evidence a DR test.

What is a disaster recovery plan, and how is it different from a backup?

A backup is a copy of data. A disaster recovery plan is the tested ability to bring a business service back after something takes it down: a failed storage array, ransomware, a flooded server room, a cloud outage or a lost office. Backups are one ingredient. The plan also names the systems in order of importance, the recovery target for each, where recovery happens, who does what and how you will know it worked.

Two numbers drive everything. Set them per system, not once for the whole company:

• RPO (recovery point objective): the most data loss you can accept, measured in time. An RPO of four hours means you can lose up to four hours of work.
• RTO (recovery time objective): the longest outage you can accept before the business is hurt. An RTO of one working day means services must be back within a day.

For a worked story of what happens when a firm has backups but no tested recovery, read IT disaster recovery for a Hong Kong brokerage. For the managed-backup buying questions, read managed backup services: what is included and the RPO/RTO questions to ask. This article adds the part those do not cover: the DR patterns, the site options and the runbook.

What are the four DR patterns?

The patterns below are the usual way to describe how much is ready before a disaster. The recovery times are typical orders of magnitude to help you compare, not guarantees; your design, your data volume and your provider decide the real figures.

• Backup and restore. Data is copied regularly to a separate location. After a disaster you rebuild or find infrastructure, then restore. Cheapest to run, slowest to recover: typically many hours to days, and the longer, the larger the data set and the more systems you must rebuild first.
• Cold site. A place, or a documented design, where systems can be rebuilt, but nothing is running. Better than nothing for rare, tolerable outages; recovery is still days.
• Warm standby. A reduced copy of key systems is already running in another location and is kept current. Failover means scaling up and switching users over. Typically hours.
• Hot standby, or active-active. A full copy runs continuously and takes load or switches almost immediately. Typically minutes, at the highest ongoing cost and complexity.

Cost rises with each step towards faster recovery. You pay for duplicate capacity, replication links, licences, monitoring and the staff time to keep them working. The question to ask for each system is: what does an hour of downtime cost the business, and does faster recovery cost less than that?

Which pattern fits which system?

A 40 to 150 person firm rarely needs one pattern for everything. A common split:

• Hot or warm: the few systems that stop revenue or breach an obligation within hours, such as order entry, trading or client-facing platforms.
• Warm or fast restore: email, file shares and core line-of-business applications, where a day of disruption hurts but does not end the business.
• Backup and restore: archives, internal tools and anything that can wait.

Write the answer as a table-substitute list in your plan: system, owner, RPO, RTO, pattern. If two systems depend on each other, give them the same recovery order, or one will come back without the other.

How do you choose a DR site?

The place you recover to matters as much as the pattern.

• A second office or server room. Familiar and under your control, but it shares risks with the first: the same building district, power grid, weather and often the same staff.
• A colocation rack in another data centre. You rent space and run the hardware; cost is moderate, effort is real.
• Public cloud as the recovery site. You pay mainly when you recover, which suits warm and restore patterns; the design work is in networking, identity and data transfer. Brocent's backup service supports the major public clouds as backup targets and can replicate across clouds.
• A provider-managed recovery service. Someone else operates and tests it under a contract.
• Mainland China data. If any of your data sits in the mainland, storage location is a design decision, not an afterthought. Brocent's backup service supports mainland storage on two public clouds; confirm what your own legal advice says about cross-border movement before you design around it.

Whatever you pick, check four things: distance from the primary site (far enough not to share the same event, near enough to reach), how fast data actually moves between them, who has access, and whether your staff can work from wherever recovery happens.

What should a one-page recovery runbook contain?

A runbook that nobody can find at 2 a.m. is not a plan. Keep it to one page per critical system, stored where it can be reached when the main systems are down (printed copy, an offline copy and a copy in a separate cloud account).

1. Trigger and decision. What counts as a disaster, and who is allowed to declare it.

2. Contacts. Names, numbers and alternates for IT, management, the provider, the landlord and the key suppliers.

3. Recovery order. Which systems come back first, and what each depends on (identity, network, storage).

4. Steps. The actual commands or console steps, with the location of credentials and licence keys.

5. Where recovery happens. The DR site, how to reach it and how users connect.

6. Verification. How you confirm the system is correct (a named test transaction, a data check), not merely running.

7. Communication. Who tells staff and clients what, and when.

8. Return. How and when you move back, and what happens to data created during the outage.

9. Owner and review date. A runbook with no owner is out of date.

How do you run and evidence a DR test?

Untested recovery is a guess. Test in stages, from easy to demanding:

1. Backup verification. Confirm that jobs ran and that sample files and databases restore.

2. Restore drill. Restore a full system to an isolated environment and check it works.

3. Tabletop exercise. Walk the management team through a scenario using the runbook, and note what is missing.

4. Failover test. Actually switch a system to the DR site during a planned window, if your pattern supports it.

Evidence matters as much as the test. Keep: the date, the scope, the RPO and RTO you aimed for, the times you actually achieved, what failed, who fixed it and what changed in the plan. This is the paper an insurer, client or regulator is more likely to accept than a statement that you have backups. Brocent's backup service builds the cycle into the contract: 24×7 monitoring of backup jobs, periodic recovery drills by its operations team, and a drill report that records recovery success and any gaps found.

What do regulated and client-facing firms tend to be asked?

Firms in financial services, and firms serving them, are often asked by regulators, customers or insurers to show tested recovery, not just a policy. The questions usually concern recovery targets by system, the date and result of the last test, where backups are held and who can access them. What applies to you depends on your regulator and contracts, so read the specific requirement. For the insurer side of the question in a Microsoft 365 setting, see cyber insurance requirements for Hong Kong IT renewal.

What does it cost, and where are the figures?

DR cost is the sum of five things: backup storage and transfer, standby capacity, replication links, licences and management effort, plus the periodic test. Which pattern you choose has more effect than which supplier. Brocent publishes a starting point: the Basic preventive-maintenance plan (monthly backup job health check, integrity verification, basic BCP documentation and an email alert when a backup fails) is from USD 298 per month. The Standard managed backup plan (24×7 job monitoring, BCP design, an annual recovery drill and a monthly status report) is quoted after scoping. Brocent's managed backup service, which designs the backup layer, monitors it and runs recovery drills, is described on the cloud managed backup service page, with published rates on the backup and recovery pricing page. Standby capacity and failover design are scoped to your environment and quoted after discussion. For the wider picture of how Brocent runs cloud and infrastructure for Hong Kong firms, see managed IT and cloud services.

If you are still choosing between backup tools and a managed service, managed backup service vs backup software covers that decision.

Frequently asked questions

What is the difference between RTO and RPO?

RPO is how much data loss you can accept, measured as time since the last good copy. RTO is how long you can be down before recovery. Set both for each system.

Do we need a disaster recovery site?

Not always. Many firms recover from backups into the cloud when needed. A standing DR site is justified for systems where downtime costs more than the standby does.

Is a cold site enough?

For systems where days of outage are tolerable, yes. For anything that stops revenue within hours, no.

How often should we test?

Verify backups continuously, run a restore drill at least yearly and a tabletop exercise at least yearly, and test again after major changes. Regulated firms may be asked for more.

Is cloud backup the same as disaster recovery?

No. Cloud backup stores copies. Disaster recovery is the tested process of using them, or a standby, to restore service within your RTO.

Where should the runbook be kept?

Somewhere reachable when your main systems are down: a printed copy, an offline copy and a copy in a separate account from your main environment.

Does Brocent publish DR prices?

Backup service rates are published on the pricing page above. Standby sites and failover are quoted after scoping, because they depend on your systems and recovery targets.

Next step

List your ten most important systems, give each an RPO and RTO, and mark the pattern that meets them at an acceptable cost. Then write the one-page runbook for the top three and schedule a restore drill. To see how Brocent runs backup, monitoring and recovery drills, read the cloud managed backup service page and the backup and recovery pricing, or talk to a Brocent consultant about a recovery plan for your environment.