logo
Sign UpSign InTry for free
Operational Resilience Framework

Setting up an operational resilience framework

An operational resilience framework is the structural backbone the working programme runs on top of - scope, governance, taxonomy, accountabilities, methodology, reporting, independent review. This page covers the framework-design step that sits before the programme starts running.

Jack Finnegan, Founder & CEO, BA Copilot

By Jack Finnegan ยท Updated 21 May 2026

Design your frameworkOperational resilience hub
What it is

What an operational resilience framework actually is

An operational resilience framework is the structural setup for a resilience programme - the answer to 'who does what, against what methodology, governed by which body, reported to whom, reviewed by whom'. It is distinct from the running programme: the framework is the chassis; the programme is the work.
Regulators want to see both. The framework documents the firm's intent and accountabilities; the running programme produces the evidence the framework's intent has been honoured. The UK regime (PRA SS1/21 and FCA PS21/3, with FCA rules codified in SYSC 15A) explicitly asks for both; APRA CPS 230 expects the framework to be approved by the board and the running programme reported annually.
The problem today

Most resilience frameworks are documented but not lived

The familiar pattern: a consultancy produces the framework document, the board approves it, the document is filed, and the working programme proceeds without ongoing reference to the framework. When something goes wrong, the gap between the documented framework and the lived programme is exposed - typically in a regulator finding or a public incident report.
The fix is treating the framework as a live structure that the programme references continuously. Each programme activity points back to the framework section that mandates it; each framework section points forward to the programme evidence that satisfies it. A BPMN map of the framework setup makes the structure navigable rather than buried in a 60-page PDF.
Four pillars

Four pillars of a resilience framework

Scope and governance

Which entities, business units, jurisdictions are covered. Which committee owns it; who escalates to whom.

Taxonomy

Shared vocabulary - "important business service" vs "critical operation", "impact tolerance" vs "risk appetite", "material" vs "non-material" service provider.

Three-lines-of-defence accountabilities

First-line owns the activity; second-line owns the framework; third-line independently assures it. Most framework failures stem from blurred 1-2 boundaries.

Methodology and reporting

How dependency mapping is done, how tolerances are set, how testing is conducted, how findings are reported. The methodology is what makes the framework consistent across business units.

Process Map

The framework-design process as a process map

The setup sequence - scope, governance, taxonomy, accountabilities, methodology, reporting, independent review - that brings the framework to live status.

Open in editor

An operational resilience framework as a process map

The framework view of operational resilience rendered as BPMN 2.0 - scope, governance, taxonomy, accountabilities, methodology, reporting, independent review. The structural backbone the working programme runs on top of.

  1. Define the framework scope - the legal entities, business units, and jurisdictions in scope.
  2. Stand up the governance committee - sponsorship, decision rights, escalation paths.
  3. Establish the risk and resilience taxonomy that the rest of the firm will use consistently.
  4. Assign three-lines-of-defence accountabilities for each programme activity.
  5. Define the methodology - dependency mapping, impact-tolerance setting, scenario testing.
  6. Set the reporting cadence - board, executive, regulator, internal-audit.
  7. Schedule independent review and external-audit involvement.
What this diagram shows: The framework setup starts when board (or regulator) mandate is confirmed. Scope definition comes first. Governance setup establishes the committee and decision rights. Taxonomy aligns the firm on language. The 3LOD accountabilities task assigns who plays which role across every activity. The methodology task defines the technical approach. Reporting cadence and independent review schedule complete the structural setup; from there the live programme runs.
FAQ

Frequently asked questions

What is an operational resilience framework?

An operational resilience framework is the structural backbone of an operational resilience programme - scope, governance, taxonomy, accountabilities, methodology, reporting cadence, and independent review. The framework is the firm's intent and structure; the running programme produces the evidence the intent has been honoured.

How is a framework different from a programme?

The framework is the chassis - it documents who does what, against what methodology, governed by which body. The programme is the working activity - identifying important business services, mapping dependencies, setting tolerances, testing scenarios, reporting outcomes. Regulators expect both.

Which regulators require an operational resilience framework?

The major operational-resilience regimes - the UK rules (PRA SS1/21 and FCA PS21/3, with FCA rules codified in SYSC 15A), APRA CPS 230, OSFI E-21, EU DORA - all expect a documented framework with board approval. The Basel Committee's 2021 Principles for Operational Resilience is the regulator-neutral source that frames the requirement.

How does process mapping fit into the framework?

BPMN process maps make the framework navigable. The framework document describes intent and structure; the process maps show the actual setup workflow and how each subsequent programme activity references the framework. Without the maps the framework is a 60-page PDF; with them it is a working structure.

Does BA Copilot replace our existing GRC platform for the framework?

No. BA Copilot is the modelling layer that produces the BPMN process maps for the framework setup and ongoing programme activities. GRC platforms own the controls library, the risk register, the evidence repository.

Jack Finnegan, Founder & CEO, BA Copilot
From the founder

14 Years in BPMN

I'm Jack Finnegan. I've spent fourteen years working hands-on with BPMN, as an analyst, an engineer, and a product director, where I felt every sharp edge of legacy business process platforms.

BA Copilot is the platform I wanted on every one of these projects: AI-first process management, which treats BPMN as a first-class output rather than an export afterthought.

Jack Finnegan on LinkedIn
Sources

Sources and verification

Last verified 21 May 2026 by Jack Finnegan.

References cited on this page:

  • Basel Committee Principles for Operational Resilience (2021)
  • PRA SS1/21 and FCA PS21/3
  • APRA CPS 230
Cosmic background pattern
Decorative rectangle pattern

Make the framework actually navigable

Open the framework setup template, customise it to your governance structure, and produce the BPMN map that ties the framework document to the working programme activities.