Operational risk has been defined by the Basel Committee on

Banking Supervision1 as the risk of loss resulting from

inadequate or failed internal processes, people and systems or
from external events.

Operational risk can refer to both the risk in operating an organization and the
processes management uses when implementing, training, and enforcing
policies. Operational risk can be viewed as part of a chain reaction: overlooked
issues and control failures can— whether small or large — lead to greater risk
materialization, which may result in an organizational failure that can harm a
company’s bottom line and damage its reputation. While operational risk
management 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
operational risk management function is to focus on the risks with the most impact on the
organization and to hold employees who manage operational risk accountable.

Examples of operational risk include:

• Employee conduct and employee error

• Breach of private data resulting from cybersecurity attacks
• Technology risks tied to automation, robotics, and artificial intelligence
• Business processes and controls
• Physical events, such as natural catastrophes
• Internal and external fraud
• Workplace safety risks

Table: Loss Event Types and Examples Defined by the Basel Committee
How Operational Risk Management Works
When dealing with operational risk, the organization has to consider every aspect of its
objectives. Since operational risk is so pervasive, the goal is to reduce and control every risk
to an acceptable level. Operational Risk Management attempts to reduce risks through the
linear process of risk identification, risk assessment, measurement and mitigation,
monitoring, and reporting while determining who manages operational risk.

These stages are guided by four principles:

• Accept risk when benefits outweigh the cost.

• Accept no unnecessary risk.
• Anticipate and manage risk by planning.
• Make risk decisions at the right level.

Risk Identification
Operational Risk Management begins with identifying what can go wrong. As a best practice,
a control framework should be used or developed to ensure completeness. Identifying risks
begins with scenario analysis — taking a look at the challenges facing the business and
pinpointing areas that could disrupt operations or pose another risk to the organization.

Risk Assessment
Once the risks are identified, the risks are assessed using an impact and likelihood scale, also
known as a Risk Assessment Matrix. At this stage, risks are categorized by type of risk and
level of risk.

Measurement and Mitigation

In the risk assessment, risks are measured against a consistent scale to allow the risks to be
prioritized and ranked comparative to one another. The measurement also considers the
cost of controlling the risk related to the potential exposure.

Monitoring and Reporting

Risks are monitored through an ongoing risk assessment to determine any changes over
time. The risks and any changes are reported to senior management and the board to
facilitate decision-making processes.

Primary Objectives of Operational Risk Management

As the name suggests, the primary objective of Operational Risk Management is to mitigate
risks related to the daily operations of an organization. The practice of Operational Risk
Management focuses on operations and excludes other risk areas such as strategic and
financial risks. While other risk disciplines, such as Enterprise Risk Management (ERM),
emphasize optimizing risk appetites to balance risk-taking and potential rewards, ORM
processes primarily focus on controls and eliminating risk. The ORM framework starts with
risks and deciding on a mitigation strategy.

Operational Risk Management proactively seeks to protect the organization by eliminating or

minimizing risk.
Depending on the organization, managing operational risk could have a very large
scope.Some organizations might categorize fraud risks, technology risks, as well as the daily
operations of financial teams like accounting and finance as part of this umbrella. The Risk
Management Association defines operational risk as “the risk of loss resulting from
inadequate or failed internal processes, people, and systems, or from external events, but is
better viewed as the risk arising from the execution of an institution’s business functions.”
Given this viewpoint, the scope of operational risk management will encompass
cybersecurity, fraud, and nearly all internal control activities.

Applying a control framework, whether a formal framework or an internally developed

model, will help when designing the internal control processes. One approach to
understanding how ORM processes look in your organization is by organizing operational
risks into categories like people risks, technology risks, reputational risks, and regulatory
risks.

