Skip to main content
Category: Foundational Concepts

Operational Risk

Simply put

Operational risk is the potential for loss caused by breakdowns in an organization's day-to-day operations, whether from flawed internal processes, human error, or failing systems. It also includes losses driven by external events outside the organization's direct control. In a third-party context, these same failures can originate within a supplier or service provider and flow back to the organization that relies on them.

Formal definition

Operational risk is the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events. Managing it is typically approached as a continual, recurring process of identifying, assessing, mitigating, and monitoring these loss exposures rather than a point-in-time exercise. This category is distinct from, though it can intersect with, financial, strategic, and reputational risk; when assessing external parties, operational risk covers process, personnel, systems, and external-event exposures within the third party's operations and does not by itself encompass the organization's own broader risk portfolio.

Why it matters

Operational risk sits at the core of third-party and supply chain programs because a supplier's day-to-day failures do not stay contained within that supplier. When a service provider's internal process breaks down, its personnel make errors, or its systems fail, the resulting loss can flow directly back to the organization that depends on it. A payroll processor that misfires, a logistics partner whose systems go down, or a vendor whose staffing gaps interrupt service all translate into operational exposure for the relying organization, even though the originating failure occurred outside its own walls.

What makes operational risk demanding to manage is that it spans multiple loss sources at once: process, people, systems, and external events. These categories interact, and a single incident can implicate several of them. Because operational risk is distinct from financial, strategic, and reputational risk, treating it as a standalone concern can leave blind spots; conversely, treating it as identical to those categories can overstate what an operational assessment actually covers. In a third-party context, assessing a supplier's operational risk speaks to exposures within that supplier's operations and does not, by itself, capture the organization's own broader risk portfolio.

A further practical challenge is that operational risk is dynamic. A supplier's processes, workforce, and systems change over time, so a favorable finding at onboarding can become stale. Programs that treat operational risk as a point-in-time judgment rather than an ongoing exposure risk missing degradation that occurs between assessments.

Who it's relevant to

Third-party risk and vendor management teams
These teams assess whether a supplier's internal processes, personnel, and systems can deliver reliably, and whether a failure in the supplier's operations would flow back as a loss to the organization. Because operational risk is dynamic, they typically treat it as an ongoing monitoring concern rather than a onboarding checkbox.
Operational resilience and business continuity functions
For these functions, operational risk covers the external-event and systems-failure exposures that can interrupt service, whether originating internally or within a critical third party. They focus on how a supplier's day-to-day breakdown could disrupt the organization's own operations.
Procurement and sourcing professionals
When selecting and contracting with vendors, service providers, and business partners, procurement teams weigh operational exposures alongside cost and capability. Understanding that operational risk is distinct from financial and strategic risk helps them scope due diligence to the right loss sources rather than assuming one assessment covers all risk categories.
Compliance and risk governance leaders
These leaders oversee how operational risk is identified, assessed, mitigated, and monitored across the program. They are positioned to ensure that operational-risk coverage of third parties is not mistaken for coverage of the organization's broader risk portfolio, and that point-in-time findings are refreshed as suppliers' operations change.

Inside Operational Risk

People and human factors
Risk arising from human error, inadequate staffing, skills gaps, fraud, or misconduct within a third party's operations. In a TPRM context this extends to whether a supplier's workforce practices and key-person dependencies could disrupt the services delivered to the buying organization.
Processes and internal controls
Risk stemming from failed, inadequate, or poorly designed internal processes at a third party, including control gaps that may affect service delivery. This component is typically assessed through due diligence and control questionnaires, though such instruments are self-reported and do not by themselves constitute independent verification.
Systems and technology
Risk from system failures, outages, or technology dependencies. This overlaps with, but is not identical to, information security risk; operational risk here concerns availability and reliability of the systems supporting delivered services rather than confidentiality or data protection alone.
External events
Risk from events outside the third party's direct control, such as natural hazards, infrastructure disruption, or supplier failure. In extended networks this can propagate through fourth-party or Nth-party dependencies that are often not directly visible to the buying organization.
Resilience and continuity considerations
The degree to which a third party can absorb, respond to, and recover from operational disruption. This draws on business continuity and disaster recovery capabilities, which are related but distinct: continuity addresses sustaining critical functions, while recovery addresses restoring systems and operations after an event.

Common questions

Answers to the questions practitioners most commonly ask about Operational Risk.

