Skip to main content
A disaster recovery plan (DRP) is your organisation’s formal commitment to continuity — the documented, tested set of procedures that gets your systems, communications, and people back online after an unexpected event. In Cambodia, where monsoon flooding, power instability, and fibre infrastructure limitations are real operational variables, an untested plan is nearly as dangerous as no plan at all. This guide walks you through every layer of a practical DRP: from identifying your risks to choosing the right recovery site model to keeping your communication runbook current.
Cambodia’s operating environment introduces specific risks that many off-the-shelf DRP templates underestimate:
  • Urban flooding — seasonal flooding in Phnom Penh and other cities can make physical office sites inaccessible for days.
  • Power grid instability — grid outages and voltage fluctuations are common; generator fuel supply chains can also be disrupted during widespread events.
  • Fibre cable cuts — underground and aerial fibre is vulnerable to construction activity and flood damage, which can sever both primary and redundant ISP links simultaneously.
  • Ransomware — targeted ransomware campaigns increasingly affect SMEs across Southeast Asia; assume your environment is a viable target and plan accordingly.
Your DRP must explicitly account for each of these threats — not treat them as edge cases.

​
Step 1 — Risk Assessment

Before you can protect your business, you need to know precisely what you’re protecting it from. A risk assessment maps every credible threat against the assets it could affect. Start by cataloguing your critical assets:
  • Production servers (on-premises and cloud-hosted)
  • 3CX phone system and SIP trunks
  • Business databases and file stores
  • Network infrastructure (firewalls, switches, WAN links)
  • Physical premises and power supply
Then map each asset against the threats most relevant to your location and industry: Document the likelihood and potential business impact of each threat. This matrix becomes the input to your Business Impact Analysis.

​
Step 2 — Business Impact Analysis (BIA)

A Business Impact Analysis quantifies how much downtime each system can tolerate before the business suffers unacceptable harm. Two key metrics drive every subsequent DRP decision:
  • RTO (Recovery Time Objective) — the maximum acceptable time between a failure and full service restoration
  • RPO (Recovery Point Objective) — the maximum acceptable data loss expressed as time (e.g., “we can tolerate losing up to 4 hours of transactions”)
Define these targets for each critical system before you choose a recovery site model. Example targets for common Cambodian SME systems:
3CX downtime directly affects customer-facing communications. Treat the phone system as mission-critical and target an RTO under 1 hour. KHCOLO’s cloud-hosted 3CX instances support automated failover that can meet this target without manual intervention.

​
Step 3 — Choose Your Recovery Site Model

Once you know your RTO and RPO targets, you can select the right recovery site architecture. KHCOLO supports all three standard models.

​
Recovery Site Comparison

​
Hot Site (Mission-Critical)

A hot site maintains a fully replicated, live standby instance of your production environment — kept in continuous sync and ready for automated failover.
  • Real-time or near-real-time data replication to a secondary cloud server
  • Automated health checks trigger failover without manual intervention
  • DNS cutover or floating IP ensures end users experience minimal disruption
  • Ideal for 3CX phone systems, payment processing, and customer-facing web applications
A warm site keeps a pre-configured cloud instance available but restores it from recent backups rather than maintaining live replication. This is the most cost-effective approach for the majority of Cambodian SMEs.
  • Cloud VM provisioned and configured, waiting to be loaded from backup
  • Recovery initiated manually or via runbook automation on declaration of a disaster
  • Recovery time typically measured in tens of minutes to a few hours depending on data volume
  • Significantly lower ongoing cost than a hot site while still meeting most SME RTO targets
KHCOLO’s managed backup service automatically transfers encrypted snapshots to a geographically isolated secondary data centre. Pairing a warm site with this backup arrangement gives you fast, reliable recovery without the full cost of a hot standby server.

​
Cold Site (Last-Resort Fallback)

A cold site provides bare-bones physical continuity — a location with connectivity and hardware where your team can operate if both primary and warm-site options fail.
  • A secondary branch office or co-working space with spare desk phones
  • An alternate ISP connection (4G/LTE failover or a secondary fibre provider)
  • Local copies of critical documentation (network diagrams, credentials vault, runbooks)
  • Designed to restore basic operations, not full system capability

​
Step 4 — Build Your Communication Runbook

Technical recovery procedures are only half the picture. When a disaster occurs, your staff, management team, and key suppliers need clear, current instructions for who to contact and in what order. Your communication runbook must include:
  • Emergency escalation directory — names, mobile numbers, and escalation order for IT staff, KHCOLO support, management stakeholders, and board contacts
  • Key supplier contacts — ISP technical support lines, generator fuel supplier, UPS maintenance vendor, Microsoft/licence portal admin contacts
  • Staff notification procedure — how employees are informed of an incident (e.g., WhatsApp broadcast group, SMS tree, email from a secondary domain)
  • Customer communication template — a pre-approved message template for notifying customers of service disruption, ready to send immediately
  • Incident declaration criteria — clear, unambiguous criteria for who can declare a disaster and invoke the DRP (avoid requiring unavailable senior approval during a crisis)
  • War room location — a designated physical or virtual meeting point where your response team coordinates
Store a printed copy of your communication runbook in your server room and at least one off-site location. During a major incident, access to digital systems may be part of the problem — don’t make your runbook unreachable when you need it most.

​
Step 5 — Test and Maintain Your DRP

A DRP that has never been tested is an assumption dressed as a plan. Schedule formal testing on a quarterly basis and after any significant infrastructure change.
  • Restoration drill — restore a critical application VM from backup into a sandbox environment and time the recovery
  • Tabletop exercise — walk your team through a simulated scenario (e.g., “flooding has made the office inaccessible for 72 hours”) and identify gaps in your runbook
  • Failover test — for hot site arrangements, trigger an actual automated failover and verify end-to-end functionality before failing back
  • Runbook review — update all contact details, system inventories, and step-by-step procedures after every test and after any staff or infrastructure change
Review the full DRP document at least annually, or whenever a major business change occurs — new branch offices, acquisitions, or significant system migrations all require corresponding DRP updates.