How to Build an Operational Risk Framework

An operational risk framework is the architecture through which an organisation identifies, assesses, monitors, and manages the risks that arise from its people, processes, systems, and external events. Most organisations have something they would describe as an operational risk framework. Far fewer have one that genuinely works: that produces risk data people trust, governance that is real rather than nominal, and board reporting that enables decisions rather than simply describing a position.
5 min read time

An operational risk framework is the architecture through which an organisation identifies, assesses, monitors, and manages the risks that arise from its people, processes, systems, and external events. Most organisations have something they would describe as an operational risk framework. Far fewer have one that genuinely works: that produces risk data people trust, governance that is real rather than nominal, and board reporting that enables decisions rather than simply describing a position.

The difference between the two is rarely a question of which components the framework contains. Most organisations know the components. The difference lies in how those components are governed, how they connect to each other, and whether the culture around the framework treats it as a genuine management tool or as a compliance obligation to be completed.

This article sets out the main components of a sound operational risk framework and the practical choices that determine whether it delivers.

Why Frameworks Fail Before They Start: The Governance Question

The most common reason operational risk frameworks underperform is not inadequate methodology. It is inadequate governance. A framework without genuine accountability is a collection of documents and processes that nobody is truly responsible for, and that can therefore drift into irrelevance without anyone being clearly at fault.

Before designing any specific component, the governance architecture needs to be explicit.

The Three Lines Structure

The IIA's Three Lines Model, updated in 2020, provides the standard governance structure for operational risk. The first line, operational management, owns the risks in their area and is responsible for identifying, assessing, and managing them day to day. The second line, the risk function, sets the framework methodology, provides challenge and oversight, consolidates the risk picture, and reports to senior management and the board. The third line, internal audit, provides independent assurance that the first and second lines are functioning as intended.

This structure works when accountability is genuine at each level. It fails when first-line managers treat risk management as something the risk function does, when the risk function substitutes for first-line ownership rather than challenging it, or when internal audit confines itself to process compliance rather than assessing whether the framework is producing meaningful risk information.

Board-Level Accountability

At board level, the Basel Committee on Banking Supervision's Principles for the Sound Management of Operational Risk are explicit: the board should establish a strong risk management culture and approve the organisation's operational risk management framework, including the risk appetite and tolerance for operational risk. This is not delegable to a risk committee without explicit board ownership of the outcome.

A board that approves an operational risk appetite statement once and receives an annual update is providing nominal oversight. A board that actively uses risk reporting in its decision-making, that asks substantive questions when the risk picture changes, and that holds management accountable for maintaining the framework, is providing the governance that makes the framework worth having.

Risk Committees and Executive Ownership

Between the board and the first line, an executive-level risk committee with genuine authority and the right membership ensures that operational risk information reaches the decision-making level it needs to influence. A risk committee composed primarily of the risk function itself, without the business leaders who own the risks, cannot fulfil this role.

The FCA's systems and controls requirements for regulated firms reinforce this by expecting governance arrangements that are appropriate to the nature and scale of the business, with clear lines of responsibility and accountability for managing risks.

Defining Operational Risk Appetite

Risk appetite for operational risk is one of the most discussed and least well-executed aspects of most frameworks. Vague appetite statements that describe aspiration rather than tolerance provide no practical guidance to the people making day-to-day decisions.

What Useful Appetite Statements Look Like

A useful operational risk appetite statement is specific enough that someone in the business can use it to decide whether a proposed action is within acceptable limits. This means moving beyond qualitative descriptions to quantitative thresholds where possible.

Quantitative appetite thresholds might include: a maximum acceptable number of customer-impacting operational incidents per quarter; a maximum acceptable financial loss from operational failures within a defined category; a threshold for the volume of overdue high-priority audit findings above which the organisation considers its control environment to be outside appetite; or a maximum acceptable system downtime percentage for critical technology.

Qualitative appetite statements are also legitimate for risks that are genuinely difficult to quantify, but they should be specific enough to distinguish clearly between acceptable and unacceptable positions. "We have zero tolerance for breaches of regulatory requirements that could result in regulatory action" is a meaningful statement. "We manage compliance risk carefully" is not.

