Operational Risk

Categorisation
Operational Risk Sound
Practice Guidance

An IRM Group Company

Foreword
The Institute of Operational Risk (IOR) was created in January 2004 and became part of
the Institute of Risk Management in 2019. The IOR’s mission is to promote the development
of operational risk as a profession and to develop and disseminate sound practice for the
management of operational risk.

The need for effective operational risk management is more acute than ever. Events such as
the global financial crisis or the COVID-19 pandemic highlight the far-reaching impacts of
operational risk and the consequences of management failure. In the light of these and numerous
other events organisations have to ensure that their policies, procedures, and processes for the
management of operational risk meet the needs of their stakeholders.
This guidance is designed to complement existing standards and codes for risk management
(e.g. ISO31000). The aim is to provide guidance that is both focused on the management of
operational risk and practical in its application. In so doing, this is a guide for operational risk
management professionals, to help them improve the practice of operational risk in organisations.
Readers looking for a general understanding of the fundamentals of operational risk management
should start with the IOR’s Certificate in Operational Risk.

Not all the guidance in this document will be relevant for every organisation or sector. However,
it has been written with the widest possible range of organisations and sectors in mind. Readers
should decide for themselves what is relevant for their current situation. What matters is gradual,
but continuous improvement.

The Institute of Operational Risk Sound Practice

Guidance
Although there is no one-size-fits-all approach to the management of operational risk,
organisations must benchmark and improve their practice regularly. This is one of a series of
papers, which provides practical guidance on a range of important topics that span the discipline
of operational risk management. The objectives of these papers are to:
• Explain how to design and implement a ‘sound’ (robust and effective) operational risk
management framework
• Demonstrate the value of operational risk management
• Reflect the experiences of risk professionals, including the challenges involved in developing
operational risk management frameworks.

2
Contents
1. Introduction 4
[Link] rationale for operational risk categorisation 5
[Link] Principles for Categorising Operational Risks 6
3.1 Risk categorisations should be based on established external frameworks 6
3.2 Risk categorisations should be customised 6
3.3 Consultation is essential 6
3.4 Periodic review 6
4. Designing an Operational Categorisation Framework 8
[Link] Basis of Categorisation: Cause, Event or Effect? 8
4.2 Minimising Gaps and Overlaps 9
4.3 Granularity 9
4.4 Other Design Considerations 10
5. Implementation 11
5.1 Roles and responsibilities 11
5.2 Ensuring consistent use 11
5.3 Reporting 12
5.4 Addressing boundary events 12
6. Conclusion 14
Appendix A: Example Operational Risk Categorisations 15

3
Section 1 - Introduction
Organisations are exposed to a range of risk types. Operational risks are one of these risk types.
Table 1 summarises some of the common risk types to which organisations are exposed.

Risk Type Description

Credit The risk that a counterparty may default of their obligations (a given financial
claim is not paid in full) or have their credit rating downgraded.
Liquidity The risk that an organisation is unable to meet its financial liabilities as they fall
due.
Market The risks that arise due to fluctuations in the value of, or income from, the assets
of an organisation.
Operational The risk of loss resulting from inadequate or failed internal processes, people,
and systems or from external events.
Reputation Threats to the public perception of an organisation and goodwill exhibited by its
stakeholders.
Strategic Risks that are created or affected by the chosen strategy of an organisation.
Table 1: Common Risk Types
Whilst the focus of this paper is the categorisation of operational risks, they exist within a wider
organizational context. Specifically, there will be times when exposures and events over-lap
these risk types or where an event in one type of risk causes risks in another. For example, the
emergence of an operational risk could precipitate a strategic risk and the combination could in
turn lead to a reputational impact. In view of this, any categorisation of operational risks must not
seek to segregate or isolate exposures and should be conducted within a holistic framework for
categorising all of the risks to which an organisation is exposed (for example, an enterprise risk
management framework).

