What Should You Restore First After a Cyberattack?

Restore the prerequisites of the most urgent business capability through a trusted recovery path. That can mean recovering a small directory, resolver, key service or administrative environment before the application leadership wants back. It can also mean using an approved substitute so that one service returns while a damaged shared platform remains isolated. The right order depends on what each recovery step requires, what the incident has made untrustworthy, and which people and resources are available.

I wouldn't settle this with a universal list that starts “identity, then databases, then applications.” Those categories conceal the very dependencies that determine whether recovery can begin. The directory might need a backup system whose administrator authenticates through that directory. An application might be able to serve useful read-only information before its payment connection returns. A payroll deadline might matter more than the system with the largest normal transaction volume.

The question I address here is how to turn business priorities into an executable sequence. My proposed method combines a map of prerequisite states, explicit alternatives, readiness checks and a resource-constrained schedule. It's a synthesis of authoritative recovery guidance and documented platform behavior, not an empirically validated scheduling algorithm or a report of a client exercise. The companion restore acceptance paper addresses the later decision about whether a recovered service is ready for production; here, the central problem is reaching that decision in a defensible order.

Define the capability before ranking the systems

A recovery priority needs a business outcome, a minimum operating mode and a time boundary. “Recover customer services” leaves too much unresolved. “Allow trained staff to retrieve existing orders, without accepting new orders, before the afternoon support shift” identifies a capability whose dependencies can be examined. Taking payments, changing addresses and initiating dispatch may require different data, authorities and downstream systems.

NIST's contingency-planning guide connects recovery priorities to business-process criticality, outage effects, tolerable downtime and resource requirements (Swanson et al., 2010, §§3.2.1–3.2.3). I would use those considerations to identify what continued interruption prevents. A priority score without its consequence is hard to defend when two owners both insist that their service is first. A missed legal filing, an unsafe operating state and a postponed sales report should not become interchangeable numbers merely because the spreadsheet demands a ranking.

The operating mode determines which dependencies are mandatory. A service that displays previously reconciled orders might need trusted identity and a readable database, but not the dispatch connector. The same interface accepting cancellations may need coordination with a warehouse that has already acted. Removing that connector from the map is therefore legitimate only for the specifically restricted mode. “Degraded service” must say which actions remain possible and which are deliberately unavailable.

Time objectives also need a common clock. Google's recovery-planning guide distinguishes acceptable application downtime from the time interval associated with acceptable data loss; neither is a demonstrated restoration result (Google Cloud, 2024b). I would establish the interruption start, the agreed capability threshold and the deadline before calculating a sequence. Otherwise one team can report completion from the start of its restore job while another measures the customer's entire outage, and both appear to meet incompatible promises.

Model required states, not just connections

An architecture diagram says that components communicate. A recovery map must explain what one component needs another to have accomplished. I would represent a node as a recoverable state: “resolver answers the recovery zone from the isolated subnet,” for example, rather than simply “DNS.” An arrow from A to B means that B cannot start its specified action until A satisfies its readiness condition. This direction convention should be written on the diagram; reversing it in a rushed handoff can reverse the schedule.

I distinguish four kinds of requirement. A startup prerequisite is needed to initialize a component. A runtime prerequisite is needed to keep the agreed capability working. An administrative prerequisite enables the team to perform or change the recovery. A trust prerequisite establishes whether a source, credential or management path is acceptable for the incident. The same product can occupy several nodes because those conditions become true at different times.

Required state	Consumer action it enables	Evidence I would attach
Recovery administrator can authenticate independently	Retrieve protected backups	Successful scoped retrieval using the designated emergency path
Isolated resolver returns approved records	Start an application against recovery endpoints	Resolution from the application's actual network context
Database recovery has reached the selected state	Start restricted application reads	Database checks and the selected recovery position
Transaction reconciliation has cleared a defined set	Enable corresponding outbound work	Approved transaction set, exclusions and duplicate-handling result
Recovery deployment tools can obtain approved artifacts	Rebuild a damaged service	Artifact identity, credentials and a rehearsed deployment path

These are proposed evidence fields, not universally sufficient security tests. NIST's cybersecurity-recovery guide calls for asset dependencies, service importance and the effects of hosted services to inform planning (Bartock et al., 2016, §2.1). My extension is to make each dependency actionable: a named consumer, a required state and something an operator can inspect. “Network available” doesn't tell a database engineer whether the specific restore endpoint, authentication flow and transfer path work.

