IT Disaster Recovery Hong Kong: A Brokerage's Wake-Up Call

The short answer: Having backup software running is not the same as having disaster recovery. A 28-person Hong Kong insurance brokerage that assumes "we have backup" usually discovers otherwise the first time someone actually tries a restore — weeks of silently failed backup jobs, a DR document nobody has opened in three years, and no defined recovery time or recovery point to test against. Real DR coverage means monitored backup jobs, scheduled restore drills, and a documented RTO/RPO and runbook — the kind of evidence both PDPO expectations and cyber-insurance underwriters actually ask for.

If your brokerage's cyber-insurance renewal questionnaire just asked for proof of a tested disaster-recovery plan, or if someone on your team recently tried to restore a file and it didn't go the way anyone expected, you're not alone — this is one of the most common ways a Hong Kong insurance brokerage or wealth-management firm discovers that "we have backup" and "we have disaster recovery" were never actually the same thing. This guide walks through what real DR coverage looks like for a firm this size, why backup software alone doesn't get you there, and what to fix before the next renewal questionnaire — or the next actual incident — asks the question again.

The Industry: Hong Kong Insurance Brokerages and Wealth Management Firms

Hong Kong's insurance brokerage and wealth-management sector sits at a smaller-scale slice of the same finance industry Brocent already supports at larger scale — global insurance groups, investment banks, and financial-services firms with far bigger IT footprints. The fundamentals are the same regardless of size: client records, policy documents, and transaction histories are the core asset the business runs on, and losing access to them, even temporarily, is a direct threat to client trust and regulatory standing, not just an IT inconvenience. What differs at the smaller end of this segment is resourcing — a 20-to-35-person brokerage rarely has a dedicated IT or security hire, let alone someone whose job is specifically to own backup monitoring and disaster-recovery testing, which is exactly the gap this guide addresses.

The Scenario: 28 Staff, a Core Asset Nobody Actively Owns

Picture a Hong Kong insurance brokerage with 28 staff — client-facing advisors, claims support, compliance, and a small operations team. Client policy files, correspondence, and transaction records are the firm's core operational asset, stored across a mix of email, shared drives, and a policy-management system. Backup was set up years ago, likely by whoever handled IT at the time or by the vendor who sold the original server, and it has run quietly in the background ever since without anyone specifically responsible for checking whether it's actually working. This is an extremely common pattern for a firm this size — backup gets treated as a one-time IT setup task completed once during onboarding, rather than an ongoing discipline that needs regular attention, and nobody notices the gap until something forces the question.

What "We Have Backup" Usually Means in Practice

When a firm says "we have backup," it typically means a backup job is scheduled and technically runs — but that's a much narrower claim than it sounds. In practice, "we have backup" for a firm this size usually means nobody is actively watching whether the job succeeds each night, no one has ever actually tried to restore a file or a full system from that backup to confirm it works, and no one has defined how much data loss (recovery point objective, or RPO) or how much downtime (recovery time objective, or RTO) would be acceptable if a restore were genuinely needed. A backup job silently failing for weeks is a strikingly common finding once someone actually looks — a changed password that broke an automated connection, a storage quota quietly filled, a schedule that stopped triggering after a software update — and without active monitoring, the first time anyone finds out is the day they need the backup to actually work.

What a Failed Restore Test Actually Reveals

The moment that usually triggers this realisation is a genuine attempt to restore something — a corrupted file, a ransomware scare, or simply someone finally taking the cyber-insurance renewal questionnaire seriously enough to test the DR plan it's asking about. What a failed restore test typically reveals isn't one single dramatic failure, but a cluster of smaller gaps that together add up to "we don't actually have disaster recovery": backups that technically exist but are incomplete, missing recent changes, or corrupted in ways nobody noticed until the restore itself failed; a DR document that describes a system configuration from years ago, before a server was replaced or a cloud migration happened, making the written runbook actively misleading rather than just outdated; and no one on staff who has actually walked through a restore end to end, meaning the first real attempt happens under the worst possible conditions — during an actual incident, with client-facing operations already disrupted.

Brocent's Perspective: Disaster Recovery Is a Discipline, Not a Document

The view that shapes how Brocent approaches DR for a firm this size is straightforward: disaster recovery is a discipline of regular restore drills and a maintained runbook, not a policy document written once and filed away. Most "we're covered" claims collapse the first time someone actually tries to restore, precisely because a policy document sitting untouched for three years reflects the infrastructure and threats of three years ago, not today's. Treating DR as a one-time deliverable — write the plan, check the compliance box, move on — produces exactly the false confidence a firm this size can least afford, because the gap between "we have a DR plan" and "our DR plan actually works" only becomes visible at the worst possible moment: during a real incident, not during a calm Tuesday afternoon review.

RTO and RPO in Plain Terms for a Firm This Size

