Recovery-Time Planning for a Small Business

Published October 23, 2026 · Last reviewed October 23, 2026

The terms, in plain words

NIST’s contingency planning guide defines these terms. Maximum tolerable downtime is the longest a business function can be unavailable before the damage cannot be accepted. RTO is the target time to restore the system, and must be shorter than that limit. RPO is the point in time you restore to, which sets how often backups must run: a four-hour RPO needs a backup at least every four hours.

Build the table (about an hour)

Use one row per system, filled in with the owner of the process, not only IT. Columns: system, who depends on it, RTO, RPO, manual workaround, depends on (identity, network, internet, a vendor), and restore order.

Fill the restore order from dependencies, not from importance. A typical order is: network and internet access, identity (the directory or your cloud sign-in), the backup tool itself and its keys, then finance and payroll, customer-facing systems and line-of-business applications, and lastly file shares and conveniences. Nothing can sign in until identity is back, and nothing can restore until the backup tool is.

Action

Write an RTO and RPO for each system and have the business owner, not IT, approve them. Ask: “If this stops on a Monday morning, when does it start costing us customers or cash, and how much of today’s work can we redo by hand?”

Why it helps

Without agreed targets, technicians guess, and the most expensive system gets restored last because nobody knew it was urgent.

Verification

Each row has two numbers and a named approver, and the owner can state the RTO for payroll and the main customer system without looking.

Fallback if delayed

If the owner will not commit, record the best estimate and mark it provisional; a rough number still orders the rebuild.

Action

Compare each target with a timed restore. Use the result of your most recent restore test and the restore-time tool for large data sets. If the measured time is longer than the RTO, the target is a wish.

Why it helps

The gap between the stated target and the measured time is the real risk, and it is only visible when you put them side by side.

Verification

The table has a “measured” column with a date, and every row where measured exceeds RTO is flagged.

Fallback if delayed

Where you cannot close the gap, write a manual workaround for the interim: paper forms, a spare laptop, a phone-based process.

Action

Print a downtime pack and keep two copies off the network: the table, the restore order, key phone numbers (IT provider, cyber insurer, bank, legal counsel), the backup console’s recovery details, and who is allowed to authorise spending in an emergency.

Why it helps

In a ransomware or outage event the shared drive and the email that hold the plan may be the very things that are down.

Verification

Pick a person who has never read it and ask them to find the insurer’s hotline and the first system to restore. They should manage in two minutes.

Fallback if delayed

A single printed page with the top five phone numbers and the restore order is better than a long document nobody can find.

Action

Agree who decides. Name one person who can decide to switch to workarounds, and the point at which the owner is told (for example, when a system is down beyond half its RTO).

Why it helps

Decisions slow down when everyone waits for permission, and the clock is the most expensive part of an outage.

Verification

The downtime pack names the decider and a deputy, and both have confirmed.

Fallback if delayed

Default to the owner as decider, with the IT contact as deputy.

Common failure mode

The usual errors are setting objectives that no one has measured, planning each system alone and missing that it depends on identity or the internet connection, and storing the plan on the file server it describes. Organisations also tend to treat the restore time as the whole outage; the real number adds detection, decisions, rebuilding of clean systems and checking. Use the downtime cost tool to see what each extra hour costs your own business.

How it works

RTO and RPO convert a business conversation into two technical settings. The RPO tells you how often to back up and which copies to keep; the RTO tells you how fast the recovery method has to be, which in turn determines whether a slow off-site restore is acceptable for that system or a faster local copy is needed as well.

Ordering by dependency matters because recovery is serial. The measured restore times from your restore tests, added up in restore order, give the realistic length of the outage, which is the number the owner needs for insurance, customer promises and the decision to pay for faster recovery.

Worked example

This is a hypothetical example with invented figures. A 40-person distribution company lists five systems. The order system has a stated RTO of four hours, but the timed restore from the off-site copy took most of a day. The gap is flagged.

The owner chooses two responses: keep a second backup copy on a local appliance that restores the order system quickly, and prepare a manual order sheet the warehouse can use for a day. The plan now says what happens in hour one, not just what is wished for.