RTO and RPO Are Not Business Continuity

“The application has a two-hour RTO, so the business-continuity plan is covered.”

No. Not before that gets copied into the audit evidence.

RTO and RPO are not business continuity.

An RTO tells your technology team how quickly it has to restore a service.

An RPO tells it how much data loss the recovery design can tolerate.

Both are disaster-recovery objectives.

Both matter.

Neither tells your organization how it keeps a critical process operating while your service is unavailable.

That missing part is not a server, a replica, a backup or a secondary region.

It is people.

Authority.

Suppliers.

Records.

Alternate services.

Reduced-capacity work.

And the unpleasant little question of what happens to everything completed while your application is down.

Somehow this distinction disappears the moment somebody puts a recovery target in a spreadsheet.

You would never say “the ambulance arrives within eight minutes, so emergency medicine is covered.”

Yet give an application a two-hour RTO and suddenly your accounts-payable process has acquired metaphysical resilience.

It has not.

1. “But the System Is the Business Process.”

No.

Your system supports, records, routes or automates your process.

It is not the whole process, unless you have somehow eliminated your customers, staff, approvals, suppliers, regulatory obligations, inputs, outputs and consequences.

The technical layer asks whether a system can be restored.

The business-continuity layer asks what becomes unacceptable if your process can’t produce its outcome.

Different questions at different layers.

ISO 22301:2019 gives the business layer a name for its outer boundary.

The Maximum Tolerable Period of Disruption.

Treated as synonymous with Maximum Acceptable Outage.

Other practitioners use Maximum Tolerable Downtime, or Maximum Tolerable Outage.

The vocabulary wanders around a little.

The distinction doesn’t.

MTPD is the point after which your process causes unacceptable stakeholder harm.

A ceiling, not a target.

Your RTO has to sit inside it with margin, because the RTO is a technical commitment, and the business consequence does not politely move when recovery runs late.

That is the job of a business-impact analysis.

Map your process, its owner, operators, systems, data, suppliers, upstream inputs, downstream dependencies, and the harm from disruption.

Then identify which dependencies can fail together.

A BIA saying “crew scheduling application: RTO two hours” has described an asset.

It has not established whether flights can be legally staffed while your system is gone.

The July 2024 CrowdStrike-related outage made that distinction brutally public.

A defective content update took down Windows systems across airlines, hospitals, banks and broadcasters on 19 July 2024.

The shared dependency was not merely an IT asset that might fail one application at a time.

It was a common failure point across many critical processes at once.

Which is what a process map is for.

Making the shared thing visible before it decides to become your incident commander.

2. “But We Have a DR Site.”

Good.

Now name what the DR site restores.

NIST SP 800-34 Rev.

1 distinguishes a cold site, a warm site and a hot site.

A cold site has space and supporting infrastructure and no pre-installed system hardware.

A warm site is partly equipped.

A hot site is fully sized and configured, with the hardware, supporting infrastructure and personnel ready to operate the system immediately.

A mirrored site goes further, with automated real-time data mirroring, and is the most expensive option.

Technical readiness tiers.

They address the running-system layer.

AWS describes the same spectrum in cloud terms.

Backup-and-restore.

Pilot light.

Warm standby.

Multi-site active/active.

Backup-and-restore brings up the environment from infrastructure as code at failover.

Pilot light keeps core data stores running.

Warm standby keeps a scaled-down but functional copy continuously running. Multi-site active/active serves production traffic from more than one region, and is the only pattern driving both RTO and RPO toward near-zero.

Excellent.

None of those words means “the claims team knows which claims to process first from an outage queue.”

A DR site can restore your application.

It cannot decide who may approve exceptions.

Or contact a supplier that is also impaired.

Or operate the reduced process while restoration occurs.

It does not give a call centre a paper queue.

Or a warehouse an alternate dispatch method.

Or a flight operation a scalable way to reassign crews.

A technically beautiful warm standby is still not a manual workflow.

It is a warm standby.

Not an argument against DR.

An argument against asking DR to answer a question it doesn’t contain.

3. “But the Backup Restores Within the Target.”

That proves something useful and narrower.

Your restore path met a technical timing target, under the conditions tested.

It does not prove your process continues during the restore.

Or that suppliers are reachable.

Or that staff know the alternate procedure.

Or that work generated outside your system can be reconciled afterwards.

A backup is evidence about bytes.

Continuity is evidence about outcomes.

Your backup mechanics make the point themselves.