4
Section 2 - The rationale for operational risk
categorisation
Operational risk exposures arise from the day-to-day operations of organisations. These
operations span many activities and processes and require people, systems, and equipment to
perform them in an efficient and low-cost manner. Give the breadth of organisational activities
and the diverse processes, people, systems, and equipment required to fulfil them, the potential
range of operational risk exposures and events are numerous. For example, they range from
IT security breaches, employment disputes, fraud and customer complaints to fires, floods and
other so-called ‘acts of god’.
Given the wide scope of operational risk exposures and events, categorisation can help to
organise the identification, assessment, monitoring and control of specific types of exposure,
as well as the types of loss that may occur. Different categories of risk may require specific risk
assessment techniques and control approaches. Equally, some may be insurable (liability claims
and property damage), others not (regulatory fines). The specific benefits are as follows:
• Identification: an operational risk categorisation provides a ‘menu’ of potential risks, which can
be used as a prompt in determining those that are relevant to an organisation or its specific
departments and functions. This should help prevent risks from being overlooked
• Measurement: the use of consistent terms and descriptions facilitates comparisons between
operational risks and supports data aggregation (especially were risks are sub-categorised,
see below)
• Monitoring and reporting: a common frame of reference enables more meaningful analysis
and oversight of the outputs generated by an operational risk management framework. For
example, management should be better able to prioritise resources to the most significant
operational risks, compare risk exposures in different departments and functions and set more
granular targets, limits, and thresholds
• Control: given the scope of operational risk, different categories may require very different
control responses. Hence by categorising these risks customised control strategies may be
developed
Finally categorising operational risks demarcates them from other types of risk (Market, Credit,
etc.). Where an organisation has multiple risks and other related control functions this helps to
minimise the potential for gaps and overlaps, though rarely will they be eliminated, especially
overlaps. Boundary issues between operational risk categories and other risk types do occur and
are discussed below.

5
Section 3 - Key Principles for Categorising Operational
Risks
It is important to minimise the potential for gaps and overlaps in any operational risk
categorisation. Avoiding gaps is especially important, since this may result in important
exposures being ignored.
Section 3.1 - Risk categorisations should be based on established external frameworks
Various organisations provide example risk categorisations. The most common for operational
risk is provided by the Basel Committee on Banking Regulation. Though this focuses on financial
institutions it represents a good starting point for any operational risk categorisation. This external
framework is outlined in Appendix A, along with one other, the UK Treasury’s ‘Orange Book’.
Section 3.2 - Risk categorisations should be customised
Though an established external framework provides a useful starting point for any categorisation,
organisations may need to adapt them to suit the nature, scale, and complexity of their
operations. Where organisations do deviate from an external framework it is recommended that
a mapping exercise is completed to ensure that all relevant categories are included. It may also
be that an organisation is required to use an external framework (e.g. the Basel framework) for
regulatory reporting. Here no category must be missed out.
Section 3.3 - Consultation is essential
The directors, managers and employees of an organisation must all be comfortable with any
categorisation. Specifically, they must be able to understand the terms and descriptions that are
used, and the categorisation must be usable and support the work that they do.
It is recommended that an initial, draft, categorisation is developed by the (operational) risk
function, using one of the established external frameworks as a foundation. Comments should
then be invited from all those that will be involved in the use of the categorisation (e.g. risk
owners, a governing body, internal audit, compliance, etc.) to ensure that they understand the
terms and descriptions used. They could also be invited to suggest omitted categories, that may
be relevant for the organisation, but which are not captured by an external framework. However,
where this is done, care should be taken to check whether any additional categories are simply
a rewording of an existing category, as well as whether they can be mapped back to one of the
categories within the external framework used as a basis for the categorisation.
Section 3.4. Periodic review
An organisation’s operations and its associated operational risk exposures will change regularly.
It may also be that through the use of categorisation gaps and overlaps are identified that were
not considered at the initial design stage. Equally new types of risk may emerge, as was the case
with cyber risk. Hence, to ensure that any categorisation framework remains valid periodic review
is necessary. Usually, this should be completed on an annual basis.
Care should be taken when changing a pre-existing categorisation. Changes to categorisation
may make it harder to track trends or interfere with historical data aggregation. When any change
is made to a pre-existing category this should be mapped back to the previous categorisation
to allow data to be carried forward into subsequent risk assessments, for example. This is
especially important where statistical tools and models are used to support risk assessment.

