Operational Risk Management: Best Practices to Mitigate Potential Threats

Defining Operational Risk: The Basel II Foundation

Operational risk is distinct from credit risk and market risk, yet it is often the category that causes the most visible and embarrassing failures. Under the Basel II Accord -- the foundational international regulatory framework for bank capital requirements -- operational risk is formally defined as "the risk of loss resulting from inadequate or failed internal processes, people, and systems or from external events." This definition encompasses four primary categories that remain the standard taxonomy for operational risk management globally.

Understanding these four categories is the starting point for any operational risk program. They are not independent silos; in practice, operational failures involve multiple interacting categories simultaneously. A fraudulent employee (people risk) exploiting a system vulnerability (technology risk) due to absent controls (process risk) during a period of organizational instability is a textbook example of how operational risks compound.

Operational risk management (ORM) is the discipline of identifying, assessing, monitoring, and controlling these risks to protect organizational value and ensure sustainable performance. A mature ORM program does not eliminate operational risk -- that is impossible -- but it does ensure that risks are understood, controlled to acceptable levels, and that residual risks are consciously accepted rather than simply ignored. For broader context on how ORM sits within a complete program, see our guide on enterprise risk management.

The Four Basel II Categories of Operational Risk

People Risk

People risk arises from the actions or inactions of employees, contractors, and other human actors within the organization. It encompasses a wide spectrum: intentional misconduct (fraud, theft, unauthorized trading), unintentional error (data entry mistakes, miscommunication, poor judgment), and capacity failures (key-person dependency, skills gaps, insufficient staffing).

People risk is particularly challenging because it is inherently unpredictable and because the controls that address it -- training, culture, supervision, segregation of duties -- are soft and difficult to measure. Rogue trader events at financial institutions are the most dramatic illustrations of people risk: individuals who operated outside sanctioned limits, often for years, before detection. But the more common and costly manifestation of people risk is the accumulation of small errors and judgment failures across thousands of daily transactions.

Process Risk

Process risk is the risk that business processes are poorly designed, inadequately documented, inconsistently executed, or not aligned with organizational objectives. It includes risks from process failures (a step is skipped or performed incorrectly), process gaps (a necessary control step does not exist), and process changes (modifications introduce new failure modes without adequate risk assessment).

Process mapping is essential for identifying process risk. Organizations that lack clear, documented process maps are effectively operating with invisible risk: they do not know what they do not know. Process hazard analysis and process FMEA are systematic tools for identifying failure modes within documented processes.

Systems Risk

Systems risk encompasses technology failures, cybersecurity threats, data integrity issues, and the risks associated with technology dependencies. In the modern organization, virtually every business process depends on technology, which means systems risk is pervasive. System outages, software defects, infrastructure failures, and cyberattacks all fall within this category.

The growing sophistication of cyber threats -- ransomware, supply chain attacks, advanced persistent threats -- has elevated systems risk to board-level concern across virtually every sector. Technology risk management has become a specialized discipline in its own right, drawing on cybersecurity frameworks, IT governance standards, and business continuity planning.

External Events

External events are risks that originate outside the organization but cause operational losses. They include natural disasters, pandemics, geopolitical disruptions, supplier failures, and criminal activity by third parties. While organizations cannot control external events, they can prepare for them through scenario planning, business continuity planning, supply chain diversification, and insurance.

The COVID-19 pandemic was the largest operational risk event in modern history, demonstrating how a single external event could simultaneously disrupt every aspect of organizational operations across every sector and geography. Organizations with mature business continuity programs adapted more rapidly and incurred lower losses than those that had not adequately planned for large-scale external disruptions.

Key Risk Indicators: Measuring What Matters

Key Risk Indicators (KRIs) are the operational heartbeat of an ORM program. They are measurable metrics that provide early warning signals that operational risk levels are changing -- ideally before an actual loss event occurs. The best KRIs are forward-looking (they predict risk, not just record it), timely (they provide information when it can still drive action), and actionable (they are linked to specific controls and trigger defined management responses).

