MSP backup and BDR scope template: price the recovery work

Put restore testing, recovery labor and storage growth in the backup quote before the client signs.

A backup subscription creates several separate jobs: protecting the named data, responding to failed jobs, proving that a recovery path works, and restoring service during an incident. Your vCIO or account manager needs to explain which jobs the client is buying. Engineering needs enough detail to deliver them. The owner needs a cost model that includes the people doing the work.

Use the template below after choosing the backup stack and before approving the service scope. It works for a Microsoft 365 tenant, an on-premises server estate or a mixed client. Complete a separate row for each recovery scenario. A file restore and a lost-site recovery deserve different plans.

Start with the business service, then list the workloads

Ask the client what must work again before the business can operate. "The server" is rarely a complete answer. The service may also depend on identity, networking, an application vendor, a license service or staff who can validate the recovered data.

NIST's contingency planning guide connects recovery planning with business impact, requirements and priorities. Use that planning principle to set the scope with the business owner. It doesn't make an SMB backup package a compliance certification.

Copy this register into discovery:

For Microsoft 365, name the tenant and selected data sets. Do not use the number of licensed users as a substitute for defining what is protected. Confirm the chosen backup product's coverage and restore method with its documentation and a test. This template makes no vendor coverage promise.

In Connectwise Manage, reconcile the scope with the client, agreement and relevant configuration records your team actually maintains. Check the RMM and tenant inventories before accepting a quantity. Treat a mismatch as a discovery task, not a convenient rounding error.

Separate the recovery objective from the evidence

A recovery point objective describes the point in time to which data must be recovered. A recovery time objective sets the recovery-time requirement. Keep the client's required objective, the designed capability and the observed test result in separate fields.

For example, the client may require its order-processing service to return within a particular window. A test that starts after the engineer has downloaded the data does not measure the whole journey the client cares about. Record the clock boundaries and dependencies so the result can be interpreted.

Use three statuses:

• Tested for the named scenario: the evidence records the recovery point, elapsed stages and business validation.
• Designed but untested: the architecture has a recovery path; the test is still outstanding.
• Gap requiring a decision: the design or test misses the client's requirement. Assign remediation, an alternative target or a documented client decision.

A successful test supports its tested conditions. It cannot guarantee the duration of a future incident with different data volumes, infrastructure or access conditions.

CISA's StopRansomware guidance recommends offline, encrypted backups of critical data and regular tests of availability and integrity in a disaster recovery scenario. That gives the test a purpose beyond collecting a green screenshot.

Copy this backup and BDR scope skeleton

Replace the bracketed fields. Have the technical lead validate the recovery design and the agreement owner review the commercial terms.

Client and service owner: [name / role]
Service start and scope version: [date / version]

Protected inventory:
[named workloads and quantities; link to the agreed register]

Protection design:
[backup product, policy, destinations and access ownership]
[retention and recovery-point settings by workload]
[offline or isolated-copy design and its validation]

Monitoring and response:
[review cadence, covered hours and assigned MSP queue]
[failed-job triage, escalation and client communication]
[dependencies on client action or vendor support]

Recovery scenarios:
[named scenarios, locations, objectives and prerequisites]
[incident authorization and recovery decision owner]
[what must be validated before service is considered restored]

Planned restore tests:
[scenario, sample or full scope, frequency and test location]
[engineer owner, client validator and approved test window]
[deliverable, exception handling and retest allowance]

Commercial boundary:
[one-time discovery, onboarding and initial acceptance test]
[recurring protection, monitoring and planned testing]
[included storage quantity and excess-usage treatment]
[emergency recovery, after-hours work and vendor charges]

Exclusions and prerequisites:
[named unprotected data, unsupported systems and client duties]
[access, recovery capacity, application support and approvals]

Acceptance and review:
[evidence needed to accept onboarding]
[client approver and unresolved-gap disposition]
[inventory / capacity review cadence and change process]

Fill exclusions with specific systems and work, not "anything else." If SaaS data, a client-owned NAS or a contractor's device is outside the service, name it. Put that boundary beside the protected inventory where the client will read it.

For the wider agreement structure, use the MSP scope of work template. For control and evidence ownership shared with a client or another provider, use the responsibility matrix.

Price the service in separate lines

Separate onboarding, recurring protection, planned testing and incident recovery. You can bundle the client-facing price while preserving those cost buckets internally.

Keep a second working table for quantity, unit cost, extended cost, sell price and gross margin. Use supplier billing terms as they are written. Retention, storage growth, protected workload counts and recovery infrastructure can change the cost base even when the client count stays flat.

Agree how changes are handled: scheduled reconciliation, a stated allowance, approved scope revision or another explicit mechanism. "Pass-through" still needs a billing basis the client understands.

Illustrative monthly cost model

This is scenario math, not a vendor price, market benchmark or promised margin. All inputs below are invented planning inputs for the example. Replace them with your supplier quote and fully loaded delivery costs.

At a scenario target gross margin of 40%, the modeled monthly sell price is $650:

Sell price = direct cost / (1 - target gross margin)
$390 / (1 - 0.40) = $650
Gross margin = ($650 - $390) / $650 = 40%

The test allocation funds the planned quarterly work in this example. It does not fund unlimited retests or incident recovery. Discovery, onboarding, runbook creation and emergency recovery are outside this monthly example. Price them separately or add their costs to the model if you include them.

Use actual time records to review the labor assumptions. If failed-job triage keeps exceeding the allowance, investigate the workload or design problem before treating the extra hours as permanent background noise.

Give the client a restore-test record they can use

A test deliverable should let the account manager answer what was restored, what worked and what still needs a decision. Avoid dumping a vendor status report into the QBR and expecting the client to decode it.

Copy these fields into the test record:

• Client, business service, protected workload and approved test scenario.
• Engineer, client validator, test date and authorized location.
• Recovery point selected and the data-loss interval assessed.
• Start and finish times for preparation, data recovery and business validation.
• Checks performed: data integrity, permissions and relevant application behavior.
• Result against the agreed objective, with the conditions of the test.
• Exceptions, blocked dependencies and evidence location.
• Remediation owner, next action, retest decision and approval.
• Cleanup confirmation and the next planned test.

Use an approved isolated destination when the test requires separation from production. Define the access and cleanup procedure before copying client data. A test that creates an unmanaged copy introduces another problem to own.

Bring a decision to the QBR

The account manager's summary can be short:

"We tested this recovery scenario and recorded the result against the target you approved. This dependency prevented the full business-service test. The recommendation is the work listed here, with an owner, cost and next test. Until that is resolved, this scenario remains unproven."

Show the finding, explain the business effect and put the remediation into the roadmap or scope. Keep the tested result intact even when the budget decision is uncomfortable.

Scopable's assessment and scoping workflow helps organize client findings, assumptions and recommendations into a reviewable scope before quoting. Use that layer for the client decision and handoff. Your backup platform and delivery team still perform protection and recovery testing.

To carry a client's recovery findings into reviewed scope, start Scopable for free.

Related backup decisions

Use the relevant comparison for the product choice, then return to the scope template for the service you will deliver:

• Datto BCDR vs Acronis or the wider Datto, Acronis and Axcient comparison.
• Veeam vs Acronis and Veeam vs Axcient.
• Wasabi vs Backblaze B2 for the storage decision, or Synology Active Backup vs Veeam for a NAS-centered comparison.
• Live client data in MSP quoting for the quantities and assumptions behind the quote.