Many MSPs already protect client data. Far fewer sell that protection as a named continuity service with recovery objectives, test cadence and a clear commercial shape. Clients who only see “backup included” struggle to value it, and you struggle to fund the design and testing that make recovery real.
This guide is for UK MSPs who want to package DRaaS and managed BCDR under their own brand — without building a second data centre. It covers why clients buy continuity as a product, which building blocks to combine, what belongs in your proposal versus a specialist partner SLA, packaging patterns, and common objections.
For the partner model itself, see also How can I offer DRaaS to my clients? and What is DRaaS and why is it important?.
Why clients buy continuity as a named service (not a buried “backup tick”)
When backup sits as a line item under “managed IT”, clients often assume copies exist somewhere and everything will come back. That assumption rarely survives the first serious ransomware, site outage or Microsoft 365 deletion incident. Backup frequency, retention, offsite copies, restore ownership and tested runbooks are design choices — not defaults.
A named continuity service makes those choices explicit. You sell outcomes the client can take to the board: which systems are covered, what Recovery Time Objective (RTO) and Recovery Point Objective (RPO) you are designing for, how often restores are tested, and who declares a disaster. Scope is clearer, change control is easier, and renewals are about risk reduction rather than whether “backup was included”.
The conversation shifts from “do you take backups?” to “how quickly can we restore payroll, email and the systems that keep revenue moving?” Clients facing insurance questionnaires or supply-chain due diligence respond better to a packaged offer than to a tick on a managed-services schedule.
Building blocks: onsite, offsite DR, file/folder, SaaS
Most MSP continuity offers are assembled from a small set of building blocks. You do not need every block for every client; you need a coherent set that matches their risk and budget.
Onsite business continuity and disaster recovery keeps recovery close to the client environment. Local restore and, where designed, local failover can shorten downtime for hardware failure or a limited incident that does not take out the site. See onsite BCDR.
Backup and offsite DR protects against site-level loss — fire, flood, prolonged power failure, or a ransomware event that compromises local copies. Offsite replication and a path to recover away from the primary location are the backbone of many DRaaS designs. See backup and offsite DR.
File and folder backup covers essential user data and application files that need fast, granular restore without waiting for a full server recovery. It often sits alongside broader workload protection rather than replacing it.
SaaS backup addresses Microsoft 365, Google Workspace and similar platforms. Provider retention and recycle bins are not the same as an independent recovery copy. Accidental deletion, ransomware that hits synced files, and admin mistakes still happen. Treat SaaS as a distinct building block — see SaaS backup — not as something “covered because the vendor is in the cloud”.
A practical MSP catalogue often uses two or three tiers: a baseline of offsite backup plus SaaS for mail and files; a mid tier with stronger RTO design and onsite continuity for critical workloads; and a higher tier with DRaaS failover and documented tests. Keep the language consistent with what you can deliver and test.
What belongs in the MSP proposal vs the specialist partner SLA
Clarity here avoids the classic failure mode: the client thinks you own every recovery decision, while your specialist partner thinks you only own the relationship.
Usually belongs in the MSP proposal (client-facing):
- Scope of systems and data included (and explicitly excluded)
- Commercial packaging, billing under your brand, and renewal terms
- Target RTO/RPO stated as design goals for the agreed scope
- Who the client contacts first, escalation paths, and how an incident is declared
- How often restores or failover exercises will be reported to them
- Change control when they add servers, sites or Microsoft 365 seats
Usually belongs in the specialist partner SLA (MSP ↔ partner):
- Platform operation: replication health, monitoring, maintenance windows
- Technical recovery procedures, runbooks and failback steps
- Infrastructure capacity and any shared recovery environment constraints
- Partner response times once you escalate a declared event
- How often the partner tests restores and how results are shared with you
- Data handling, access control and exit arrangements for the protected estate
Your job is to remain the face of the relationship. The partner’s job is to operate the recovery stack against that SLA so you are not inventing a second data centre in-house. Map both documents carefully: if the client proposal promises a four-hour RTO for a workload the partner design cannot support, you own the gap. Align proposals to what the partner can evidence in testing.
Pricing and packaging patterns (structures only)
Exact rates belong to your commercial model and partner costs — this post does not invent them. What you can standardise are structures clients recognise and that scale across your book.
Per endpoint or per device works well where protection is tied to workstations or a clear device count. It is easy to quote and to adjust when headcount changes. Watch for servers and shared storage that do not map cleanly to “a laptop”.
Per workload or per server / VM suits estates where a handful of systems carry most of the risk. Pricing follows what you actually protect and recover. Pair it with clear rules for new VMs so shadow IT does not expand scope unpaid.
Per user / per mailbox / per SaaS seat is the natural shape for Microsoft 365 and Google Workspace backup. Align seat counts with the tenant you are protecting and define what happens when licences are added mid-term.
Capacity-based (protected data volume) can fit large file estates or growing repositories. Be explicit about how growth is measured and billed so renewals do not become a surprise.
Tiered by RTO / recovery design is often the clearest continuity story: Bronze for backup and restore with longer recovery windows; Silver for faster restore and stronger offsite design; Gold for DRaaS-style failover of named workloads with scheduled tests. Clients compare tiers on outcomes, not on feature checklists they do not understand.
Many MSPs blend patterns — per-workload for servers, per-seat for SaaS, and a tier label for RTO. Keep exclusions written down (development systems, personal OneDrive, unmanaged SaaS apps) and revisit after major changes.
Common objections and how to answer them
“We already pay for Microsoft / Google — isn’t that enough?”
Shared responsibility means the provider keeps the service running; you still need a recovery copy for deletion, corruption and many ransomware scenarios. Retention is not backup. Point them at a plain explanation of SaaS backup and walk through one restore scenario they care about (for example a leaver’s mailbox or a wiped SharePoint library).
“Backup is already in our managed service.”
Agree that copies may exist — then ask when the last restore was tested, what RTO they believe they have, and whether offsite and ransomware-ready copies are in the design. Reframe the upsell as making those answers contractual and reportable, not as “more backup software”.
“We’ll build DR ourselves when we’re bigger.”
Secondary sites, replication tooling and 24/7 recovery process are capital and skills projects. A partner-backed DRaaS model lets you offer the outcome now and revisit ownership later if the numbers ever justify it. See How can I offer DRaaS to my clients?.
“Failover sounds expensive for an SME.”
Not every client needs full DRaaS on day one. Start with offsite backup, defined RPO and tested restores; add onsite continuity or failover for the workloads where downtime cost is obvious. Tiered packaging exists precisely so SMEs are not forced into an all-or-nothing buy.
“We can’t sell what we don’t operate.”
You sell and support the client relationship; a specialist operates the platform under SLA. Your engineers still need enough product knowledge to escalate cleanly and to set expectations — they do not need to run the recovery fabric themselves. That split is the core of the MSP partner model.
“Prove it works.”
Build test evidence into the package: scheduled restore reports, occasional failover exercises for higher tiers, and a short post-incident review format. Continuity without testing is a promise, not a service.
Closing
Packaging DRaaS and BCDR as a named MSP service line is less about acronyms and more about clear scope, honest RTO/RPO language, the right mix of onsite, offsite and SaaS building blocks, and a clean split between your proposal and your partner SLA. Get those right and continuity is easier to sell, renew and deliver when it counts.
If you want to map a white-label or under-your-brand offer to your current stack, book a free consultation (opens in a new tab), email [email protected] or call 01386 898324.