Designing Effective KRIs

The most common mistake in KRI design is selecting metrics that are easy to measure rather than metrics that are genuinely predictive of operational risk. Transaction error rates, system availability percentages, staff turnover rates in control functions, and overdue audit findings are all examples of KRIs with genuine predictive value. By contrast, measuring the number of risk trainings completed per quarter tells you something about program activity but relatively little about actual risk levels.

Effective KRI programs establish thresholds for each indicator: a "green" zone representing normal operations, an "amber" zone requiring management attention and investigation, and a "red" zone triggering escalation and immediate corrective action. These thresholds should be calibrated against historical data and periodically reviewed as the organization and its risk environment evolve.

KRI Libraries and Industry Benchmarks

The Risk Management Association (RMA), the Basel Committee on Banking Supervision, and various industry consortia publish KRI libraries that provide starting points for organizations building their first KRI program. These libraries are valuable for benchmarking -- understanding how your KRI levels compare to industry peers helps contextualize whether a particular reading represents a genuine concern or simply reflects the baseline operational environment of your sector.

Loss Event Databases: Learning From What Goes Wrong

A loss event database is a structured repository of operational risk incidents -- events that resulted in financial losses, near-misses, or other adverse outcomes. It is one of the most valuable assets in an ORM program because it transforms painful experience into institutional knowledge that can prevent future losses.

Effective loss event databases capture not just what happened and how much it cost, but why it happened: the root causes, the contributing factors, the controls that failed or were absent. This causal information is what makes the database actionable. A list of losses with dollar values attached is interesting but not instructive; a database that identifies recurring root causes enables targeted, evidence-based investment in risk reduction.

External loss data -- industry-level operational loss databases such as ORX (Operational Riskdata eXchange Association) -- supplements internal data, particularly for low-frequency, high-severity events that an individual organization has not experienced but which the industry as a whole has. Quantitative models for operational risk capital under Basel frameworks rely heavily on this combination of internal and external loss data.

Business Process Mapping for Risk Identification

You cannot manage what you have not mapped. Business process mapping is foundational to operational risk management because it makes the invisible visible: it documents how work actually flows through the organization, where handoffs occur, where data is transformed, and where controls are supposed to operate.

The standard business process mapping tool is the process flow diagram or swim-lane diagram, which shows each step in a process, the function responsible for each step, the inputs and outputs at each stage, and the decision points where different outcomes can occur. For risk purposes, process maps are overlaid with control points: places in the process where a check, review, or approval is designed to prevent or detect errors and misconduct.

From Process Maps to Risk Identification

Once a process is mapped, risk identification becomes systematic. For each step in the process, assessors ask: What could go wrong here? Who could make an error? What could cause this step to be skipped? What happens downstream if this step fails? What controls exist to prevent or detect failures at this point? Are those controls adequate given the risk level?

The answers to these questions populate the operational risk register for that process. This approach is far more comprehensive than survey-based risk identification, which relies on participants' memory and intuition, and far more targeted than checklist-based approaches that may not reflect the specifics of the organization's processes.

Internal Controls and Segregation of Duties

Internal controls are the mechanisms by which organizations manage operational risk in their day-to-day operations. They are the specific actions, reviews, approvals, and system configurations that are designed to prevent operational risk events from occurring or to detect them quickly when they do.

Control Types

Controls are classified along several dimensions. Preventive controls are designed to stop risk events from occurring: dual authorization requirements, system access restrictions, and mandatory checklists are all preventive controls. Detective controls identify when a risk event has already occurred: reconciliations, exception reports, and audit logs are detective controls. Corrective controls are activated after an event to limit its consequences and restore normal operations.

A robust control framework includes both preventive and detective controls for each material operational risk. Relying solely on detective controls means accepting that risk events will occur and trusting that they will be caught quickly; relying solely on preventive controls creates brittle systems that can fail catastrophically when a prevention barrier is breached.