Alternatives require equally explicit logic. If a service can use either the normal directory or a preapproved emergency identity mechanism, record that as an alternative with its restrictions. Don't draw both as mandatory prerequisites. Conversely, “database and key available” is a joint requirement: recovering only one doesn't unblock the consumer. This small distinction prevents a visually impressive map from producing the wrong execution order.

Break recovery loops before calculating the order

Consider a hypothetical loop: the directory is needed to access the secrets vault; the vault holds the backup-management credential; the backup service contains the directory's recovery image. No topological ordering can start that cycle while all three requirements remain mandatory. Giving the directory a higher priority doesn't create a credential. The architecture needs a deliberately independent bootstrap path, an already available prerequisite, or an approved change to the required operating mode.

Microsoft documents a concrete version of this problem. In its forest-recovery guidance, BitLocker Network Unlock cannot be the only key protector for the first restored domain controller in the described Windows Deployment Services scenario, because the services needed to unlock it aren't yet available (Microsoft, 2023a). The significance is narrower than “encryption blocks recovery.” A particular unlock dependency defeats a particular starting condition. The solution must preserve protection while providing a supported way to begin.

I would examine every set of mutually dependent recovery states as a unit. Which edge can be removed safely through advance preparation? Could a recovery credential be held under a separately administered, audited emergency-access process? Can essential runbooks be available without the collaboration service being repaired? Can a known configuration be staged in the recovery environment without retrieving it from the unavailable deployment pipeline? Each alternative needs custody, authorization and a retirement procedure; independence must not become an excuse for an uncontrolled master account.

A bootstrap dependency can also hide below the diagram. A password stored offline is little help if the person authorized to release it is unavailable. A spare recovery workstation is not usable if its only login method calls the impaired identity provider. Test the entire access chain from the responder's starting position, including the human release process. I would record what must already be available at time zero rather than describing those assets as magically recovered.

Let platform constraints refine the graph

Some ordering rules come from the platform, not from the organization's preference. Microsoft's Active Directory procedure begins with a writable domain controller in the forest root domain and requires a parent domain to be recovered before a child. Other domains can be recovered concurrently where the stated prerequisites permit (Microsoft, 2023b). I would preserve those constraints inside the wider service sequence rather than replace them with a homegrown “all identity in parallel” rule. The vendor procedure remains necessary; this article is not a substitute forest-recovery runbook.

Likewise, an orchestration tool's completion event must be interpreted precisely. Azure Site Recovery documents parallel operation within recovery groups and ordered startup across groups; it also supports runbooks and manual pauses for additional actions (Microsoft, 2025). That gives a team useful sequencing machinery. It doesn't establish that every application-specific consistency check has passed when a virtual machine starts. I would attach the readiness checks required by the next consumer instead of treating infrastructure startup as the universal release signal.

There is an important design choice between preparation and activation. Disk restoration, image verification or package staging may proceed concurrently while network connections and application writes remain disabled. A graph that models every activity as one indivisible “restore server” task can unnecessarily serialize independent preparation. A graph that treats every prepared server as ready for traffic makes the opposite mistake. Split those states wherever the distinction changes timing or risk.

For example, a database image could be prepared before the recovered application identity is authorized to query it. The application package could be staged before the database has finished replay. Neither fact permits the application to accept customer writes. The sequence should express the actual hold points, with an explicit event that advances each state. That makes automation easier to review and failed steps easier to resume without repeating everything.

Include the machinery used to rebuild the machinery

Recovery often introduces dependencies that normal service operation does not exercise. Google's guidance for CI/CD continuity explicitly includes internal dependencies such as credentials and configuration, and external dependencies beyond the immediate toolchain (Google Cloud, 2024a). A recovered application may run happily from an existing image while rebuilding that image requires a repository, package registry, signing service, deployment credential and network route. A production dependency inventory alone will miss this recovery path.

I would trace a rebuild from a clean administrative workstation through artifact selection, configuration, secrets retrieval and deployment. If a required package is fetched from a public service, record the approved version and alternative source policy before the incident. If an artifact registry remains reachable but its signing authority is suspect, availability hasn't satisfied the trust requirement. Whether to use a previously verified artifact or rebuild from source is a specific recovery decision, with different prerequisites and uncertainty.

The control plane deserves separate treatment. Furr (2019) distinguishes the machinery that changes resources from the data plane that operates existing resources, explaining how static stability can reduce reliance on new control-plane actions during an impairment. I would apply that distinction when deciding which recovery infrastructure to prepare in advance. An already provisioned capacity pool may remove a launch dependency, but its credentials, network configuration and artifact state still require review under the cyberattack scenario.

