Ransomware recovery: which applications should be restored first?

After a ransomware incident, the instinct may be to restart the most visible servers first. But a restored application may still be unusable if its identity service, data or network dependencies are missing. CISA's ransomware guidance emphasises critical services and their dependencies when setting recovery priorities. 1

Business priority is not the same as technical sequence

An order-processing platform may be the highest business priority, while its database, directory, DNS and storage services need to be available first. A recovery plan therefore needs two connected views: which business functions matter most and which technical components enable them.

A business impact analysis identifies tolerable interruption and data loss. NIST SP 800-34 links recovery strategies to those requirements and the system architecture. 2

A six-step recovery approach

1. Agree on the critical business functions

Rank functions by safety, legal obligations, essential operations and financial consequences. Business leaders and the incident management team should approve the priorities; IT should not decide alone.

2. Map dependencies end to end

For each function, identify applications, databases, identity services, DNS, networking, certificates, keys, storage, cloud services and external providers. Record what is essential and what can temporarily run in a degraded mode.

3. Establish trust before reconnecting

Do not reconnect potentially compromised systems to a clean recovery environment. Investigation, containment, eradication, credential rotation and backup validation may change the planned order. CISA recommends restoring from verified backups while avoiding reinfection. 1

4. Design an executable sequence

There is no universal rule that directory services must always be restored before networking or vice versa. An isolated recovery network or temporary identity service may change the prerequisites. For each stage, define its inputs, owner, estimated duration and acceptance criteria.

5. Test the business outcome

A running virtual machine is not proof of service recovery. Test user authentication, representative transactions, data reads and writes, and integrations with third parties. Recovery testing should address the resources and dependencies needed to operate the service. 3

6. Update the plan after exercises

Record unexpected dependencies, actual recovery times, gaps between planned and observed sequences, and follow-up actions. The recovery plan should evolve with the system.

Fictional example: a manufacturing company

A manufacturer needs to resume order entry within 24 hours. Its ERP depends on a database, identity service and a carrier integration.

| Component | Recovery role | Decision | | --- | --- | --- | | Isolated recovery network | Hosts validated systems | Prepare before reconnection | | Identity and DNS | Enable access and resolution | Restore or provide a secure alternative | | ERP database | Holds consistent transaction data | Validate integrity and recovery point | | ERP application | Enables order processing | Test end to end | | Carrier integration | Enables shipping | Reconnect after validating flows |

The company may use a documented manual process while carrier integration is unavailable. That fallback must itself be tested.

Mistakes that delay recovery

• An inventory that overlooks identity services and certificates.
• Backups that have never been restored in an exercise.
• Supplier dependencies without escalation arrangements.
• Premature reconnection of potentially compromised systems.
• Reporting “server online” as proof that the business function works.

Ransomware recovery is therefore a system-understanding challenge as much as a backup challenge. A credible sequence is one the organisation can execute safely and validate through a real business transaction.