Operational risk management: Overview and guide

Key Takeaway: Operational risk management (ORM) targets losses from failed internal processes, people, systems, and external events, explicitly excluding strategic, financial, and market risks. In 2026, DORA, UK PRA SS1/21, and the Basel Committee's December 2025 third-party risk principles have forced ORM programs to integrate ICT resilience, vendor oversight, and continuous monitoring into a single framework.

Senior management typically holds one of two perspectives on risk. In the traditional Enterprise Risk Management (ERM) view, the goal is to find the right balance of risk and reward — accepting more risk for faster growth, or tightening controls and slowing growth when conditions warrant. The operational risk management (ORM) perspective is more loss-averse, focused on protecting the organization from the downside of day-to-day execution.

What is operational risk management?

Operational risk management is the continual, recurring process of identifying, assessing, mitigating, and monitoring risks of loss from failed or inadequate internal processes, people, systems, or external events. These losses can be directly or indirectly financial. A poorly trained employee may lose a sales opportunity outright, while weak customer service can erode brand value over time.

Operational risk covers both the risk of operating an organization and the processes management uses when implementing, training, and enforcing policies. Operational risk can be viewed as a chain reaction: overlooked issues and control failures — small or large — can lead to risk materialization, organizational failure, and damage to the bottom line and reputation. While ORM is considered a subset of enterprise risk management, it excludes strategic, reputational, financial, and market risks, focusing on unsystematic risks.

Examples of operational risk

Operational risk permeates every organization and every internal process. The goal of the ORM function is to focus on the risks with the most impact on the organization and hold accountable the employees who manage them.

Common examples of operational risk include:

• Employee conduct and employee error
• Data breaches resulting from cyberattacks
• Technology risks tied to automation, robotics, and artificial intelligence
• Business process and control breakdowns
• Development and introduction of new products
• Physical events, such as natural disasters
• Internal and external fraud
• Workplace safety hazards
• Third-party and vendor risks, including service outages and supply chain disruptions
• AI and model risks, including bias, drift, and unintended automated decisions

A brief history of operational risk

Over the last two decades, the methodology for evaluating internal controls and risks has become increasingly standardized. The shift responded to government regulators, credit-rating agencies, stock exchanges, and institutional investor groups demanding greater insight into companies' risk-control environments — meaning both the risks themselves and the effectiveness of the controls in place to mitigate them.

The discipline traces some of its earliest roots to military applications — notably the U.S. Navy's ORM doctrine — before being adapted and formalized in financial services through the Basel Committee on Banking Supervision, founded in 1974. Standardized risk management practices then spread well beyond banking. The release of COSO's Internal Control-Integrated Framework in 1992 and the Sarbanes-Oxley Act of 2002 — fueled by the financial frauds at WorldCom and Enron — increased pressure on organizations to operate effective ORM disciplines. In the U.S., the audit committee remains the strongest driver of senior-executive risk oversight. More recently, COSO released an Enterprise Risk Management Framework, and many risk managers have since shifted toward a dedicated operational risk management process. The Basel Committee continues to evolve the framework, most recently publishing December 2025 Basel principles on the sound management of third-party risk.

Table: Loss Event Types and Examples Defined by the Basel Committee

Table source: FDIC Operational Risk Management

How operational risk management works

When dealing with operational risk, the organization has to consider every aspect of its objectives. Because operational risk is so pervasive, the goal is to reduce and control every risk to an acceptable level. ORM attempts to reduce risk through a continual, recurring process of risk identification, assessment, measurement and mitigation, monitoring, and reporting — while clearly defining who owns each risk. These stages are often referred to as the four pillars of operational risk management: identification, assessment, mitigation, and monitoring.

These stages are guided by four principles:

1. Accept risk when benefits outweigh the cost.
2. Accept no unnecessary risk.
3. Anticipate and manage risk by planning.
4. Make risk decisions at the right level.

Risk identification

ORM begins with identifying what can go wrong. Risk identification — sometimes referred to as hazard identification — is the foundation of the ORM process. As a best practice, a control framework should be used or developed to ensure completeness. Identification typically starts with scenario analysis: examining the challenges facing the business and pinpointing areas that could disrupt operations or expose the organization to loss.

Risk assessment

Once risks are identified, they are assessed using an impact and likelihood scale, also known as a risk assessment matrix. At this stage, risks are categorized by type and level.

Measurement and mitigation