These two terms show up in every DR conversation and are worth defining plainly rather than leaving as jargon. Recovery Point Objective (RPO) is how much data the firm can afford to lose, measured in time — if backups run nightly and something fails at 4pm, an RPO of 24 hours means you'd lose that day's work; a tighter RPO requires more frequent backups. Recovery Time Objective (RTO) is how long the firm can tolerate being down before systems are restored and usable again — a few hours is realistic and achievable for most firms this size with the right setup; multiple days generally isn't acceptable once client-facing operations and regulatory obligations are considered. For a 28-person brokerage, a realistic target is usually an RPO measured in hours (not days) for core client and policy data, and an RTO the firm has actually tested and confirmed, not just written down as an aspiration. Neither number means anything until it's been tested against a real restore.

What Cyber-Insurance Underwriters Actually Ask For

Cyber-insurance renewal questionnaires have become considerably more specific over the past few years, and it's worth understanding what underwriters are actually probing for rather than treating the questionnaire as a box-ticking formality. Underwriters typically want evidence of monitored, verified backups — not just a statement that backups exist, but confirmation that someone actively checks their success and periodically tests restores. They want a documented RTO/RPO that reflects an actual tested capability, not an aspirational number nobody has confirmed. They often ask specifically whether backups are isolated from the production network (protecting against ransomware that targets connected backup systems along with primary data), and whether the DR plan has been reviewed or tested within a defined recent period, commonly the last 12 months. A brokerage that can answer these specifically, with dates and evidence, is in a meaningfully different position — often reflected in premium and coverage terms — than one that can only offer a general assurance.

How PDPO Factors Into a DR Plan

Hong Kong's Personal Data (Privacy) Ordinance is relevant to disaster recovery in a way that's easy to overlook when DR gets treated purely as a technical or insurance topic. PDPO's data protection principles require reasonably practicable steps to protect personal data against loss, and client policy records held by a brokerage are squarely personal data under the ordinance. A DR plan that can't actually restore client data within a reasonable timeframe — or, worse, one that turns out not to work at all when tested for the first time during a real incident — is a genuine data-protection exposure, not just an operational inconvenience. Building DR review into the same governance conversation as PDPO compliance, rather than treating them as separate checklists handled by different people, tends to produce a plan that actually holds up when both a regulator and an underwriter ask about it.

What Real DR Coverage Looks Like for a Firm This Size

Concretely, real DR coverage for a 28-person brokerage means backup jobs that are actively monitored, with alerts when a job fails rather than silent failure discovered months later. It means scheduled restore drills — not a hypothetical annual mention, but an actual calendar-driven exercise where someone restores a real file or system and confirms it works, on a defined cadence rather than whenever someone remembers. It means a documented RTO and RPO that have actually been tested against a real restore, not aspirational numbers copied from a template. And it means a runbook that's current — reflecting today's actual systems, not a description of infrastructure from years ago — with clear, specific steps someone unfamiliar with the details could follow under pressure, because the person who normally handles IT may not be the one available when an incident actually happens.

Building a Restore-Drill Cadence That Actually Happens

The single most common reason DR plans go untested isn't a lack of intent — most firms genuinely mean to test their DR plan "at some point" — it's a lack of a specific, calendared commitment that survives competing daily priorities. A restore drill that isn't scheduled with a specific date, owner, and defined success criteria tends to get pushed indefinitely in favour of whatever's more urgent that week, which for a 28-person firm without dedicated IT staff is essentially everything. A cadence that actually happens usually looks like a quarterly restore test of a real file or folder, an annual full-system restore test conducted in a way that doesn't disrupt live operations, and a brief written record of what was tested, what worked, and what didn't — partly for the firm's own confidence, and partly because that record is exactly what a cyber-insurance underwriter or a PDPO inquiry will eventually ask to see.

What to Check Before Trusting Your Current Backup Setup

For a brokerage that hasn't reviewed its backup and DR setup recently, a few specific checks are worth doing before assuming everything is fine. Confirm someone actually receives and reviews backup success/failure notifications daily, not just that notifications are technically configured to send. Confirm backups are isolated from the production network in a way that would survive a ransomware incident targeting connected systems. Confirm the last time anyone actually restored a file or system from backup, and how long ago that was — if the honest answer is "never" or "we're not sure," that's the clearest possible signal that a real DR review is overdue. And confirm the written DR plan or runbook, if one exists, actually describes today's systems rather than an earlier server or software configuration that's since changed.

What This Actually Costs to Fix, Versus What an Incident Costs

It's worth being direct about the cost comparison, because "we'll get to it eventually" usually survives on the assumption that fixing DR properly is expensive relative to the risk. In practice, monitored backup and a scheduled restore-drill cadence for a 28-person firm is a modest, predictable addition to an existing managed IT relationship — nowhere near the cost of a genuine incident. A firm that discovers its backups have silently failed during an actual ransomware event or system failure faces not just the direct cost of data loss or rebuild, but the cost of client notification obligations, potential regulatory scrutiny under PDPO, reputational damage in a business built on client trust, and quite possibly a cyber-insurance claim that gets contested or reduced because the policy's own DR-readiness representations turn out not to have been true. Measured against that, the cost of proper monitoring and quarterly restore drills is genuinely small — the real barrier is usually that nobody has made it anyone's specific job, not that it's expensive to do.

