Recovery Planning

Define a Minimum Viable Business Restore

Resume essential transactions safely before rebuilding every feature and historical dataset.

Direct answer

Quick answer

A minimum viable business restore is the smallest controlled combination of people, data and systems that can process critical work safely. It is not a partially restored production environment by accident. Define permitted transactions, data cutoffs, manual controls and reconciliation steps before an incident.

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.

Which business services should be restored first?

Production and logistics commonly lead because missing upstream transactions can later block inventory, shipping, accounting and financial close.

  • A useful dependency sequence is identity, network and DNS, ordering, production, inventory, shipping and accounting.
  • For a manageable exercise, disable two connected services—ordering and inventory—rather than pretending every silo fails at once.
  • Document manual intake, duplicate detection and post-recovery reconciliation before declaring Excel an acceptable workaround.

Decision table

The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.

FactorPractical guidanceEvidence to retain
Critical transactionsList the customer, financial, safety or regulatory actions that cannot wait for full recovery.Business-approved transaction scenarios and volume assumptions.
Data cutoffState the recovery point and how missing transactions will be captured for later reconciliation.A tested offline or alternate capture procedure.
Control substitutionsReplace unavailable automated controls with explicit manual approvals and logs.Named approvers, evidence templates and reconciliation ownership.

Validation procedure

Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.

  1. Run the sequence with named owners and a measured clock.
  2. Translate the requirement into a pass/fail test for define a minimum viable business restore.
  3. Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
  4. 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.

  • Temporary processes create untracked transactions or privacy violations.
  • Teams call any reachable system minimum viable without business approval.
  • Reconciliation work is omitted from the recovery plan.

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: Critical transactions.
  • A tested requirement exists for: Data cutoff.
  • A tested requirement exists for: Control substitutions.
  • Evidence includes a date, environment, operator and reproducible procedure.
  • The exception path identifies who can accept residual risk.
Editorial note. This guide separates design guidance from vendor claims. Product, licensing and regional availability must be rechecked against dated official documentation and validated in the reader’s own environment. Review cadence: review every six months and after each recovery exercise.

Frequently asked questions

These answers state the decision in plain language and preserve the conditions that can change it.

Can Excel be used during ransomware recovery?

It can serve as a temporary intake mechanism when the business defines the fields, approvals, storage location and later reconciliation. Do not reuse affected collaboration or remote-access paths until the incident owner has established that they are trustworthy.

Which two systems make a realistic first tabletop?

Ordering and inventory create a useful dependency test without making the exercise unmanageably broad. The choice should still be confirmed against the organization’s actual value stream and safety obligations.

Who can approve degraded business operations?

The BCP executive or delegated business owner should approve the temporary control set and residual risk. Infrastructure availability alone is not authorization to resume transactions.