Risks are measured against a consistent scale to allow them to be prioritized and ranked relative to one another. The measurement also weighs the cost of controlling the risk against the potential exposure.

Monitoring and reporting

Risks are monitored through ongoing reassessment to detect changes over time. The risks and any material changes are reported to senior management and the board to inform decision-making.

Primary objectives of operational risk management

As the name suggests, the primary objective of ORM is to mitigate risks tied to the daily operations of an organization. ORM focuses on operations and excludes other risk areas such as strategic and financial risks. While other disciplines such as ERM emphasize optimizing risk appetite to balance risk-taking and reward, ORM is primarily concerned with controls and eliminating or reducing risk. The ORM framework starts with the risk and works backward to a mitigation strategy.

Operational risk management proactively protects the organization by eliminating or minimizing risk exposure.

Depending on the organization, the scope of ORM can be very broad. Some organizations include fraud risk, technology risk, and the daily operations of financial teams such as accounting and finance under the ORM umbrella. Under a comprehensive view, operational risk encompasses the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events — better viewed as the risk arising from the execution of an institution's business functions. Under that lens, ORM scope encompasses cybersecurity, fraud, and nearly all internal control activities.

Applying a control framework — formal or internally developed — helps when designing internal control processes. One useful approach is to organize operational risks into categories such as people, technology, and regulatory risks.

People

The people category includes employees, customers, vendors, contractors, and other stakeholders. Employee risk covers human error and intentional wrongdoing such as fraud, along with breach of policy, insufficient guidance, poor training, and bad decision-making. People can pose risk externally as well; social media amplifies individual conduct in ways that can affect the business. Because people touch every part of operations, this category is particularly sensitive. Fostering a healthy risk culture through training and regular communication is central to managing it.

Technology

Technology risk from an operational standpoint covers hardware, software, privacy, and security. It spans the entire organization and intersects directly with the people category. Hardware limitations can constrain productivity, especially in distributed work environments. Software outages or undertrained users reduce productivity and can directly affect customer interactions. External threats — including ransomware and credential-based intrusions — create data privacy and customer-information exposures. KPMG's 2025 third-party cyber risk survey found that 73% of organizations said TPRM inefficiencies expose them to reputational risk.

As technology takes on a larger role across the enterprise, risks in this space become more complex. Business continuity plans should explicitly address technology failures and related disruptions.

Regulations

Non-compliance risk exists in some form in nearly every organization. Some industries are more heavily regulated than others, but every regulation ultimately comes down to operationalizing internal controls. Over the past decade, the number and complexity of rules have increased and penalties have become more severe — exemplified by the EBA's updated ICT guidelines issued in February 2025 in the context of DORA.

Understanding the sources of risk helps determine who owns operational risk. ERM and ORM address risks in the same areas but from different perspectives. To reconcile these disciplines, some organizations have adopted Integrated Risk Management (IRM), which addresses risk from a cultural and operating-model point of view. Depending on the objective, the organization can configure technology with different parameters for teams like ERM and ORM.

Steps in the ORM process

While different versions of the ORM process exist, it is generally applied as a five-step process. All five steps are critical, and all should be implemented.

Image: Steps in the ORM Process

Image source: PWC Operational Risk Management

Step 1: Risk identification

Risks must be identified before they can be controlled. Identification starts with understanding the organization's objectives — risks are anything preventing the organization from achieving those objectives.

• Process analysis: Review internal processes — including production, IT, human resources, and customer service — to identify potential fail points or vulnerabilities.
• Loss data analysis: Examine historical loss data within the organization to identify trends. This includes financial losses, data breaches, compliance violations, and incidents that disrupted operations.
• Risk workshops and interviews: Conduct workshops and interviews with employees at various levels to gather insights on perceived risks, control gaps, and past incidents.
• External event analysis: Consider external events and changes in the regulatory landscape that could affect operations, including industry trends, technology shifts, and geopolitical events.
• Scenario analysis: Develop "severe but plausible" scenarios to test the organization's resilience and surface low-likelihood, high-impact exposures.

Step 2: Risk assessment

Risk assessment is a systematic process for rating risks by likelihood and impact. The output is a prioritized list of known risks, each with a risk owner and a mitigation plan — also known as a risk register. Prioritizing is critical and points project teams to the most significant exposures, since addressing every identified risk is rarely possible or advisable. This process often mirrors the risk assessment performed by internal audit and should be informed by prior audit reports and findings.

Step 3: Risk mitigation

