Outsourced Backup Monitoring for MSPs

This guide concerns the people and operating scope around your backup products. Keep software licenses, storage, retention, recovery infrastructure and the customer's business requirements visible in the same proposal.

Buy four results separately

Put a named owner beside each result. If backup monitoring is bought only as alert handling, keep restoration with an accepting internal team or a separately contracted service. If restoration is included, define its authority and completion criteria before a live incident.

What a verification result means

Veeam's SureBackup job documentation ↗ (external website) distinguishes two modes. Full recoverability testing starts machines from backup in an isolated environment and tests live applications. The verification-and-content-scan mode checks backup integrity and content without that virtual lab. Ask for the configured mode, the restore point and the actual result, rather than accepting the product name alone.

Its verification-options documentation ↗ (external website) also separates boot checks from application tests. A heartbeat or ping result describes its selected check. Specify the application test or script, required dependencies and expected outcome for your workload. This product example supplies questions for your own platform; confirm its inclusion in the proposed supplier scope.

For recovery after a cybersecurity incident, NIST SP 800-61r3, physical PDF page 42 ↗ (external website) separates checking restoration assets before use, validating essential services with system owners and confirming restored systems before return to normal operations. Suspected compromise needs the incident lead and security response as well as a person who can run a restore.

Published NOC scope examples

The following purchases show why the service name needs its operating scope. Open a service to read its dated source and prepare a request for that exact choice.

The Watch description already includes reactive remediation and restoration. Care adds explicit backup verification and restore validation. Ask what those words mean for your backup product and workload; the wider ITBD training list supplies separate context about products. For ConnectWise, keep the named BCDR product, RMM package eligibility and enabled sites in the order.

Worksent's Standard/Premium NOC table marks backup checks excluded in Standard and included in Premium. Confirm the purchased plan and what happens after a failed check; that entry alone does not promise restore validation.

Keep response and recovery clocks separate

Uptime's NOC brochure, physical PDF page 7 ↗ (external website) lists first-response targets of 30 minutes, two hours and eight hours by priority, each with a 90% target. Those are first-response figures. Obtain the restoration objective and its start, stop and exclusion rules separately.

Illustrative times, not a service result: the agreed incident start is 02:00 UTC, acknowledgement is 02:05, the selected restore point is 00:00 and the application owner accepts recovery at 03:20. Response took five minutes. The selected point is two hours before the agreed incident start. The interval from that start to accepted operation is 80 minutes. Compare each observation with the separately agreed objective and its measurement rules.

Preserve the selected restore point, verification result, authorization, execution times and application acceptance in the case log. The SLA guide explains the separate service clocks. A fast response leaves data age and usable service as separate questions.

Agree authority and the full cost

• Name who may observe jobs, retry failures, change backup policy, run an isolated test and restore into production. Each action can have a different approver and role.
• Define the recovery target and isolation boundary. Agree who handles conflicting live changes and the return to the primary environment.
• Keep backup administration, deletion rights, retention changes and emergency recovery authority separate. Use the access handover plan when replacing a supplier.
• Request charges for monitored units, failed-job work, verification runs, restore labor, recovery compute, storage or transfer, licenses and work outside the purchased window. Mark inapplicable items explicitly.
• State who maintains the job inventory and notices a missing or newly added workload. Assign the next action when a restore point or test is unavailable.

Use a blank scope and restore log

Keep job monitoring, failure work, verification and recovery as four obligations. The blank log also keeps five action permissions, one restore case, charges and the acceptance decision together.

Download blank backup scope and restore log (.md)

# Backup Scope and Restore Acceptance Log

Use with https://mspshortlist.com/guides/outsourced-backup-monitoring/

Complete this blank log with the authorized MSP, supplier and application owners. Use an agreed test workload for a trial. Store ticket or result references rather than passwords, keys or client data.

## Purchased scope

- Buyer and supplier: __________
- Exact service, order and revision: __________
- Tenant, workload and backup product/version: __________
- Job inventory and owner responsible for changes: __________
- Backup copies, retention and required restore-point age: __________
- Monitoring window, timezone and missed-job trigger: __________
- Ticket queue and receiving escalation owner: __________

## Four separate obligations

| Obligation | Assigned owner | Trigger / timing objective | Completion and accepting owner |
| --- | --- | --- | --- |
| Monitor jobs and missing schedules | __________ | __________ | __________ |
| Remediate allowed failures | __________ | __________ | __________ |
| Verify a usable restore | __________ | __________ | __________ |
| Execute an approved recovery | __________ | __________ | __________ |

## Action authority

Leave the permission blank until the responsible owner authorizes it. An unfilled cell grants no action.

| Action | Allowed / approval required / excluded | Identity or role and approver |
| --- | --- | --- |
| Observe job status | __________ | __________ |
| Retry a failed job | __________ | __________ |
| Change schedule, policy or retention | __________ | __________ |
| Restore into an isolated test environment | __________ | __________ |
| Restore into production | __________ | __________ |

## One restore case

- Case or ticket reference and workload: __________
- Agreed incident start and timezone: __________
- Alert / request received and acknowledged: __________
- Selected restore point and selection owner: __________
- Verification mode, required checks and result reference: __________
- Authorized target, isolation boundary and dependencies: __________
- Recovery approval, identity and time: __________
- Execution started and finished: __________
- Application check, accepting owner and time: __________
- Observed data age and return interval, with measurement rules: __________
- Open faults, next owner and next update: __________
- Return to primary environment and rollback owner: __________

## Commercial and acceptance decision

- Included units, verification runs and recovery labor: __________
- Extra compute, storage, transfer, licenses and excess-work charges: __________
- Decision, reviewer and date: __________
- Required correction and retest reference: __________

No supplier test, recovery result, permission or acceptance decision is prefilled.

Before expanding access, use an authorized test workload to sample a missing-job alert, an allowed retry, an approval hold, a failed verification and acceptance of a restored application. Choose the expected outcomes with the responsible owners first. These are proposed cases for your team; no supplier exercise or live restore is reported here.

The NOC pilot plan provides the wider case log and acceptance decision. Compare the purchased scope with the NOC directory and the pricing guide, then keep the same backup requirements in each supplier's RFP.