6
Adding new categories is easier, but it is important to double check whether a ‘new’ category is
not simply a re-imagining of a pre-existing one. Adding multiple new categories may also make
the categorisation unnecessarily complex, especially if they increase the potential for overlaps
and mis-classifications.
Table 2: Levels of granularity for operational risk categorisation
The Basel operational loss event classification provided in Appendix A illustrates the first three
levels of table 2.
Not all organisations may elect to have levels 2 or 3 in table 1. But most will have level 4. This is to
allow specific departments, functions, etc. to customise the categorisation to meet their specific
needs while ensuring that all risks can be mapped back to a level 1 category.

7
Section 4 - Designing an Operational Categorisation
Framework
As explained above designing an operational risk categorisation framework requires great care.
Errors at the design stage may make the framework inefficient and time-consuming to use. Worse
it may result in important operational risks from being overlooked.
Section 4.1 - The Basis of Categorisation: Cause, Event or Effect?
Like any type of risk, operational risks are multi-faceted. Meaning that they are a combination of
causes, events, and effects. Figure 1 illustrates the relationship between them.

Figure 1: Cause, event, and effect

The common definition of operational risk provided in table 1 demarcates operational risk based
on its causes: people, processes and systems and external events. These causes may result in
a wide range of operational risk events (fires, floods, theft, errors, and omissions, etc.). In turn,
these events have multiple effects (financial loss, physical injuries, etc.). A categorisation may be
based on any one of these three facets of operational risk.

Categorisations based on operational risk events are most common. The Basel categorisation in
Appendix A is event-based, so financial institutions are often required to report their operational
losses using this categorisation and therefore decide to use it elsewhere to ensure consistency.
Also, loss data is collected on a per-event basis. Loss events being the most visible manifestation
of the presence of operational risk in an [Link] of the advantages of an event-based
approach is that it does not preclude the further sub-division of events into their constituent
causes and effects. This allows an organisation to better picture the relationships between
causes, events, and effects, highlighting potential correlations or concentrations of risk.

However, the downside of an event-based approach is that the associated categorisation

framework can become very detailed, in an attempt to reflect the totality of events that may occur.
This requires careful consideration of the issue of granularity (see section 4.3, below).

Causal based categorisations have an intuitive appeal because they represent the starting point
for operational risk exposures and so may help make operational risk management more leading
and proactive. However effective classifications are hard to achieve in practice. Though the
broad categories of causes are small, specific causes are numerous, often more numerous that
potential events.

8
The absence of established external frameworks for categorising operational risks according
to their causes also makes them more challenging. The same arguments apply to effect-
based categorisations (numerous sub-effects, especially non-financial effects, and no external
framework).

The IOR’s view is that operational risks are best categorised on an event basis. However, where
possible high-level sub-categorisations for their causes and effects should be used to complement
an event-based categorisation. This will allow an organisation to better link causes, events, and
effects and to identify and mitigate potentially dangerous patterns in these causes and effects.

Section 4.2. - Minimising Gaps and Overlaps

No operational risk categorisation is perfect. Compromise is always required. A very detailed
categorisation may eliminate most gaps but result in frequent overlaps and classification
problems. Misclassification is just as serious an issue as potential gaps or overlaps. In contrast, a
less detailed classification should make it easier to categorise risks but could result in important
risks being missed.
The best approach is to develop levels of classification. The initial level of classification is kept
relatively broad, with additional layers added to provide further detail (see 4.3 below). The
advantages of such an approach are that all operational risk events should be classifiable, while
the layers of detail help users to apportion events, thus preventing overlaps and gaps. For more
on addressing boundary issues see section 5.3.

Section 4.3. - Granularity

Determining the level of detail in any operational risk categorisation is an essential decision. Less
granularity will make the categorisation easier to manage and aggregate data for assessment
and reporting purposes, but more detail will assist the focus of management and support
mitigation. Some organisations adopt a compromise solution, which involves adding more
granularity for critical categories but accepting less detail for categories of lower significance
(in terms of volume and/or value). This avoids the trap of too few risks spread across too many
categories, resulting in an inability to aggregate.
Various layers of granularity are possible. Table 2 summarises the most common.