The risk mitigation step involves choosing how to handle a specific risk. In the ORM process, there are four options for addressing potential risk events: transfer, avoid, accept, and mitigate.

1. Transfer: Transferring shifts the risk to another organization. The two most common means are outsourcing and insurance. Outsourcing never fully transfers responsibility for controlling the risk; insurance transfers some of the financial impact. A common example is cloud software: the contract typically includes data breach insurance, and the vendor provides SOC reports demonstrating sufficient controls.
2. Avoid: Avoidance prevents the organization from entering a risk-rich situation. For example, when selecting a vendor, the organization could choose a higher-priced bid if the lower-cost option lacks adequate references.
3. Accept: Based on the comparison of risk to the cost of control, management may accept the risk. For example, installing new coffee makers in the break room carries a minor burn risk; the benefit of employee satisfaction outweighs the exposure, so management accepts it.
4. Mitigate: Mitigation involves implementing action plans and controls that reduce the likelihood, the impact, or both. For example, if employees work from home, there is a risk of data leakage over the public internet. Requiring VPN access reduces that likelihood and mitigates the risk.

Few risks can be eliminated outright. Capturing residual risk — the risk remaining after controls are applied — is an equally important part of the mitigation phase. Inherent risk, by contrast, is the gross exposure before any controls. Documenting both clarifies whether the control environment is sufficient relative to risk appetite; if residual risk still exceeds appetite, additional treatment is required and should be tracked in the risk register with an owner and target date.

Step 4: Control implementation

Once mitigation decisions are made, action plans are formed, and residual risk is captured, the next step is implementation. Controls should be designed specifically to address the risk in question. The control rationale, objective, and activity should be formally documented so they can be communicated and executed consistently. Controls may take the form of a new process step, an additional approver, or built-in system controls that prevent end users from making errors or performing malicious activities.

Whenever possible, controls should be preventive rather than detective or corrective. Prevention is generally the strongest cure, but it is not always possible — that is where detective controls come in. Detecting anomalies and correcting them can be sufficient to mitigate certain risks.

Most organizations already have controls in place. Review them at least annually to determine whether they remain sufficient or whether additional controls are needed to close gaps.

Step 5: Monitoring

Because controls are performed by people who make mistakes — and because the environment changes — controls must be monitored. Control monitoring tests the design and operating effectiveness of each control. Exceptions and issues should be raised to management with documented action plans.

Within the monitoring step, mature programs — especially in financial services — have adopted continuous monitoring or early warning systems built around key risk indicators (KRIs). Key risk indicators are forward-looking metrics that signal rising exposure in a specific risk area before a loss event materializes. Effective KRIs are tied to a defined risk in the risk register, have a clear data source and owner, use thresholds (green/amber/red) calibrated to risk appetite, and trigger documented escalation actions. Examples include failed login attempts per 24 hours (cyber), aged unreconciled items (finance ops), employee turnover in critical roles (people), and vendor SLA breaches per quarter (third-party).

The 2026 regulatory landscape for operational risk

Three regulatory regimes have reshaped operational risk obligations for financial institutions and critical infrastructure providers.

DORA. The EU's Digital Operational Resilience Act has been fully applicable across the EU financial sector since January 2025. DORA requires firms to embed continuous ICT risk management, formal incident classification and reporting, threat-led penetration testing, and oversight of critical ICT third-party providers into their ORM programs. ICT risk can no longer sit in a silo — it must be governed within the broader ORM framework, with documented impact tolerances and board-approved resilience strategies.

UK PRA SS1/21 and FCA operational resilience. The UK rules came fully into force on 31 March 2025. Firms must document their processes, secure governing-body approval of written records, and implement testing plans to remain within impact tolerances for important business services during severe but plausible disruptions. Firms are also expected to report incidents that meet defined thresholds even before impact tolerances are breached.

Basel Committee third-party risk principles. On 10 December 2025, the Basel Committee published final principles for the sound management of third-party risk in the banking sector. The principles require banks to govern vendor supply chains with continuous oversight rather than point-in-time due diligence, including concentration risk monitoring across critical providers.

Cross-border firms should align controls across these regimes — alongside the European Banking Authority's amended ICT and security risk management guidelines (11 February 2025) and NIST CSF 2.0 — to eliminate duplicate testing and support multi-jurisdiction reporting.

State of operational risk management

