Do You Consider and Integrate the Whole Control Environment?
A big challenge that organisations face is recognising and defining what a control environment is and why they should have one. It is very easy to get caught up in the flurry of documenting controls, writing them down and rating them without taking a deep breath and asking oneself, are all the available tools being considered as part of control environment monitoring – it is not just individual controls we should be monitoring, after all.
Documenting does not always drive good culture and vice versa – so why do we do it?
Being able to articulate a control on paper well, has nothing to do with being a conscientious person that has methods in their daily process of identifying and flagging up potential problems to someone who can help; this happens an awful lot in the workplace every day regardless of how well the control environment is monitored. It does not have to be written down and documented to shine a light on risk in most instances. In my personal experience I find that colleagues who work in Operations and Finance departments develop a natural way of working to identify errors and mitigate them as part of everyday rhythm. Installing an effective risk framework and testing its usage, auditing it, etc, etc still relies on a huge degree of firm conduct and behaviours; in essence a system of crime and punishment for it to all work.
So why do we document the control environment and go to all this trouble if it simply relies on firm-wide behaviours either way? Here are a few reasons.
As in everyday life, the vast majority of people in the workplace know the difference between right and wrong as described above. Control environments are there to identify the small minority who are not conscientious and do not follow the rules.
Demonstrate to regulators and external auditors that there is a mechanism in place to identify the corporate bad people and fix processes before errors become catastrophes to protect clients, shareholders, colleagues and other vested interests.
Technology is not perfect and can cause all manner of catastrophes which require monitoring, repairing, and fixing. This intricate network of protection requires documenting in order not to make a mistake or miss something.
Organisations are at the mercy of external weather, political, free market events – how can we know that everything has been considered unless it is documented, analysed and debated?
I am sure you can think of many more reasons – which means hopefully we have answered the question of why we document and follow Operational Risk frameworks.
What is the Control Environment?
I observe a challenge in organisations with being clear on what the Control Environment is and how to get optimum value out of it. Here are some simple definitions.
Control – An activity that prevents or detects errors to mitigate risk.
Control Environment - The overall attitude, awareness and actions of management pertaining to the system of controls, incorporating; Controls, KRIs, RCSAs, Controls Assessments and Testing, Issues and Actions, Risk Event reporting, Governance, Risk Reporting.
Control Assessment and Testing – assess the design of the control and how effective they are in theory at monitoring risk; test the operating effectiveness then rate that with evidence and/or samples; the tester/assessor should ask the control operator for examples of the control being performed using a large element of randomness in dates/occurrences.
Process – a series of steps that are followed to achieve a result.
Key Risk Indicators (KRIs) are used to monitor risk on an ongoing basis, nearly always using ‘numbers’ to identify degradation in the control environment. Key Control Indicators complement KRIs and are usually used where the control is performed with a high frequency and its operating effectiveness can be measured very effectively (tested) simply by looking at the numbers involved as opposed to using large amounts of evidence and samples.
Risk reporting – collecting all the results from around the control environment and providing analysis and commentary on the control environment.
Risk Events – the recording, story-telling and next steps to prevent recurrence of an error, failing or catastrophe.
Issues and Actions – the observation of a weakness in the control environment either before an error has occurred or after, to plan a path to a corrective, safer state.
Rating system – quite simply how bad something is. For example, KRIs have a predefined point of worsening states of approaching and busting risk appetites (e.g., red, amber, green) or Issues might have numeric or worded levels of concern (1-6 or simply ‘Very High, High, Medium, Low) with definitions.
Emerging risks – I have possibly identified something inside or outside the firm’s control, but it requires more investigation to be sure if it can be a problem for the firm, an often under-utilised technique.
Risk and Control Self-Assessments (RCSAs) – the inherently ‘high’, material risks in a business unit of the firm that are rated and monitored an ongoing basis for impact and likelihood of occurrence.
Scenario Analysis – ‘What if’; low likelihood, huge impact assessment sometimes referred to as ‘black swan’ or ‘tail’ events (a reference to statistical probability curves).
All the above tools make up the Control Environment. Not one of them; not some of them – an effective control environment consists of and considers all of them in its monitoring – we are not talking about documenting a ‘Framework’ here – we are addressing the practical application and reminding ourselves why we do it.
Bringing it all together
The RCSA is the main vehicle for bringing the control environment together in a single, easily digestible view, here’s how.
RCSAs generally begin with a workshop to consider risks in the unit. Too often however, these can be driven by anecdotal story-telling and assumptions as opposed to looking at the facts available through the Control Environment and analysing the Process.
Risk Events - Consider occurrences of Risk Events in the past 12-18 months raised by the business unit or Process to give a view on what has gone wrong. This is, incredibly in my view, a hugely under-utilised way of identifying inherent risks as well helping drive residual risk ratings for the assessment period. You may find a risk in the process that you did not even realise you had by looking at Risk Events.
Open Issues and Actions – what have people identified as a weakness that needs to be addressed before it causes a ‘loss’ of some description; or as part of an Assurance/Audit review or Risk Event that already occurred. Closed Issues and Actions can also provide interesting colour, but open items are those where it is perceived that the risk is ‘open’ and could hurt the firm at any moment.
Control assessment and testing results – what has the assessor found when sampling occurrences of the control being performed. Did the control performer do it correctly or even at all on the date requested? When the RCSA owner looks at the results of the control testing this will influence their opinion of the residual risk rating. There will be examples of a control owner/assessor rating something as ‘green’ but the RCSA owner may have discovered some Risk Events in the period where that control has failed and go back and ask questions in this regard.
KRIs – how have KRIs and KCIs owned by the business unit performed in the assessment period? Reds and Ambers may influence the residual risk rating.
Integrating together all the elements of the Control Environment effectively and summarising it all with good risk reporting requires patience, a non-blame culture and the will to continuously develop and evolve, learning lessons all the time. However, recognising these elements in the first place and how they influence each other, and then making some decisions about what works best at your firm to bring them all together is the first step. Adding in Emerging Risks, a look again at Scenario analysis findings where relevant and how things ultimately tie back to Risk Appetite and Objectives completes the picture. Integrating in this way, also lays the foundation for efficient Policy Effectiveness measures and reviews. A completely integrated control framework.
Ultimately a solid eGRC platform like MetricStream for example, helps automate and standardise all the elements of the ICF with the ability to form linkages in the data, creating efficiencies in risk practices. This allows risk professionals to focus on smarter risk reporting to draw out themes and trends and deploy the firm’s precious resources into first fixing the problems that increase the likelihood of a risk crystallising and then sustainably preventing them before they happen.
At ICF Consulting we pride ourselves in being able to deploy an integrated control framework for our clients to draw out these benefits on an ongoing basis.