Segregation of Duties

Segregation of duties (SoD) is one of the most fundamental internal control principles. It requires that no single individual has end-to-end control over a critical process -- particularly one involving financial transactions, data modification, or system administration. By separating the authorization, execution, and recording of transactions among different individuals, SoD significantly reduces both the opportunity for and the concealment of fraud and error.

In small organizations, full SoD may not be achievable due to staffing constraints. In these cases, compensating controls -- enhanced monitoring, manager review, periodic external audit -- can partially offset the additional risk created by SoD gaps. These gaps should be explicitly documented and accepted by senior management rather than treated as acceptable background noise.

Operational Resilience: Beyond Business Continuity

Operational resilience is an evolution of the traditional business continuity planning (BCP) concept. Where BCP focuses on restoring specific systems and processes after a disruption, operational resilience focuses on the organization's ability to absorb disruptions and continue delivering its most critical services, even in degraded states, regardless of the specific nature of the disruption.

Regulators in the United Kingdom (PRA/FCA), the European Union (DORA -- Digital Operational Resilience Act), and the United States (OCC, Federal Reserve) have all published operational resilience frameworks that shift the focus from point-in-time recovery metrics (such as Recovery Time Objectives and Recovery Point Objectives) to impact tolerances: the maximum disruption an organization can tolerate to a critical service before the impact becomes unacceptable to customers, the market, or the broader financial system.

Mapping Important Business Services

The operational resilience methodology begins with identifying Important Business Services (IBS) -- the end-to-end services that matter most to customers and to the organization's viability. Each IBS is then mapped to the people, processes, technology, data, and third-party dependencies that support it. This mapping surfaces single points of failure and concentration risks that might not be apparent from a traditional IT recovery or process continuity perspective.

Business Continuity Planning in an Operational Risk Context

Business continuity planning (BCP) remains a core component of operational risk management. A well-designed BCP confirms that for each identified disruption scenario -- a major IT outage, a physical facility unavailability, a key supplier failure, a pandemic -- the organization has documented procedures for maintaining minimum viable operations and an escalation pathway for decision-making under crisis conditions.

Effective BCPs are tested regularly. A plan that has never been exercised is a plan of unknown quality. Tabletop exercises (scenario-based discussions), functional exercises (testing specific response procedures), and full-scale simulations (activating actual recovery arrangements) all serve different testing objectives. Regular testing also identifies gaps and outdated assumptions before they are exposed in a real event. For guidance on structuring this planning, see our dedicated article on business continuity planning.

Technology and Cyber Risk Management

Technology risk has grown from a subset of operational risk into a discipline that commands dedicated attention at the highest levels of organizational governance. The volume, sophistication, and impact of cyber incidents have accelerated dramatically over the past decade, and regulators have responded with increasingly prescriptive requirements for technology risk management.

Cybersecurity Risk Assessment

Cybersecurity risk assessment follows the same fundamental principles as operational risk assessment but applies them to the specific threat landscape of information technology. The NIST Cybersecurity Framework, ISO/IEC 27001, and the Center for Internet Security (CIS) Controls are the most widely adopted reference frameworks. These frameworks emphasize asset inventory (you cannot protect what you do not know you have), threat modeling (identifying the specific attack vectors most likely to target your environment), and control effectiveness assessment.

Third-Party and Supply Chain Technology Risk

Modern organizations rely on extensive technology supply chains: cloud providers, software vendors, managed service providers, and specialized SaaS applications. Each of these relationships introduces technology risk that extends beyond the organization's direct control. The SolarWinds and MOVEit attacks demonstrated how a single third-party vendor compromise can cascade into hundreds of downstream victims simultaneously.

Third-party technology risk management requires due diligence at onboarding, contractual requirements for security standards, ongoing monitoring of vendor security posture, and contingency planning for scenarios in which a critical vendor becomes unavailable or is compromised.

