The opinions expressed here are those of the authors. They do not necessarily reflect the views or positions of UK Finance or its members.

This expectation ties to the increasing demand for organisations to maintain a “minimum viable service” (MVS) during the most severe but plausible scenarios, with the term appearing more frequently when discussing Important Business Service (IBS) recovery. 

This shift has left many organisations searching for a way to bridge the gap between regulatory adherence, testing maturity and IBS recovery. One approach is to break down the technology estate into logical “service recovery blocks” (SRB) that support the restoration of MVS - the essential functions customers and colleagues need during a disruption. For some organisations, they will need to carefully consider how they define their MVS; to protect the safety and soundness of the firm, to avoid intolerable harm to the customer, or to ensure the financial stability of the economy. For some firms, these three objectives will result in the same MVS, but others may be left with conflicting regulatory requirements.

Technical foundations: Building the blocks

SRBs are built on the principle of modular recovery. Each SRB is a defined set of infrastructure, applications, and tooling that collectively enable a specific function within an IBS or core infrastructure, but are importantly distinct from an IBS. Blocks are mapped using architectural artefacts, CMDB data, existing IBS documentation and SMEs to identify dependencies and recovery priorities.

Initially, an organisation building an SRB would focus on the ‘foundation layer’ - this comprises the organisations core infrastructure components such as network access, authentication systems, monitoring tools, and hosting platforms. These must be restored first to enable IBS recovery. Once the foundation is in place, SRBs are defined for each IBS by identifying the minimum viable set of components required to deliver a basic version of the service. These components are grouped into logical blocks, sequenced based on technical dependencies and business impact, and ownership assigned to teams. 

Implementation and use cases

By defining these blocks, organisations can:

• Prioritise recovery based on customer and/or market impact
• Identify what is truly “critical” to avoiding customer harm and promoting customer and market confidence
• Identify variables that may influence recovery prioritisation order, such as the length of disruption, media coverage and market confidence
• Improve recovery times for recovering an MVS
• Implement a common recovery method across the organisation

This approach is especially useful in complex environments where full end-to-end testing isn’t always feasible. SRBs allow firms to rehearse recovery of individual components or journeys, gradually building layered recovery capability, confidence and evidence over time. Whether the disruption is caused by a cyber-attack, network failure, or even a physical incident like a fire or flood, SRBs provide a structured way to plan and rehearse recovery.

Defining SRBs can also play a crucial role in guiding an organisation’s technology strategy and innovation. By identifying a clear set of components and dependencies essential to the provisioning of an MVS, SRBs can be used to influence the adoption of new technologies within an organisation’s ecosystem. This structured approach can be drawn on to facilitate the migration from old to new systems, safeguarding a smooth transition and minimising disruption.

Conclusion: Building confidence through structure

As regulatory expectations evolve and scenarios become more complex, organisations need structured, testable recovery strategies to restore MVS at pace. SRBs provide a way for firms to rehearse recovery in manageable segments, respond proportionately to incidents, and build credible evidence of resilience. Start small, build incrementally, and use the structure to turn recovery at scale, from a concept into a capability. 

Visit our website to understand more about our lessons learnt from scenario testing.