Managed Backup and Disaster Recovery: Scope, RTOs, and Testing

Backup is a copy; disaster recovery is the people, systems, priorities, and procedures needed to restore business operations. Buyers should verify coverage by workload, retention, protection, recovery point, recovery time, test method, responsibilities, and exclusions. “Unlimited” is meaningful only when attached to exact workloads and contract terms.

Define the service boundary

• Microsoft 365, Google Workspace, endpoints, physical and virtual servers, databases, cloud resources, identity systems, configuration, and SaaS applications.
• Included data, metadata, versions, permissions, encryption, immutability, and retention.
• Storage caps or unlimited terms by workload.
• Network, compute, licensing, egress, and emergency-service dependencies.
• Customer, ITECS, platform, and third-party responsibilities.

Set RPO and RTO from business impact

A recovery point objective defines tolerable data loss in time; a recovery time objective defines tolerable service interruption. Both should be approved by business owners and mapped to backup frequency, replication, recovery sequence, staffing, vendor dependencies, and cost. Neither is a guarantee unless the contract says so and testing supports it.

Protect recovery from the incident

CISA’s ransomware guide recommends offline, encrypted backups and regular testing of availability and integrity. Use separate administrative paths, MFA, least privilege, immutable or offline copies where appropriate, monitored deletion, protected configuration, and credentials that are not exposed through ordinary production access.

Test evidence, not job status

A successful backup job does not prove application recovery. Test representative files, mailboxes, permissions, databases, systems, dependencies, and business workflows. Record actual recovery point, elapsed time, integrity checks, owners, defects, and corrective actions. Repeat after architecture and process changes.

Next step for your environment

Create a recovery matrix listing each workload, owner, scope, exclusions, retention, RPO, RTO, backup identity, restore method, last test, evidence, and next test. If you need a documented baseline before changing production systems, start with an ITECS technology and security assessment.

Record the accountable owner, current baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, model availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.

Sources and update trigger

• ITECS — Backup and disaster recovery service scope
• NIST — Cybersecurity Framework
• CISA — StopRansomware Guide

Review trigger: Review after workload, licensing, retention, storage, architecture, vendor, RPO/RTO, incident, test, or contract changes.