Setting RPO and RTO from a business impact analysis

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Ask an IT team for recovery objectives and you will often get a list of servers: the finance server, four hours; the file server, a day. Ask the business and you often get something vaguer: back as fast as possible, with nothing lost.

Neither answer is a sound basis for spending. A server does not have a tolerable downtime; a business activity does. And zero loss with instant recovery is a price, not a plan. This guide is for business owners and managers who need to set recovery objectives that the business has actually agreed to. It follows the business impact analysis (BIA) method in NIST Special Publication 800-34 Revision 1, a US government contingency planning guide widely used as a reference (our understanding).

Why it matters

Objectives drive cost. NIST puts it directly: "The longer a disruption is allowed to continue, the more costly it can become to the organization and its operations. Conversely, the shorter the RTO, the more expensive the recovery solutions cost to implement."

It gives an example of the spread: "if the system must be recovered immediately, zero downtime solutions and alternate processing site costs will be much higher, whereas a low-impact system with a longer RTO would be able to implement a less costly simple tape backup system."

Without agreed objectives, two things tend to happen (our reading). Either every system is protected expensively because no one will accept less, or protection is chosen on cost alone and the business discovers its real tolerance during an outage.

Three terms, in business language

NIST defines three measures. Two are about time; one is about data.

Maximum tolerable downtime (MTD). "The MTD represents the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption and includes all impact considerations." In plain terms: how long this activity can stop before the harm is serious. NIST's glossary describes it as "The amount of time mission/business process can be disrupted without causing significant harm to the organization’s mission."

Recovery time objective (RTO). "RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD." This is the target for getting a system back.

Recovery point objective (RPO). "The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage." It is about how much recent work you can afford to lose and redo.

Two relationships follow from NIST's text.

• RTO sits inside MTD. "Because the RTO must ensure that the MTD is not exceeded, the RTO must normally be shorter than the MTD." NIST explains why: "because it takes time to reprocess the data, that additional processing time must be added to the RTO to stay within the time limit established by the MTD."
• RPO is separate. "Unlike RTO, RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process."