Bringing It Together: Disaster Recovery as an Ongoing Discipline

None of this requires a 28-person brokerage to build a dedicated internal DR function — it requires a partner that treats backup monitoring and restore testing as an ongoing service, not a one-time setup task checked off and forgotten. Brocent's cloud managed backup is built around active monitoring and scheduled restore verification rather than a "set it and hope" configuration, paired with managed IT security services that keep backups genuinely isolated from the risks that threaten production systems, and managed IT and cloud services that give a firm this size the kind of ongoing IT discipline a dedicated in-house function would otherwise need to provide.

Frequently Asked Questions

Does a 28-person brokerage really need a formal DR plan, or is backup software enough?

Backup software alone isn't disaster recovery — it's one component of it. A formal DR plan adds the parts that actually determine whether a real recovery succeeds: monitoring that confirms backups are working, scheduled restore drills that prove they can actually be used, and a documented RTO/RPO the firm has tested rather than assumed. A firm this size doesn't need a heavyweight enterprise DR program, but it does need these specific elements in place.

What's the difference between having backup and having disaster recovery?

Backup is the technical mechanism that copies data somewhere else. Disaster recovery is the broader discipline that ensures that backup can actually be used to restore operations within an acceptable time and with an acceptable amount of data loss — which requires monitoring, testing, documented targets, and a runbook, not just a scheduled job quietly running in the background.

How often should a restore actually be tested?

A practical cadence for a firm this size is a quarterly test of restoring a real file or folder, plus an annual full-system restore test conducted in a way that doesn't disrupt live operations. What matters more than the exact frequency is that it's scheduled with a specific date and owner rather than left as a vague intention that competes with daily priorities and consistently loses.

What do cyber-insurance underwriters expect to see?

Typically, evidence of monitored and verified backups (not just a statement that they exist), a documented RTO/RPO reflecting a tested capability, confirmation that backups are isolated from the production network, and evidence the DR plan has been reviewed or tested within a defined recent period, commonly the last 12 months. Dates and specifics matter more than general assurances.

How does PDPO factor into a DR plan?

Client policy records are personal data under Hong Kong's PDPO, and the ordinance requires reasonably practicable steps to protect personal data against loss. A DR plan that can't actually restore that data within a reasonable timeframe is a genuine data-protection exposure, not just an operational inconvenience, which is why DR review and PDPO compliance are worth handling as part of the same governance conversation rather than as separate checklists.

What does a realistic RTO/RPO look like for a firm this size?

A reasonable target for a 28-person brokerage is usually an RPO measured in hours rather than days for core client and policy data, and an RTO of a few hours for critical systems once the setup is properly monitored and tested. Neither number is meaningful until it's actually been tested against a real restore rather than written down as an aspiration.

What if we've genuinely never tested a restore and don't know where to start?

That's a common starting point, not an unusual one, and the fix doesn't need to be dramatic — start with a single, scheduled restore test of one real file or folder, confirm it works, document what you learned, and build outward from there toward a full-system test and a defined cadence, rather than attempting to design a complete DR program before testing anything at all.

Is cloud-based backup automatically safer than on-premises backup for a firm this size?

Not automatically — the location of the backup matters less than whether it's monitored, isolated from the production network, and actually tested. A cloud backup that nobody watches has exactly the same silent-failure risk as an on-premises one; the genuine advantage of a well-managed cloud backup setup is that monitoring, isolation, and geographic redundancy are typically built into the service rather than left for the firm to configure and maintain itself.

Backup Software With No Monitoring vs One-Time DR Policy Document vs Managed Backup With Scheduled Restore Drills

• Backup Software With No Monitoring — A job runs on schedule, but nobody actively checks whether it succeeds, and the first sign of a problem is usually discovering it during an actual restore attempt, which is the worst possible time to find out.
• One-Time DR Policy Document (Never Tested) — Satisfies a paperwork requirement on the surface, but a plan describing infrastructure from years ago, never validated against an actual restore, provides false confidence rather than real recovery capability.
• Managed Backup + Scheduled Restore Drills (Brocent's Model) — Actively monitored backup jobs with alerting on failure, a calendared restore-testing cadence, and a documented, tested RTO/RPO and runbook that reflects today's actual systems.

From "We Have Backup" to Actual Disaster Recovery

A Hong Kong insurance brokerage's next cyber-insurance renewal questionnaire, or its next genuine restore attempt, will ask the same question either way: does the DR plan actually work, or has it only ever been assumed to? Brocent's cloud managed backup, managed IT security services, and managed IT and cloud services are built to turn "we have backup" into disaster recovery that's actually been tested, for firms that can't afford to find out the gap exists during a real incident. If it's been a while since anyone actually tried a restore at your firm, get in touch or see our pricing for how managed backup and DR review are structured.