Level Explanation
1 A small number of high-level labels reflecting, for example, common categories of
events, the generic systems and processes of an organisation, areas of regulatory
concern or the organisation’s objectives. For example: Acts of God (fires, etc.), Business
Continuity, IT Systems, Legal and Regulatory, Financial Crime, etc
2 The level 1 categories split into their logical component parts, depending on the specific
manifestations of these events. For example, acts of god might be spit into fires, floods,
windstorms, etc. Financial crime into internal and external fraud or IT systems into
hacking attacks and equipment failures
3 Level 2 categories further sub-divided to reflect the operational activities that may occur
within an organisation’s divisions, departments, or functions
4 A detailed description of the level 2 or 3 (where present) operational risk events that may
occur within a specific context (e.g. payroll, manufacturing, sales, etc)

The advantage of levels 2 and 3 is that they add extra detail. This detail can help users to ensure
that risks are categorised consistently. Also, it can reduce the potential for risks being overlooked,
because users have not considered a specific aspect of a risk event (e.g. internal as well as
external hacking attacks).

9
Section 4.4. - Other Design Considerations
In the course of designing operational risk categorisations practitioners have discovered a
number of other factors to consider. These are summarised below.
• The design of the categorisation must be appropriate and proportionate. A more granular/
detailed approach is not necessarily better and can lead to confusion, increasing the time and
resources required to manage operational risks. For many organisations this means that level
1 granularity should be sufficient, at most level 2
• Consistency of use is key – this means ensuring clear and unambiguous explanations for
each category of risk. Non-technical language (so-called plain English) is recommended, as
this will reduce the potential for any misunderstanding
• Ensure relevance to all parts of the organisation. The framework must make sense to the user
population and be structured in a manner that is consistent with their activities and objectives
• It is advisable to avoid including an “other” category. Such categories can become over-
loaded with risks that could be categorised elsewhere. Where a discrete new category of risk
genuinely emerges, it should be added to the framework

10
Section 5 - Implementation
This section outlines the factors that should be considered when implementing an operational
risk categorisation, along with some common challenges and how these challenges may be
overcome.
Section 5.1. - Roles and responsibilities
An operational risk classification will influence many operational risk management activities
across all of the departments and functions that make up an organisation. Table 3 outlines the
primary users of the classification and their responsibilities.

Role Responsibilities
Governing body The governing body supported by senior management have responsibility
and senior for ensuring that a sound system of operational risk management is in place.
managers This includes ensuring that an appropriate risk categorisation framework is in
place and that the framework is working as intended.
Risk owners and Risk owners are business managers which responsibility for the management
other staff with of some or all operational risks in their area. Risk owners should ensure that
operational risk they and their staff understand the operational risk categorisation framework
management and that it is used correctly to support risk identification, reporting, etc.
responsibilities
All other staff with operational risk management responsibilities must also
ensure that they understand the categorisation framework and use it correctly.
Risk function The risk function, or operational risk function, where present, is responsible
for the design of the operational risk management categorisation framework
and for ensuring that it is used consistently across the organisation.
To support the implementation of the framework the (operational) risk function
should ensure that it is documented and that a clear description of each
category is provided. Mechanisms for dealing with any boundary issues (see
below) should also be explained. This documentation could be supported
by training and awareness activities, to help ensure that all relevant staff
understand the framework and can use it effectively.
Internal audit Internal audit is responsible for providing assurance to the governing body
and supporting senior management that the operational risk categorisation
framework is fit for purpose and working as intended.
Internal audit may also choose to use the operational risk classification
to support audit planning and to structure management actions in audit
reports. Linking each action to one or more category of operational risk.
Where possible this approach is recommended, as it can help to embed the
categorisation approach and ensure a consistent approach to operational
risk.

Section 5.2. - Ensuring consistent use

Consistency of use is key. If different managers or parts of the organisation classify similar risks
differently then it will be impossible to achieve an accurate organisation-wide view of its operational
risks.

