Chapter 4 Back Up Book for Printing PDF

6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing Chapter 4 Back Up Book for Printing Site: The Institute of Risk Management Printed by: calvin oyieke Co...

6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing Chapter 4 Back Up Book for Printing Site: The Institute of Risk Management Printed by: calvin oyieke Course: IOR - Certificate in Operational Risk Management Date: Tuesday, 18 June 2024, 8:19 AM Book: Chapter 4 Back Up Book for Printing https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 1/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing Description The back up book allows you to print this units course content. This can be done by clicking on More and simply clicking ‘Print Book’. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 2/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing Table of contents Chapter 4: Operational Risk Tools - Categorisation https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 3/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing Chapter 4: Operational Risk Tools - Categorisation 4. Understand the nature and use of data categorisation in the management of operational risk. 4.1 Define the objectives of data categorisation and use of data categorisation in the management of operational risk. 4.2 Describe the different data types that need categorisation. 4.3 Distinguish between different approaches to creating and applying categorisation structures. 4.4 Explain the various challenges in creating and applying categorisation structures. Key themes The key themes are as follows: The basic concepts and terminology used for risk-related data categorisation. Criteria for developing a good data categorisation scheme and their benefits. The boundaries and attributes of data categorisation scheme. Getting the granularity right: the balance between granularity, simplicity and usability. Typical categories of operational risk data. The bow-tie model and how operational risk data categorisation schemes are used in practice. Challenges with scope/definition, the need for management buy-in, maintenance and data quality Introduction to Chapter 4 Creating a single, consistent data categorisation approach and structure for use across the firm should be one of the first activities to be undertaken by any operational risk management function. It is important in that it provides a common language for the rest of the operational risk framework, including policy development, programmes for risk identification and quantification, scenario assessment, risk or loss event management or the deployment of risk, control and performance metrics. The reason why categorisation is so important is that large quantities of unstructured data cannot deliver the information necessary for an operational risk manager to do their job. The data needs to be organised in a scientific way, with a clearly defined hierarchy, if it is to be useful. Data that is classified in a consistent way is easier to aggregate, analyse and report than data which is unstructured and uncategorised. It is important to understand that operational risk covers a wide range of risks and, compared with other risk disciplines, there is less consensus about what it does and doesn’t cover. This feeds through to the data used for operational risk, in stark contrast to the more financial risk disciplines such as credit risk where there are widely used common data and measures such as Loss Given Default and Expected Loss. A well-defined and implemented categorisation scheme provides good control over data and helps to make sense of it. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 4/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.1 Define the objectives of data categorisation and use of data categorisation in the management of operational risk 4.1.1 Taxonomy In this Workbook, the term ‘taxonomy’ is used to describe the data attributes for risk events (e.g. losses, near misses and gains), as set out in section 7.2. A different term, either “data categorisation”, or “data categorisation scheme”, will be used to describe the many forms of data relevant to operational risk managers which need to be categorised. Risk events are part of that data universe. But in this Workbook they have their own chapter and hence this chapter will simply cross-reference to Chapter 7, Operational Tools - Events and Losses. Please be aware, though, that some firms may use the term ‘taxonomy’ for the entire data categorisation structure used for operational risk, or risk more widely. This Workbook deliberately does not use this approach, to try to keep the definitions clear. The use is consistent with the Basel II and Solvency II regulations, to describe the data structure for risk events only. 4.1.2 Industry practice The regulatory definitions around data are sometimes considered as a standard for operational risk data categorisation. But they are not the only ones; nor are they exhaustive. Inevitably, given such a broad ranging discipline as operational risk, there is no single industry standard that can be used by all firms for all purposes. Consequently most firms either (i) adapt an industry categorisation scheme (e.g. the Basel II standard, or perhaps a different scheme developed by an industry body for benchmark analysis) to meet their own particular internal needs; or (ii) create their own bespoke categorisation scheme. If they choose the second option they often map their own bespoke data scheme to regulatory or other external/industry definitions. Exchanging data with other firms via industry bodies is an increasingly common practice in operational risk management. So this kind of mapping of firms’ own internal data categories to regulatory or industry categories is an important feature of the operational risk data framework. Workplace reflection Does your firm make use of a single data categorisation scheme, or more than one? Check how functions such as IT & Information Security, Compliance and Internal Audit classify the data they use and see whether the different categorisation schemes are used in consistent way. 4.1.3 Benefits of a data categorisation scheme A firm needs a common language to describe the various data attributes which occur repeatedly in its business. The aim is to ensure a common understanding amongst all providers and consumers of that data as to what the data is and what it represents. This also reduces the variability in interpreting the data. The higher the percentage of data attributes that can be described using pre-defined characteristics, the less scope there will be for misinterpretation of that data. It also enables consolidation of data into matching groups, sometimes known as ‘data buckets’. The following highlight some of the other benefits of a successful data categorisation scheme. Scaling/aggregation: Where data has to be scaled or aggregated, the underlying source data has to be homogeneous; i.e. classified in a consistent way so that the scaling or aggregation calculation gives accurate and appropriate results. Completeness: A good data categorisation scheme gives assurance for risk managers and other control functions that the datasets they are looking at are complete. Let's say, for example, that a firm has a data categorisation scheme with 30 separate groups or categories in it. If the risk identification process for a business entity only generates exposures in, say, 12 of the 30 groups or categories, that provides a good basis for the control function to go back to the risk identification process or information source, and ask for data on the remaining 18 categories. Internal reporting: Categorisation facilitates the grouping of common data sets in a meaningful manner, to enable comprehensive, accurate and informative reporting. This goes beyond simply consolidating or aggregating data sets. There is also a need to facilitate comparisons between different types of data using common standards. This is most relevant in reporting data on risk events, as described in Chapter 7. But it also applies to other forms of operational risk reporting, for example on Risk & Control Self Assessment, as described in Chapter 5, and Scenarios, as described in Chapter 8. Regulatory reporting: In many jurisdictions, regulators require firms to submit various operational risk reports, typically in accordance with a pre-defined template and using some particular categorisation scheme. To meet these obligations a firm must be able to arrange its data in accordance with whatever structure is demanded by the regulator, something that is virtually impossible if the internal data is unstructured. Benchmarking: While well-structured reports for each business unit are important to management, equally important is the ability to benchmark different business units against each other, which provides a completely different perspective for risk management. To achieve such benchmarking, the data sets of the respective entities have to be comparable, i.e. categorised using the same data attributes. Similarly, even the most comprehensive suite of internal reports and data can only provide information about where the firm itself stands. Internal benchmarking can be the comparative analysis of a division, business line or product line. It may also support the analysis and confirmation of initial assumptions versus the actual data collected; are there gaps, is data volume and quality what was https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 5/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.1 Define the objectives of data categorisation and use of data categorisation in the management of operational risk expected? For an insight into where the firm stands in comparison with its peers, it is necessary to benchmark the firm’s data against its peers’ data. External benchmarking requires an acceptable common categorisation scheme, to which each participating firm can map its own data categorisation scheme. Without this a firm cannot participate in external benchmarking. Again the Basel II standard, or perhaps a different scheme developed by an industry body, is relevant for benchmark analysis. 4.1.4 Features of a good data categorisation scheme The following highlight some of the features associated with a good data categorisation scheme. A good balance between these factors is not easy to achieve but it is what firms should be striving for. Homogeneity: Each individual group in the data categorisation scheme must contain homogeneous data, i.e. data of a very similar nature. Often data structures are layered, or hierarchical, with parent-child relationships. The lower you go down the structure, the more similar the contents have to be. As an example, a ‘parent’ data category could be Vehicles, with ‘child’ categories being Haulage Vehicles, Passenger Vehicles and Sport Vehicles. At level 1 (parent level), cars and trucks are in the same bucket, but at level 2 (child level), they fall into different buckets. If we went one level further down we might define Cars as one of our level 3 categories below Passenger Vehicles, along with Buses and perhaps others. Cars is still a sufficiently homogeneous category for this to work. Granularity: On the other hand the categorisation scheme must also strive for enough granularity for whatever your purposes are, i.e. must have enough levels to accommodate unambiguous categories or groups at the lowest level. If we wanted a level 4 ‘child’ grouping below Cars we could go for a number of different approaches: colour, model, or engine cc (in defined ranges). It depends on the purpose for holding the data, and on how simple it is to use. The lowest level of grouping needs to be sufficiently homogeneous that it is possible and appropriate to group things together in that category. Simplicity: The data categorisation scheme must retain enough simplicity to be intuitive and workable. Too much granularity – e.g. model in the above example of a possible level 3 category below cars – might make it burdensome to use. There needs to be a balance: granular enough to make it meaningful, simple enough to make it useable https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 6/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.2 Describe the different data types that need categorisation 4.2.1 Boundaries, attributes and levels This section provides guidance on the kinds of data that may need to be categorised. This will require consideration of recurring features, or elements of the business environment that the firm might need to identify – now or at some point in the future - so it can correctly categorise them for one or more of the purposes set out in section 4.1. This is challenging, because until firms start to use the data categorisation scheme for real business purposes they can't be sure that the elements are correct, either in terms of the population of elements they may use, the way elements are described, or the level of granularity. The categorisation scheme therefore needs to be iterative, and capable of evolving. If some business data cannot be easily categorised in the categorisation scheme, the firm might need to change the data structure to capture it, if it is important enough. But it still needs to be consistent and comparable over time so the firm can compare performance of the data over time periods. There is a tension at work here. A firm needs a scheme which is consistent over time; yet it needs flexibility to evolve to address new business data that are not yet known. The firm needs an appropriate balance of simplicity against sufficient granularity. Creators of categorisation schemes have to be smart and sensible when defining the attributes of data categorisation scheme, designing them so that they can take account of things which haven’t yet happened. One important thing to know is what the data categorisation scheme will be used for and what it won’t be used for. In other words what are the boundaries of the scheme? This will facilitate decisions on what must be included and what might be left out. Once the boundaries are defined, the firm can assess the business environment and decide what elements it wants to capture. At the same time, the firm can assess the level of granularity needed for each element. It may not always be possible to know what level of granularity will be needed but informed judgements can be made based on what the data will be used for. Or a decision may not be needed if information is only available at a particular level of the data hierarchy. Let’s assume that a firm is categorising methods of transport, for the purpose of measuring accident rates. The firm decides it is interested in a wide universe of possible methods, so for level 1 it chooses Air, Water and Land. It then decides to have two levels of granularity, and after some thought arrives at the following categorisation scheme: Air: Light aircraft. Passenger aircraft. Cargo aircraft. Space re-entry vehicle. Hot air balloon. Water: Canoe. Yacht. Motor cruiser. Barge. Liner. Ferry. Submersible. Land: Bicycle. Passenger vehicle. Cargo vehicle. Farm vehicle. Motorcycle. Train In this structure, the category ‘passenger vehicle’ could include buses, mini-buses, sports cars, family cars and off-road vehicles. But it would exclude F1 racing cars, which do not fit into any category. This suggests – given the purpose established up front (which is to look at accident rates) – the firm needs to amend the categorisation scheme so it includes ‘Motor sport vehicles’ or something similar as an additional level 2 category. It is also clear from this scheme that the firm needs at least one additional (child) level below ‘passenger vehicle’, to allow it to differentiate what are actually quite different forms of transport. The question then arises as to how many further levels to use. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 7/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.2 Describe the different data types that need categorisation The approach used is to go into sufficient detail that going one level further down would be describing specifics such as branding differences, colour differences or pricing differences. Consider a credit card – and compare a Visa platinum card to a MasterCard gold card. They are essentially the same type of product. They differ by issuing bank, managing card clearer, colour, interest rates, and other attributes. However, the processing activities and the operational risks are more or less identical. For operational risk purposes a firm would probably not need to distinguish between any attribute more detailed than ‘credit card’. However, assume for instance that a firm needed to distinguish by issuing bank or clearer – it would define a lower (child) level in the categorisation scheme. This would be below ‘credit card’ and allow it to distinguish by additional level of granularity, given the firm's particular needs https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 8/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.2.2 Elements commonly found in an operational risk categorisation schem The following section considers some of the common elements found in an operational risk data categorisation scheme. Process types The concept of process types relates to the activities which a firm undertakes and performs. In analysing these activities, the firm should consider common activities which occur on a repetitive basis across the enterprise, typically at a high level. Examples would be customer/client on-boarding, transaction capture and update, payments and settlements, and transaction accounting. Process types are one of the fundamental elements in a data categorisation scheme, as virtually everything that occurs within the firm relates to some specific process. Risks may arise in processes and affect other processes; risk events may manifest themselves in specific processes; while controls are applied to manage risk in specific processes. For example a multi-level process structure might include the following: Level 1:Business origination. Level 2: Customer and client relationship management. Level 3: New customer on-boarding. Level 4: Know Your Customer, Politically Exposed Persons, Blacklist checking. Level 4: Signature verification. Level 3: Customer file establishment and maintenance. Level 3: Ongoing customer relationship management. Level 3: Customer profitability and requirements review. This element of the categorisation scheme would need to be both comprehensive and granular so it describes each and every process undertaken by the bank, at a high level of granularity. This could run to many hundreds of processes. It is up to the firm to assess an appropriate balance between simplicity and granularity. Risk types or categories Risk types or categories are subject to considerable differences in interpretation from firm to firm, and are often heavily influenced by the primary industry in which the firm is based. Risk types for financial services firms tend to be high level. At level 1 this may cover risk types covered in Chapter 1 such as strategic risk, credit risk, market risk and operational risk. Typically, firms would define a three to four level hierarchy to capture the various risk types including operational risk. An example hierarchy may include the following: Level 1: Operational Risk. Level 2: External Theft and Fraud. Level 3: External Fraud. Level 4: Credit card fraud. Level 4: ATM fraud. Level 4: Identity fraud. The risk category structure will also be affected by the specific industry in which the firm is located, with different sub-categories, for instance, for banking, asset management or insurance. This element is the one which probably generates more disagreement amongst industry participants than any other, but is also the one which, if incorrectly defined, will cause more misclassification and ‘dirty data’ than any other element. In terms of an industry standard, certainly in banking, the Basel II operational risk event types (covered in Chapter 1) are probably the most widely used. But they only consist of two levels, which is relatively high-level. Industry associations, particularly the various loss data consortia, have in some cases created more granular structures to be used by their members for reporting purposes. As set out in more detail in Chapter 1, the Basel II taxonomy at level 1 reflects seven loss event types: Internal fraud. External fraud. Employment practices and workplace safety. Clients, products and business practices. Damage to physical assets. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 9/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.2.2 Elements commonly found in an operational risk categorisation schem Business disruption and system failure. Execution, delivery and process failure. But an alternative level 1 structure to consider for loss events could be: Errors and omissions. Business disruption. Conduct and business practices. Financial crime Control types The first form of control-related categorisation originated from the audit profession and focused on the purpose of the control, that is, what the control was intended to do. Examples of this would include preventative, detective or corrective controls, which are covered in 6.6, The Nature and Role of Controls. As well as their purpose, controls can be categorised in different ways, if that helps risk management. One example is to categorise by the nature of the control: Physical controls e.g. fences, doors, locks and fire extinguishers. Procedural controls e.g. incident response processes, management oversight, security awareness and training. Information security controls e.g. user authentication (login) and logical access controls, antivirus software, firewalls. Legal and regulatory or compliance controls e.g. privacy laws, policies and clauses. In relation to information security, a further level of categorisation can be derived from international information security standards, such as ISO 27001:2013, where controls are divided into 14 groups, such as: Human resources security. Physical security of the organisation's sites and equipment. Secure communications and data transfer. Security for suppliers and third parties. Incident management. Industries An industry type hierarchy is particularly useful as an additional attribute in analysis of commercial clients and for credit risk purposes. From an operational risk perspective, it is a useful attribute to assist in the analysis of risks, exposures and losses to identify correlations with specific industries. However, rather than defining your own hierarchy, you could consider adopting a structure published by a national, regional or international authority, such as the World Bank or the United Nations. These structures may also be very granular, so consider cutting off your own use of these categorisation schemes at an appropriate higher level of granularity. Many will also provide a structured breakdown of the financial services industry which may be a useful alternative to the ‘business line’ structure discussed below. Business lines The concept of business lines as part of firms’ data categorisation schemes arises from Basel II where, for the Standardised Approach to calculating operational risk regulatory capital, firms are required to divide their business activity into eight revenue-generating business lines. This business line structure is also used in what is often referred to as the ‘7 by 8’ matrix, a mapping of the eight business lines against the seven Basel II level 1 loss event types noted earlier. The Basel II business lines are described in more detail at 7.2.6. Many firms have, however, amended the initial eight business lines suggested by Basel II. One common addition is for the corporate centre or for centralised, non-revenue-generating functions of the firm. Another common difference is for firms to divide its retail banking business line between generic retail or branch banking and private banking or wealth management. Products/services The product or service type hierarchy is essentially a lower level of categorisation below a business line or industry type. Most firms are only active in a single industry type (or sub-type), or only active in a sub-set of the business lines. This has led some firms to develop a categorisation element for the products and services they offer customers, or in which they transact in the financial markets. Many of these https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 10/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.2.2 Elements commonly found in an operational risk categorisation schem product or service elements tie back to a specific business line or generic area of activity. For example, a multi-level product type structure for commercial banking could be: Commercial Banking Commercial Branch Operations. Commercial Credit: Commercial Loans. Commercial Leasing. Commercial Real Estate Financing. Trade Finance. Project Finance. Factoring. Letters of Credit and Bank Guarantees. Commercial Cards. Commercial Deposit and Investment Accounts. Commercial Banking Services With a product or service type element hierarchy, remember the objectives of homogeneity, simplicity and granularity and avoid including actual product names into the structure. Customers/clients In certain jurisdictions, for example those subject to the second EU Markets in Financial Instruments Directive (MiFID II) and the accompanying Regulation on Markets in Financial Instruments and Amending Regulation (MiFIR), it is mandatory to segment customer and client bases and to classify each according to the nature of business transacted with that type of customer or client. However, using a customer or client categorisation structure is also useful for other forms of risk data analysis and is used by many firms to manage which product types are made available to which customer or client types. A common customer and client type hierarchy is also useful for comparison between different business units, where different nomenclature is common, for example, the use of ‘customer’ in retail banking compared to ‘client’ in asset management or retail brokerage. Distribution channels Distribution channels refer to the channels the firm uses to both secure business opportunities from existing and prospective customers and clients and to deliver its products and services through. It is common for different processes, different control structures and even different product types to be offered or delivered through different channels, or to restrict certain channels to specific customer or client types. Examples of distribution channels to include in a data categorisation scheme could be branch, website, call centre, mobile app, broker or other intermediary, business partners and sales staff. Geographies The geographical structure of business, from continents and countries down through provinces, states and counties, to cities and specific locations/buildings, all form part of data which are commonly used within the firm and thus form part of its data categorisation scheme. As with industry types, there are a variety of existing structures available for these geographical attributes, which it is often sensible to adopt. However, actual location data is usually firm-specific and often requires a unique naming convention. Causes This is covered in more detail in section 7.3, but the Basel II definition of operational risk is primarily causal. That is, it refers to the risk of loss arising from inadequate or failed processes, people, systems and/or external systems. Although few operational risk frameworks have historically focused on causal analysis, most firms have included a causal element in their data categorisation schemes, usually consisting of four level 1 instances: people, processes, systems and external factors. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 11/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.3. Distinguish between different approaches to creating and applying categorisation structures 4.3.1 An approach to creating categorisation structures: bow-tie model The essence of the bow-tie model has been covered in Chapter 1. The essence of the model is that it characterises the relationship between cause, event and impact as illustrated below: Figure 4.3.1 (a): Bow-tie model The bow-tie model holds that events can only occur if one or more causal factor arise and impacts can only occur from events. What the bow-tie model does, firstly, is force differentiation in the risk event taxonomy, to ensure that it accurately distinguishes between causes, events and impacts; then secondly lead to appropriate categorisation of the different components or attributes of risks and risk events. A practical implementation of a bow-tie model in a financial services firm is illustrated in the diagram below: Figure 4.3.1(b): Different aspects of a bow-tie based data categorisation scheme https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 12/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.3. Distinguish between different approaches to creating and applying categorisation structures The connection between this bow-tie implementation diagram and the data categorisation scheme is that, however it is organised, the data scheme needs to support analysis of each and every component of the bow-tie model. You can see, for instance, that the yellow boxes in the above diagram represent data categories covered in section 4.2.2 above. Every item on this diagram should be capable of being analysed or supported by the data categorisation scheme we implement. If the cause-event-impact analysis breaks down, for example due to insufficient granularity or usability of the data framework, then the data scheme needs to be enhanced to ensure the logic of the bow-tie model can be followed. Workplace reflection Does your firm recognise the ‘bow-tie’ model within its operational risk management framework? If not, what impact would introducing the model have on your framework and the various supporting tools and techniques? https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 13/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.3.2 Applying categorisation structures The following section deals with how categorisation structures are used with other tools and processes in the operational risk management framework. Risk and control self-assessment (RCSA) See Chapter 5 for more detail on RCSA. As indicated in the previous section, a firm’s data categorisation scheme will typically include a group denoting risk types or risk categories. Many firms document their risk in so-called ‘risk registers’, describing the risk, then indicating which risk type or risk category the risk belongs to. The firm may adopt a slightly more granular approach and could also include any customer or client types which the risk is specific to, and/or any distribution channel types through which it may materialise. Turning to controls, these are often documented in a ‘control register’. As with a risk, it is also common to describe the control and to indicate which control type it belongs to. A control may also be mapped to other categorisations such as process types. The organisation hierarchy will provide additional level of details on where controls are executed. Moving on to assessment, in addition to the elements of data categorisation already used for the risk and its associated controls, it is common to define the process in which the risk may materialise and where the controls are situated, describing the process along with its process type. Some firms may also undertake some form of ‘root cause analysis’, describing the cause and applying the appropriate causal type to it. The final step of most assessments will include some form of quantification, either through ratings or actual monetary values. Risk and control indicators See Chapter 6 for more detail on indicators. Risk indicators are linked to key risk, implying the use of risk type or risk category. Some more advanced firms will also include causes into their risk indicators, thus including causal types into the mix of data categories they use. As with RCSAs the risk indicator framework could either source – or be sourced from – the data categorisation scheme; either way there is scope for integration between categorisation scheme and the wider operational risk framework. Risk events See Chapter 7 for more detail on risk events. Risk events (e.g. losses, near misses, gains and offsets) represent the record of a risk which has already manifested itself and, as a result, the data requirements for risk event recording encompasses all the data categorisation elements described in this chapter. Scenario analysis See Chapter 8 for more detail on scenario analysis. Scenario analysis considers the potential implications of a risk manifesting itself, on a forward looking basis. It describes in what situations a risk might arise (including risk type and risk category, process type, products or services, customers or clients and distribution channels); what might make the risk manifest itself (causes); and what might prevent the risk from manifesting itself (controls). There is therefore a considerable connection between the data categorisation scheme and the key features of the scenario analysis tool, which can be used to ensure consistent data usage and understanding. Capital estimation While simpler forms of capital estimation may only have a limited need for data categorisation support, more advanced modelling or estimation approaches require data to be arranged into clear, granular buckets. As these approaches may include the output of RCSA, scenarios, various indicators and internal and external loss event data, the categories used by each of these tools become a part of the capital estimation process. Other applications Other programmes, tools and functions across the firm may also use different elements of the data categorisation scheme, including business continuity management, information security, compliance and internal audit as well as back office process management functions. The firm’s data categorisation scheme can also be used in management information reporting, facilitating the presentation of consistently categorised information from across the firm expressed in a commonly understood and accepted language. Learning activity Select one or two (or all, if you wish) of the applications for a data categorisation scheme described in this sub-section, then analyse the comparable programme or tool within your own firm and compare the elements suggested here against what is used in practice. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 14/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.3.2 Applying categorisation structures https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 15/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.4. Explain the various challenges in creating and applying categorisation structures There are many challenges in creating a data categorisation scheme and using it in practice to actually classify data. On the face of it a simple data scheme with few levels should be easy to create and to understand. Conversely a more expansive, more granular data categorisation might be more difficult to create and understand but easier to use. The real answer often lies in the degree of documentation and the extent to which the lowest levels of each element of the data hierarchy are truly unambiguous. 4.4.1 Scope/definition The first challenge is defining the scope or boundary of the categorisation scheme. Will it be restricted to operational risk, or to operational risk and compliance, or will it be made available more broadly? The broader the domain, the more difficult to align all stakeholders and the more comprehensive the content has to be. Conversely, the narrower the domain, the more likely it will be regarded as specific to that area and discounted for wider use. Boundary issues, as discussed in section 1.3, are a challenge, particularly if the categorisation scheme has low granularity, and if different standalone categorisation schemes are used for different risk types. Contradictory definitions, and the potential for different risk teams to use the ‘wrong’ categorisation scheme for their risk type, are challenges here. A further challenge is writing clear, concise yet complete definitions for different elements in the categorisation scheme: what they mean and how they differ from each other. Creating a meaningful, descriptive and unique name for each element is one thing; but without clear guidelines and definitions for each one, the probability of accidental misuse and incorrect categorisation increases. The lens or viewpoint used to categorise risk events can be another key challenge. As set out in the description of the bow-tie model above, many events result from so-called ‘causal chains’ that is a cause-event-impact chain occurs, where the impact becomes the cause in a different cause-event-impact chain. These chains can have numerous iterations. A software coding error (event) results in a defective system (impact) for the IT department; the defective system (cause) miscalculates interest (event) resulting in compensation claims (impact) for an operations unit; the miscalculated interest (cause) creates unhappy customers (event) who lodge complaints with the ombudsman (impact); etc. Depending on which unit is using the categories, the resultant risk or event may end up being documented in very different ways. 4.4.2 Granularity A challenge we refer to frequently within this chapter is the level of granularity. The more granular, the more unambiguous the data scheme can be. But, in general, the more granular, the more difficult it is to get the business to understand, adopt and use it. The solution has to be to pursue additional layers of granularity for those elements that really need it (e.g. risk category, control and products or services) and to keep the other elements at higher levels of granularity (e.g. risk type, industries, geographies). 4.4.3 Buy-in Another key challenge relates to getting management buy-in and adoption of the categorisation scheme. If too generic, or too granular, it may face challenges being adopted by the business. As indicated earlier in the chapter, it needs to achieve the balance between simplicity and granularity. Achieving buy-in from the business, as with many aspects of operational risk management, is highly dependent on senior management support and promotion. To achieve this buy-in, the categorisation scheme needs to use language the business is familiar with and can relate to. Labels such as ‘execution, delivery and process management’ or ‘clients, products and business practices’ may not mean much to people in the business; whereas ‘errors and omissions’ or ‘conduct and ethics’ would be more intuitive and understandable. At the beginning of a categorisation exercise, different areas within the firm may well use different terminology for similar things. The aim has to be consistency across the firm wherever possible. Some firms have adopted technology solutions whereby divisional or business unit- specific labels can be added to individual elements in the data categorisation scheme, and displayed or used in reporting for that division or business unit. 4.4.4 Maintenance and data quality Keeping the data categorisation scheme updated to reflect changes in the business environment is a challenge – as is applying any changes and re-categorising previously categorised data, where needed. Maintenance of data categorisation schemes lags business reality. The next challenge relates to staff capabilities, both in the use of the data categories and in applying them to different types of data. This challenge can be offset by training, but a robust, extensive and granular data categorisation scheme will require business knowledge and categorisation experience if it is to be applied properly. Consistent application of the categories is a further challenge. Individuals make mistakes and are biased. Biases are discussed in section 8.7. https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 16/17 6/18/24, 10:19 AM Chapter 4 Back Up Book for Printing 4.4. Explain the various challenges in creating and applying categorisation structures Another challenge relates to effort and time. The amount of effort to categorise some data can be significantly reduced by a well-structured, comprehensive data categorisation structure. However if that same structure is relatively granular and staff are inadequately trained, the degree of effort to categorise the data will increase. Further, if the staff undertaking the data categorisation have little time, or are faced with unrealistic categorisation and reporting deadlines, short-cuts will be taken and an inappropriately categorised data set will result. Data categorisation is a critical component of risk management and reporting, highly dependent on the quality of the input data and staff should be allowed sufficient time to categorise data appropriately. A final challenge lies in where the data categorisation process takes place. The closer to the point of origin of a specific risk, the greater the awareness and knowledge of the specifics of the situation; conversely, the further away from the point of origin, the less will be known about the business and related risk information. However, staff in second line of defence risk functions tend to have greater knowledge of data categorisation schemes and can thus categorise data sets more quickly and easily. One solution which some firms have adopted is for the business to submit a comprehensive narrative describing the risk related data and for risk support staff to undertake the categorisation, then asking the business to confirm the categorisation. Workplace reflection Which of these challenges have you encountered within your firm? Discuss these challenges with your colleagues and see whether they have faced similar or different challenges. Are there other challenges which you or your colleagues have faced which are not included here? Summary This chapter has focused on the role of data categorisation within the operational risk environment, covering concepts and terminology, the objectives for data categorisation, different elements of a data categorisation taxonomy, some approaches and applications for data categorisation, finishing with an overview of some of the challenges, both in building and in using, a data categorisation scheme. As part of your understanding of this chapter, it is worth reviewing the IOR’s Sound Practice Guidance paper on Risk Categorisation. Key learning You will be ready to move to the next chapter when you can confidently answer the following questions: 1. What are some of the key benefits of data categorisation? 2. What industry data categorisation options are available to firms? 3. What are some of the key features of a good data categorisation scheme? 4. What types of operational risk data are typically structured using a data categorisation scheme? 5. How can the bow-tie model facilitate creation of a data categorisation scheme? 6. What are some of the common ways in which a data categorisation scheme is applied to operational risk activities (e.g. RCSA)? 7. What are some of the key challenges which need to be considered when developing a data categorisation scheme? https://www.irmvle.org/mod/book/tool/print/index.php?id=4162 17/17 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing Chapter 5 Back Up Book for Printing Chapter 5: Operational Risk Tools – Risk and Control Self -Assessment Learning outcomes and assessment criteria 5. Understand the nature and role of risk and control self-assessments in the assessment and management of operational risk. 5.1 Examine the nature of risk and control self-assessments in the management of operational risk. 5.2 Describe the benefits of risk and control self-assessments. 5.3 Explain the role of risk and control self-assessments in identifying operational risk. 5.4 Consider the advantages and disadvantages of different methods for undertaking risk and control self-assessments. 5.5 Explain the concepts of likelihood and impact in assessing operational risk and controls. 5.6 Examine the nature and role of controls. 5.7 Explain the roles and relationships between risk owners and control owners. 5.8 Describe common methods of reporting risk and control self-assessments. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 1/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing Key themes The key themes of this chapter are as follows: The benefits and uses of risk and control self-assessment (RCSA). Approaches to RCSA. Identifying operational risk. Assessing operational risks and controls. Taking action and monitoring. Reporting operational risk and control information. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 2/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing Introduction to Chapter 5 Risk and Control Self-Assessment (RCSA) is one of the most important tools in a firm’s operational risk management and control framework. The purpose of RCSA is to enable a firm to manage the key risks it faces to avoid these adversely impacting on the business line's or broader organisation’s objectives. This involves identifying, assessing, monitoring and reporting both new or emerging risks and existing risks, together with related controls. Figure 5: Components of risk assessment https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 3/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.1 Examine the nature of risk and control self-assessments in the management of operational risk RCSA is the process of identifying, recording and assessing potential risks and related controls. The process also identifies and assesses the effectiveness of controls in reducing risks. RCSA can be undertaken at various levels in a firm, for example ‘top-down’ aggregate risk and control reviews performed on behalf of the governing body and senior management, or ‘bottom-up’ reviews performed in business entities and central functions. It is common practice for RCSA to be performed at each level of significant decision-making within the firm (for example by business line) and also to be applied to end-to-end processes (for example, in financial firms, from trade inception through to booking, valuation, risk and back office processes). In the case of multinational organisations RCSA may also be scoped to address specific geographical locations. RCSA is more effective when it is an integrated part of an operational risk framework. Clear risk governance and the engagement of senior management are the most important factors behind an effective approach to RCSA. Executive and senior management support in the form of sponsorship and participation is essential in clarifying ownership of the risks and controls to be managed. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 4/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.2 Describe the benefits of risk and control self-assessments Before addressing the ‘what’ and ‘how’ of RCSA it is useful to understand the ‘why’ – the reasons organisations do RCSA in an integrated way involving both their risk process and their business processes. What are the benefits and uses of RCSA? The basic answer is to enable strong control support for the environment in which businesses and functions operate. To enable risks to be proactively managed and timely actions to be taken to address unacceptable levels of exposure. By demonstrating that this is indeed the case, regulatory requirements are also fulfilled. When carefully designed, planned and executed, RCSAs can be expected to provide a range of potential benefits and uses, including the following: Benefits and uses Cultural change, helping operational risk management to become embedded at all levels of the firm, with respect to both day-to-day activities and longer term business decision making. Cultural A focus on proactive management of risk (as opposed to a simple reaction to events). A practical way of applying and informing people about the firm’s risk appetite and tolerance. Alignment to strategic A documented way to align business strategy and objectives with risk management processes, providing a means direction of establishing a link between risk and performance. Open discussion of risk and control matters amongst staff and management, leading to better transparency and Interaction & consensus understanding of risk and its implications across the firm, and the design and effectiveness of related controls. Clear and specific ownership of action plans. Ownership & accountability Responsibilities assigned to individuals for delivering and monitoring action plans. A mechanism to record and rank the priority of risks that exist within a firm. A common language and set of values across the firm. Supports a ‘top down’ and ‘bottom up’ view allowing for material risks identified at executive level to be cascaded Record capture (auditable & down the firm, with appropriate actions being captured in lower level RCSA outputs. evidence based) Risks identified at lower level RCSA workshops should have an escalation route up to senior management in order to provide visibility of potential newly emerging threats that may require executive consideration. Providing evidence of analysis and remedial action to external stakeholders. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 5/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.2 Describe the benefits of risk and control self-assessments Cultural change, helping operational risk management to become embedded at all levels of the firm, with respect to both day-to-day activities and longer term business decision making. Cultural A focus on proactive management of risk (as opposed to a simple reaction to events). Improved efficiency in business processes and operations and thus customer outcomes. Where an ‘end to end’ view is taken, it promotes a holistic view considering critical processes or specific business Driving efficiencies lines, capturing key controls that should operate across different areas of the organisation. Workplace reflection Check whether, and if so how, your organisation uses the outputs of RCSA exercises to support management and business decisions. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 6/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.3 Explain the role of risk and control self-assessments in identifying operational risk Identification of risk is an important function of the RCSA. Failure to identify risks and related required controls may result in financial loss and adverse consequences for the firm that could have been anticipated and avoided. If you fail to identify a risk you won’t understand its potential likelihood or impact. To enable a firm to assess its risks and respond appropriately, it must first identify the risks it faces. 5.3.1 Role of RCSA in the operational risk framework The diagram below demonstrates the role of the RCSA process in the broader operational risk framework, including interactions between framework components. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 7/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.3 Explain the role of risk and control self-assessments in identifying operational risk Figure 5.3.1: RCSA in the operational risk framework Workplace reflection Explore how the RCSA in your organisation interacts with other parts of the operational risk framework. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 8/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.3 Explain the role of risk and control self-assessments in identifying operational risk 5.3.2 Identifying operational risk framework sources Different components of the operational risk framework generate information that can assist the identification of new or emerging risks. Risk categorisation: The firm’s recognised risk categories (see Chapter 4) can be reviewed for risks that may be relevant currently even if they weren’t considered previously, due to changes in the internal or external operating environment. Internal loss Events: Actual events may provide details of ‘new’ risks not already captured by previous RCSA exercises. If a risk has been identified by a previous RCSA, actual events can help to validate previous estimates of impact and likelihood. External Loss Events: Actual events that have materialised in other organisations should prompt the question ‘could it happen here?’ and, if so, may provide details of ‘new’ risks obtained from loss data consortia. Risk Indicators: In the case of ‘leading’ indicators (see Chapter 6), adverse trends in underlying causes may suggest the possibility of an ‘emerging’ risk or could prompt a re-assessment of an existing risk. 5.3.3 Other sources Apart from the operational risk framework, a firm will usually have additional sources of information that can help identify new or emerging risks, including the following: Business line or wider firm’s objectives – Identify what the firm is looking to achieve (its objectives) and consider what could go wrong and prevent it from achieving these objectives (i.e. risks). Further consideration of what absolutely must go right to deliver the objective can assist in identifying key risks. Customer complaints: Feedback from customer satisfaction surveys can identify flaws in customer-facing processes and approaches. Outputs from business planning processes, e.g., ‘PESTLE’ (Political, Economic, Social, Technological, Legal, Environmental) or ‘SWOT’ (Strengths, Weaknesses, Opportunities, Threats) analysis. Business performance management information. Failures to meet performance targets may point to inherent risk or control failures Details of planned change and transformation. Any change in process, products or strategy should be taken as an opportunity to review potential operational risks. Loss or event analysis reports. Internal audit reports. Workplace reflection Find out how your organisation identifies operational risks and whether you can add any sources of information to the above list. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 9/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.3 Explain the role of risk and control self-assessments in identifying operational risk Learning activity Consider whether a firm’s risk categorisation scheme should be used as (a) the starting point for risk identification; or alternatively (b) as means of validation, to ensure that all relevant risks have been identified by other means. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 10/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.4 Consider the advantages and disadvantages of different methods for undertaking risk and control self-assessments There are three main approaches that can be applied when performing an RCSA. Each firm should consider which approach or combination is best suited to its governance, culture, operating environment, size, complexity, structure and geographical dispersion. Workshop approach A workshop approach to RCSA provides interaction and enables guidance to be provided during the RCSA process. Workshops can either be held internally or seek the support of the Risk function or internal audit to facilitate these. The approach entails getting a small number of key representatives together (usually 6-8, no more than 12). Although time-consuming, a workshop approach to RCSA often produces appropriate and relevant data. The objective of a workshop approach is to get people engaged in talking about their risks, and to gain consensus in the identification and assessment of risks, controls and required improvements. It can also bring experience of loss events into focus and can be run in conjunction with business process checklists and procedural reviews. Questionnaire approach Some firms have established comprehensive standardised questionnaires, with questions allocated to respondents based on their respective responsibilities. Others have developed questionnaire-based RCSAs, with each central function setting its own questions and a centralised operational risk oversight function ensuring the completeness, consistency and quality level of the questionnaires and responses. A questionnaire-based RCSA approach can be used as a desktop review, as a structure for interviews with subject matter experts (SMEs) or risk and control owners (face to face, by telephone or otherwise), or as a combination of the two. The structure of an RCSA questionnaire should ensure complete coverage of a firm’s operational risks by being aligned to its established risk categorisation scheme. Hybrid approach It is possible to use a range of techniques in combination including not just workshops and questionnaires but also interviews or reviews by third parties. This is termed the hybrid approach. It tends to consist of an initial workshop, facilitated either internally or externally, followed later by a questionnaire or interview process to update the initial findings. This is less time-intensive compared to recurring workshops. It helps to keep the information generated current and relevant without becoming too cumbersome for participants. Alternatively, a top-down workshop involving senior management could be held to identify significant risks to the firm, alongside a questionnaire approach to provide the bottom-up perspective. When considering which RCSA approach to use, an organisation needs to consider the respective advantages and disadvantages of each. The relative merits of each approach are discussed below. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 11/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.4 Consider the advantages and disadvantages of different methods for undertaking risk and control self-assessments RCSA Advantages Disadvantages approach Opportunity to have the right people with the right knowledge and experience in the room. Ability to maintain open dialogue with all members of the group, so everyone has the chance to have their say; gains buy-in from attendees. Platform for open, honest discussion, with various perspectives and good interaction promoting a holistic view. Time intensive - can inhibit attendance of appropriate Outputs are a consolidated view achieved by group contributors/SMEs. consensus. Inappropriate attendees could result in less than optimal Cross reference to the organisation’s risk data outcome.  Potential logistical challenges (e.g. geographical). categorisation scheme ensures that ‘missing’ risks are Inadequate facilitation skills may result in the workshop being Workshop identified. dominated by particular attendees or senior managers, leading Ability to include process flow analysis and statistical to poor or unbalanced outcomes. analysis through discussion. Requires an understanding of operational risk roles and Opportunity to clearly define roles & responsibilities. responsibilities of each area of the organisation Ability to raise awareness and check understanding by asking questions. Facilitation ensures balanced input; facilitator can act as ‘devil’s advocate’ to challenge inputs and help mitigate estimation bias in the data. Provides an opportunity for transfer of risk management skills across the firm. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 12/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.4 Consider the advantages and disadvantages of different methods for undertaking risk and control self-assessments RCSA Advantages Disadvantages approach Less time intensive than workshop. Allows individual focus and contribution. Failure to set the ‘right’ questions or correctly interpret the Flexible: can be done as a desktop review or face-to- answers will compromise the quality of outputs. face interview. Limited if any discussion – thus reliance on interpretation of the Can be done remotely or facilitated. questions. Consistent structure to questions promotes better read Can result in differing views and opinions – may not be possible Questionnaire across and easier aggregation. to achieve consensus without additional consultation.  Scope Can involve a larger number of participants than a of assessment may not be clear. workshop. Responses can be biased by individuals’ experience. Provides a physical record of contributions (providing Terminology used can be misinterpreted evidence for subsequent reference). Workplace reflection In relation to the approach(es) used in your own organisation, can you identify any advantages or disadvantages to add to the above table? Learning activity What skills are required to achieve effective facilitation of RCSA workshops? What training and development would be appropriate? https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 13/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.5 Explain the concepts of likelihood and impact in assessing operational risk and controls RCSA involves the assessment of risks and controls, but note the use of the term ‘assessment’ in preference to ‘measurement’, which implies more precise quantification. Although some aspects of operational risk can be measured with a reasonable degree of accuracy, others can only be estimated. Starting with the assessment of risks, this involves consideration of two key questions: What are the chances of the risk materialising and how often? (i.e., concept of likelihood outlined below) What are the expected consequences if the risk does materialise? (i.e., concept of impact outlined below) 5.5.1 Understand the concept of likelihood Likelihood is defined as the possibility of something happening. It can be expressed in a number of ways, but is commonly conveyed by ranges of values representing a low, medium or high likelihood of occurrence e.g. low likelihood: less than 1 in 10 years; medium likelihood: 1 in 1-10 years: high likelihood: 1 in a 12- month period. Likelihood and probability are often used synonymously but have subtly different uses. Probability refers to chance rather than possibility, i.e. the calculated chance of something occurring based on quantitative parameters, data or a mathematical process. Likelihood on the other hand is more judgmental, based on inference and observation rather than mathematical processes. Typically in RCSA we refer to likelihood rather than probability. 5.5.2 Understand the concept of impact The consequences of an operational risk materialising are generally described as the severity of the risk outcome or impact. This impact can be direct or indirect, and financial or non-financial. Direct and indirect impacts Direct impacts are directly attributable to the event and in financial terms would represent incremental costs, e.g. a fine, penalty or overtime payments. Indirect impacts are consequential rather than directly attributable to the event. In financial terms they could include a loss of market share or loss of sales. An important source of indirect impact is increased regulatory oversight, scrutiny or on-site presence, which has in recent years become the most costly indirect impact for many firms. Indirect impacts are also often influenced by other factors and not always solely attributable to the materialisation of the risk in question. They can also arise over a period of time after the event. Financial and non-financial impacts https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 14/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.5 Explain the concepts of likelihood and impact in assessing operational risk and controls The financial impact of an operational risk represents a possible outflow of funds from the firm, and accordingly can often be quantified with a high degree of confidence. If such impacts are quantified, the basis for the quantification should be stated alongside the estimate; for example if some kind of scaling has been used. Examples of non-financial impacts include reputational damage, and loss of goodwill or customer confidence. Such impacts can be assessed using a defined range, e.g. Low-Medium-High, calibrated to a measure such as the number of customers involved and the duration of the loss of service. In addition to the consequences for the firm, consideration needs to be given to the impact on customers and the markets in which the firm operates. Operational risks will often have both prudential and conduct implications from a regulatory perspective and these should be recognised in the assessment. Furthermore, there can be situations in which a financial impact will give rise to a non-financial impact, and vice versa. For example: A high value fraud (financial impact) may well be widely reported in the media with adverse implications for its reputation/brand (non-financial impact). Significant IT system outages depriving customers of services (non-financial) may result in redress in recognition of unfavourable customer outcomes and fines from regulators (financial). In the case of both financial and non-financial impacts, estimates can be informed or validated by reference to data sources within the organisation and externally. The following table illustrates how various impacts, both financial and non-financial, can be combined. This involves using a common rating (in this example, High, Medium and Low) and clear definitions. It is worth noting that whilst use of such an approach is common practice, the thresholds may vary from firm to firm to reflect the appropriate level of materiality for that specific firm. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 15/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.5 Explain the concepts of likelihood and impact in assessing operational risk and controls Figure 5.5.2: Types of impact If a particular operational risk is considered to have a number of different impacts, the impact assessed as being the highest should drive the nature and urgency of an expected response. It is worth noting that determination of both likelihood and impact is subjective. Scales such as those described above can provide guidance and drive some degree of consistency in assessments. However, this will be subject to biases which we will consider further in section 8.7. Chapters 7 and 8 provide further discussion as to how risk indicators and risk events respectively can be used to validate these assessments. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 16/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.5.3 Assessment of risk exposure The assessment of operational risk comprises the two dimensions of likelihood and impact. When combined, these provide an indication of an organisation’s relative vulnerability or exposure to various risks. A likelihood and impact matrix is used to combine the respective scores, with the intersection of likelihood and impact on the matrix providing the overall risk assessment. As discussed in section 3.1.2 this can be used to express operational risk appetite. However, it can also be used to understand the relative ranking of different exposures as illustrated in the table below. Figure 5.5.3(a): Risk exposure In this example, six risks have been assessed, all with different combinations of likelihood and impact. Risk 4 is considered to be most likely to occur and also to involve a high impact. Using the risk matrix above it would be rated as a “Red” exposure, and at this stage, represents the greatest risk exposure compared with the remainder which are rated “Amber” or “Green”. Workplace reflection Different organisations use a variety of calibrations of risk exposure, using a matrix of, for example. 3 by 3 as above or 4 x 4, 5 x 5 etc. For your own organisation, investigate: 1. How the risk exposure matrix is constructed. How many ratings are there for likelihood and impact and what are they? 2. The calibration of impacts. What is the rationale behind the values? So far, the assessment has been considered without taking into account the benefits of any controls that may be in place. In operational risk management, risks are generally assessed on both an inherent and residual basis. (These are sometimes referred to as ‘gross’ and ‘net’ respectively.) Inherent risk is an assessment of the level of untreated risk; that is the natural level of risk without controls to reduce the likelihood or impact. For https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 17/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.5.3 Assessment of risk exposure example, consider the risk of a building burning down without any controls e.g. sprinklers, smoke alarms or fire extinguishers. Inherent risk is useful for understanding how bad the exposure could be and thus the value and effectiveness of implemented controls. Figure 5.5.3(b): Gross/inherent and net/residual exposures The next step in the RCSA process is the application and assessment of controls, to arrive at a ‘residual’ risk assessment i.e. the level of risk remaining after the effect of existing controls has been taken into consideration. 5.5.4 Assessing the controls A control can be defined as any action taken by the firm to reduce the likelihood of the risk occurring or the impact if it does. The capture of ‘key’ controls in the RCSA is critical in defining and understanding which controls a firm can rely upon for effective operational risk management. The definition of ‘key’ being those controls which provide the most defence against a particular risk. There are three aspects of control assessment to be considered: The types of controls involved; The effectiveness of each control; and The implications for the assessment of the related risks. These are discussed further in the next section https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 18/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.6 Examine the nature and role of controls There are various types of controls that can be applied to the management of risks and they are generally used in one of two ways – either before or after the event materialises – as illustrated in the below representation of the bow-tie model which was introduced earlier in this Workbook, in Chapter 1 and Chapter 4. Figure 5.6: Controls before/after the event Controls are categorised as either ‘preventative’, ‘detective’, ‘corrective’ and ‘directive’. 5.6.1 Preventative controls Controls that are designed to ‘prevent’ or deter the risk are important because they seek to address the underlying causes of risks. If they succeed, the event will not arise and there will be no adverse consequences to deal with. In effect, such controls mitigate the likelihood of the risk materialising. For example, in the case of the risk of fire, controls to address the underlying causes could include regular inspections of electrical equipment or a ban on smoking on the firm’s premises. 5.6.2 Detective controls Once the event has materialised, the first type of control is ‘detection’ – that is, to identify the fact that the event has occurred. A smoke alarm would fulfil this function in the example of a fire. Early detection enables appropriate corrective action to be taken on a timely basis. Such controls therefore assist in mitigation of the impact of the risk once it has materialised. 5.6.3 Corrective controls https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 19/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.6 Examine the nature and role of controls ‘Corrective’ controls are also concerned with damage limitation – that is to mitigate the impacts of the event. In the example of a fire, recovery controls could include sprinklers, fire extinguishers, fire evacuation procedures and fire exits. Specific details of risk events may be difficult to anticipate or the underlying causes may be external to the firm. In these cases, we rely on generic controls such as business continuity/recovery/resilience planning and crisis management procedures. These kinds of corrective controls are designed to enable an organisation to react quickly and appropriately when an event occurs minimising the impacts of the event. 5.6.4 Directive controls A number of organisations use an additional category of controls, described as ‘directive’. These are usually exemplified by policies that serve to ‘direct’ how controls are to be applied in processes and procedures. They are not included in the ‘before/after the event’ illustration above because they could be relevant either before or after the event, depending on the subject of the policy. For example, a policy dealing with information or data security is likely to focus on controls to avoid or prevent such a breach i.e. before the event. On the other hand, a business continuity or resumption policy will focus on damage limitation measures i.e. after an event has occurred. Learning activity Of those additional or replacement controls introduced in response to recent RCSAs, establish what proportion were designed to mitigate underlying causes of the risks as opposed to the potential impacts. Consider whether this has achieved an optimum balance in mitigating the risk exposure. Within these 4 main categories of control further aspects should be considered: The nature of the control (i.e. whether it is manual or automated) – manual controls involve human intervention, for example a four eye check or dual authorisation of payments. They can be subject to intermittent failure depending on the operator. Automated controls involve computerisation, for example access rights on a payments system which prevent an operator processing a payment above their agreed mandate. Automated controls are generally deemed to be stronger than manual. Frequency of operation – dependent on the control, it can operate daily, weekly, monthly, quarterly or less frequently. It is important that the frequency of control operation aligns with the pace at which the risk materialises. Workplace reflection Consider what proportion of controls on RCSAs within your organisation are manual versus automated. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 20/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.6.5 Control effectiveness To ensure RCSA is robust it is essential that controls are assessed to ensure their effectiveness. The effectiveness of controls can be assessed in two ways – by considering whether they are fit for purpose in terms of design, and the extent to which they are being operated in practice (referred to as ‘performance’). An assessment of design or fitness for purpose involves considering whether controls – individually and collectively – adequately address the causes and impacts of risks they are intended to mitigate. Reviewing all controls associated with a particular risk helps to identify whether some potential mitigation may be missing. Whilst controls may be appropriate in design they may not operate as intended in practice. It is the combination of these which tells us whether a control is effective overall. Figure 5.6.5 Control effectiveness If either the design, or the operation, or both are ineffective, the control will be ineffective overall. There is no benefit in correctly operating a control that is not fit for purpose, and a control that is not operated correctly will not provide the intended benefit. It is only if both the design and operation are effective that the control can be assessed as effective. Risks assessed as insufficiently controlled should be subject to mitigating actions to bring the residual risk exposure to more tolerable levels. In providing its assessment, the firm should consider: Design – Will the controls realistically reduce the risk they are managing? Do they achieve completeness of coverage? Performance – Is the control operating as designed? Are there adequate resources to perform it? Is the control automated or manual? Does the control operate effectively on every occasion? Firms will generally be expected to perform testing of controls and provide validating evidence for their assessment. This is generally done through one of the following means: Formal testing programme – A series of tests are designed to validate and evidence effectiveness of the control. This can include inspection of evidence, re-performance of the control, and / or observation of the control in action. Testing is undertaken on a sample basis by someone independent to that performing the original control. Attestation – A declaration by management confirming their controls are in operation or noting any exceptions. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 21/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.6.5 Control effectiveness Learning activity What testing of controls is done in your organisation? Can you demonstrate it provides sufficient evidence of control effectiveness? 5.6.6 Assessment of net/residual risk exposure Taking into account the effectiveness of controls, the assessment of inherent risk exposure illustrated above can now be revisited to arrive at a net/residual risk exposure. Taking three of those risks as examples: Figure 5.6.6: Residual risk exposure The controls associated with Risk 4 are mainly preventative and are assessed as being effective. This will result in a reduction in the net risk exposure by virtue of a lower likelihood of the risk materialising. However, the impact is still high and demonstrates the expected outcome if the controls failed. This assessment suggests a significant reliance on the controls, so one response to the assessment should be rigorous and frequent monitoring and testing of the associated controls, to ensure they continue to be effective. Risk 6 has a medium likelihood of occurring, and medium impact. Impact trumps likelihood and so, despite its medium likelihood, additional detective controls are needed to bring it to a low impact and so within risk appetite. In the case of Risk 3 the controls are judged to be ineffective in reducing the inherent risk assessment and therefore the likelihood continues to be assessed as ‘low’ and the impact as ‘medium’. The assessment suggests the response should be to investigate improving or replacing the existing https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 22/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.6.5 Control effectiveness controls. Risk 6 has mainly recovery controls which are assessed as being effective. This results in a reduction of the net risk exposure by virtue of lower impact if the risk materialises. In this case a response could be to either accept that the recovery controls are adequate or – if management’s risk appetite dictates that a medium likelihood assessment is too great for this risk – to consider additional/enhanced preventative controls. This example illustrates how assessing the risk exposure from both an inherent and a residual risk perspective helps to identify appropriate responses in the management of the risks. The level of the risk is at the target at which no additional mitigation is required to align it to the governing body’s risk appetite (as set out in Chapter 3). Decisions regarding appropriate controls to be introduced should always be tempered by sound economics. For example, if it has been ascertained that a given risk can be fully mitigated by the implementation of a control costing £500k, but the maximum residual risk exposure is quantified as £100k, alternative control measures to mitigate that risk should be evaluated instead https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 23/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.7 Explain the roles and relationships between risk owners and control owners It is common practice for the accountability and responsibility for risks and controls to be assigned to specific roles in a firm’s senior management or executive structure. While ultimate responsibility for the management of a specific risk may rest with a particular executive as the ‘risk owner’, controls that are relied on to mitigate that risk may be ‘owned’ in a different part of the firm. The ‘risk owner’ is responsible for the management of risks, i.e., the identification, assessment, monitoring and reporting of risks within agreed risk appetite/tolerance. Typically it is the business line, the first line of defence, which runs and own the risks. The ‘control owner’ is expected to be responsible for the design and execution of appropriate controls and to have processes in place to monitor and assess control effectiveness. As necessary, the control owner will also be responsible for identifying and implementing required enhancements. In some cases, specific (i.e. more formal) parameters of responsibility between control owner and risk owner may be established. Clearly, in any event, close and regular communication is necessary between risk and control owners to ensure that the level of mitigation is necessary, appropriate, and provided as required. 5.7.1 Recording the RCSA results The results of the RCSA must be recorded for future reference in what is often described as a ‘risk log’ or ‘risk register’. This can be achieved in a formal database which encourages consistency in the way information is recorded and reported. The following list is illustrative, rather than comprehensive, but provides an indication of the type of data that needs to be captured in this database: Unique risk reference (system or manually generated). Risk description (including the event, its causes and impacts). Risk event category. Risk owner. Assessment of inherent likelihood. Assessment of inherent impacts (financial and non-financial). Gross/inherent risk exposure. Summary of controls and frequency of operation. Control owners. Assessment of control effectiveness. Net/residual risk exposure. Response decision based on appetite/tolerance. Actions – detailing what will be done, by whom and by when. Action status. Target/expected risk exposure following completion of actions. https://www.irmvle.org/mod/book/tool/print/index.php?id=4163&chapterid=2322 24/35 7/29/24, 10:04 AM Chapter 5 Back Up Book for Printing 5.7 Explain the roles and relationships between risk owners and control owners 5.7.2 Responding to risk exposures Following the identification and assessment of risks and controls, consideration should be given to how to respond to any risk exposures which exceed the firm’s risk appetite or are otherwise deemed necessary. Any actions so identified need to be documented and tracked. There are four recognised alternative responses to identified risks and any one or a combination of the following options may be utilised by an organisation as appropriate to the risk exposure. Action: Risk acceptance It may be appropriate for risks to be accepted at the net/residual level due to: The net/residual exposure being within appetite/tolerance. The cost of mitigating the risk exceeding the net/residual exposure. If a risk is being accepted, analysis will be needed to support the cost-benefit justification and allow an individual or committee within the firm’s governance structure to make the appropriate decision as to whether or not a risk acceptance is appropriate. Such acceptance decision and its rationale should always be documented. It is recommended that any risk acceptance does not exceed a 12-month period, at which point a review will be required to determine whether any of the underlying assumptions (likelihoo