The Real Gap in MSP Backup and BCDR Operations

Backup and BCDR are shifting from a line item you resell to a staffed, tested operational discipline, and the gap between what an MSP assumes its backups can do and what they actually do under real conditions is the biggest risk on the table. Closing that gap, not buying another point tool, is what turns a BCDR practice into a margin line instead of a liability.

The confidence gap that shows up during a real incident

More than 60% of organizations believe they can recover from a downtime event within hours, but according to Unitrends' State of Backup and Recovery Report 2025, only 35% actually could. That gap does not close itself. It closes when someone owns the restore process end to end, documents it, and proves it works before a client ever needs it.

For an MSP, this is the difference between a backup product and a BCDR service. A product ships a nightly job and a green checkmark. A service assigns an owner, a tested recovery time, and a client-facing report that shows the restore actually happened. Clients paying a recurring fee for business continuity are buying the second thing, whether or not that's what they're technically receiving today.

The confidence gap also shows up at renewal time, not just during an incident. A client who asks for proof of a successful restore test and gets a shrug instead of a report is a client who starts pricing out other providers, and a cyber insurer asking the same question during underwriting puts that same gap in front of someone who can cancel the policy over it. Either way, the cost of not being able to answer the question lands on the account team, months after the backup job itself ran fine.

Why does testing cadence keep slipping?

Testing slips because it competes with billable work, and nobody schedules time for the thing that only pays off during a disaster. A quarter of organizations test disaster recovery once a year or less, according to the same Unitrends report. That cadence leaves most restore plans unverified for most of the year they're relied on.

The staffing cost is part of why testing gets skipped. Over half of organizations spend 10 or more hours a week just managing backups, per Unitrends' 2025 report. That figure covers management, not the verification testing that would need to happen on top of it. When a technician is already spending a full workday a week keeping backup jobs green, adding a disciplined quarterly restore test to every client feels like the thing that gets cut when a fire drill shows up.

This is an operational math problem, not a willpower problem. If restore testing isn't built into a standard, repeatable runbook with a fixed time budget per client, it will always lose to whatever is on fire that day.

What tool sprawl costs an MSP running BCDR as a line item

Cost management is the single biggest challenge MSPs report in delivering backup-as-a-service, cited by 35.9% of MSPs, according to Infrascale's BaaS Statistics for MSPs USA 2025. That's not surprising when BCDR often runs on a different platform than the RMM, the PSA, and the documentation tool a technician is already living in.

Integration matters more than most MSPs price for it. About 95% of MSPs say connecting their RMM, PSA, and IT documentation tools is essential for running smooth, scalable operations, according to Kaseya's 2025 Global MSP Benchmark Report findings. A BCDR platform that lives outside that connected stack means a technician toggling between systems to check a backup job, log a ticket, and update client documentation, and every toggle is time not billed and a place a restore step can get missed.

Attackers have adapted to exactly this operational reality. Ransomware groups increasingly target backup infrastructure early in an intrusion specifically to prevent recovery, according to ConnectWise's 2026 MSP Threat Report. A fragmented BCDR stack with inconsistent access controls across tools gives an attacker more surface to find and disable the one thing that would let a client recover without paying.

Every platform an MSP adds to the BCDR line is another login to secure, another vendor to keep current on patching, and another system a new technician has to learn before they can safely touch a client's recovery plan. None of that shows up on the invoice a client sees, but all of it shows up in onboarding time, in training cost, and in how long it takes a night-shift technician to find the right console when a client actually calls in with a failed server at two in the morning.

How do you turn BCDR into a margin line instead of a cost center?

You standardize the runbook, price the testing, and stop treating verification as optional overhead absorbed into the managed services fee. Standards guidance is blunt about the baseline: CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups and testing them on a regular basis. That's a testing requirement, not just a job-completed notification in a monitoring dashboard.

A BCDR runbook that holds up under a real incident, and under a client or cyber insurer asking for proof, usually covers the same handful of things for every client:

• A documented recovery time and recovery point target per client tier, not a single assumed number for the whole book
• A fixed, calendared restore test cadence, with the result logged and shared with the client
• An escalation path that names who executes the restore and who approves it under pressure
• Verification that at least one backup copy is offline or immutable and confirmed unreachable from the production network
• A short, standardized client-facing report proving the last test, not just the last backup

Pricing this as a distinct, tiered service line, rather than folding it silently into a flat managed services rate, is what lets an MSP staff the testing work without eating the cost every quarter. A basic tier might guarantee a documented annual test with a best-effort recovery window, while a premium tier guarantees quarterly tests, a contracted recovery time, and a named on-call recovery lead. The point is not the exact tier structure, it's that the work of testing is visible, priced, and staffed instead of assumed to happen for free inside the base contract.

What does standardized testing actually save?

Hypothetical example: assume an MSP manages BCDR for 40 clients, and an unstructured, ad hoc verification process costs a technician 3 hours per client per quarter at a fully loaded rate of $60 an hour. That works out to 480 hours a year, or $28,800 in labor, spent proving backups work only after something has already gone wrong. Standardizing the runbook and cutting verification time to 1 hour per client per quarter would bring that down to 160 hours, or $9,600, freeing roughly $19,200 in technician time for billable work elsewhere.

That kind of standardization is exactly the provisioning and workflow discipline Catalyst is built to productize, so a white-label BCDR practice runs on one consistent process instead of whatever each technician happens to remember. If you're still deciding whether BCDR belongs in your core stack or as a separate add-on tier, the stack builder walks through how it fits next to the rest of what you sell.

Where this leaves your BCDR line

The MSPs that make money on BCDR are not the ones with the newest backup software. They're the ones who treat recovery as a rehearsed, staffed, and reported process, because that's what actually closes the gap between believing a client can recover and proving it. Everything else, the platform, the storage tier, the retention window, is a supporting decision underneath that operational commitment.

None of that requires ripping out an existing backup platform. It requires deciding who owns the testing calendar, what a client sees as proof, and how that work gets priced instead of absorbed. Get those decisions right and the platform underneath them becomes a much smaller argument, because the operational discipline is what a client is actually renewing every year, not the storage vendor's logo on the report.

A full breakdown of how BCDR fits alongside the rest of a white-labeled security and operations stack is in the product catalog. See the full stack to see where a productized BCDR line slots in next to the rest of what you already sell.