Outsourcing and Vendor Risk Management

Outsourcing creates operational risk in multiple dimensions. Execution risk -- whether the vendor actually performs as contracted -- is the most obvious. But concentration risk (over-dependence on a single vendor), substitution risk (difficulty replacing a vendor quickly if needed), and information risk (data shared with third parties) are equally significant.

A mature vendor risk management program includes risk-based due diligence proportionate to the criticality and sensitivity of the outsourced function, contractual provisions for audit rights and security standards, ongoing performance monitoring, and exit planning that confirms operational continuity if the vendor relationship ends unexpectedly. Regulatory frameworks such as the EBA Guidelines on Outsourcing Arrangements and the OCC's Third-Party Risk Management Guidance provide detailed requirements for financial institutions, but the underlying principles apply across sectors.

Regulatory Expectations: SOX, Basel III, and Beyond

Operational risk management is extensively regulated across financial services and other sectors. The Sarbanes-Oxley Act (SOX) requires public companies to maintain effective internal controls over financial reporting, with management certification and independent auditor attestation. Material weaknesses in internal controls must be disclosed publicly, creating powerful incentives for control investment.

Basel III retains the operational risk capital requirement from Basel II and strengthens it with the new Standardized Approach for operational risk, which links capital requirements to a bank's business volume indicators and loss history. The Basel Committee's "Principles for Operational Resilience" and "Principles for the Sound Management of Operational Risk" provide detailed guidance on expected ORM program components.

For compliance-focused operational risk programs, see our detailed guide on compliance risk management and our broader article on risk management frameworks.

Incident Management: From Detection to Learning

When operational risk events occur -- and they will -- the quality of the organization's incident management process determines both the immediate impact and the long-term learning benefit. A well-designed incident management process moves through four stages: detection and reporting, assessment and escalation, response and remediation, and post-incident review.

Detection depends on the robustness of monitoring mechanisms: transaction surveillance systems, exception reporting, employee reporting channels, and customer complaints all serve as detection mechanisms. Organizations that make it easy and safe to report incidents -- including near-misses -- generate far more valuable risk intelligence than those where reporting is bureaucratic or culturally discouraged.

The post-incident review is where the greatest long-term value is created. A thorough review identifies root causes, assesses control failures, and generates corrective actions with clear ownership and deadlines. These findings feed back into the risk register, the control environment, and ultimately the KRI system, verifying that each incident makes the organization more resilient against future occurrences.

Creating an Operational Risk Framework

An operational risk framework is the architecture that connects all of the above components into a coherent, integrated program. It defines the governance structure (who is responsible for what), the risk taxonomy (how risks are categorized and described), the assessment methodology (how risks are identified and evaluated), the appetite and tolerance statements (what level of operational risk is acceptable), and the reporting structure (how risk information flows to decision-makers).

The Three Lines of Defense

The Three Lines of Defense (now often called the Three Lines Model) is the dominant governance framework for operational risk. The First Line comprises the business units and operational functions that own and manage operational risks in their day-to-day activities. The Second Line comprises risk management and compliance functions that provide oversight, challenge, and specialized expertise. The Third Line is internal audit, which provides independent assurance over the effectiveness of both first- and second-line activities.

Clear role definition and effective communication across the three lines is essential. The most common failure mode is a passive first line that treats risk management as a second-line responsibility, and a second line that compensates by becoming operational rather than maintaining its oversight role. When this happens, both lines are operating outside their proper function and the governance model breaks down.

Building an effective ORM framework requires sustained investment in people (skilled risk professionals), process (consistent methodologies and tools), and culture (genuine commitment from leadership and meaningful engagement from the business). Organizations that make this investment consistently demonstrate lower operational losses, better regulatory relationships, and greater organizational resilience. For practical implementation guidance, review our overview of risk assessment methodologies that underpin every effective ORM program.