Objectives (value creation) and Risk & Control (value protection) Businesses, Not For Profit Organisations, and individual's investment and pension decisions, will all have an Objective behind the decision making process.
In corporate environments, ‘To provide sustainable annual growth to our customers and shareholders’ is a commonly used objective. ‘To provide modern, sustainable living conditions, farming and agriculture to poor Central African communities’ may be another.
Objectives set out what we are trying to achieve. In order to achieve an Objective we need to define the amount of risk we are willing to take to make it happen (Risk Appetite). For example, an objective in life might be to become as rich as possible, in as least time as possible. How far are you willing to go ie. how much risk are you willing to take in order to achieve that? This may involve investing every penny of savings that you have or your willingness to break the law. We all have our limits regarding these questions of risk taking. So it follows that it is important to set out the amount of risk you are willing to take in order to meet your objectives. Breaking it down into manageable elements Organisations are not in the business of taking Operational Risk in order to invest and grow, in the same way as they do with Financial Risk. Operational Risk is created by virtue of the fact of merely existing to do business. The product has to first be created and find its way to the customer and in doing that, something may go wrong. The Basel definition of Operational Risk is concerned with the essence of defining the risk, cause and impact of something going wrong whilst trying to achieve your objective.
"the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events".
The likelihood of each of these going wrong increases with the level of risk you are willing to take. In Basel's purest form we talk about
a) “the risk of loss“(which covers both risk and impact) and
b) the possible causes of what went wrong: processes, people and systems (assets).
In addition, we can infer that in order to protect against the cause of these risks and threats, monitoring and mitigation of the situation is derived from a fourth element, controls. And so we are introduced to the balance between delivering on Objectives (value creation) and doing what we can about the risks involved by using controls (value protection). Control types are commonly defined as Preventative, Detective, Corrective and Directive and operated in the first line business areas.
The question for Organisations is how to get the balance correct between its Objectives (value creation) and Risk & Control (value protection). How far are you willing to go, i.e. how much risk is willing to be taken in order to achieve the Objective. This can create tension between 'the business’ (first line) and the Risk, Compliance and Audit ’Second Line’ and ’Third Line’ teams, which can be perceived at times as taking away key resource from value creation and/or interfering with the process of creating and delivering value creation.
Many firms are still on the journey to join the two and educate value creation teams on how Risk & Control can provide value protection, especially in larger, more established firms that have created a loyal customer base and historical good reputation. Often adding more and more controls into a process at the behest of a second or third line assurance review can be perceived as unnecessary bloating of the process and unnecessarily costly. A firm's level of market presence and maturity and product type can influence the levels of spend between value creation and value protection. Education and maturity of risk understanding within businesses begins with clear frameworks pertaining to Operational Risk, Compliance and Audit, of which data and categorisation is key. If the Second and Third Lines are not clear on the Policies, Standards, Risk Data (Taxonomies), general Governance and Frameworks, this will lead to obvious confusion and tension across the Organisation. Clear guidance on how to articulate risks and controls and what one is — and more importantly, what one isn’t requires clear understanding and communication. Each one of these areas of Governance is a study in itself but here we attempt to provide clarity on Data and in particular the Risk Taxonomy and how it interacts with the Framework and other risk related data.
Importance of discipline and structure A system for naming and organising things in a logical way can be defined as a taxonomy.
Cambridge Dictionary Definition: A system for naming and organising things, especially plants and animals, into groups that share similar qualities.
It is essentially a scientific idea that has been borrowed by other areas like Operational Risk to make sense of that particular world. Taxonomies have a system of levelling to bring order to the chaos before us. The 'Domains of Life’ taxonomy uses eight levels, each of those populated with the types of living things on planet Earth, creating a structure as follows; Domain, Kingdom, Phylum, class, order, family, genus, species. We’ve all heard the phrase ’Animal, Vegetable, Mineral’. These are often used cited as the original nomenclature that spawned the concept of the taxonomy in Science - three Domains of life. Considering the Animal branch of this 'tree’, we then start to identify the various ’Phylum’: anthropod‘s, Lizards and Vertebrates. Followed by ’Class’: (Vertebrates) Mammals, Fish, Birds.
Eventually, we get into a level that starts to become more meaningful, ‘Order’: Primates, Rodents, Bats, Elephants and so forth. It is only when we get to this lower level of Class, that we start to recognise things that mean something to us in our every day. For example, we wouldn’t say "eeek, there’s an Anthropod on my wall!!".
In the other direction, when Darwin was arranging his findings from Galapagos, the easiest way to make his audience understand, was to group things into categories at higher levels to draw out his point; but only by having the granular, every day observations could he then aggregate in this way into something more powerful. There is no difference with Operational Risk data. Categorisations - getting it right It can be murky trying to correctly categorise and avoid overlapping between risk, causes, impacts, controls, processes, organisation/department and so forth. It is important to understand that with any data classification or taxonomy that its success or failure ultimately depends on its accuracy and avoidance of duplication and overlap. if something has been determined to be a 'bird’ and a contributing factor to that classification is the fact that it lays eggs, then you cannot logically have 'bird’ and 'egg’ in the same data grouping of a taxonomy. One influences the other. If bird is our risk then the egg is our cause. Therefore, if an Operational Risk framework has determined that ’People' related data points are causes then they cannot be risks. Example of Causes. Source: Ariane Chapelle.
Even experienced, conscientious Operational Risk practitioners can find this challenging. There are People related risks – but they are risks, not causes. ‘The risk of capacity issues’ is a common mistake when thinking about people related problems. Always think back to the Basel definition for help.
a) the risk of loss
b) due to processes, people and systems (assets).
Not enough people, capacity, is a cause. Something more valid that is often expressed is ‘the risk of losing my best people’. This is more valid – we see firms losing their talented people due to culture fit and reward structures, for example.
Similarly, we often see ‘the risk of manual processes…’. Manual processes are a cause or indeed an Issue that is increasing the likelihood of a failure or has already caused it.
Granularity is key If we have correctly drawn out the distinction between causes and risks, there are still challenges with granularity to resolve.
It is not until you have an appropriately granular body of information that you can begin to classify it. A visitor to earth would not start by saying "there are carnivores on this planet”. They would first need to look at the many different creatures; those that walk on land, swim in the sea, fly in the sky before then examining the attributes that make them unique — these may be physical but would also need to consider more ’under the surface’ observations and questions like how they survive for example; eventually starting to categorise behaviours or objectives (value creation), and threats, exposures and vulnerabilities to their types (risks) and defence mechanisms (controls / value protection). One way that these could then be crudely described would be external risks (availability of food [revenue streams], environment and predators [market and geopolitical risks] ); internal risks (ability to work within the belief systems of a pack of animals [conduct, regulation], ability to effectively contribute to the group [business processes] ); near misses (a predatory attack that was narrowly avoided [a cyber-attack that was avoided because someone noticed accidentally rather than a preventative control triggering] ). Only then can you categorise your observations into a taxonomy to perform greater analysis; read across, root cause analysis, etc - but it starts with the more detailed, granular information to get to that point, not the other way round. That would be the equivalent of saying "I’ve decided there are carnivores on this planet, but I cannot find them”. Once we have this information, we can begin to form categorisations into a taxonomy of commonality whereby reports to senior management are an aggregation of the granular information. Even senior managers have granular level risks —the means of monitoring will change accordingly with Management Controls as opposed to Process level controls but the risk itself remains specific and granular. The defence mechanism will adjust to fit the individual’s view of the danger. These lower level, ’real' risks in the process can be arranged into ’Risk Libraries’. A powerful role that the second line can play is in identifying where different parts of the organisation are identifying similar risks, using similar titles but unique descriptions, or ’risk articulations’. By settling on common risk titles at the granular level, a Risk Library is built and leveraged upon to find commonality and ultimately identify the firm’s unique risks. This then fits into and under the risk taxonomy. Application - The senior manager Identifying a high level taxonomy category like ’Technology Risk’ in a senior manager’s, say a Chief Technology Officer’s (CTO), Risk and Control Self-Assessment (’RCSA’) does not logically identify the risks that she deals with on a day to day basis. Firstly, for a senior manager this concern is something more akin to a firm’s ’Top Risk’ — An Enterprise Wide, compiled set of risks (usually limited to ten) drawn out from all the Financial and Non—Financial internal and external threats and risks 'on the mind’ of managers across the firm — as opposed to something that managers and process—performers have to mitigate with controls every day because they exist in the process, all the time. ’Technology Risk’ is not specific enough. lt is an Anthropod rather than a garden spider. Secondly, rating a risk at this level absorbs the entire suite of technology. The likelihood that ’a system’ or ’a process’ control fails in the assessment period, as well collating and aggregating the impact of every single issue and Incident/Notifiable Event into such a high level category provide a near-certain likelihood and that risk will never be out of ’Red’ for its Residual Risk Rating. The value and granularity is lost. Something more aligned to reality could be ’Disruption of customer facing IT systems’ or ’Failure to implement appropriate levels of Cyber Threat and Vulnerability Management’. These risks will likely appear in RCSAs lower down the Organisation among support and infrastructure teams but depending on the size of the inherent risk relative to the overall department and firm, can also appear in the CTO's RCSA. Whether it appears in the CTO’s, to reiterate, may be a judgement call and will ultimately depend on the size of that Risk to the firm on an ongoing basis. The difference though will be in the type of control used to manage the risk. For the CTO this may take the form of approving large—scale change in an approval system (preventative) or through management dashboards (detective). For the infrastructure or support team this may be checking daily ’up/down’ infrastructure online dashboards (preventative) or responding to alerts (detective). The Risk is the same but the Control is different. Management versus Process level.
Higher level value from granularity Over time , Risk Functions (first and second line) can then use the collation of this data through the taxonomy to identify themes and weaknesses in the firm that require attention; essentially start reporting at the Technology Risk level in an aggregated way to start to call out the risk - but only by examining the granular information that makes it up or by ’Theming Up’ the risk. The key elements of taxonomy available to a firm are commonly but not restricted to risks, causes, impacts, controls, processes, organisation - among others. The theming up and interrelation bet“ these elements are key, as with the bird and egg analogy example in the animal taxonomy.
As a senior manager, my managers will be expected to identify the risks in the process performed, deduce the key risks by assessing the inherent risk rating for each (involving determining the size of potential impacts). Then, understanding the causes so that they can be monitored and mitigated with controls and then determined whether the controls in existence are sufficient to perform the tasks every day with no further action — or whether more work is required (note — this does not always mean introducing more or different controls but could for example involve obtaining insurance or reducing the volume flowing through the task in order to reduce either the inherent or residual risk). Once this information is to hand, the manager may then choose to create value or sense from it by arranging the risks by organisation, or department to perform read-across, examine themes and learn lessons. The same could apply to cause or potential impacts. An extra dimension is then provided to risk reporting for example, by 'arranging’ or ordering the information by department/organisation or process — indeed most of the above can be derived from the start—point of process definition. Another example might be collating RCSAs by Organisation. Conclusion — bringing it all together Should a risk materialise and be logged as an Incident or Risk Event, another type of taxonomy or category is required to describe what has happened in a fast, easily recognisable way — an Impact Category. These are usually single level and arranged into a matrix alongside the size or impact of the Event. As with all Risk and Control data, it takes time and a little research to determine what fits well with an Organisation for its Impact categories. There are many ways of expressing the same thing – the key point remains of not confusing the different data elements - although impacts can often, sensibly overlap with risk types as we are essentially saying a risk has materialised so there is likely to be a close correlation. The trick is defining the thresholds inserted into the intersections which will ultimately be driven from Risk Appetite and/or historical information on Events. The key components of an Operational Risk framework include but are not limited to: Governance (Policies, Standards, Procedures); RCSAs (Risk identification, assessment and mitigation/monitoring); Key Risk Indicators (early warning system), Risk Event Management; Scenario Analysis (what if); Issues and Actions; and Emerging Risk. It is only through clean, simple, clearly defined risks, causes, impacts, controls, processes and organisation structure that the true benefit is gained in being to recognise how each influences the other, ties them together, provide analysis and so materialise all the benefits of value protection for an organisation -— identify new risks, mitigate known risk and prevent repeat Events.
Recommendations Risk - Identify risks at the granular level — regardless of how high in the Organisation the assessment is. Create a lower level library of common, real risks to the firm and arrange them into a Risk Taxonomy. These are the firm’s risks, viewed in granular and aggregated form. Rate the granular risks via RCSAs and create action plans where Risk Treatment plans are required to change the Residual Risk Rating. The Residual Risk Rating will be influenced by control assessments, open Issues, Key Risk Indicators, Losses and other Events or Incidents. Controls — Controls do not operate in a vacuum. They need to be tied to the cause and risk they are monitoring/mitigating and are part of a Process. Regular assessments and/or testing should be performed depending on the frequency the control is performed which should always be evidenced appropriately — the population and sample sizes should be defined by relevant Standards. Results should inform the RCSA. They can be Management, Transactional or Process level (not to be confused with Process in the sense of an-end-to-end creation and delivery of a product or service to a customer). They will normally be categorised into Preventative or Detective but can also incorporate Directive and Corrective as appropriate to a firm’s view. Causes — The Risk due to... Common to many firms is to categorise by People, Process, Systems and External Events. A second level if used well can provide powerful insight when combined with the risk data types. Impacts — Impact categories are normally closely aligned to the risk taxonomy but this is flexible. One, simple level is required to be combined with impact size or rating to define thresholds into a matrix so that common terminology can provide a fast way of nderstanding and escalating a crystallised risk (Event). Process — Without a Process there is no risk. In a race car analogy, there are no need for brakes if there is no engine. Effective risk frameworks can be operated without defining processes but it introduces a sub-optimal view of the risk world. Without Objectives and Process in the equation, the formula is incomplete. ‘ Organisation - As with process, some firms are not able to invest in documenting a clean, succinct Organisational structure that offers. an extra dimension for ordering and arranging the risk and control environment. Without clear roles and responsibilities, it can often get lost as to the why, how and what is actually a risk and how it is mitigated
Integrate – make the powerful linkages between these elements and the framework to create immutable push and pull effects on policy requirements, regulatory requirements and effectiveness reviews. Policy can discharge responsibility on to first line process owners by allocating requirements and recommending expected controls. Hence a control failure might suggest not only a red or amber residual risk but also a policy breach automatically. This is just one powerful example.
Kommentare