So a business activity has an MTD. The systems it depends on get RTOs that leave room inside that MTD for catching up. The data it uses gets an RPO based on how much re-work is acceptable (our reading of NIST's definitions).

The three steps of a BIA

NIST says: "The BIA is composed of the following three steps". In its words, they are to determine mission or business processes and their recovery criticality, identify resource requirements, and identify recovery priorities for system resources.

Step 1: Business processes and how critical they are

Start with activities, not systems. NIST's first step is to work "with input from users, managers, mission/business process owners, and other internal or external points of contact (POC)" to "identify the specific mission/business processes that depend on or support the information system".

For each activity, NIST asks the coordinator to work "with the process owners, leadership and business managers" to "determine the acceptable downtime if a given process or specific system data were disrupted or otherwise unavailable."

To make that judgement measurable, NIST recommends impact categories: "Impact categories should be created and values assigned to these categories in order to measure the level or type of impact a disruption may cause." Its example is cost: "an impact category such as “Costs” can be created with impact values expressed in terms of staffing, overtime, or fee-related costs."

Useful categories for a small or mid-sized business might be (our recommendation):

• Revenue lost or delayed per day.
• Penalties, missed contractual deadlines or regulatory reporting dates.
• Customer harm or loss of trust.
• Staff time to catch up afterwards.
• Safety or legal exposure.

Pick severity bands for each, then ask: at what point does this outage move from minor to serious? That point is the MTD (our reading of NIST's method).

NIST notes data can be gathered "through individual/group interviews, workshops, email, questionnaires, or any combination of these."

Step 2: What each activity needs

NIST's second step looks at resources. It says "Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible."

Here you list, for each activity, the systems, data, people, suppliers and connections it relies on (our recommendation). Dependencies matter: an invoicing process may need the finance application, the database under it, email to send invoices, and the bank's portal (our illustration). Budget the recovery dependency chain, not just each component separately. Identify which steps can run in parallel and which must wait for earlier steps; the critical path, application validation and business catch-up must fit the activity's MTD (our recommendation).

Step 3: Recovery priorities

NIST's third step sets order: "Recovery priorities can be effectively established taking into consideration mission/business process criticality, outage impacts, tolerable downtime, and system resources."

The output is a ranked list: which systems come back first, because the most time-critical activities need them (our reading).

Turning objectives into requirements

NIST's template shows the shape of the result: a table with columns for "Mission/Business Process", MTD, RTO and RPO, followed by a request to describe "the drivers for the MTD, RTO, and RPOs". A simple version might look like this (our illustration):

The payroll row is one explicit scenario, not a universal payroll target. It leaves 16 hours after system recovery for validation and catch-up before the stated deadline; the process owner must confirm that allowance. An outage nearer the deadline requires a different duration or an agreed contingency. Recovering only the last pay run could lose the entire current cycle, so the acceptable data point and work at risk must be stated.

Each number then becomes a requirement (our reading):

• RPO informs the protection method and cadence. Nightly backups alone cannot meet a 15-minute RPO. NIST's control text ties backups to "organization-defined frequency consistent with recovery time and recovery point objectives". A 15-minute schedule is still not proof of a 15-minute recoverable point: failures, capture duration and replication lag can make the newest usable data older. Demonstrate freshness by recovering and validating the protected data.
• RTO sets the restore method. A four-hour RTO for a large system may rule out restoring from slow or distant storage; a two-day RTO may not.
• MTD sets the plan's urgency. It decides who is called and when.

NIST also describes cost balancing: "Plotting the cost balance points will show an optimal point between disruption and recovery costs." In practice, compare costs only among options that meet all agreed RTO, RPO and MTD requirements, dependency constraints, security needs and other business obligations. Choose the lowest-cost suitable option using demonstrated recovery evidence; meeting MTD alone is insufficient (our recommendation).

When you cannot meet the objective yet

Often the current setup cannot meet an agreed objective. NIST anticipates this: "When it is not feasible to immediately meet the RTO and the MTD is inflexible, a Plan of Action and Milestone should be initiated to document the situation and plan for its mitigation."

For a business, that means recording the gap, accepting it in writing for now, and naming who will close it and by when (our recommendation). An honest gap is better than an objective nobody can meet (our reading).

The Australian small-business angle

The Australian Government's business.gov.au emergency management guidance takes a simpler line for small firms. Its template is described as including a "Continuity plan" that "Prepares your business for an emergency by identifying risks to critical areas and how to manage them." For information, it asks you to "Record how you protect business information such as customer records, financial records and contact lists."

Its preparation guidance also advises: "avoid relying on a single network provider, payment method or type of communication." That is a dependency point in the same spirit as NIST's step 2 (our reading).

A small business can apply the same three steps in a single workshop of an hour or two, without the full federal template (our recommendation).

Read-only checks

These checks compare existing plans and evidence with the objectives; none changes any system. They are document reviews, not commands.

1. Find the current objectives. Look for any written RTO or RPO in contracts, plans or backup settings. Note whether each is stated per system or per business activity.
2. Compare recoverable freshness with RPO. Record protection cadence, but also the latest successful usable recovery point, replication lag where applicable, and the recovery test that demonstrated it. Treat a schedule without that evidence as unproven.
3. Compare tested restore time with RTO. Use your last restore test records. If there is no test result, record "unknown"; do not use an estimate as a measured time (our recommendation).
4. Check the whole recovery path. Map dependencies and serial versus parallel steps. Budget their critical path, application validation and business catch-up inside the process MTD while satisfying the agreed system RTOs. Several individually short steps can still exceed the process limit when performed sequentially.
5. Check sign-off. Confirm the business owner of each activity has agreed its MTD and RPO.

These checks show gaps on paper. Whether objectives are met in practice needs a restore test; that is covered in our guidance on proving RPO and RTO with real numbers.

Safe restore rehearsal

A BIA is validated by a tabletop exercise before any technical test (our recommendation).

1. Choose one high-priority activity.
2. Walk through an outage of its main system on paper, hour by hour, with the business owner and the person who would restore it.
3. Mark the hour at which the impact becomes serious; compare with the agreed MTD.
4. List what would have to be re-entered from the latest demonstrated usable recovery point, not merely the scheduled backup time; compare with the RPO and allow time for catch-up inside MTD.
5. Plan a technical restore test on an isolated test system for the steps you could not confirm.

Diagnosing what you find

• The MTD is shorter than any realistic restore: objectives were set without pricing; dependencies were left out; or the restore method was assumed rather than tested.
• Every activity is rated critical: impact categories were not defined; no one with authority made the trade-offs; or cost was not shown alongside each choice.
• The RPO cannot be met by the backup schedule: backup frequency was set by default; the activity's data lives in a system no one listed; or replication was assumed but not in place.
• Recovery order conflicts: dependencies were missed; two activities share a system with different RTOs; or priorities were set per team without one overall ranking.

Worked example (illustrative)

The following is invented. A wholesale business has servers rated four hours each by its IT provider, with nightly backups. In a two-hour workshop, the owner and managers go activity by activity.

Taking orders turns out to have an MTD of one working day, with phone orders on paper as a stopgap. Dispatch can wait two days. But the order system's RPO is the real problem: re-keying a day of phone and web orders would take three staff a full day. The business keeps the nightly backup for the finance system, adds more frequent protection for the order database, records a written gap until it is in place, and books a restore test.

Risks and limits

• NIST SP 800-34 was written for US federal systems in 2010; adapt its terms.
• A BIA is only as good as the people consulted.
• Objectives on paper are not proof; test them.
• This is general information, not advice for a particular business.

Sources

All accessed 14 November 2026.

• NIST, Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems (May 2010, with errata): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
• business.gov.au, Develop an emergency management plan: https://business.gov.au/planning/templates-and-tools/emergency-management-template-and-guide
• business.gov.au, Prepare your business for an emergency: https://business.gov.au/risk-management/emergency-management/prepare-your-business-for-an-emergency
• business.gov.au, Make a risk management plan: https://business.gov.au/risk-management/risk-assessment-and-planning/make-risk-management-plan

Related future topics

• Proving RPO and RTO with real restore tests
• Running a one-hour recovery workshop with business owners
• Pricing recovery options against downtime cost

This article was originally published on 14 November 2026.