A backup report can show 100 successful jobs and still leave one unanswered question: can the business open its application, find the expected data and serve a customer after a real outage?
That question belongs in the MSP review. A green status proves a scheduled task completed. It does not prove that every required component was captured, the credentials and encryption keys are available, dependencies start in the right order, or staff can finish the recovery within an agreed time.
Separate three promises
High availability, replication and backup are not interchangeable. Replication can keep a service running through an infrastructure failure, but it may also copy corruption or an unwanted deletion. Microsoft’s Azure reliability guidance explicitly treats replication and backup as complementary controls because they protect against different risks. [1]
Define two business targets before discussing tools. The recovery point objective (RPO) is the maximum acceptable data loss measured in time. The recovery time objective (RTO) is how long the service can remain unavailable. “Daily backup” is not an RPO statement unless the business has accepted the possible gap and the MSP has proved it can restore within the required window.
Set targets by service. Payroll, the finance database, file shares, Microsoft 365 content and a public application do not automatically deserve the same schedule. Identify the dependencies too: identity, DNS, certificates, encryption keys, network rules, application configuration and vendor access can determine whether restored data is actually usable.
Demand a restore test, not a screenshot
NIST published specific guidance for MSPs to conduct, maintain and test backup files. It describes data loss as wider than ransomware: hardware failure, accidental deletion and intentional destruction all matter. [2] CISA’s ransomware guide likewise recommends offline, encrypted backups and regular testing of their availability and integrity. [3]
A useful monthly test can be narrow. Restore a selected file, mailbox item or small database to an isolated, non-production location. A quarterly exercise can go deeper: restore an application and its database, reconnect only the approved test dependencies, sign in as a test user and complete a representative business transaction.
Isolation matters. A recovery test should not overwrite production or reconnect an untrusted image to the live network. The runbook should name who authorises the test, who performs it, who validates the business result and who decides whether a failed test becomes an incident or corrective action.
Measure what actually happened
Start the clock when an authorised person requests recovery, not when an engineer finally opens the console. Stop it only when the agreed validation is complete. Microsoft’s 2026 cloud security benchmark recommends recording success status, actual recovery time, data validation and issues found, then comparing the result with defined RTO and RPO. It also recommends testing different scenarios, including point-in-time, individual-file and complete-system recovery. [4]
| Evidence | What management should see |
|---|---|
| Recovery point | Backup timestamp, expected cut-off and confirmed missing-data window. |
| Recovery time | Request, start, technical completion and business-validation times. |
| Validation | Named checks: login, record count, application function and dependency status. |
| Corrective action | Owner, due date, risk and retest date for every material gap. |
A checksum or “restore completed” message is only part of validation. For a database, Microsoft states that there is no reliable backup strategy until the backups have been successfully restored in every combination included in the restore strategy and each restored database has been tested for physical consistency. [5] Business validation must then confirm that the application behaves as expected.
Test a scenario the dashboard cannot answer
Hypothetical example: A 60-person Malaysian distributor chooses its order-management system for a quarterly drill. Its MSP restores the latest database and application configuration into an isolated network. The technical restore takes 55 minutes, but login fails because a certificate renewal was never added to the recovery runbook. The team fixes the dependency, validates a test order and records a total recovery time of two hours and ten minutes. This is an illustrative scenario, not an AXO customer case or a promised recovery time.
The value is the discovered gap. A failed or slow drill is not evidence that testing was wasted; it is the least expensive time to correct the runbook, access model or architecture. Repeat the test after remediation rather than closing the action when the document is updated.
Put proof into the MSP service review
Ask for a service-by-service recovery register, the last successful restore date, actual RTO/RPO evidence, exceptions and the next test. Review backup-administration privileges and ensure one compromised operational account cannot silently destroy every recoverable copy. Confirm how the customer retrieves backup data, encryption keys, configuration and documentation if the MSP relationship ends.
Do not turn this into a monthly full-disaster exercise. Use a risk-based cycle: frequent small restores, periodic application recovery and an annual cross-team scenario for the most critical services. The outcome should be a decision management can understand: recovery proved, recovery proved with gaps, or recovery not yet proved.
If your current report ends at “Success,” add one question to the next review: show us the last restore that a business owner validated.
For a practical review of managed backup, recovery testing and MSP accountability, contact AXO Technologies.