Is operational risk the same as operational resilience?
No. Operational risk refers to the potential for loss arising from inadequate or failed internal processes, people, and systems, or from external events. Operational resilience is broader and outcome-focused: it concerns an organization's ability to prevent, adapt to, respond to, recover from, and learn from operational disruptions. Managing operational risk is one input into building resilience, but the two are distinct concepts and should not be treated as interchangeable.
Does operational risk only cover internal failures within our own organization?
Not exclusively. While operational risk originates in internal processes, people, and systems, its recognized scope also includes external events. In a third-party context, disruptions or failures at a supplier, service provider, or business partner can transmit operational risk into your organization. Depending on how a program defines its boundaries, third-party-driven operational risk may be assessed within the operational risk domain, within third-party risk management, or across both, so it is worth confirming where responsibility sits rather than assuming it is internal-only.
How should we distinguish operational risk from other third-party risk categories during assessment?
In many programs, operational risk is one category alongside information security, financial, compliance, geopolitical, and ESG risk, and a single vendor can carry several simultaneously. When scoping an assessment, it typically helps to identify which processes, people, and systems the third party supports, then evaluate the operational risk to those specifically. Be explicit about what a given operational risk assessment covers and what it does not, since controls addressing operational disruption may not speak to financial stability or data protection.
What limitations should we keep in mind when assessing a third party's operational risk?
Point-in-time assessments can become stale as a supplier's processes, staffing, or systems change, so operational risk ratings may not reflect current conditions. Self-reported questionnaires describe intended or claimed practices but do not independently verify them. Visibility also tends to weaken beyond the first tier, so operational risk introduced by fourth or Nth parties may be understated. Framing these limitations openly helps set expectations about what an operational risk view can and cannot tell you.
How does operational risk relate to concentration risk and single points of failure in a supplier base?
These are related but distinct. Operational risk is the potential for loss from failed or inadequate processes, people, systems, or external events. Concentration risk arises when reliance is heavily aggregated on a limited set of suppliers, and a single point of failure is a specific element whose failure would halt a process. Concentration and single points of failure can amplify the impact of an operational risk event, but they describe structural exposure rather than the risk category itself. Assessing them together, rather than conflating them, gives a fuller picture.
How can operational risk be monitored on an ongoing basis rather than only at onboarding?
Onboarding due diligence typically establishes an initial operational risk baseline, but it does not capture how that risk evolves. Depending on the risk tier, programs may layer in ongoing monitoring such as periodic reassessment, performance and service-level tracking, incident and disruption reporting, and reviews tied to material changes at the supplier. The intent is to keep the operational risk view current between formal assessments, though the cadence and depth of monitoring often vary with the criticality of the relationship.

Common misconceptions

Operational risk is essentially the same as information security or cyber risk.
Operational risk is broader, covering people, processes, systems, and external events affecting service delivery. Information security risk is one contributing category but does not encompass financial, staffing, process-failure, or external-event dimensions of operational risk.
A completed due diligence questionnaire or supplier attestation confirms that operational controls are effective.
Questionnaires and attestations are typically self-reported and point-in-time, and do not constitute independent verification. They may become stale between assessment cycles and often give limited visibility beyond the first tier of the supply network.
Assessing a direct third party's operational risk captures the full operational exposure.
Direct third-party assessment does not necessarily reveal fourth-party or Nth-party dependencies, single-source concentrations, or single points of failure residing deeper in the supply chain, which fall more within the scope of supply chain risk management.

Best practices

Scope operational risk assessments explicitly, distinguishing which components (people, processes, systems, external events) are covered and which risk domains, such as financial or ESG, are handled separately.
Supplement point-in-time questionnaires and attestations with ongoing monitoring, and where warranted by the risk tier, seek independent verification rather than relying on self-reported responses alone.
Tie assessment depth and monitoring frequency to the criticality of the service, applying more rigorous scrutiny to third parties whose disruption would materially affect operations.
Evaluate business continuity and disaster recovery capabilities as distinct but complementary elements, confirming both the ability to sustain critical functions and to restore systems after disruption.
Probe for concentration risk, single-source dependencies, and single points of failure, and where feasible extend visibility to fourth-party and Nth-party dependencies rather than stopping at the first tier.
Refresh operational risk information on a defined cadence and after significant changes, recognizing that point-in-time assessments become stale and may not reflect a supplier's current state.
Application Security Isn’t Optional Anymore.