Operational risk has moved from being a supporting risk discipline to being a board-level resilience issue. Financial institutions are dealing with higher regulatory expectations, growing technology dependence, and a more visible connection between operational failures and customer harm. The European Banking Authority has estimated that total materialised losses from new operational risk loss events reached €17.5billion in 2023, an increase of 23% on the previous year. That trajectory is not slowing down.
The result is simple: firms need a practical operational risk framework that is robust enough to stand up to regulatory scrutiny, but proportionate enough to actually work in day-to-day operations. Too many firms end up with one or the other. A framework borrowed wholesale from a global bank's risk manual looks impressive in a board pack and gets ignored by the people who are supposed to use it. A framework that is too informal looks practical until the first serious incident or supervisory visit, at which point its gaps become obvious to everyone in the room.
This article sets out what a workable framework actually contains, how the pieces connect, and what proportionate implementation looks like for small and mid-sized institutions specifically, rather than firms with the resources of a tier-one bank.
A strong framework gives senior management and the board a single way to understand how risk is identified, assessed, controlled, monitored and escalated. It connects governance, controls, incidents, third parties and resilience planning so risk is not managed in fragments. In practice, that means fewer blind spots, clearer ownership and better decisions when disruption happens.
The alternative, which is more common than most firms would like to admit, is a set of disconnected activities that each look reasonable in isolation. A risk register exists but nobody updates it between annual cycles. Controls are documented but rarely tested. Incidents are logged but the lessons never feed back into the risk assessment that should have anticipated them. Third-party contracts sit in a filing system without anyone tracking whether the supplier is still performing as expected. Each piece, on its own, might satisfy a checklist. Together, they do not add up to genuine risk management.
The connection between these elements is what actually protects the organisation. A control failure identified through testing should update the residual risk rating in the RCSA. An incident should be checked against the scenarios the firm has already modelled, and if it was not anticipated, that scenario library needs updating. A KRI breach should trigger a specific, pre-agreed response, not a debate about whether it matters. None of this happens automatically. It happens because the framework is designed, from the outset, as a connected system rather than a collection of separate compliance activities.
Every framework starts with clear governance. The board approves the broad direction, appetite and oversight model. Management translates that into operating structures, reporting lines and decision rights. A scaled but explicit three lines model remains the clearest way to divide ownership, challenge and assurance.
The first line, meaning business and process owners, identifies and manages risk in the flow of daily work. The second line, typically risk and compliance functions, provides independent oversight and challenge. The third line, internal audit or an outsourced equivalent, assures the overall framework is designed and operating as intended. This structure is endorsed explicitly by regulators: the Prudential Regulation Authority expects first line risk ownership, with oversight and challenge by independent second and third lines, and the European Banking Authority's Internal Governance Guidelines note that firms should align with the three lines model when assigning risk roles.
In smaller firms, a strict separation of duties is often impractical. The head of risk may also hold the compliance brief. An external professional services firm may perform the third-line audit function. None of that is a problem in principle, provided the roles are formally delineated and documented, with clear reporting lines into a risk committee or the board. What regulators are actually looking for is not headcount. It is role clarity, documented accountability and evidence that challenge is genuinely independent, even where it is provided by a small team or an outsourced partner.
Risk and Control Self-Assessment is where the framework becomes operational. Business areas identify their risks, document controls, assess impact and likelihood, and decide whether residual risk is acceptable. This is not just a register-building exercise. Done properly, RCSA creates the evidence base for action plans, investment choices and board reporting.
The key steps are straightforward to describe and harder to execute well. Scope and objectives need to be defined before assessment begins, usually starting with the highest-volume or highest-risk areas of the business. Risk identification should cover people, processes, systems, third parties and external events, including climate-related risk, and should draw on workshops or structured questionnaires rather than a single person's judgement. Each risk needs an inherent impact and likelihood rating, typically on a consistent scale, with documented potential consequences across financial, operational, regulatory and reputational dimensions. Controls are then identified and rated for both design effectiveness and operating effectiveness, with evidence from testing or past incidents informing that rating rather than assumption alone. Finally, residual risk is determined, and where it exceeds the firm's appetite, a decision is made: treat the risk through stronger controls, or tolerate it, with that decision explicitly recorded.
Conducting RCSAs is, in the eyes of most regulators, the bare minimum. What separates a genuinely useful framework from a tick-box exercise is what happens afterwards. Does the RCSA output actually change resourcing decisions? Does it inform what gets escalated to the board? Does it connect to the control testing programme, so that controls rated as weak in the RCSA get prioritised for testing? Moving from documentation to genuine influence over decisions is harder in smaller firms with limited resource, but the cost of getting it wrong, in remediation effort or regulatory sanction, far outweighs the investment required to do it properly.
RCSA tells you what should be controlling risk. Control testing tells you whether those controls actually work. Design effectiveness and operating effectiveness both matter, and they are different questions. A control can be well designed and still fail in practice because nobody performs it consistently. A control can be performed religiously and still fail because it was never designed to catch the specific failure mode it is meant to address.
A practical testing programme starts with a control library, ideally an output of the RCSA process itself, capturing control type, frequency, owner and failure mode for each significant control. Testing every control annually is rarely feasible, so firms should prioritise by risk: controls tied to high-impact risks, or linked to important or critical business services, warrant more frequent and more rigorous testing than peripheral ones. Each test needs a documented plan covering what is being tested, the method, and the criteria for success, and both successful and unsuccessful results should be recorded in detail. Where a control fails, the finding and its severity need to be logged, and many firms link failures directly back into the RCSA, which can in turn trigger a wider risk assessment refresh.
Remediation matters as much as detection. Control failures must be fixed, with target dates and named ownership, and best practice is to retest once remediation is complete rather than simply assuming the fix worked. Where it is feasible, continuous or automated monitoring, particularly for IT-related controls, supplements periodic manual testing and catches issues faster than an annual cycle ever could.
Without testing, firms are relying on documentation rather than evidence. That distinction is exactly what auditors and regulators are probing for: not whether a control exists on paper, but whether there is a record showing it was tested, by whom, and what was found.
A framework also needs boundaries. Risk appetite statements define the level and type of risk the organisation is prepared to accept, while KRIs track whether actual conditions remain within those boundaries. The best KRIs are measurable, owned, reported regularly and linked to clear escalation actions.
ISO 31000 defines risk appetite as the amount and type of risk an organisation is prepared to pursue, retain or take in order to achieve its objectives. In operational risk terms, this typically combines quantitative limits, such as the number and duration of permitted system outages or a cap on total losses from incidents, with qualitative boundaries, such as zero tolerance for material compliance breaches. The board should calibrate these using historical loss data and stress scenarios, and should review the overall appetite statement at least annually, often alongside the firm's strategic planning cycle.
KRIs operationalise appetite by giving it measurable, monitored form. For each appetite statement, there should be a corresponding KRI with defined warning and action thresholds. A useful KRI measures something that actually matters to the business objective it relates to, not simply something that happens to be easy to capture. Thresholds need owners and a reporting cadence, ideally visualised through a simple red, amber, green dashboard that makes the current position obvious at a glance. Crucially, a breach should trigger something specific: an investigation, a remediation plan, or a formal, documented decision to accept the position. A red KRI that nobody acts on is worse than not having the KRI at all, because it creates a false sense that the firm is monitoring something it is, in practice, ignoring.
Policy management translatesexpectations into operating rules. Scenario analysis tests severe but plausibleevents before they happen. Incident management ensures real events arecaptured, analysed and learned from. Third-party risk management extends theframework beyond the legal boundary of the firm, which is increasinglynecessary in outsourced and cloud-dependent environments.
Each of these deserves its own deep treatment, which is exactly why they are covered individually elsewhere in this series. But the point worth making here is that none of them function well in isolation. A scenario analysis exercise that never gets revisited after a real incident occurs is a wasted exercise. A policy that exists but was never communicated to the staff expected to follow it offers no real protection. An incident log that never connects back to the control testing programme misses the single most valuable source of evidence a firm has about where its framework is actually weak. The framework only works as a connected system, and these final four components are where that connectivity is tested most directly.
Smaller firms do not need a heavyweight framework copied from a global bank. They do need role clarity, a usable risk taxonomy, real ownership, documented decisions and evidence that the framework is being used. Proportionality is not a reason to omit core disciplines. It is a reason to design them so they are sustainable.
In practice, this might mean a single combined risk and compliance function rather than two separate teams, provided the reporting line to the board preserves genuine independence. It might mean a simplified risk taxonomy with fewer categories than a larger institution would use, provided it still captures the risks that are genuinely material to the business. It might mean scenario analysis conducted qualitatively rather than through detailed financial modelling, provided the exercise still produces a documented, board-reviewed view of the firm's vulnerabilities. What it should never mean is skipping governance, skipping testing, or skipping documentation because the firm is small. Those are the elements regulators check first, and they are the elements that protect the firm when something actually goes wrong.
The most effective operational risk frameworks are not built around disconnected spreadsheets and annual rituals. They are built around a connected view of governance, risk, controls, incidents and resilience. If your framework still feels fragmented, start with the basics: define ownership, run meaningful assessments, test key controls, measure against appetite and link every insight back to management action.
Building this connected view from scratch, or strengthening a framework that has grown piecemeal over several years, is exactly what our full whitepaper on operational risk management walks through in detail, with practical guidance tailored to small and mid-sized financial institutions across the UK, Ireland and the EU. Download the complete Operational Risk whitepaper for the full framework, including governance models, RCSA workflows, KRI design principles and a practical approach to outsourcing oversight.
