A wire-transfer settles to the wrong account because of a keying error
A process and people failure. The loss comes from how a routine transaction was handled, not from a market move or a credit default.
Operational risk management (ORM) is the discipline of identifying, assessing, controlling, and monitoring the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events. It runs as a continuous cycle, built on RCSAs, key risk indicators, loss event data, and scenario analysis, and is governed through the three lines of defense.
Operational risk management is the discipline of identifying, assessing, controlling, and monitoring operational risk: the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events. That definition comes from the Basel Committee on Banking Supervision and is the one most widely used across industries.
The definition deliberately spans four sources of loss, which is why operational risk reaches almost every corner of an organization. Under the Basel framing the definition includes legal risk but excludes strategic and reputational risk. In practice, operational risk is the everyday risk of running the business: the risk that the way work actually gets done will produce a loss. It is distinct from credit risk (a borrower failing to pay) and market risk (prices moving against you), and it is harder to model because it stems from how people and processes behave rather than from a market price.
A broken or inadequate internal process. A control that is missing, a procedure that is not followed, a handoff that drops the ball.
Human error or misconduct. A mistake, a skills gap, a key-person dependency, fraud, or a deliberate breach of policy.
A technology failure. An outage, a software defect, a failed integration, a capacity limit, or a data-integrity problem.
Something outside the organization. A natural disaster, a third-party failure, an external fraud attempt, or a supplier disruption.
“The risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events.”
Operational risk is the one category every organization carries, because every organization runs processes, employs people, and depends on systems. Regulators have steadily formalized the expectation that it is managed deliberately rather than absorbed by accident.
In banking, the Basel Committee on Banking Supervision codified operational risk as a category that firms must identify, measure, monitor, and control, and its Principles for the Sound Management of Operational Risk set the supervisory baseline that national regulators build on.
In the United States, prudential supervisors such as the Office of the Comptroller of the Currency and the Federal Reserve examine operational risk management as part of safety and soundness, and the interagency FFIEC IT Examination Handbook sets expectations for the technology and process risks that sit inside it. In the European Union, the Digital Operational Resilience Act (DORA) places explicit obligations on financial entities to manage information and communication technology risk and to withstand disruption.
The pressure is not confined to financial services. Any organization that processes transactions, handles customer data, relies on suppliers, or runs critical systems is exposed to the same four sources of loss. Healthcare, energy, manufacturing, retail, and the public sector all run operational risk programs under their own rules and standards, even when they do not call the discipline by its Basel name. The common thread is that a structured program turns scattered, reactive firefighting into a managed, reportable picture of exposure that a board and a regulator can both follow.
The Basel framework groups operational risk into seven event-type categories. They give a program a common language for classifying losses and assessments, so risk from very different parts of the business can be rolled up and compared consistently.
Losses from acts intended to defraud, misappropriate property, or circumvent regulations or company policy involving at least one internal party, such as unauthorized trading, theft, or intentional misreporting of positions.
Losses from acts by a third party intended to defraud, misappropriate property, or circumvent the law, such as theft, forgery, check fraud, or computer hacking.
Losses from acts inconsistent with employment, health, or safety laws or agreements, including discrimination claims, workers' compensation, and general liability for employee safety.
Losses from an unintentional or negligent failure to meet a professional obligation to clients, or from the nature or design of a product, such as fiduciary breaches, improper disclosure, market manipulation, or product defects.
Losses from loss of or damage to physical assets from natural disasters or other events, including fire, flood, terrorism, and vandalism.
Losses from disruption of business or system failures, including hardware and software failures, telecommunication problems, and utility outages.
Losses from failed transaction processing or process management, and from relations with trade counterparties and vendors, such as data-entry errors, accounting errors, failed mandatory reporting, and negligent loss of client assets.
These are illustrative examples, not real incidents. Each one maps to one of the seven Basel categories, which is exactly how a working program classifies a loss when it happens.
A process and people failure. The loss comes from how a routine transaction was handled, not from a market move or a credit default.
An external party deceives the organization into a payment. The trigger is outside the firm, but the loss lands through an internal process.
A systems failure that stops the business from operating. The cost is the disruption itself plus any downstream service or contractual breach.
A failure to meet a professional obligation to a client. The loss arrives later as remediation, refunds, or a regulatory penalty.
The term “operational risk management” here refers to the financial-services and enterprise discipline defined by Basel. It is not the same as the military “composite risk management” (CRM), the US Army doctrine for assessing and controlling hazards in operations and missions. The two share a risk-identification mindset but have different origins, scopes, and vocabularies, and they should not be conflated.
An operational risk management framework is the set of tools and governance that lets an organization identify, measure, monitor, and control operational risk on an ongoing basis. Four data-gathering tools form the core of most frameworks, and together they give a program both a backward-looking and a forward-looking view of exposure.
A structured exercise in which each business unit identifies the operational risks it faces, assesses their likelihood and impact, and evaluates the controls meant to mitigate them. The RCSA is the bottom-up engine of an ORM program, surfacing where residual risk is highest after controls are accounted for.
Metrics that act as early-warning signals for rising operational risk, for example failed-transaction rates, system downtime, staff turnover, or the volume of open audit findings. KRIs are tracked against thresholds so a deteriorating trend prompts action before it becomes a loss.
A record of operational loss events that have actually occurred, including the event type, the amount, and the cause. Internal loss data shows where a program is bleeding, and external loss data from industry sources helps benchmark exposure to events that have not yet happened in-house.
A forward-looking exercise that estimates the impact of severe but plausible events that may sit outside the historical loss record, such as a major outage, a fraud ring, or a natural disaster. Scenario analysis fills the gap left by relying on past loss data alone.
Most operational risk programs are governed through the three lines of defense model, which clarifies who owns risk, who oversees it, and who provides independent assurance. The Institute of Internal Auditors refreshed it as the Three Lines Model in July 2020.
The operating units and process owners who take on and manage risk day to day. They own the controls and are accountable for the risks their activities create.
The operational risk management and compliance functions that set the framework, oversee the first line, challenge its assessments, and report aggregated risk to senior management.
Independent assurance that the first two lines are working as intended, reporting to the board or audit committee rather than to management.
The operational risk management process is the repeatable cycle a program runs to keep exposure under control. The steps are continuous rather than one-time: the output of monitoring feeds the next round of identification and assessment.
Map where operational risk lives across processes, people, systems, and external dependencies. RCSA workshops, process mapping, and loss event data feed this step.
Rate each risk by likelihood and impact to establish an inherent rating, then assess the controls in place to arrive at a residual rating. KRIs and scenario analysis sharpen the measurement.
Decide how to treat each risk: accept it, reduce it with stronger controls, transfer it (for example through insurance), or avoid the activity. Assign an owner and a target date for every action.
Track KRIs against thresholds, log new loss events, and report residual risk to management and the board. Monitoring closes the loop and keeps the risk picture current.
Revisit assessments on a defined cycle and after material events, update controls, and feed lessons learned back into the program so it improves over time.
Ready to move from theory to a first assessment? Our free risk assessment template gives you a structured way to identify risks, score likelihood and impact, and track controls and owners, the same backbone an operational risk program runs on. Pair it with the risk register template to keep the output current between cycles.
Operational risk management sits next to two terms it is often confused with: enterprise risk management above it, and operational resilience alongside it. Clear boundaries keep the program coherent.
Operational risk management focuses on one category of risk: the risk that internal processes, people, and systems, or external events, will produce a loss. Enterprise risk management is broader: the organization-wide discipline of identifying and managing all the major risks a business faces, including strategic, financial, market, credit, compliance, and operational risk together. Operational risk is one of the categories ERM oversees. A mature program runs ORM as a discipline in its own right, then rolls that view up into the enterprise risk picture the board sees.
Operational risk management is about reducing the chance and impact of loss events. Operational resilience is about keeping important business services running through a disruption and recovering quickly when one occurs. ORM identifies and treats the threats; resilience plans for how the business absorbs and recovers from the disruptions that get through. Business continuity planning is one of the main disciplines that delivers resilience in practice.
To go deeper on the broader discipline, see our guide to what risk management is and to enterprise risk management. On the resilience side, see business continuity planning and supply chain risk management. To see how a platform supports the whole program, look at risk management software.
Nine questions practitioners, board members, and new risk hires ask on the way to a working program.
Last reviewed . Sources are named for reference; this guide carries no figures or quotes beyond the Basel definition of operational risk.
RiskWatch turns RCSAs, key risk indicators, loss data, and controls into a managed program, with owners, automated review cycles, and risk roll-ups across the organization. Start a free trial or request a demo.
No credit card required · 30-day free trial · Cancel anytime