What Comes Back First: Setting the Restoration Order

The systems are down and the bridge call has forty people on it. Sales wants the CRM. Finance wants the ERP before payroll. Operations wants the scheduling system, and the plant manager is not asking anymore. Everyone's system is the critical one, and the recovery team is watching its queue become a political contest.

The restoration order is a business decision disguised as a technical one. Made in advance, it is a calm conversation about what the company cannot live without. Made during the incident, it is an argument conducted at the worst possible time, with the recovery team in the middle.

Writing the order down takes one working session. It pays off in the first hour of the worst day, when the recovery plan opens to a page that already settled the argument.

Key takeaways

• The restoration order is a business decision that should be made before the incident, not during it.

• Sequence by what stops the bleeding: revenue, safety, legal deadlines, then everything else.

• Include the hidden dependencies: the system everyone forgot that three critical systems need.

• Put times on the order: what returns in hours, in days, in weeks.

• Test the order in the recovery exercise, because the dependency surprises live there.

Step 1: Rank by business consequence, not by system size

The ranking question is not which system is biggest but which absence hurts fastest. A small scheduling tool that halts the plant outranks the ERP that finance can work around for a week.

Run the conversation with the business owners, not the IT team. IT knows what the systems do; the business knows what their absence costs per day. The restoration order needs the second answer.

The discipline mirrors the thinking behind the recovery time you promised: the number only means something if the business chose it.

Step 2: Map the hidden dependencies

Every restoration order has a surprise: the identity system that everything else needs to authenticate, the network segment that three 'independent' systems share, the vendor API that the ordering system silently requires.

This fictional example shows a manufacturer's restoration order with dependencies marked. It is an illustration, not a prescription.

Order	System	Restored within	Depends on
1	Identity and email	4 hours	Network core
2	Plant scheduling	8 hours	Identity, site network
3	Order management	24 hours	Identity, vendor API
4	ERP and finance	72 hours	Order management data feed
5	Historical reporting	2 weeks	ERP

The dependency column is where the argument about sequencing gets settled by facts instead of volume.

Step 3: Attach times, and price the promises

Each line in the order needs a target time, and each time has a cost. Restoring in four hours instead of twenty-four may require standby infrastructure that changes the budget. That trade-off belongs to the business, stated plainly: this is what faster costs.

The honest version of this conversation sometimes concludes that the current recovery capability cannot meet the order's times. That is not a failure of the exercise. It is the point of the exercise, and it is exactly the gap the backup and recovery testing discussion addresses.

Step 4: Rehearse the order, then keep it current

The restoration order survives contact with reality only if it is tested. In the recovery exercise, follow the order literally and record where it breaks: the dependency nobody mapped, the vendor who cannot restore on your timeline, the person who is the only one who knows step three.

Review the order when the business changes: new systems, new products, new sites. A restoration order from three org charts ago is a historical document, and incidents have a way of arriving before the annual review.

The related discussion of recovery time you promised is worth your time alongside this one. The related discussion of backup is not recovery is worth your time alongside this one.

Frequently asked questions

Who signs off on the restoration order?

The executive team, because it encodes business priorities. IT proposes the sequence based on dependencies; the business owns the ranking and the recovery time it is willing to pay for.

How many systems belong in the top tier?

Few. If everything is tier one, nothing is. A useful test: the first tier should be restorable with the people and capacity you actually have in the first day.

How does this relate to our RTO numbers?

The restoration order is where RTOs come from. Each system's recovery time objective should be a line in this document, chosen by the business, not a number inherited from an old template.

A Defensible Next Step

Ask your recovery team one question: if everything went down tonight, what is the written order of restoration, and whose signature is on it? If the answer is a shrug, schedule the working session this month. Book a Decision-Clarity Call if you want a facilitator who has run it before.