11
A key challenge to consistency is that categories are rarely mutually exclusive. This means that
the users of any operational risk categorisation framework will sometimes find that risk could
potentially be placed into two or more categories. For example, a fraud committed by a former
employee might be classified as either an internal or external fraud.

A related challenge is that risk events can be related, with the occurrence of one event causing
another to occur. For example, an external hacking attack might, in turn, result in a systems
failure as well as data theft. How then should such an event be categorised? As an external fraud
or cyber attack (the underlying cause) or as a systems failure or data theft event?
There are no single right solutions to these challenges. But it is essential to agree on a consistent
approach for them across an organisation. As a general rule the IOR would recommend the
following:
• Operational risk events should be categorised according to the underlying or original event. In
the case of the above hacking attack example, this means classifying the event as an external
hacking (cyber) attack, rather than a systems failure or data theft event. However, the potential
for such an event to impact systems continuity and security should be noted and addressed
in any management response.
•
Procedures should be documented on how to resolve any classification difficulties. As a
general rule if managers are in any doubt about how an operational risk should be classified
they should refer the matter to the (operational) risk function for a decision.
• These procedures should be supported by training on how to categorise operational risks
consistently. Ideally, this training should include local examples of risks and explain how they
should be categorised.
• Where an IT system is used to support operational risk management, the risk categorisation
framework should be embedded within this system and include guidance on how to classify
risks appropriately (e.g. drop-down descriptions of each risk category).
• As part of the periodic review process of the operational risk categorisation attention should
be paid to problem categories, where management finds it most difficult to allocate risks
consistently. Where possible these categories should be amended, in consultation with
management, to correct any issues.

Section 5.3. - Reporting

The structure of operational risk reports should reflect, where possible, the agreed operational
risk categorisation. This should ensure the accurate aggregation of operational risk data and help
to further embed the categorisation across the organisation.
An operational risk categorisation should also be used to adjust the level of detail provided in
reports. As a general rule, the governing body will require reports that summarise any significant
exposures or loss events with an organisation’s level 1 (see table 2) operational risk categories.
Senior management significant exposures/loss events with the level 2 categories and for
departmental/functional managers exposure to their local level 2 or 3, if used, risks.

Section 5.4. - Addressing boundary events

A boundary event can be defined as one which becomes apparent in one risk type but has its
causes in a different risk type e.g. an insurance risk or credit risk loss that has arisen as a result
of an underlying operational risk event (e.g. a processor control failure). For example, a creditor
default is an example of credit risk, but the underlying cause may have been errors in the due
diligence process, which meant that credit was provided to a counterparty with a poor credit
rating.

12
Boundary events are inevitable for most organisations. They can be particularly problematic
in organisations that have discrete risk functions (e.g. a credit risk management function and
an operational risk management function). This is because arguments may occur over which
function ‘owns’ the risk. It may also lead to a waste of management resources because it is
double managed. Even worse risks may be overlooked, with each function assuming that it is the
other’s responsibility.
Boundary events are less problematic in organisations that have mechanisms for coordinating
the management of different risk types, such as an Enterprise Risk Management Framework
or a holistic risk function lead by a Chief Risk Officer. Cross-discipline training can also help,
where specialist risk functions learn about the work of their peers (e.g. operational risk training
for the credit risk function and vice-versa). As can the establishment of a cross-disciplinary
risk committee that discusses potential boundary events and apportions responsibility for their
management to the relevant risk function.

13
Section 6 - Conclusion
Given the wide variety of operational risks, they must be organised consistently. The
categorisation is an important part of this objective, helping to allocate limited management
resources efficiency and preventing risks from being overlooked.

