In what order do you bring systems back after ransomware?
Recover in dependency order, defined before the incident, not decided during it.
Updated August 2026 · KELYN Recovery Engineering
Recovery order is a dependency graph, not a list
The question "what comes back first?" has a technical answer, and it is the same every time: whatever the most things depend on. Recovery flows up a dependency graph from the foundation to the business applications. Get the order wrong and higher tiers fail and have to be redone, which is how a recovery loses a day it did not have.
A typical sequence
Identity and DNSActive Directory or Entra, DNS and certificate services, so authentication and trust exist before anything needs them.
Core infrastructureNetwork, virtualization, storage and the backup and recovery infrastructure itself.
Shared servicesDatabases, middleware, messaging, file services and email that many applications sit on.
Business-critical applicationsThe minimum viable operations set, the smallest group of systems that lets the core of the business run.
Everything elseThe remaining applications and services, restored once the essentials are proven and stable.
Define your minimum viable operations first
Minimum viable operations, or MVO, is the smallest set of systems that keeps the core of the business alive: the handful of functions without which you are truly down. Naming that set in advance turns a chaotic "restore everything at once" into a focused "restore these first." It is the single most useful thing you can decide before an incident.
What people get wrong
No documented order at all, so sequencing is improvised while the clock runs.
Restoring the loudest team's application first instead of the systems it secretly depends on.
Missing hidden dependencies: a certificate authority, a license server, an identity provider, a shared database.
Not knowing the order until the incident, which is the most expensive time to learn it.
How to build the order before you need it
Inventory the critical business functions, not just the servers.
Map what each function depends on, all the way down to identity.
Group systems into recovery tiers and assign an owner to each.
Validate the order in an isolated test, which is where the hidden dependencies surface.
How KELYN makes this operational
KELYN architects recovery around the functions your business cannot operate without, documents the dependency order with named owners, and proves it in isolated tests on Commvault. When the order is already written and rehearsed, recovery becomes execution rather than discovery.