Direct answer
An MSP backup platform must isolate tenants administratively and cryptographically, support delegated recovery roles, export customer-specific evidence and prevent one compromised operator from destroying multiple customers. Multi-tenant convenience should not create a single ransomware blast radius.
How to frame the decision
Vendor capabilities vary by edition, deployment model, region and contract date. Convert each material claim into a dated requirement, a contractual answer and a proof-of-concept result.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Tenant isolation | Verify data, keys, identities, policies and destructive actions across customer boundaries. | A cross-tenant access and deletion test. |
| Delegation | Separate monitoring, customer restore, policy administration and platform ownership. | Role tests for MSP and customer personnel. |
| Evidence and billing | Export service-level coverage, recovery tests, usage and exceptions per customer. | Customer-ready reports reconciled to billing units. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Require a dated vendor response and a proof-of-concept result for material claims.
- Translate the requirement into a pass/fail test for backup software requirements for an msp.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- One MSP administrator can delete every tenant and repository.
- Customer offboarding removes access to required historical recovery points.
- The platform reports successful jobs but not customer-level recovery confidence.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Keep commercial claims separate from tested technical evidence.
- A tested requirement exists for: Tenant isolation.
- A tested requirement exists for: Delegation.
- A tested requirement exists for: Evidence and billing.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
What backup features do MSPs need?
An MSP backup platform must isolate tenants administratively and cryptographically, support delegated recovery roles, export customer-specific evidence and prevent one compromised operator from destroying multiple customers. Multi-tenant convenience should not create a single ransomware blast radius. The deciding factors in this guide are tenant isolation, delegation, evidence and billing.
How should backup tenants be isolated?
Treat the answer as conditional on the actual environment and plan. Separate monitoring, customer restore, policy administration and platform ownership. Retain role tests for MSP and customer personnel.
Can customers perform restores without admin rights?
Do not rely on the product label or a successful backup job alone. Test the requirement directly: export service-level coverage, recovery tests, usage and exceptions per customer. Record the result with a date, operator and named exception owner.