In most mid-tier financial services firms, technology resilience and operational resilience are managed by different teams. The IT or technology function owns the disaster recovery plan, the business continuity manager or Head of Operational Resilience owns the IBS mapping and scenario testing programme, and the two programmes run in parallel with limited interaction.
That parallel structure made operational sense when the regulatory frameworks were separate. It is now creating a material compliance gap for firms that have not yet integrated the two programmes, because both PRA SS2/21 and DORA are explicit that technology recovery capability must be evidenced against the same operational resilience standard that governs the firm's Important Business Services.
This article describes precisely what has changed, where the gap between most firms' current technology resilience position and the regulatory expectation actually sits, and what an integrated programme that satisfies both frameworks looks like in practice.
What the Frameworks Require and Where They Overlap
Three regulatory frameworks create ICT and technology resilience obligations for mid-tier UK financial services firms. Understanding how they interact is the prerequisite for building a programme that addresses all three without duplication.
PRA SS2/21 requires banks, insurers, and other PRA-regulated firms to maintain ICT and technology resilience frameworks that demonstrate the ability to recover systems supporting Important Business Services within their stated impact tolerances. The specific requirement is not that disaster recovery plans exist: it is that the recovery time objectives embedded in those plans have been validated against the impact tolerances the firm has committed to under PRA SS1/21. An IBS with a 24-hour impact tolerance is not evidentially supported if the technology system it depends on has never been tested to confirm it can recover within 24 hours.
FCA SYSC 15A, through its dependency mapping requirements at SYSC 15A.2.4, requires firms to trace the technology dependencies of each Important Business Service at a granular level: specific systems, platforms, cloud environments, and the third-party providers who operate them. This is not a high-level technology inventory. It is a mapped dependency chain that allows the firm to understand which technology failures would breach which tolerances and why. Most firms' technology dependency mapping, produced by IT teams against an asset register rather than an IBS dependency framework, does not meet this standard.
DORA, effective January 2025, introduces for in-scope entities a standalone ICT risk management framework obligation. The DORA framework requirement covers ICT asset identification, protection, detection, response, and recovery, and must be documented and tested against the DORA technical standards published by the European Supervisory Authorities. For UK firms with EU-regulated entities, the DORA framework obligation sits alongside and in several respects exceeds the SS2/21 requirements, particularly in the specificity of the technical documentation it requires.
The overlap between these three frameworks is real and significant. Firms that are managing them as three separate compliance projects are duplicating effort and almost certainly leaving gaps at the interfaces. The most common interface gap is the connection between the recovery time objective in the DR plan and the impact tolerance in the operational resilience programme: both documents make assumptions about the other, and neither team has verified that those assumptions are consistent.
The Gap That Most Technology and Resilience Teams Do Not Know They Have
The specific compliance gap that appears most consistently in FourthLine's diagnostic work involving ICT resilience is not the absence of DR plans or the absence of an operational resilience programme. Both typically exist. The gap is the unverified assumption that sits between them.
The operational resilience programme sets an impact tolerance of, say, 4 hours for the claims handling IBS. That tolerance was set based on the team's assessment of what the firm should be able to achieve. The DR plan for the claims platform specifies a recovery time objective of 2 hours. On paper, the two documents are consistent: the RTO is comfortably within the tolerance.
The problem is that neither figure has been tested against the other under realistic conditions. The DR plan's 2-hour RTO was set by the IT team based on the technical architecture and recovery procedures as they were designed. It was not set based on a test of how long recovery actually takes when the scenario is adversarial rather than scripted, when multiple systems fail simultaneously rather than in isolation, and when the people executing the recovery procedures are dealing with the full complexity of a real incident rather than a planned exercise.
The impact tolerance's 4-hour figure was set by the operational resilience team based on their assessment of customer harm thresholds. It was not set based on a validated technical recovery capability. Both figures exist in their respective documents, both look reasonable on paper, and neither has ever been validated against the other.
When a PRA supervisor asks to see the evidence that the claims handling IBS can recover within its stated tolerance, the DR plan's RTO figure is not evidence. It is a design target. The evidence is a tested recovery record that demonstrates the system was actually recovered within the tolerance under realistic conditions. Most firms do not have that record, because the integration required to produce it has never been the responsibility of either team working in isolation.
What DORA Added Beyond the Pre-Existing Obligations
For firms managing DORA compliance alongside their existing SS2/21 and SYSC 15A obligations, the specific areas where DORA adds materially to the pre-existing standard are worth identifying precisely, to avoid the common error of assuming that SS2/21 compliance satisfies DORA.
ICT risk management framework documentation. DORA requires a documented ICT risk management framework that covers all five elements: identify, protect, detect, respond, and recover. The PRA SS2/21 obligation is broadly similar in scope but is expressed as a principles-based requirement. The DORA framework must meet the specific technical standards set out in the ESA Regulatory Technical Standards, which prescribe a level of documentation granularity that exceeds what SS2/21 requires. A framework that satisfies SS2/21 through principles-based evidence will not automatically satisfy DORA's documentation standard.
ICT asset classification. DORA requires firms to maintain a complete, classified inventory of ICT assets supporting critical or important functions. The classification must reflect the asset's criticality, its dependency relationships, and the data it holds or processes. Most firms' IT asset inventories are not built to this standard because they were produced for ITAM or procurement purposes rather than for regulatory evidence. The gap between an IT asset inventory and a DORA-compliant ICT asset classification is typically significant.
Recovery testing specificity. DORA's testing obligations for in-scope entities include requirements around digital operational resilience testing that are more prescriptive than the general scenario testing obligation under SS1/21. The specific DORA requirement for Threat-Led Penetration Testing at significant entities is the most demanding, but even the basic testing obligations require a level of ICT-specific test design and evidence production that general operational resilience scenario testing does not provide.
Why the Technology Team and the Resilience Team Need to Work from the Same Map
The practical solution to the integration gap described above is straightforward in concept but requires deliberate effort to implement. Both teams need to be working from a shared IBS-to-ICT dependency map: a document that traces, for each Important Business Service, the specific technology systems it depends on, the recovery time objectives that apply to each system, and the validation status of each RTO against the IBS impact tolerance.
This is not a technology document and it is not an operational resilience document. It is a joint document that lives at the interface of the two programmes and requires both teams to have contributed to it. The technology team brings knowledge of what the systems can actually achieve under recovery conditions. The operational resilience team brings knowledge of what the business requires those systems to achieve. The IBS-to-ICT dependency map is the document that confirms those two sets of knowledge are consistent.
Building that map in practice means three things happening that typically do not happen when the two programmes operate in isolation. First, the impact tolerances for each IBS need to be reviewed against the recovery time objectives of the supporting technology systems, with any inconsistency documented and owned for resolution. Second, the DR plan for each critical system needs to be tested under conditions designed by the operational resilience team, not just the IT team, so the test reflects the scenario conditions under which the IBS tolerance would be at risk. Third, the combined evidence set needs to be structured for regulatory use: a document that a PRA supervisor or DORA competent authority could examine and use to verify that the firm's stated resilience position is supported by tested technology recovery capability.
This integration work is one of the areas where FourthLine's ICT and Technology Resilience solution adds the most value for mid-tier firms. The analytical capability required to do it well sits at the intersection of operational resilience regulatory expertise and technology recovery technical knowledge: a combination that few internal teams possess in sufficient depth, and that large consultancies rarely put in the same room.
The Evidence Set That Demonstrates Integrated Compliance
For firms that have completed or are progressing the integration described above, the evidence set that demonstrates compliance with SS2/21, SYSC 15A, and DORA (where applicable) across the ICT resilience domain contains the following elements.
An IBS-to-ICT dependency map that traces each IBS to its specific technology dependencies, with recovery time objectives per system, data classification, and third-party provider identification. Version-controlled and updated quarterly as the operating model evolves.
Recovery time objective validation records: tested evidence that each critical system can actually be recovered within its RTO under realistic conditions, including a scenario in which multiple systems are disrupted simultaneously. Not design targets, not untested DR plan specifications, but tested outcomes with contemporaneous records.
A DORA-compliant ICT risk management framework document for in-scope entities, covering all five DORA framework elements with the level of documentation specificity required by the ESA technical standards.
ICT incident detection and response procedures that are tested under the same scenario conditions as the recovery procedures, demonstrating that the firm's detection and escalation capability is integrated with its recovery capability rather than managed in isolation.
A board-ready ICT resilience evidence pack that presents the firm's current technology recovery position per IBS, the validated RTO status, the open items from the most recent testing programme, and the regulatory traceability to SS2/21 and DORA requirements.
Where to Start
For most mid-tier firms, the most useful first step is establishing an honest view of where the technology resilience programme currently stands against the integrated SS2/21 and DORA standard, rather than against the IT function's own design objectives.
FourthLine's ICT and Technology Resilience solution begins with a diagnostic assessment that maps the firm's current IBS-to-ICT dependencies, identifies the gap between current RTO specifications and validated recovery capability, and produces a prioritised remediation roadmap that sequences the highest-risk gaps by regulatory exposure. For firms where this work is already in progress internally, the diagnostic is also a useful independent validation before a supervisory engagement.