People
The people category includes employees, customers, vendors, contractors, and other
stakeholders. Employee risk includes human error and intentional wrongdoing, such as in
cases of fraud. Risks include breach of policy, insufficient guidance, poor training, bad
decision-making, or fraudulent behavior. People can pose a risk to the organization even
externally, as social media is more and more likely to have an impact on business. Risks
associated with people can be especially sensitive and tricky, especially since people play a
role in every aspect of an organization’s operations. Fostering a healthy risk culture through
training and regular communication is key to managing this area of risk.

Technology
Technology risk from an operational standpoint includes hardware, software, privacy, and
security. Technology risk also spans the entire organization and affects the people category
described above. Hardware limitations can hinder productivity, especially when in a remote
work environment. Software too can reduce productivity when applications suffer an outage
or employees lack training. Software can also impact customers as they interact with your
organization. External threats exist as hackers attempt to steal information or hijack
networks. This can lead to leaked customer information and data privacy concerns.

As technology expands to play a larger role in all of our lives risks in this space become
increasingly significant and complex. If not included already, business continuity plans
should address risks related to technology failures and other disruptions.
Regulations
Risk for non-compliance to regulation exists in some form in nearly every organization. Some
industries are more highly regulated than others, but all regulations come down to
operationalizing internal controls. Over the past decade, the number and complexity of rules
have increased and the penalties have become more severe.

Understanding the sources of risk will help determine who manages operational risk.
Enterprise Risk Management and Operational Risk Management both address risks in the
same areas but from different perspectives. In an effort to consolidate these disciplines,
some organizations have implemented Integrated Risk Management or IRM. IRM addresses
risk from a cultural point of view. Depending on the objective of the particular risk practice,
the organization can implement technology with different parameters for teams like ERM
and ORM.

Steps in the ORM Process

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

Image: Steps in the ORM Process

Image source: PWC Operational Risk Management

Step 1: Risk Identification

Risks must be identified so these can be controlled. Risk identification starts with
understanding the organization’s objectives. Risks are anything preventing the organization
from achieving its objectives. Asking “What could go wrong?” is a great way to begin
brainstorming and identifying risks.

Step 2: Risk Assessment

Risk assessment is a systematic process for rating risks based on likelihood and impact. The
outcome of the risk assessment is a prioritized listing of known risks, along with the risk
owner and risk mitigation plan, also known as a risk register. It may not be possible or
advisable for an organization to address all identified risks — thus, prioritization is critical for
the management of operational risk and points project teams at the most significant
risks.This risk assessment process may look similar to the risk assessment done by internal
audit, and should, in fact, be informed by prior audit reports and findings.

Step 3: Risk Mitigation

The risk mitigation step involves developing and choosing a path for controlling specific risks.
In the Operational Risk Management process, there are four options for addressing potential
risk events: transfer, avoid, accept, and mitigate.

Transfer: Transferring shifts the risk to another organization. The two most common means
for transferring are outsourcing and insuring. When outsourcing, management cannot
completely transfer the responsibility for controlling risk. Insuring against the risk ultimately
transfers some of the financial impacts of the risk to the insurance company. A good
example of transferring risk occurs with cloud-based software companies. When a company
purchases cloud-based software, the contract usually includes a clause for data breach
insurance. The purchaser is ensuring the vendor can pay for damages in the event of a data
breach. At the same time, the vendor will also have their data center provide SOC reports
showing there are sufficient controls in place to minimize the likelihood of a data breach.
Avoid: Avoidance prevents the organization from entering into a risk-rich situation or
environment. For example, when choosing a vendor for a service, the organization could
choose to accept a vendor with a higher-priced bid if the lower-cost vendor does not have
adequate references.
Accept: Based on the comparison of the risk to the cost of control, management could
accept the risk and move forward with the risky choice. As an example, there is the risk an
employee will burn themselves if the company installs new coffee makers in the break room.
The benefit of employee satisfaction from new coffee makers outweighs the risk of an
employee accidentally burning themselves on a hot cup of coffee, so management accepts
the risk and installs the new appliance.
Mitigate: Mitigating risks involves implementing action plans and controls that reduce the
likelihood of the risk and/or the impact it would have if the risk were realized. For example,
if an organization allows employees to work from home, there is a risk of data leakage due
to the transmission of data across the public internet. To mitigate this risk, management
might implement a VPN service and have remote users access the business network through
VPN only. This would reduce the likelihood of data leakage, thereby mitigating the risk.
We’ve mentioned a few times that very few risks can be completely eliminated. Noting the
residual risk — the risk remaining after mitigation — is an equally important part of the risk
mitigation phase of ORM.

