Understanding Business Continuity

Start with how long you can afford to be down

Two numbers drive every continuity decision. The first is how long you can operate without the system — your tolerance for downtime. The second is how much data you can afford to lose, measured in time — an hour, a day, a week.

These are business questions, not technical ones, and only the business can answer them. Once answered, they determine what the technology has to deliver, and how much it should cost.

A useful exercise is to rank your systems by how quickly their absence stops revenue. The accounting system may tolerate a day. Email and your line-of-business application usually will not.

The four ways you should expect to fail

Equipment failure is the most familiar: a server, a drive, a switch, a firewall. It is also the one most businesses plan for, which is why it is rarely the worst case.

Human error is more common. Someone deletes the wrong folder, applies the wrong setting, or moves a file. Notably, human error can defeat a backup if the deletion is mirrored before anyone notices.

Cyber incidents are the fastest-growing category. As with ransomware, the attacker often targets recovery capability specifically — which is why recovery systems must be isolated from the network they protect.

Physical and infrastructure events — fire, flood, theft, a prolonged power or internet outage — are rarer but can remove an entire site's capability at once. These are the cases where cloud infrastructure earns its place, because your systems no longer sit in one room.

What a workable plan contains

A list of the systems that matter, ranked, with the expected recovery time for each. Not everything needs the same treatment, and treating everything as critical is how projects become unaffordable.

Named people and their alternates. A plan that only works when one specific person is available is not a plan; it is a single point of failure with documentation attached.

A communication path that does not depend on the systems that are down. If your team coordinates over email hosted on the server that just failed, the plan fails with it. The usual answer is a messaging channel and a printed contact list.

And a written procedure for the first hour — who to call, in what order, and how to decide whether to invoke the plan. Decisions made under pressure are better made in advance.

Test it, then fix what the test reveals

The value of a test is not reassurance; it is discovery. Every meaningful exercise finds something — a credential nobody has, a runbook that assumes a system that no longer exists, a backup that restores but takes twice as long as assumed.

Start small. Restore a single critical file, then one application, then rehearse a fuller scenario. A modest test that actually happens beats an ambitious one that keeps being postponed.

Record the actual timings. Real recovery time is usually longer than estimated, and knowing the true number is what lets you make honest promises to clients.