Appetite Connected to Strategy

ISO 31000's principle that risk criteria should be established in the context of the organisation's objectives applies directly here. Operational risk appetite is not set in isolation. It reflects strategic choices about what level of operational risk the organisation is willing to carry in pursuit of its objectives, and those choices must be made by the board, not determined retrospectively by whatever level of risk the organisation happens to be running.

Monitoring and Acting on Appetite

An appetite statement only has governance value if it is monitored and acted upon. This means the risk reporting cycle needs to include a clear comparison of the current risk position against appetite thresholds, with explicit identification of any areas in breach, and a clear governance process for responding to those breaches. Appetite that is consistently breached without consequence is not functioning as a governance mechanism.

The Risk and Control Self-Assessment

The RCSA is the primary mechanism through which operational risks are identified and assessed across the business. It asks first-line risk owners to examine their processes systematically, identify what could go wrong, assess the significance of each risk, document the controls in place, and assess whether those controls are adequate.

Designing the RCSA Process

The most important design decision in an RCSA process is determining where the boundary between facilitation and completion sits. The risk function should design the process, provide the methodology, facilitate workshops or structured conversations, challenge assessments that look implausible, and consolidate results into the enterprise risk picture. It should not complete the RCSA on behalf of the business, because that removes first-line ownership and produces assessments that reflect the risk function's understanding rather than the operational reality of the people doing the work.

Facilitated workshops, where a risk professional leads a structured discussion with a business team about what could go wrong in their processes, tend to produce better quality assessments than questionnaire-based approaches completed individually. The discussion dynamic surfaces risks and control weaknesses that no individual would identify alone, and the facilitated format builds risk awareness in the business as a by-product of the assessment process.

Maintaining Quality Over Time

The quality problem in most RCSA processes is not the initial assessment. It is subsequent ones. When the first assessment is complete, there is often a period of genuine engagement. Over subsequent cycles, without active effort to maintain quality, assessments become increasingly perfunctory, with risk owners updating numbers slightly without genuine reassessment of whether the underlying picture has changed.

Maintaining quality requires active challenge from the risk function, comparison of current assessments against previous ones with explicit discussion of any changes, and comparison against incident data to identify areas where the assessment does not reflect what the loss history suggests. An area with a consistently low risk assessment and a steady stream of incidents has a credibility problem that needs to be addressed in the RCSA.

Risk Assessment Methodology

For each identified risk, the RCSA should record both the inherent risk, the level of risk before controls are applied, and the residual risk, the level after controls are considered, using a consistent likelihood and impact scale across the organisation. This dual assessment is important because the gap between inherent and residual risk is itself a signal: it represents the claim being made about what the control environment is achieving. The Basel Committee's operational risk framework identifies the risk and control self-assessment as one of the four elements of a sound operational risk management system, alongside internal loss data, external data, and scenario analysis.

Loss Event Collection

Internal loss data is among the most objective inputs available to operational risk management. Where self-assessments reflect what people believe about their risk position, loss data reflects what has actually happened. The two should inform each other: significant discrepancies between the assessed risk picture and the loss history are an important governance signal.

What to Capture

An effective loss event collection process captures all incidents above a defined financial threshold, records both financial and non-financial impacts, documents the root cause and the control failure that allowed the event to occur, and classifies each event within the organisation's operational risk taxonomy.

Non-financial impacts, including customer detriment, regulatory concern, reputational damage, and management time, are often more significant than the direct financial loss and should be captured alongside it. An incident with a small direct financial impact but significant regulatory exposure is not a minor event.

Near-Miss Reporting

Near-misses, events that did not cause loss but could have, are at least as valuable as loss events and considerably more difficult to capture. The difficulty is cultural: near-misses require people to report something that did not actually go wrong, which is counterintuitive and requires an explicit organisational commitment to value and act on this information.

An organisation that captures near-misses well has built a reporting culture in which surfacing vulnerability is valued rather than penalised. This culture does not develop without visible leadership endorsement and consistent follow-through: when near-misses are reported and result in tangible improvements, others see the value of reporting them.