Step 4: Control Implementation

Once risk 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 and mitigate the risk in question. The control rationale, objective, and activity
should be formally documented so the controls can be clearly communicated and executed.
Controls might take the form of a new process, an additional approver, or built-in controls
that prevent end users from making errors or performing malicious activities. Whenever
possible, controls should be designed to be preventive, rather than detective or corrective.
With risk management and medicine, it seems the best cure is prevention. That said, it may
be impossible to prevent a risk from occurring, which is where detective controls come into
play. Detecting anomalies and then correcting them may be sufficient to mitigate certain
risks.

Most likely, your organization already has some controls in place to combat risks. It’s still
wise to review those controls on an annual basis (at minimum) and determine whether
additional controls are needed if there are gaps in the control, or if the control is sufficient to
address the risk and requires no changes.

Step 5: Monitoring
Since controls may be performed by people who make mistakes, or the environment could
change, controls should be monitored. Control monitoring involves testing the control for
appropriateness of design, and operating effectiveness. Any exceptions or issues should be
raised to management with action plans established.

Within the monitoring step in Operational Risk Management, some organizations, especially
in financial services, have adopted continuous monitoring or early warning systems built
around key risk indicators (KRIs). Key risk indicators are metrics used by organizations to
provide an early signal of increasing risk exposure in various areas of the enterprise. KRIs
designed around ratios monitored by business intelligence applications are how banks can
manage operational risk, but the concept can be applied across all industries. KRIs can be
designed to monitor nearly any potential risk and send a notification. As an example, a
company could design a key risk indicator around customer satisfaction scores. Falling
customer satisfaction scores could indicate customer service representatives are not being
trained or that the training is ineffective.

IMPORTANT QUESTIONS:

What Are the 5 Levels of Risk?

Companies often gauge risk by determining whether it is highly likely,
likely, possible, unlikely, or highly unlikely an event will occur. Highly likely
is often assigned a percentage of greater than 90%, while likely includes a
range that is always above 50%. Management uses these percentages to
determine the best course of action when evaluating the cost of mitigation
against the cost of a detrimental outcome.
How Do You Identify Operational Risk?
Operational risk is identified by assessing what could go wrong in the day-
to-day aspects of a company. Management often identifies operational risk
by asking questions such as "what if a certain system broke down?" or
"what if a certain supplier was unable to deliver goods on time?".
Management can come up countless areas of operational risk; it is up to
them to decide which aspects are most important to mitigate and which to
accept.

What Are the 4 T's of Risk Management?

The four T's of risk management are:

• Tolerate: management decides they are okay with a certain

operational risk and does not action to stop it.
• Terminate: management is not okay with any level of risk with a
certain activity and decides to stop that activity.
• Treat: management puts in place certain maneuvers that decrease
the potential total risk.
• Transfer: management wants to perform an activity but seeks a
third-party to incur the risk on their behalf (i.e. buy insurance).

Who Is Responsible for Managing Operational Risk?

Senior management is often responsible for managing operational risk by
being aware of what risks are in place and the strategies for overcoming
them. Though lower-level field managers are more involved in the day-to-
day aspects, senior management should oversee their activities to make
sure the operational risk strategies are being properly carried out.

The Bottom Line

Operational risk is the risk of loss resulting from many normal aspects of
business. This includes the risk of loss caused by failed processes,
unskilled employees, inadequate systems, or external events. In many
ways, operational risk can't be avoided as it is part of the daily business
activity of a company. In other ways, companies can seek to reduce,
mitigate, or accept operational risk.