Static stability is not a claim that spare infrastructure is clean or that failover defeats an attacker. It addresses a failure dependency; compromise can invalidate the assumed healthy spare. My map would therefore identify both “capacity exists” and “capacity is acceptable for this recovery.” That prevents an availability technique from quietly becoming a security assurance it was never designed to provide.

Calculate the critical path, then add the people

The following example is entirely hypothetical. Its durations are invented assumptions, not measurements, vendor promises or recommended targets. Suppose the required capability is restricted order lookup, with new orders and outbound dispatch disabled. The exercise begins when an interruption is declared and includes preparing the trusted administrative environment. Independent teams can initially work in parallel, resources are available, and every predecessor listed is mandatory.

Task	Required predecessors	Assumed duration	Earliest finish
A: Establish trusted administration and isolation	None	30 minutes	30
B: Recover the minimum directory and resolver	A	50 minutes	80
C: Prepare approved artifact and configuration set	A	25 minutes	55
D: Restore and check the order database	B	80 minutes	160
E: Start the restricted application and check reads	B, C, D	20 minutes	180
F: Validate the restricted business workflow	E	30 minutes	210
G: Reconcile a bounded outbound transaction set	D	60 minutes	220
H: Validate and enable bounded dispatch	E, G	15 minutes	235

For this simplified acyclic graph, the earliest finish of a task equals its duration plus the latest finish among its predecessors. Tasks with no predecessors start at zero. Restricted lookup becomes eligible at minute 210 along A–B–D–E–F. Bounded dispatch becomes eligible at minute 235 along A–B–D–G–H. Those are two different capability milestones. Adding every duration gives 310 minutes and incorrectly assumes that all the work must be sequential.

The model also shows where an improvement would matter. Cutting C from 25 minutes to 10 does not change either finish: D still governs when E can begin. Cutting D by 20 minutes reduces both milestones by 20 under these assumptions. That is a more informative investment discussion than rewarding whichever team reports the largest local speedup. Criticality is a property of the current dependency structure and durations, not a permanent label attached to a prestigious platform.

Now remove the unlimited-staff assumption. Suppose the same specialist must perform F and G and cannot overlap them. After E completes at 180, doing F first yields restricted lookup at 210, then G at 270 and dispatch at 285. Doing G first from 160 to 220 allows F to run from 220 to 250, while a separate engineer performs H from 220 to 235. Dispatch arrives at 235, but lookup acceptance moves to 250. Neither order is universally preferable; leadership must choose which capability deadline takes precedence.

These schedules assume the specialist can defer G while E runs and that H has an independent operator. If those assumptions are false, recalculate. The dependency-only critical path is a lower bound under constrained resources, not a staffing plan. Record shared storage throughput, cloud quotas, vendor assistance, approval capacity and operator availability where they prevent apparently parallel work. The useful result is an explainable schedule with assumptions, not an impressive number divorced from how recovery will actually happen.

Keep restored data behind a transaction barrier

A sequence that ends at application startup can restart business effects in the wrong order. PostgreSQL 18's recovery documentation illustrates why restoration itself contains prerequisites: continuous archiving requires an unbroken sequence of archived WAL files extending back to the base backup's start, and WAL replay does not restore manually edited configuration files such as authentication configuration (PostgreSQL Global Development Group, n.d.). Those are specific PostgreSQL requirements, not generic assertions about every database. They justify separate recovery states for the selected data history and its surrounding configuration.

My proposed transaction barrier sits after technical restoration but before queued or scheduled business actions are released. It identifies the recovered data position, the authoritative external records and the set of actions that can be reconciled. A payment already settled outside the organization doesn't become unsettled because a local database was rolled back. The relevant ordering requirement is therefore “reconcile this set before replay,” not simply “start the database before the queue.”

Featonby (n.d.) describes explicit client request identifiers, handling of late requests and parameter mismatches in idempotent API design. That supports a useful mechanism for avoiding repeated side effects, but it doesn't establish that an organization's application has preserved the required identifiers or that a provider retains deduplication state indefinitely. In a recovery exercise, I would inspect the actual contract and recovered state before assuming a retried command is harmless. A database restore could remove the local record that previously prevented a duplicate operation.

Separate commands whose effects are known, commands whose effects are unknown, and commands proven not to have run. Do not automatically replay the unknown set simply because the queue recovered successfully. Where verification must be manual, put that effort on the schedule with its available staff. In the hypothetical example, G is visible precisely because reconciliation can govern dispatch even after the application has passed its read checks. H permits only the bounded set that G cleared, not an unexamined backlog.

Choose among feasible sequences without hiding uncertainty

