The business continuity planning industry has a problem it rarely acknowledges: most of the plans it produces don't work.
Not in the sense that they are poorly written or technically incorrect. Many of them are well-structured documents that accurately describe a recovery framework. They fail because the organization cannot execute them — because the plan was built in a way that optimized for completion rather than for use, and because it was never tested against the conditions under which it would actually be needed.
This failure pattern is particularly pronounced in mid-market organizations. Not because mid-market companies are less capable than large enterprises, but because the structural conditions that make business continuity programs work are harder to sustain in organizations without dedicated resilience functions.
Why Do Mid-Market BCPs Fail? Five Structural Reasons
1. The Plan Was Built Once and Handed Off
In large enterprises, business continuity is a function — typically staffed by a dedicated team that maintains the program, monitors regulatory developments, manages the exercise calendar, and updates the plan as the organization changes. In mid-market organizations, the BCP is typically a project. A consultant builds it, an internal owner accepts delivery, and the program maintenance that the plan assumed would happen — does not.
The result is a plan that accurately describes the organization as it existed when the plan was written. Twelve to eighteen months later, the systems have changed, the key personnel have changed, the vendors have changed, and the contact trees in the plan route to people who left the company.
A business continuity plan is a living document that requires active maintenance. A mid-market organization that does not have either a dedicated internal owner or an ongoing external program partner will find that its plan degrades from the moment it is delivered.
2. The Business Impact Analysis Was Not Rigorous
The Business Impact Analysis (BIA) is the foundation of a business continuity program. It identifies the organization's critical functions — the processes and systems whose failure would cause unacceptable harm — and establishes the recovery time objectives (RTOs) and recovery point objectives (RPOs) that drive the plan design.
In mid-market BCP engagements, the BIA is frequently the step that receives the least rigor. It is conducted through a limited set of interviews with senior leaders who describe what they believe are the critical functions, without engaging the operational managers and technical staff who know what those functions actually require to run. The RTOs are set based on what feels reasonable in a conference room, not based on what is actually achievable given the systems, vendors, and personnel involved.
A BIA conducted at insufficient depth produces a plan designed around the wrong priorities, with recovery targets that cannot be met. When a disruption occurs and the plan is activated, the mismatch between what the plan says and what is actually possible is the first thing everyone discovers.
3. IT Disaster Recovery and Business Continuity Were Not Integrated
Business continuity covers the whole organization. IT disaster recovery covers the systems. The two are not the same, and the plan that addresses one without adequately integrating the other will fail when both are needed simultaneously — which is the scenario most disruptions produce.
In mid-market organizations, the business continuity plan and the IT disaster recovery plan are often built separately, by different teams, with different assumptions about what the other team will provide. The business continuity plan assumes that systems will be available within the RTO the IT team committed to. The IT team's actual recovery capability, when tested, is significantly longer than that commitment.
The gap between what the business continuity plan assumes about IT recovery and what IT can actually deliver is one of the most consistent findings in tabletop exercises. It is not discovered until the exercise, or the incident, forces both teams into the same conversation.
4. The Plan Was Never Tested
This is the most fundamental failure and the most common. A business continuity plan that has never been tested through a tabletop exercise is a set of assumptions documented as facts. It describes what the organization believes will happen — not what will happen — when a real disruption forces the organization to execute.
The assumptions that matter most are the ones about people. Which leaders will be available at 3:00 AM on a Tuesday when the incident occurs? Who actually has the authority to make the financial commitments the plan requires? Which employees know their roles well enough to execute without someone walking them through it?
These questions are answered in exercises. They are discovered in incidents. The discovery cost in an exercise is a few hours of organizational time and a revised plan. The discovery cost in an actual disruption is measured in operational harm, financial loss, and reputational damage that no plan can fully address after the fact.
5. The Plan Owner Does Not Own the Program
Every business continuity plan has a named owner — typically a COO, a risk officer, or a senior HR or operations leader. That person is accountable for the plan's existence and its formal compliance status. They are not always the person who could actually explain what the plan says, identify its current gaps, or describe when it was last reviewed.
Program ownership in a meaningful sense requires engagement — regular review, familiarity with the content, participation in exercises, and accountability for updates. In mid-market organizations where the plan owner has significant other responsibilities, BCP program ownership is frequently nominal rather than substantive.
A plan without an engaged owner is a plan without an advocate for the resources, the attention, and the organizational will required to maintain it. It is also a plan that will be presented to a board, an auditor, or an insurer as evidence of resilience that the organization does not actually have.
What Distinguishes a Business Continuity Program That Actually Works?
The business continuity programs that work when needed share a set of characteristics that are visible before any disruption occurs.
A genuine BIA.The critical function identification was done through structured interviews with operational and technical owners, not just senior leadership. The RTOs are based on what is actually achievable, not what leadership wanted to hear. The plan is built around the organization's real dependencies, including third-party vendors and systems.
Tested recovery procedures.At least the most critical recovery procedures have been walked through — not in a tabletop discussion but in an actual test, where the people who will execute them have done so in a controlled environment. IT recovery procedures, in particular, should be tested before they are relied upon.
An exercise program.Annual tabletop exercises at minimum. A facilitator who is not invested in making the plan look good. Scenarios calibrated to the organization's actual risk profile. Documented after-action reviews that produce plan updates, not just commendations.
An engaged program owner. The person responsible for the BCP can describe what it says, when it was last reviewed, and what the current open items are. They participate in exercises. They have the organizational authority to get resources allocated when gaps are identified.
Integration with IT.The business continuity plan and the IT disaster recovery plan are consistent — the RTOs the BCP assumes for systems are the same RTOs the IT team has committed to and tested. The two teams have participated in exercises together.
A maintenance cadence.The plan is reviewed on a defined schedule — minimally annually — and updated whenever significant organizational changes occur. The contact trees are current. The system inventory reflects current infrastructure. The vendor list includes current critical vendors.
What Advantage Do Mid-Market Organizations Have?
The structural challenges that mid-market BCPs face are real. But mid-market organizations have an advantage that large enterprises frequently do not: the people who make decisions are close enough to the people who execute decisions that communication during a crisis is not a multilayered organizational challenge.
A well-built, actively maintained business continuity program in a mid-market organization can be more agile and more effectively executed than an enterprise program buried under governance layers and committee approvals. The constraint is not organizational complexity. It is investment — the decision to treat business continuity as a real program rather than a compliance artifact.
That decision is usually made once, after an incident, by leadership that wishes they had made it earlier. The organizations that make it proactively — often starting with a structured BCP engagement — spend a fraction of what the reactive ones do, and they make it in a context where they still have the full range of options available to them.
Kestralis Group builds and maintains business continuity programs for mid-market organizations — Business Impact Analysis, plan development, tabletop exercise facilitation, and annual program retainer. Engagements are led by a Certified Business Continuity Professional. Contact us to discuss your organization's current posture.
