When people talk about business continuity, they think of ransomware first. Yet among our clients, the most frequent interruptions have far more ordinary causes: a power outage lasting several hours after a storm, water damage in the network closet, a switch that dies on a Monday morning. In Quebec, fall and winter wind and ice storms put these scenarios to the test every year.

Two Numbers to Set First

A recovery plan starts with two business decisions, not technical ones:

  • RTO (maximum downtime) — How long can your business operate without a given system? Four hours for billing? A day for the intranet?
  • RPO (acceptable data loss) — How much work can you afford to lose? If the answer is "one hour," a nightly backup is not enough.

These two numbers drive the budget. Demanding zero downtime on everything is very expensive; defining them system by system lets you protect what brings in revenue first.

The Weak Spots We Find Most Often

  • A UPS with worn-out batteries — It still shows a green light but would last less than two minutes. Batteries usually need replacing every 3 to 5 years.
  • No automatic server shutdown — When the UPS runs dry, servers switch off abruptly, risking data corruption.
  • A single Internet connection — If the fibre is cut, IP telephony, Microsoft 365, and remote access all go down together. A cellular backup link is inexpensive and fails over automatically.
  • Backups in the same room as the servers — Water damage or a fire destroys both at once.
  • A plan that only exists in one person's head — And that person is on vacation the day of the outage.

A Useful Plan Fits on a Few Pages

There is no point producing an 80-page binder nobody will read. A good recovery plan answers four questions: who decides to trigger the plan, who to call (with phone numbers, printed), in what order to restart systems, and where to work if the premises are inaccessible. Keep a copy outside your network: a plan stored only on the failed server is useless.

The Test Is the Plan

An untested plan is a hypothesis. Once a year, simulate a realistic scenario: restore a server from off-site backups, fail over to the backup Internet link, have a team work remotely for half a day. Every test reveals a forgotten detail — a password nobody can find, a licence tied to old hardware — that is far better discovered on a quiet Tuesday than in the middle of a crisis.