A common issue that arises when implementing an enterprise risk management (ERM) framework is “who owns, is responsible for, is accountable for risks and controls?” Clear risk and control ownership is critical to ensure that all risks are being managed and none are falling through the cracks and the main risk control has an owner who is accountable for the control’s performance. Equally, it is important that we are not duplicating effort through multiple owners.
That Risk is Not Mine
A regular situation is where a business department uses IT systems. When “systems” risks are raised, we commonly hear from the business department manager that they do not own that risk, it is owned by the IT department! Although there will not be one simple answer, what logical rules can we use to determine what the ownership and responsibility situation should ideally be?
A starting point is to consider the definition of risk in the ISO 31000 risk management standard. In that standard, risk is defined as “the effect of uncertainty on objectives”. The starting point should therefore be business objectives. (Read the article 6 Key Questions to Define Risk Management Controls)
Using an example of a Call Centre
One of the objectives of a call centre will be customer service. There will be little debate that this objective will be owned by the Head of the call centre. One of the risks that could impact the customer service objectives would be IT failure and specifically system outages where the call centre staff member cannot access the customer details when they call. As this risk impacts the objective, it should be owned by the same department as the objective, i.e. the call centre.
The first general rule should therefore be:
The risk should be owned by the same department that owns the impacted objective.
This general rule does however become complicated when, for example, an IT system is owned by multiple business units and its failure will affect multiple units.
The general rule would mean that each business unit owns “IT failure” risk and if material, should be included in that business units risk registers and assessed. The practical problem is that we have substantially the same risk recorded and assessed in multiple business units. This may be valid, if for example, each business unit uses the system for different purposes and / or rates the risk differently due to it having different effects on each business unit’s objectives. If however, the risk is substantially the same in each business unit, it may make more practical sense to consolidate the risk in terms of identification, assessment and management back in the IT department. If this is done, it makes managing the risk easier. However, we have to be clear that:
- The IT department has responsibility for the risk and its management but it is accountable for that risk to each business unit that is affected by it.
- Each business unit that is affected by it is still responsible but that responsibility is met through making IT accountable for the risk and its management to the standard required of that business unit.
This can be practically handled as follows:
- The risk is entered into the IT risk register as “IT failure”. It is connected to the IT department’s business objective of “To provide business units with relevant, reliable and continuous IT solutions”. Controls will be attached to that risk in the IT risk register and assessed accordingly.
- Visibility over that risk and related controls should be provided to the affected business units to support the accountability IT has to those business units. This would communicate the level of risk and the performance of related controls so that each affected business unit could monitor how well that risk, which can affected its objectives, is being managed.
- There should be dialogue, and at a more formal level where required, a service level agreement between the business units and IT which sets out these responsibilities and accountabilities.
In terms of control ownership, this should lie with whichever department is responsible for the performance of the control. Where a control has multiple owners, each owner must clearly understand what part of the control they are responsible for, otherwise responsibility will be lost between the cracks.
If you would like to know more about how Protecht can help you develop methodology and policy around your ERM framework and practically support the process with Protecht’s leading ERM software, please contact info@protechtgroup.com