A full backup copies all source data at a point in time and offers the fastest restore at the highest storage cost.

An incremental stores changes since the most recent backup of any type, and restoration requires the last full backup plus every subsequent incremental in sequence.

A differential captures changes since the last full backup, so restoration needs at most the full backup and the latest differential.

All three can be sensible designs.

They aren’t interchangeable restore paths.

A chain of 30 daily incrementals takes a different route from one full backup plus one differential. Even when both were created in a schedule somebody calls “protected.”

The same is true of data protection.

The 3-2-1 rule calls for at least three copies, on two storage-media types, with one offsite.

The 3-2-1-1-0 variant adds one offline or immutable copy and a target of zero backup errors after verification.

That helps establish that your recovery material survives the disaster.

It does not teach your organization how to receive, authorize and later reconcile orders while your application is unavailable.

Keep retention out of this argument too.

A retention window says how far back a restorable point exists.

RTO says how fast the chosen point returns.

RPO says how current it is.

Retention is not continuity either, although at this point the vocabulary may feel as though it is trying very hard to become one enormous spreadsheet cell.

4. “But Staff Can Wait Two Hours.”

Perhaps they can.

That is a business decision.

Not an automatic property of a two-hour number.

A commonly used criticality scheme gives Tier 1 core services a one-to-four-hour RTO and a five-to-15-minute RPO.

That range does not announce that every Tier 1 process may pause for two hours without consequence.

It says the target is attached to a criticality tier. Your BIA has to establish why that tier exists in the first place.

Ask what accumulates during the interval.

Does your queue grow faster than staff can clear it after recovery?

Does an approval expire?

Does a supplier have a cut-off?

Does a downstream process need the answer before your application returns?

Does a legal or safety constraint turn delay into a different outcome entirely?

Delta’s crew-tracking programme came back at roughly 11:00 a.m. on 19 July 2024.

That didn’t end the operational failure.

Your programme could not process the unprecedented volume of pending crew changes quickly enough to catch a fleet-wide collapse already in motion.

Crew members reached Federal Aviation Administration duty-time limits before replacements could be confirmed. That cancelled the next flight, which displaced more crews, which added to the backlog.

The disruption lasted roughly five days, through about 24 July. Delta cancelled more than 7,000 flights and stranded an estimated 1.3 million passengers.

Your process didn’t wait for recovery to become difficult.

It got more difficult while recovery was happening.

Waiting is a continuity option only when the owner has decided that the delay, the backlog, the dependencies and the downstream effects remain tolerable.

“Staff can wait” is not a control until somebody has done that work and accepted the result.

5. “But Manual Workarounds Create Errors.”

Yes.

They do.

So does an unavailable process.

The choice isn’t between an error-free automated system and a grubby clipboard.

It is between the consequences of a defined, reduced-capacity alternate process, and the consequences of doing nothing until technology returns.

A manual workaround isn’t “tell everybody to use spreadsheets.”

That is how a temporary queue becomes an archaeological site.

It is a non-automated process capable of sustaining a critical function at reduced capacity while the primary system is unavailable.

It specifies what work continues.

What work is deferred or declined.

Who performs it.

Who authorizes exceptions.

Which record is authoritative during the outage.

What capacity it can absorb.

Then comes the part teams mysteriously leave off the whiteboard.

Reconciliation.

When your system returns, every outage record has to be entered, checked, deduplicated and resolved against the recovered system.

If an alternate service accepted a transaction, if staff wrote an approval into a log, or if a customer received a promise outside your application, your restored system does not gain that fact by telepathy.

Delta had no equivalent manual process capable of reassigning crews at the necessary scale, once the automated system fell behind.

Other carriers recovered relatively quickly after the same Friday outage. Some smaller carriers manually checked in passengers, or issued handwritten boarding passes.

Not glamorous controls.

Actual process continuity.

The drawback of a manual workaround isn’t an argument for omitting it.

It is a design requirement.

Bound your scope.

Train named operators.

Preserve records.

Define authority.

State the capacity limit.

Exercise the reconciliation.

A workaround nobody can run is a very expensive paragraph.

6. “But Process Mapping Is Not the Technology Team’s Job.”

Correct.

Finally, a useful objection.

Your technology team owns recovery mechanisms.

Backup design.

Replication mode.

Failover automation.

Restore testing.

Data-plane routes.

The readiness of cold, warm, hot or active/active targets.

It should explain what those mechanisms can actually deliver, and under what conditions.