Over the past five years, U.S. organizations have seen significant increases in the volume and complexity of risks, with 32% of companies reporting an operational surprise in that period. As organizations grow and evolve, so do the complexity, frequency, and impact of poorly managed risks. Losses from failure to manage operational risk have contributed to the collapse of several financial institutions; recent bank failures have been attributed in part to weak operational risk management and poor decision-making around asset valuation. Growing board-level demand for risk oversight further reinforces the importance of a strong ORM practice.

Survey data points to persistent gaps. PwC's 2025 compliance survey ranked technology as the top compliance priority for executives, suggesting a persistent disconnect between operational and enterprise risk management and strategy execution. Recent benchmarks reinforce the pattern: KPMG's 2025 third-party cyber risk survey found that 73% of respondents said TPRM inefficiencies expose them to reputational risk.

Challenges and shortcomings of operational risk management

In many organizations, operational risk management is one of the weaker links in the ability to meet customer and stakeholder demands. Because ORM is a subset of ERM, similar issues — competing priorities and lack of perceived value — affect both. Common challenges include:

• Insufficient resources committed to ORM or ERM.
• Limited communication and education around the importance of ORM and the consequences of operational failures on the bottom line.
• Limited awareness or engagement among the board and C-suite on ORM.
• Inconsistent methodologies for measuring and assessing risk, producing an unclear picture of the organization's risk profile.
• Lack of standard risk terminology, which is essential to successful Risk and Control Self-Assessments (RCSAs).
• Processes that are varied and complex due to ongoing technology change.
• ORM consolidated into other functions, such as compliance and IT, preventing it from receiving appropriate attention.
• ORM programs that are manual, disjointed, and over-complicated — largely because ORM developed as a reactive function in response to regulations, a concern reinforced by Deloitte's 2025 survey of 136 firms on model risk and AI governance.

Benefits of a strong operational risk management program

An effective ORM program supports the organization's strategic objectives and sustains business continuity during disruptions and system failures. A strong ORM program also demonstrates to clients that the organization is prepared for crises and loss events. Organizations that implement ORM well can realize competitive advantages, including:

• Better C-suite visibility into operational exposures.
• Better-informed business risk-taking.
• Improved product performance and brand recognition.
• Stronger relationships with customers and stakeholders.
• Greater investor confidence.
• Better performance reporting.
• More sustainable financial forecasting.
• Strengthened business resilience and continuity in the face of disruptions, cyber incidents, and third-party failures.

Effective ORM saves monetary costs by preventing or correcting loss events. It also encourages optimization of business practices and equips the organization to adapt as conditions change.

Developing an operational risk management program

When designing an ORM framework and program, the risk management team should focus on:

• Promoting an organization-wide understanding of the program's value and function.
• Using technology to automate monitoring, aggregation, and collection of risk data.
• Establishing an effective method for identifying and continuously updating principal risks and their associated measures.
• Reducing material risk exposures while supporting activities where the potential benefits outweigh the risks.
• Partnering ORM with other functions to embed risk practices across the organization.

Leading 2026 practices add specific operating disciplines on top of this foundation:

• Adopt a unified control matrix that cross-references NIST CSF 2.0 outcomes with EBA ICT guidelines and Basel third-party risk principles to eliminate duplicate testing.
• Run RCSAs at the business-unit level using standardized risk taxonomy.
• Deploy continuous monitoring through KRIs and automated alerts rather than periodic reviews.
• Embed incident-threshold reporting to meet SEC cyber-disclosure rules and UK PRA SS1/21 requirements even before impact tolerances are breached.
• Integrate ORM with third-party risk management, given that 73% of KPMG survey respondents reported TPRM inefficiencies expose them to reputational risk.

The risk and control self-assessment

Developing an operational risk program starts with risk management teams engaging with business process owners to identify the risks and controls in the organization. While every organization measures operational risk differently, one of the first steps is the Risk and Control Self-Assessment (RCSA).

The RCSA is a framework that provides an enterprise view of operational risk and can be used to perform operational risk assessments, analyze the organization's operational risk profile, and chart a course for managing risk. It forms a critical part of the broader ORM framework. An RCSA requires documenting risks, estimating frequency and impact to identify risk levels, and documenting the controls and processes related to those risks. A common best practice is to conduct the RCSA at the business-unit level.

The RCSA should serve as a reference for the organization's broader risk initiatives. Leading industry best practices for developing an RCSA include:

• Integrate RCSA programs into operational risk initiatives.
• Establish standard risk terminology and consistent methodologies to measure and assess risk.
• Develop a complete view of risks and controls — essential for later analysis.
• Incorporate trend analysis into the RCSA to identify patterns in risk and potential control failures.
• Identify non-financial risks that may still affect the bottom line.
• Use the RCSA to budget for ORM initiatives.

