Recovery Objectives
Defined RPO/RTO targets, criticality classification, and the capabilities that meet them.
Capture progress
3 of 8 fields captured
Maturity preview · Initial

Recovery objectives

Defined objectives

Recovery Point Objective — how much data the district can afford to lose, measured in time (e.g. "at most 4 hours of SIS edits"). Drives backup frequency. Per-tier RPOs (different for SIS vs file shares) reflect mature practice.

Recovery Time Objective — how long the district can afford to be down, measured in time (e.g. "SIS back online within 8 hours"). Drives recovery capability investment (hot/warm/cold). Per-tier RTOs (different for SIS vs file shares) reflect mature practice.

The point past which the district is in unrecoverable territory — instruction can't continue, finance can't close, the year is at risk. Different from RTO: RTO is the target, MTPD is the cliff.

Each district system tagged as Tier 1 (mission-critical) / Tier 2 (important) / Tier 3 (nice-to-have). Cross-reference with Data Stewardship's inventory (STW-INV F2) — same tier mapping should drive both stewardship and recovery.

Recovery capabilities

Where the recovery infrastructure lives relative to production. Multi-region (e.g. Azure paired regions) is the strongest; secondary on-prem site is acceptable; none means a site-level event takes everything.

Hot = warm production duplicate, ready in minutes. Warm = infrastructure standing, data sync periodic, hours to bring up. Cold = capacity-on-order, days to weeks. Match to the F2 RTO target.

Step-by-step recovery procedures, not just narrative. Per-tier runbooks reflect maturity; general runbooks are the floor; none means recovery is reconstructed under stress at incident time.

Named vendors and contracts the district depends on during recovery (Veeam reseller, MSP engineering hours, SIS vendor failover support). Unknown dependencies become acute pain points at incident time.

Notes