Domenico Salvati and Adrian Leuenberger of DefCon Switzerland ran a workshop on corporate risk management in Zurich. This one-day event addressed two goals:
- To present a model of risk “compatible” with upper management in order to allow techies to talk with high-ranked business representatives.
- To talk about a second model which measures and calculates probabilities in IT risk.
Now measuring and calculating risks is a tricky business and while I was impressed with the idea presented at the workshop, that project is still a work in progress and I am focusing on the risk language here.
Information Technology is an engineering discipline. Therefore risk is about applying measures to mitigate or prevent catastrophes. For executive management and the board however, risk is a decisional phenomenon. It’s about Return on Investment when working a market and about insuring against “unwanted” risks. Risk is perceived as a mix of challenge and security by the board of a company.
When it comes to risk, there are different roles within a firm. Domenico, head of risk management at a Swiss health insurance company, presented an adapted version of a standard model for company-wide co-operation in risk and compliance matters used by upper management. It’s named GRC for Governance, Risk and Compliance. Note that the following refers to “Risk” and “Compliance” as a way of working rather than the usual organisational functions.
Working in a risk-oriented fashion in a Company entails identifying risks and proposing possible measures to avoid them. Executive management and the company board (Governance) then decides on the measures proposed by “Risk” and initiates a necessary course of action. On the other hand, working in a compliance-oriented fashion entails checking how well implemented measures comply with expectations (i.e. how well they fulfill measures proposed by standards and best practices the board has decided to adopt).
It has to be noted, that this kind of thinking also applies to measures adopted to comply with internal or external regulations with the difference that you are not that free in deciding whether you want to comply with, e.g., a law. “Compliance” then reports back to Governance and highlights weaknesses within measures (i.e. reports on the status of the implemented measures) and proposes additional/other measures to close the gaps. Both “Risk” and “Compliance” have to talk “management speak” if they want to communicate successfully with executive management or the board.
The board itself is in an area of conflict between market and regulation. The complexity stems from the fact, that the company or the governance role does not understand the environment completely. Furthermore, there is a “principal agent” problem, an asymmetry of information. The governance role seeks assurance to cover information asymmetries by seeking information from the business line who is closer to the information itself.
If you step down into the IT section within a big company, then you realize that when applying the GRC-concept the same people turn out to have multiple roles within the company. As a techie, for example, you can identify a risk or can identify a measure which is not operating properly, i.e. as originally specified. Then, as a team you decide on certain (additional) measures either to enhance an existing measure or to counteract a risk. You may implement the additional measure yourself or have somebody else implement, e.g., a sensor.
This brings us to a second concept aside of GRC. It’s the three lines of defense model – a model usually promoted by Internal Audit that beautifully expands the GRC-view. The first line of defense within a company is operational management. Operational Management usually implements what the Governance has asked them to do (however, keep in mind the above information asymmetry). The second line of defense are the aforementioned assurance functions (as in the GRC we saw above). Main duty of the 2nd line of defense is to re-assure the Governance that everything works according to plan in the first line of defense. To this end they
support a network of control points to assess the measures implemented by the first line (yes, the so called internal control system). Finally, there is the third line, which is tasked to provide assurance by auditing either the first or second line or both.
Interesting is the reporting structure within the three lines. The business lines are referred to as the first line. Here you are as close to the front as you can be and you are reporting to operational management. In the 2nd line, you usually run via executive management and in the 3rd line you report to the board of the company. Needless to say that the aforementioned conflicts of interest/principal agent problem can also apply between executive management and the board, that is why you have a third line of defense.
So these are the roles that handle risk within a Company. It is obvious, they all have a varying views or definitions of risk. And sometimes even varying understanding. Here are some:
- Risk as error / fault / omission
- Risk as probability of occurrence and loss after event
- Risk as deviation from expected value
If you as a techie want to talk risk with the upper levels of management you need to align with those different perceptions. With company management and the board, it is best to discuss “risk” as a deviation from the strategic goals of the company (i.e. an expected value in strategic areas which the Governance deems worth pursuing): If customer satisfaction is a strategic issue for your company, then talk “risk” in terms of a deviation from an intended value for customer satisfaction. Let me give you a plain and simple example:
You fear the email servers could reach their CPU limit during one of the next major waves of SPAM. Based on the past reports, you know the height and length of the SPAM waves and the capacity of the server. This allows you to project the delay of emails, when the server falls behind. Now you need to talk e.g. marketing, to corporate communication or the business line closest to the customer to find out what this may mean for customer satisfaction. It is likely they have some numbers useful to underline your argumentation: A mail server serving messages with a lag of n hours will result in m customer complaints. This will affect
our customer happiness by k points. The chance of this event happening within the next 12 months is i percent.
What is crucial here is (a) the translation of a performance problem into an issue affecting a strategic goal of the Company and (b) the need to find partners that help you when contacting executive management or the board. And (c) you need to add value to the problem you see. A server with an obscure problem is not interesting for the board. It’s the impact of the problem, which is.
This also resonates with a presentation of Marc Henauer at the Swiss National Cyber Risk Conference two weeks ago: It is not the infrastructure, which is important for an organisation. It is the process or rather the customer-oriented service affected by an IT problem, which matters.
Applying the above to the decisional phenomenon outlined at the beginning: you need to translate your IT problems into “unwanted” risks. Then, you have an increased chance that executive management will want to do something about it.
A day with many insights! Thanks to Domenico and Adrian.