In a sense, a sound operational risk categorisation is the skeleton that supports the entire
operational risk management framework. A weak approach to categorisation will mean a weak
framework. However effective the other elements are believed to be.
Appendix A: Example Operational Risk Categorisations
L Below two external categorisations that include a significant number of operational risk
events are provided. It is recommended that one of these (the one believed to be most suited
to the nature, scale and complexity of the organisation) is used as the starting point for the
organisation’s customised operational risk classification.
Though the Basel loss event types were designed for financial institutions and specifically banks,
it remains a useful reference source for non-financial organisations, especially those in the private
sector. The Treasury’s ‘Orange Book’ classification (updated in 2020) is primarily designed
for public sector organisations, but is relevant for private sector also, especially smaller, less
complex ones.
The Basel classification is dedicated to operational risk events. In contrast the Orange Book
classification includes other types of risk. Nevertheless a significant number of the Orange Book
risk types fall within the scope of operational risk.

14
Event Type Definition Categories (Level 2) Activity Examples (Level
Category (Level 1) 3)
Internal Fraud Losses due to acts • Unauthorised • Transactions not
of a type intended to Activity reported (intentional)
defraud, misappropriate • Theft and Fraud • Transaction type
property or circumvent unauthorised (with
regulations, the law monetary loss)
or company policy, • Mismarking of position
excluding diversity/ (intentional)
discrimination events, • Mismarking of position
which involves at least (intentional)
one internal party • Fraud / credit fraud /
worthless deposits
• Theft / extortion /
embezzlement /
robbery
• Misappropriation of
assets
• Malicious destruction
of assets
• Forgery
• Check kiting
• Smuggling
Account takeover /
impersonation etc
• Tax non-compliance /
evasion (wilful)
• Bribes / kickbacks
• Insider trading (not on
firm’s account)

External Fraud Losses due to acts • Theft and Fraud • Theft / robbery
of a type intended to • Systems Security • Forgery
defraud, misappropriate • Check kiting
property or circumvent • Hacking damage
the law, by a third party • Theft of information
(with monetary loss)

Employment Losses arising from • Employee • Compensation,

practices and acts inconsistent Relations benefit, termination
workplace safety with employment, • Safe Environment issues
health or safety laws • Diversity and • Organised labour
or agreements, from Discrimination activity
payment of personal • General liability (slip
injury claims, or from and fall etc)
diversity / discrimination • Employee health and
events safety rules events
• Workers compensation
• All discrimination
types

15
Clients, Losses arising • Suitability, • Fiduciary breaches / guideline
products and from an disclosure and violations
business unintentional fiduciary • Suitability / disclosure issues (know-
practices or negligent • Improper your-customer etc)
failure to meet business • Retail customer disclosure violations
a professional or market • Breach of privacy
obligation to practices • Aggressive sales
specific clients • Product flaws • Account churning
• Selection, • Misuse of confidential information
sponsorship • Lender liability
and exposure • Antitrust Improper trade / market
• Advisory practices
activities • Market manipulation
• Insider trading (on firm’s account)
• Unlicensed activity
• Money laundering
• Product defects (unauthorised etc)
• Model error
• Failure to investigate client per
guidelines
• Exceeding client exposure limits
• Disputes over performance of advisory
activities
Damage Losses arising Disasters and • Natural disaster losses
to physical from loss or other events • Human losses from external sources
assets damage to (terrorism, vandalism)
physical assets
from natural
disaster or other
events
Business Losses arising Systems • Hardware
disruption from disruption • Software
and system of business or • Telecommunications
failures system failures • Utility outage / disruptions

Execution, Losses from Transaction • Miscommunication

delivery and failed transaction capture, execution • Data entry, maintenance or loading
process processing and maintenance error
management or process • Missed deadline or responsibility
management, • Model / system mis-operation
from relations • Accounting error / entity attribution
with trade error
counterparties • Other task mis-performance
and vendors • Delivery failure
• Collateral management failure
• Reference data maintenance

16
Monitoring and • Failed mandatory
reporting reporting obligation
• Inaccurate external
report (loss
incurred)

Customer • Client permissions

intake and / disclaimers
documentation missing
• Legal documents
missing /
incomplete

Customer / • Unapproved
client account access given to
management accounts
• Incorrect client
records (loss
incurred)
• Negligent loss or
damage of client
assets

Trade • Non-client
counterparties counterparty mis-
performance
• Miscellaneous non-
client counterparty
disputes

Vendors and • Outsourcing

suppliers • Vendor disputes

17
 [Link]

Developing risk professionals