An RTO can be met while an important business service still breaches its impact tolerance.

The application is back before its recovery target. The database restored to the approved data point. The network route also passed its checks. Your incident report therefore says the recovery time objective was met.

Customers still cannot complete the service. A queue awaits manual authorisation, an external provider has rejected the replayed files, and balances remain unreliable. Technical restoration has happened. The important business service has already crossed the maximum outcome the board said it would tolerate.

That gap matters in a regulated firm. PRA2021/5 and FCA SYSC 15A judge whether the complete service remains within tolerance during severe disruption. A green component recovery report cannot answer that question. It only proves that one dependency reached its internal target.

Separate the continuity objectives before comparing them. Reconciliation fails when the same field carries several meanings. MTPD records the outer period after which process interruption produces unacceptable harm or threatens viability. RTO sets the earlier restoration point for an activity or supporting resource. RPO sets the pre-disruption data position that must be recoverable.

NIST SP 800-34 keeps MTD, RTO and RPO separate in its US federal system context. It expressly excludes RPO from MTD. The distinction travels well because lost data and elapsed recovery create different consequences. A restored application can meet RTO while its recovered data misses RPO.

Give each objective an approver. The executive accountable for the business outcome approves MTPD and minimum acceptable output. The process owner approves the business RTO. The data owner approves RPO after the application owner confirms capability. Record disagreement as a funded gap, not an optimistic footnote.

The UK Cabinet Office toolkit illustrates why sequence matters. It assesses consequences across the first 24 hours, 24–48 hours, up to one week and up to two weeks before setting MTPD and RTO. Your bands may differ. The decision still begins with accumulating harm and ends with an approved target.

Write impact tolerance as the service outcome ceiling. An impact tolerance answers how much disruption customers or markets can bear before harm becomes intolerable. FCA SYSC 15A requires time in every tolerance and permits other relevant metrics. Those measures can cover affected clients, transaction effects, lost access and data integrity.

Component availability supplies evidence about one cause. It cannot express the full outcome. A payment endpoint may answer calls while customers receive stale balances. A claims platform may accept forms while payments cannot be authorised. PRA SS1/21 treats a service with insufficient integrity as outside tolerance even where availability continues.

Keep approval separate too. Under PRA SS1/21, the board approves and regularly reviews important business services, impact tolerances and the written self-assessment. An infrastructure owner may propose an RTO. That owner cannot quietly turn the target into the board’s tolerance for customer harm.

Dual-regulated UK firms may set up to two clearly stated tolerances for one service under FCA PS21/3. The two decisions reflect different regulatory objectives. They still govern the external service outcome. Neither becomes a second name for the recovery time of its slowest application.

Map the service past the recovered component. Recovery reports stop at system boundaries because system owners can attest to them. Customer harm develops across handoffs. Your map must follow the transaction from request through authentication, decision, fulfilment, confirmation, exception handling and downstream reconciliation.

FCA SYSC 15A.4 requires documentation of the people, processes, technology, facilities and information needed to deliver each important business service. Add the third parties and internal support functions on which those elements depend. FCA PS21/3 treats internally important processes as mapped dependencies rather than external services by default.

Map far enough to decide whether the complete service stays within tolerance. Name the trained people who can approve exceptions, the facility from which alternate processing runs, the information they need, and the provider that accepts the output. A supplier’s successful restore proves little when its interface rejects your backlog.

PRA SS1/21 expects mapping to be updated at least annually. Material change should reopen it earlier. A yearly review cannot rescue a map that still points to a retired queue, an expired alternate-site contract or a provider whose handoff changed during the last release.

Record recovery as controlled states. Technical recovery masquerades as service recovery when the plan has only open and closed. Use separate records for invocation, alternate processing, validation and handback. Each record needs entry authority, actual capability, outstanding exceptions and an explicit exit decision.

Invocation proves that the authorised person activated the procedure early enough to mobilise it. Alternate processing proves that the minimum business output is moving under temporary controls. It also records actual data position against RPO and elapsed restoration against RTO. An “active” plan status proves neither.

Validation proves the service output. NIST SP 800-34 uses three execution phases: activation and notification, recovery, and reconstitution. It places testing and validation before the system owner declares the recovered system operational. Your business owner must then validate authorisation, integrity, downstream acceptance and the customer result.

Handback is another decision. Temporary records must be reconciled, queued work controlled, and the permanent environment ready. The handback owner accepts residual risk and confirms normal processing. Closing the incident when the server starts erases the interval in which the service can still breach tolerance.

Test the outcome after every target turns green. Component tests prove component claims. They miss the queue, staffing limit and shared dependency that appear only when the whole service runs. NIST SP 800-84 distinguishes quantifiable technical tests, discussion-based table-tops and simulated functional exercises because each supports a different conclusion.

Build a severe disruption in which applications, databases, facilities and providers meet their approved RTOs. Then carry real work through the restored chain. Measure customers still waiting, transactions completed incorrectly, inaccessible funds, market effects, confidentiality and integrity. Continue beyond the first successful technical check.

FCA SYSC 15A.5 requires adverse circumstances of varying nature, severity and duration. PRA SS1/21 expects scenarios in which the firm anticipates exceeding impact tolerance. A test designed to stay green avoids the evidence the regime asks the firm to produce.

Run the decision as well as the machinery. The service owner must decide whether alternate processing still protects the tolerance. Operations must validate outputs. The board needs evidence of the maximum harm reached, the vulnerabilities exposed and the remediation accepted. A component-by-component pass cannot support those decisions.

Treat the records as duties where the regime makes them rules. In-scope UK firms have binding requirements for mapping, scenario testing and written self-assessment under PRA2021/5 and FCA SYSC 15A. These records are more than aids to implementation. A firm can fail an evidence duty before a live outage proves the capability gap.

The self-assessment should connect the approved service, tolerance, map, scenarios, results and remediation. FCA guidance also expects notification when an impact tolerance is missed under Principle 11. Preserve the original estimates and later corrections. A clean final timeline should never replace what decision-makers knew at invocation.

Outsourcing leaves the same problem at another boundary. DORA Article 28 keeps the financial entity fully responsible when it uses ICT services, and Articles 11 and 24 require yearly testing of specified ICT plans and supporting systems. Provider evidence has value only when your service test connects it to the regulated outcome.

Reconcile the evidence service by service. Start with one important business service. Put its board-approved tolerance beside its MTPD, business RTOs and RPOs. Name every approver. Trace each target to the mapped dependency, recovery procedure, test result and state transition that supports it.

Then read the record from the customer’s end. Ask when usable service returned, with sufficient integrity and accepted downstream output. If that moment falls outside tolerance, report the breach plainly even when every component met RTO. Apparent recovery is the weak evidence. The service outcome is the result the regime governs.