When recovery is under pressure, teams cannot afford to debate what should be restored first. A pre-defined priority worksheet ensures that restore sequence is a documented decision, not a spontaneous one made during an incident.
The Priority Trap
Without a documented priority order, the loudest stakeholder determines what gets restored first. This rarely aligns with technical dependency chains, resulting in systems that are restored but cannot function because their upstream dependencies are still down.
How to Use This Worksheet
Complete this worksheet for each system in your recovery scope before an incident occurs. Review and update it whenever infrastructure changes, new services are added, or dependency relationships evolve. The worksheet should be approved by both technical leads and business stakeholders.
Priority Tier Definitions
Systems are assigned to tiers based on their role in the infrastructure stack. Lower tiers must be verified operational before higher tiers begin recovery. This prevents cascading failures from upstream dependencies.
Priority
What returns first and why. Without a defined restore sequence, teams attempt parallel restorations that fail when upstream dependencies are missing.
Active Directory / LDAP directory services.
DNS resolution infrastructure.
Network routing, firewall rules, and VLAN configuration.
Dependencies
Every restored system depends on other systems, credentials, network paths, and storage locations that may not exist in the recovery environment.
Database servers and clusters (SQL, PostgreSQL, MongoDB).
Storage area networks and shared file repositories.
Message queues and caching layers (Redis, RabbitMQ).
Assumptions
Teams carry silent assumptions about what will be available during recovery. Testing validates or disproves these assumptions before they cause failures.
Application servers and API gateways.
Background workers and scheduled job processors.
Authentication and authorization middleware.
Ownership
Recovery requires decisions at every stage. Without pre-assigned ownership, decisions stall or conflict.
Web servers and load balancers.
Desktop and mobile application backends.
Reporting and analytics dashboards.
Verification
“Files restored” is not “service operational.” Verification must test at the application level, not just the file level.
Development and staging environments.
Archival and logging systems.
Internal tools and administrative interfaces.
Worksheet Output
The completed worksheet produces a documented restore sequence, approved by technical and business stakeholders, that can be executed without debate during an incident. Each system has a tier, a dependency list, and a verification criterion.
The worksheet should be approved by the lead infrastructure engineer (technical feasibility), the application owners (business priority), and the incident commander (operational coordination). All three perspectives are required to ensure the sequence is both technically sound and business-aligned.
The worksheet should be reviewed quarterly and updated whenever new systems are added, dependencies change, or business priorities shift. Stale priority worksheets are as dangerous as having no worksheet at all.
Systems in the same tier can be restored in parallel, but only after all systems in lower tiers are verified operational. Within a tier, sub-prioritize based on dependency count — systems with more downstream dependents should be restored first.