Direct answer
A recovery priority matrix should order business services, not servers. Start with identity, network and security dependencies, then group applications into recovery waves based on business impact and shared dependencies. Every priority requires a named owner and a definition of minimum viable service.
How to frame the decision
A recovery objective is useful only when it names the service boundary, measurement point, dependencies and authority to accept a miss. Exercises should record actual elapsed time rather than optimistic estimates.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Dependency depth | Identify foundational services that many applications require before ranking by business importance. | A service dependency graph validated by application owners. |
| Minimum viable service | Specify the smallest safe feature set or manual process that resumes critical work. | Acceptance tests for degraded operation. |
| Recovery capacity | Limit each wave to available clean compute, people, bandwidth and validation capacity. | A resource-loaded schedule from a tabletop or technical exercise. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Run the sequence with named owners and a measured clock.
- Translate the requirement into a pass/fail test for build a ransomware recovery priority matrix.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- The matrix is a list of servers sorted by executive preference.
- All tier-one services are scheduled concurrently without enough recovery capacity.
- Application owners have not agreed on acceptance criteria.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Make every target measurable and tied to a business service.
- A tested requirement exists for: Dependency depth.
- A tested requirement exists for: Minimum viable service.
- A tested requirement exists for: Recovery capacity.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
What should be restored first after ransomware?
A recovery priority matrix should order business services, not servers. Start with identity, network and security dependencies, then group applications into recovery waves based on business impact and shared dependencies. Every priority requires a named owner and a definition of minimum viable service. The deciding factors in this guide are dependency depth, minimum viable service, recovery capacity.
How do you rank applications for disaster recovery?
Treat the answer as conditional on the actual environment and plan. Specify the smallest safe feature set or manual process that resumes critical work. Retain acceptance tests for degraded operation.
What is minimum viable service?
Do not rely on the product label or a successful backup job alone. Test the requirement directly: limit each wave to available clean compute, people, bandwidth and validation capacity. Record the result with a date, operator and named exception owner.