Business Impact Analysis Under DORA: Deriving RTO and RPO That Supervisors Accept

The RTO/RPO Problem

Every financial institution has RTOs and RPOs documented somewhere. Most were set years ago — often during a business continuity planning exercise that involved gathering business stakeholders in a room, asking "how long can this function be down?", recording the answer, and never revisiting it.

The result: RTOs and RPOs that are aspirational rather than analytical. A payment processing function with a declared RTO of 2 hours — but actual recovery testing shows 6 hours. A core banking function with an RPO of 1 hour — but the backup architecture only supports daily backups (24-hour RPO). A customer-facing platform with a declared RTO of 30 minutes — but no documented recovery procedure that could be executed in 30 minutes.

DORA Art. 11 requires that financial entities establish "ICT business continuity policies and ICT disaster recovery plans" with "recovery time objectives and recovery point objectives for each function." The ECB's 2024 cyber stress test tested whether banks could actually meet these objectives — and 31% could not.

The problem is not that institutions lack RTOs and RPOs. The problem is that the derivation methodology is flawed: the numbers are not grounded in quantified business impact, not validated against actual recovery capability, and not calibrated against Maximum Tolerable Period of Disruption (MTPD).

The BIA Methodology for DORA

Step 1: Identify Critical and Important Functions

Art. 3(22) defines "critical or important function" as a function whose discontinuity would materially impair the financial entity's financial performance, service continuity, or compliance with regulations. Art. 8 requires identification of all ICT-supported business functions.

The BIA starts by identifying all business functions and classifying them:

Regulatory mapping is essential: A function that is required by regulation (payment processing per PSD2, sanctions screening per EU restrictive measures, AML monitoring per AMLD) is inherently critical because its unavailability is a regulatory breach.

Step 2: Quantify Impact Over Time

The key insight of BIA methodology is that impact is not binary (function available / unavailable). Impact escalates over time. A payment processing outage for 15 minutes may be operationally invisible. The same outage for 4 hours causes customer complaints and internal escalation. For 24 hours, it becomes a regulatory incident. For 72 hours, it threatens the institution's license.

For each critical function, quantify impact across five dimensions at each time interval:

Step 3: Determine Maximum Tolerable Period of Disruption (MTPD)

MTPD is the point at which the cumulative impact becomes existentially threatening — the institution can no longer recover its reputation, regulatory standing, or financial position. MTPD is always greater than or equal to RTO.

For each critical function, MTPD is determined by identifying the time at which:

• Regulatory impact becomes irreversible (license revocation proceedings, criminal liability)
• Financial impact exceeds capital reserves allocated for operational risk
• Reputational damage permanently alters customer or market behavior
• Systemic impact triggers supervisory intervention

MTPD defines the outer boundary. RTO must be set well within MTPD to provide a recovery margin.

Step 4: Derive RTO From Impact Analysis

RTO is not MTPD. RTO is the recovery target that ensures the institution avoids the escalation thresholds identified in Step 2. The derivation logic:

1. Identify the time at which impact becomes unacceptable (regulatory breach, material financial loss, significant customer harm)
2. Set RTO at 50-75% of that time to provide margin for unexpected delays
3. Validate that the RTO is technically achievable (can the recovery procedure complete within this time?)

Example: Payment processing BIA shows regulatory impact (Art. 19 reporting threshold) at 4 hours, material financial loss at 8 hours, and MTPD at 24 hours. Preliminary RTO = 50% of 4 hours = 2 hours. Validation: can the DR procedure restore payment processing in 2 hours? If yes, RTO = 2 hours. If not, invest in faster recovery or formally accept the residual risk with documented justification.

Step 5: Derive RPO From Data Sensitivity Analysis

RPO defines the maximum acceptable data loss measured in time. It is derived from the data sensitivity and recoverability of the function's data:

Example: Core banking ledger data is financial, regulatory, and not reconstructible from external sources → RPO = near-zero (requires synchronous replication). Customer relationship notes are important but reconstructible from customer interactions → RPO = 24 hours (daily backup is acceptable).

Step 6: Validate Through Testing

The BIA produces theoretical RTOs and RPOs. Art. 24-27 testing validates whether they are achievable. Every BIA-derived RTO and RPO must be tested:

• Recovery Time Actual (RTA) measured during DR testing must be ≤ RTO
• Recovery Point Actual (RPA) measured during restoration must be ≤ RPO
• Testing under stress conditions (peak load, multiple concurrent failures, ransomware recovery)

Testing results that exceed RTO/RPO require either:

• Investment in faster recovery capability (reducing RTA/RPA to meet objectives)
• Revision of RTO/RPO with updated BIA justification (if impact analysis was too conservative)
• Formal risk acceptance with documented justification and management body approval

Common BIA Mistakes Under DORA

1. Setting RTO without impact quantification. "Our RTO is 4 hours because that feels right" is not defensible. The RTO must trace to a quantified impact analysis showing why 4 hours (not 2, not 8) is the correct threshold.

2. RPO set by technology, not business. "Our RPO is 24 hours because we back up daily" describes the technical capability, not the business requirement. If the business requires RPO of 1 hour (because 23 hours of data loss is unacceptable), the technology must be upgraded or the risk formally accepted.

3. Ignoring interdependencies. A function's RTO is constrained by the RTOs of its dependencies. If payment processing depends on sanctions screening, and sanctions screening has a 4-hour RTO, payment processing cannot have a 2-hour RTO unless sanctions screening's RTO is also reduced or a workaround is in place.

4. Static BIA. A BIA conducted once and never updated decays in accuracy. New functions, new vendors, new regulations, and new threats all change the impact analysis. DORA Art. 6(5) requires at least annual review; material changes should trigger immediate reassessment.

5. Not involving business owners. IT teams cannot quantify business impact. Business owners cannot set technical recovery targets. BIA requires collaboration: business owners quantify impact, technology teams assess recovery capability, and the gap between them drives investment or risk acceptance decisions.

Supervisory Expectations

The ECB and EBA examine BIA quality as part of operational resilience assessments. Supervisory expectations include:

• Traceable derivation: Each RTO and RPO must trace to a documented impact analysis. Supervisors will ask "why is this RTO 4 hours and not 2?" The answer must reference quantified impact thresholds, not subjective judgement.
• Consistency between BIA and testing: If the BIA sets RTO = 2 hours but the last DR test achieved RTA = 6 hours, there is a governance gap that supervisors will flag.
• Dependencies mapped: The BIA must account for function interdependencies and third-party dependencies. An RTO that ignores a critical vendor dependency is unrealistic.
• Management body awareness: Art. 14 requires that the management body understands the institution's recovery objectives. The BIA summary — which functions are critical, what their RTOs are, and what the residual risk is — must be part of board reporting.

Key Takeaways

• RTOs and RPOs must be derived from quantified impact analysis, not set by intuition or technical capability. Supervisors require traceable derivation.
• Impact escalates over time. The BIA must quantify impact at multiple time intervals across financial, customer, regulatory, reputational, and systemic dimensions.
• RTO = 50-75% of the first unacceptable impact threshold. This provides recovery margin while remaining defensible.
• RPO is driven by data sensitivity and recoverability, not by backup technology. Technology must match the RPO requirement, not define it.
• Testing validates the BIA. If actual recovery exceeds declared objectives, either invest in capability or formally accept the residual risk.
• Update the BIA at least annually and after material changes to functions, vendors, or risk profile.

---

Resume en francais

L'article 11 de DORA exige des RTO et RPO pour chaque fonction critique. Le stress test BCE 2024 a revele que 31 % des banques ne pouvaient pas respecter leurs propres RTO, souvent parce que ceux-ci etaient fixes arbitrairement plutot que derives d'une analyse d'impact. Ce guide propose une methodologie BIA en six etapes : (1) identifier les fonctions critiques selon l'Art. 3(22), (2) quantifier l'impact a intervalles temporels successifs sur cinq dimensions (financier, clients, reglementaire, reputation, systemique), (3) determiner le MTPD (delai maximal tolerable de perturbation), (4) deriver le RTO a 50-75 % du premier seuil d'impact inacceptable, (5) deriver le RPO selon la sensibilite des donnees et la reconstructibilite, (6) valider par les tests Art. 24-27. Si les tests revelent un ecart entre RTO declare et RTA mesure, l'institution doit investir dans la capacite de reprise ou accepter formellement le risque residuel avec approbation du conseil. Les erreurs courantes incluent fixer le RTO sans quantification d'impact, definir le RPO par la technologie plutot que le besoin metier, ignorer les interdependances et ne pas mettre a jour le BIA annuellement.