Business Continuity and Disaster Recovery: What Most Mid-Market IT Setups Are Missing

Almost every mid-market business has a disaster recovery plan of some description. Almost none of them have tested it in the way that matters: by actually trying to recover a system under realistic conditions, with the people who'd really be on call, on a day nobody chose in advance.

That gap between having a plan and having a plan that works is where most business continuity failures actually come from. It's rarely the absence of a document. It's the presence of one nobody has stress-tested.

The document versus the capability

A disaster recovery plan is a description of what should happen. A tested recovery capability is proof of what actually will. These are treated as the same thing far more often than they should be, and the gap between them tends to surface at the worst possible moment: during a live incident, when the plan calls for a step that depends on a system, password or person that's no longer available.

This isn't a criticism of the people who wrote the plan. Most DR documentation was accurate when it was written. The problem is that IT estates change constantly, new systems get added, staff move on, credentials rotate, and a plan written eighteen months ago is describing an estate that no longer exists. Without a rhythm of testing, the plan quietly drifts out of date and nobody notices until it's needed.

The single points of failure hiding in plain sight

The most common gap Boardman sees across mid-market IT setups is a single point of failure disguised as redundancy. A business believes it has backup because data is copied nightly, but the copy sits with the same cloud provider, in the same region, accessible through the same admin account as the primary system. A genuine regional outage, a compromised credential, or a billing dispute with that provider can take out both copies at once.

The second common gap is people, not technology. Recovery procedures that depend on one specific engineer knowing an undocumented step are a continuity risk no amount of infrastructure spend fixes. If the recovery plan lives mostly in one person's head, the business doesn't have a continuity plan, it has a hope that person answers their phone.

Recovery time versus recovery point, and why the difference matters

Two numbers matter more than almost anything else in a continuity plan: how long it would take to get a system back (recovery time objective) and how much data the business could afford to lose in the process (recovery point objective). Most mid-market businesses have never had a real conversation about either number for their most critical systems, which means the IT team is quietly making assumptions about what the business can tolerate, without the business ever having agreed to them.

Setting these numbers deliberately, system by system, based on what the business actually needs rather than what the infrastructure happens to default to, is one of the highest-value and lowest-cost exercises a mid-market business can run. It often reveals that the business is over-investing in recovery speed for systems that don't need it, while under-investing in the two or three systems that would genuinely hurt if they went down for a day.

What testing actually looks like

Testing doesn't need to mean a full-scale simulated disaster. It can start much smaller: picking one critical system and actually walking through the recovery steps, on paper first and then in practice, to see where the plan breaks down. Most businesses find their first gap within the first hour of doing this.

The businesses that get real continuity value from this work treat testing as a routine, not an event: a recurring exercise that catches drift before an actual incident does. Continuity isn't bought once. It's maintained, and the maintenance is where most mid-market setups are currently falling short.