Using Loss Data for Analysis

Individual loss events are data points. Their analytical value lies in what they reveal in aggregate: which risk categories are generating the most loss, whether specific processes or teams account for a disproportionate share of incidents, whether loss frequency and severity are increasing or decreasing over time, and whether the pattern of losses matches what the RCSA would predict.

The Basel Committee's guidelines require that operational risk management uses internal loss data as one of the four key inputs to risk assessment. Where the loss data tells a different story from the self-assessment, the discrepancy needs to be understood and resolved rather than ignored.

Scenario Analysis

Scenario analysis asks "what if?" rather than "what has happened?" It is particularly valuable for low-frequency, high-severity risks that may not appear in the internal loss history but could have catastrophic consequences if they did materialise.

A structured scenario analysis process identifies plausible but severe operational risk scenarios relevant to the organisation, assesses the potential financial and non-financial impact, considers whether the current control environment would adequately contain the event, and uses the findings to test whether the risk and capital position is robust to severe but plausible operational risk events.

The Basel Committee's principles identify scenario analysis as one of the four elements of sound operational risk measurement alongside internal loss data, external loss data, and business environment and internal control factors. Scenario analysis is particularly important for operational risk categories where an organisation has limited internal loss history, either because the risks have not yet materialised or because the organisation is relatively new in a particular business area.

Key Risk Indicators

KRIs provide the real-time monitoring layer that sits between periodic risk assessments. A good set of KRIs gives the risk function and management visibility of whether risk levels are increasing or decreasing between formal assessment cycles, without needing to wait for the next RCSA or for an incident to occur.

KRI design and the common mistakes in KRI programmes are covered in detail in our dedicated article. The key point in the context of the framework as a whole is that KRIs need to be genuinely integrated with the risk assessment process: when a KRI signals increasing risk in a particular area, that signal should feed into the assessment of that risk, potentially triggering an out-of-cycle RCSA update or an escalation of the risk's status.

Operational Risk Reporting

Reporting is the mechanism through which the framework connects to governance. The design of reporting should reflect what each audience needs to be able to do with the information.

Board Reporting

Board-level operational risk reporting should provide a current view of the organisation's overall operational risk position relative to appetite, highlight the most significant individual risks and any material changes in the risk profile, surface trends in loss event data, and identify any areas requiring board attention or decision. It should not require the board to wade through granular detail to extract the headline picture.

The most effective board reporting connects the risk position explicitly to strategic context: where is the organisation taking on more operational risk as a consequence of strategic choices, and where is risk increasing due to factors outside management's control?

Management Reporting

Management-level reporting needs more granularity, covering risk positions by business unit, KRI status across the monitoring suite, incident trends and root cause analysis, and the status of risk and control improvement actions.

Common Reporting Failures

Reporting that consistently presents a positive picture without surfacing genuine concerns is not serving its governance purpose. A board that never sees operational risk reporting that identifies significant concerns either has an unusually well-managed risk environment or is receiving reporting designed to reassure rather than inform. The risk function's role is to ensure the board sees an honest picture, including the concerns.

Keeping the Framework Live

The most common failure mode in operational risk frameworks is not poor design but calcification after launch. The initial implementation generates genuine engagement. Over time, without deliberate effort to sustain it, the framework becomes an administrative exercise.

Keeping a framework live requires technology that makes participation straightforward, active challenge from the risk function when quality declines, genuine consequences when first-line owners do not maintain their risk information, and periodic refresh of the framework methodology to reflect changes in the organisation and its risk environment.

A practical indicator of framework health: can the risk function, at any point in the year, produce an accurate and current view of the organisation's operational risk position? If the honest answer is "only immediately after the quarterly RCSA cycle completes," the framework is not live.

References and Further Reading

Keywords: operational risk management framework, RCSA operational risk, loss event collection, operational risk appetite, operational risk governance, three lines model, operational risk reporting

Next Steps

Ready to elevate your operational risk management?

Join 150+ organisations who’ve already made calQrisk their competitive edge.