Your business owner owns the consequence.

That owner decides whether your process can tolerate delay, manual operation, alternate service or accepted loss.

Approves the MTPD.

Accepts the tradeoff.

Is accountable for the process-specific fallback.

Operations owns how it will actually be performed.

Suppliers and dependent teams supply the constraints that make a plausible diagram fail on Tuesday.

ISO 22301:2019 does not treat this as a helpful suggestion from IT.

Its leadership clause requires top management to demonstrate commitment to the business continuity management system and establish the continuity policy.

ISO/TS 22317:2021 addresses BIA, ISO/TS 22318:2021 supply-chain continuity, ISO/TS 22332:2021 continuity plans and procedures.

The subject is visibly larger than a replication topology.

The regulatory version is even less subtle.

By 31 March 2025, the UK’s FCA and PRA required in-scope firms to demonstrate that each important business service could operate within its stated impact tolerance under severe disruption.

Not document it.

Demonstrate it.

Naming your service, setting the limit, testing the operating capability and recording lessons are all different from attaching an RTO to an application inventory.

Technology should not own the business decision.

It has to refuse to let the business pretend that no decision exists.

7. No, This Does Not Mean Every Process Needs a Paper Fallback.

It doesn’t.

Nor does every minor internal tool deserve a hot site, a war room and a laminated binder with forty-seven signatures.

Some processes can wait.

Some can use an alternate provider.

Some can continue at reduced capacity.

Some can accept a defined loss.

A Tier 3 low-use archive, commonly assigned a 12-to-24-hour RTO and an RPO as loose as four to 24 hours, is not a payment gateway.

Treat them identically and you either overspend on the archive or underprotect the payment process.

The point is that your business owner decides before the outage which option is tolerable, records that decision, and exercises the one chosen.

Your process map makes the dependencies explicit.

The BIA sets the MTPD ceiling.

The DR design derives the RTO and RPO.

The continuity procedure covers the recovery interval.

There is a cost curve here, because of course there is.

Backup-and-restore runs roughly 5% to 10% of production infrastructure cost.

Pilot light 10% to 15%.

Warm standby 40% to 60%.

Multi-site active/active 100% to 200%.

Near-zero technical recovery is not free.

And it still does not substitute for a process decision.

Nobody is arguing for ceremonial paperwork.

The argument is against discovering, during the outage, that the only plan was to stare at the status page with increasing professionalism.

8. What You Should Actually Do

Perform a business-impact analysis for each critical process. Identify the outcome, process owner, operators, customers or stakeholders, MTPD, and the harm that establishes the ceiling.

Map the dependencies. People, systems, data, suppliers, upstream inputs, downstream processes, regulatory constraints, and shared dependencies that can fail together.

A diagram with an application and a database is not a process map.

Set RTO and RPO from that map. Attach every target to a criticality tier, and explain the business impact it protects.

Choose backup-and-restore, pilot light, warm standby, multi-site active/active, or the corresponding cold, warm, hot or mirrored site.

Only after the process has justified the cost.

Document the recovery-interval procedure. State whether the process waits, runs manually at reduced capacity, uses an alternate service, or accepts loss.

Name the people who operate it and the authority that approves exceptions.

Design reconciliation before the outage. Define the outage record, the system of record after restoration, the checks for duplicates and omissions, and who resolves conflicts.

Reconstitution validates that the recovered system functions.

Reconciliation establishes that the work performed during the outage belongs in it.

Exercise the whole chain. Test technical restoration, then run the process through the recovery interval.

Backlog handling, manual capacity, supplier contact, decision authority, reconciliation. A restore test that ends when the login page appears has tested a restore.

Assign the tradeoff to the process owner. Technology reports the achievable target and its conditions.

The process owner approves the consequence of delay, manual operation, alternate service or accepted loss. Not bureaucracy, the difference between an engineering estimate and a business decision.

9. The Actual Model Is Not Complicated

Disaster recovery asks: how do we restore the system and data, how quickly, and with how much loss?

Business continuity asks: how does the critical process continue while that restoration is happening, and how is the outage work reconciled afterwards?

RTO and RPO belong to the first question.

A BIA, an MTPD, a dependency map, an operating workaround and a process owner belong to the second.

Use both.

Your application might return in two hours.

The business may have been accumulating an unworkable queue for one hour and fifty-nine minutes.

Those are not the same clock.

Pretending they are is how a recovery target becomes a very confident description of the wrong problem.