I’ve seen many instances when KRIs live their own life. Often, KRIs that are being showcased to the board are very operational. Like Number of DDos attacks. While the KRI presentation is not bad in itself, there should a value that drives this demonstration. What is a KRI, where they live, what they need to show, and who and when need to see them?
To begin, I would like to note, that this discussion lies in Operational Risk Management and is not specifically prescribed to other areas, like Project Management etc.
In my previous post, I talked about the Risk Posture and the way organizations can gather this information. The primary source of this information is coming from Controls.
Controls are assessed and they drive the residual risk ratings. Risk ratings are used to determine the risk they are related to and flow up the risk pyramid.
Risk posture is not a KRI. Risk posture is ‘current’ state, while KRIs are forward looking.
Key Risk Indicators
KRI is not a tool to identify new risks, it is a tool to analyze the potential of control failing and communicating this information to leadership.
KRIs are heavy related to controls and their performance. So, if control is effective and performing well, the organization shall take an interest in operational metrics relevant to that control performance.
The performance metrics must capture the underlying mechanisms behind the control.
KRI can analyze the specific operational metrics behind the control and, with thresholds defined, this data can be extrapolated into the potential future control failures.
KRIs should not exist in the vacuum and must be supporting existing controls.
If you utilize the 800-53, and mitigating the network against the DDoS attacks, you might have this control in place.
| SC-5 |
| Denial of Service Protection |
| Primary control addressing DDoS. Requires organizations to protect against or limit the effects of DoS attacks by employing boundary protection devices, redundancy, and load balancing. |
As a result, this control could be related to a KRI named “Number of DDos Attacks”. Per your threshold, you can monitor this KRI and proactively identify potential issues and apply additional control hardening before control becomes ineffective for any reason such as Bandwidth, Resource Limit etc.
Who and When should be informed about KRIs?
KRIs that are ‘green’ should not be discussed with executives. So, presenting a ‘fixed’ set of KRIs time after time should not be a good practice.
Assuming the organization runs thousands of controls, all controls should be monitored and analyzed for potential failures.
In case, if a KRI shows an indication of potential failure, the KRI shall be reviewed internally by the team and discussed within the KRI boundary. Then the management should make a decision, or align with the reporting policy on the next step of action.
In case if KRI is a low-level KRI which, if failed, could result in control failure, but a control is a low risk control, then there could be less urgency to mitigate potential failure.
If case if KRI is for control that manages elevated risk, then the KRI could be reported to the upper management or the board. This might help with getting funding and allocating resources for remediation.
Leave a Reply