Business priority and graph position answer different questions. Priority says which interruption has the greatest unacceptable consequence. Dependencies say what can happen next. A shared foundation may deserve early work because it unlocks several urgent capabilities, but counting downstream systems alone is insufficient. Restoring ten minor dashboards can be less valuable than removing the single blocker to a time-sensitive business obligation.

I would first eliminate sequences that violate mandatory technical or trust requirements. Among the feasible choices, compare capability deadlines, the consequences of delay and the scarce resources consumed. Where no feasible schedule meets the objective, show the miss directly. Possible responses include an approved restricted mode, additional qualified resources, prepositioned infrastructure or a changed business commitment. Relabeling a missed objective as “mostly restored” does not resolve the constraint.

NIST SP 800-61 Rev. 3 recommends selecting recovery actions according to defined criteria and available resources, changing them when organizational needs or resources change, and validating the appropriate restoration order (Nelson et al., 2025, RC.RP-02–RC.RP-04). I would implement that as a revision point in the incident process. If a backup fails validation, a supplier becomes unavailable or the compromise scope expands, update the affected nodes and downstream schedule. Preserve the superseded version so the reason for a decision remains understandable.

Avoid inventing precision where evidence is thin. A single successful exercise duration is not a probability distribution. Report a measured run with its conditions, or show clearly labeled planning scenarios such as an extra two hours awaiting vendor support. A deadline met in the favorable scenario and missed in the constrained scenario identifies a dependency to resolve. It doesn't justify claiming an estimated percentile without the observations and model needed to support it.

Test the edges that the plan is tempted to assume

The most useful test is often an intentionally unavailable prerequisite in a controlled environment. Google Cloud's planning guide recommends testing the recovery plan, including a scenario in which the usual access path does not work (Google Cloud, 2024b). I would translate that into an exercise that starts with the actual designated recovery access method, rather than letting engineers prepare everything through the path the scenario says has failed.

Choose an edge and require evidence from both ends. For a resolver-to-application dependency, demonstrate the application's required lookup from its recovery context. For an administrative dependency, retrieve the approved artifact without the unavailable production identity. For a transaction barrier, verify that restricted reads can run while outbound processing remains held. Record assistance, prepositioned assets, failed attempts and any manual intervention needed to move to the next state.

Cyber recovery also needs controlled reconnection. The joint #StopRansomware Guide warns against reinfecting clean systems and gives the example of admitting only clean systems to a recovery VLAN (Cybersecurity and Infrastructure Security Agency et al., 2023, p. 27). I would treat the required trust assessment as a prerequisite to the specified connection, not a permanent certificate that a machine is safe. New evidence may invalidate a readiness decision and require downstream activity to stop.

Resumption deserves its own test. If an orchestrated step times out after changing state, does retry repeat the change, detect completion, or need an operator decision? If a prerequisite is withdrawn, which dependent actions are reversible and which have already produced external effects? An exercise should preserve the event timeline and compare the observed order with the planned graph. The difference reveals missing dependencies and incorrect readiness conditions more usefully than a single green completion indicator.

Where this method helps, and where it stops

A detailed map can become an expensive document that is obsolete before anyone uses it. I would start with the smallest set of business capabilities whose interruption changes an executive decision, then trace only dependencies that affect their recovery. Keep the map alongside the runbook and update it when a material architecture or authority change alters a prerequisite. A manually maintained, rehearsed sequence can be sufficient for a small environment; formal graph tooling earns its place when it reduces real coordination errors.

Nor does every interruption justify a full rebuild sequence. A narrow outage may have a trusted failover path with fewer affected components. The graph should reflect the incident and operating mode rather than force a maximal ransomware scenario onto every service event. Conversely, these IT examples do not establish a safe restart procedure for physical processes. Operational technology requires its own engineering and safety constraints; a fast software schedule cannot authorize plant operation.

The evidence base also has limits. The twelve works used here are standards, government guidance and original platform documentation, with several sharing publishers; they are not twelve independent empirical studies. The calculated schedules demonstrate the consequences of stated assumptions. They do not validate the method against production incidents, establish a universal optimal order or prove that the selected recovery environment is free of compromise. Platform editions and configuration details must be checked when developing an actual runbook.

What the method does offer is a decision record that can be challenged: the capability to recover, the prerequisites that unlock it, the alternatives accepted, the work that sets the deadline and the uncertainty still outstanding. If your recovery plan is a ranked server inventory, request a critical-service recovery sequencing assessment. I would use a scoped dependency review and facilitated exercise to identify bootstrap failures, develop the minimum recovery path and show which unresolved constraints prevent the business from meeting its recovery commitment.