Operational risk management tools and resources

Technology increases the value ORM delivers to the organization. When planning the ORM function, build the library of risks and controls and the risk assessment process in a risk management software application. Embedding processes in technology drives consistency across teams and business units.

An effective ORM tech stack typically includes a centralized risk and control library (often a GRC platform), an RCSA workflow tool, KRI dashboards with automated thresholds, incident and loss-event capture, third-party and vendor risk monitoring with continuous external signals, and control testing automation tied to SOX and compliance programs. A strong ORM program supports your operational audits and risk library, as well as your SOX and compliance programs. Find out how Optro can help you manage, automate, and streamline your operational risk management program to turn operational risks into competitive advantages.

Frequently asked questions

What are the four pillars of operational risk management?

The four pillars of operational risk management are risk identification, risk assessment, risk mitigation, and risk monitoring. Together, they form the continual, recurring cycle ORM programs use to reduce loss exposure from failed internal processes, people, systems, and external events. Many practitioners expand the pillars into a five-step process by separating control implementation from mitigation, but the four-pillar framing is the most common shorthand in regulatory and industry guidance.

What are the four principles of ORM?

The four principles of ORM, originally codified in U.S. Navy doctrine and now widely adopted, are: (1) accept risk when benefits outweigh the cost; (2) accept no unnecessary risk; (3) anticipate and manage risk by planning; and (4) make risk decisions at the right level. These principles govern how risk decisions are made — not the process steps — and are useful for embedding risk-aware decision rights across the three lines of defense.

How does operational risk management differ from enterprise risk management?

ORM is a subset of ERM focused specifically on losses from failed internal processes, people, systems, and external events. It explicitly excludes strategic, reputational, financial, and market risks, which ERM covers. ERM optimizes the risk/reward trade-off to support growth, while ORM is loss-averse and control-focused. Many organizations integrate the two under an Integrated Risk Management operating model to eliminate duplicate assessments and align taxonomies.

How does DORA impact operational risk management programs?

The Digital Operational Resilience Act, applicable across the EU financial sector since January 2025, requires firms to embed continuous ICT risk management, formal incident classification and reporting, threat-led penetration testing, and oversight of critical ICT third-party providers into their ORM programs. ICT risk must be governed within the broader ORM framework, with documented impact tolerances and board-approved resilience strategies. Cross-border firms should align DORA controls with the EBA's amended ICT guidelines (11 February 2025) and UK PRA SS1/21 to avoid duplicate testing.

How should ORM integrate with third-party and vendor risk?

Third-party risk should be governed as a first-class category within the ORM framework, not as a parallel program. The Basel Committee's December 2025 final principles for the sound management of third-party risk require banks to implement governance over vendor supply chains, including concentration risk monitoring and continuous oversight rather than point-in-time due diligence. Practitioners should integrate vendor inherent-risk scoring into the RCSA and map critical vendors to specific business services with documented impact tolerances.

What is the difference between inherent risk and residual risk in ORM?

Inherent risk is the level of risk that exists before any controls are applied — the gross exposure. Residual risk is what remains after the design and operation of controls. ORM programs should document both: inherent risk drives where controls are needed, while residual risk indicates whether controls are effective enough relative to risk appetite. If residual risk still exceeds appetite, additional treatment is required and should be tracked in the risk register with an owner and target date.

How is AI changing operational risk management?

AI introduces a new operational risk category — model risk, including bias, drift, hallucination, and unintended automated decisions — that must be embedded into the ORM taxonomy. The EU AI Act, with general application from 2 August 2026, imposes conformity assessments and governance requirements on high-risk AI systems, and Deloitte's 2025 EMEA Model Risk Management Survey of 136 firms shows model-risk governance is now a board-level concern. On the capability side, AI is being deployed inside ORM to automate KRI monitoring, detect control failures, and accelerate RCSA evidence collection — but those tools must themselves be governed as in-scope models.

About the authors

Vice Vicente started their career at EY and has spent the past 10 years in the IT compliance, risk management, and cybersecurity space. Vice has served, audited, or consulted for over 120 clients, implementing security and compliance programs and technologies, performing engagements around SOX 404, SOC 1, SOC 2, PCI DSS, and HIPAA, and guiding companies through security and compliance readiness. Connect with Vice on LinkedIn.