A member of the FAIR Institute LinkedIn forum asked an important question the other day:
“I was wondering if there are any guidelines, rules-of-thumb, etc. on how to decide when something should end up in a risk register or should be handled differently.
"If I address every concern, audit finding etc., as a risk, I end up with a huge risk register with low-risk entries of which most are quickly addressed with some technical change, policy etc.
"If I ignore something maybe it turns out to be a larger issue than I thought it would be.
"So how do you decide if something should go through risk management or shouldn’t?”
Having lived this problem myself as a CISO, I feel his pain.
Too often, risk registers become a due diligence dumping ground for everything that turns up from audits, self-examinations, policy exceptions, etc. These dumping ground risk registers can feel like a great source of comfort for those who worry about risk management, but more often than not they create a signal-to-noise problem that impedes effective risk management programs.
Now, let me say something that’s going to sound contradictory. Yes, organizations should have a place to record and track everything that turns up from audits, self-examinations, policy exceptions, etc. But here’s the catch — none of those things are risks. None. Nada. Zip. They are conditions that contribute to risk. Here’s my point…
“Risk management” is (or should be) about managing the frequency and severity of adverse events (e.g., outages from DDoS, ransomware events, unauthorized disclosure of confidential information, etc.). These potential adverse events are the “risks” that belong in a cyber risk register. The good news is that the volume of meaningful risks an organization faces is relatively finite — at least if defined at a reasonable level of granularity. I wrote a blog post series about prioritization (Best Approach to Prioritizing Risk) that's related to this so I won’t get into the gory details here. I also wrote a white paper a couple of years ago entitled “The Failure of GRC” that discusses this and offers solutions. It’s available on the member resources page of the FAIR Institute. Another related resource on the member resources page is a white paper I recently wrote for the FAIR Institute Cyber Risk workgroup entitled, “A Clarification of Risks?”
But for those who just want a quick-and-dirty answer, it boils down to this:
- Risk registers should be used to document the portfolio of potential adverse events an organization is subject to. These entries should describe the event and have fields for the likelihood and impact associated with the event.
- A separate register (you pick a name) should be used to record the control deficiencies, etc. that contribute to an organization’s risk portfolio. The entries in this register can be mapped to the relevant risks in the risk register. The significance of these conditions can then be characterized based on the degree to which they increase the likelihood/impact of those risks. As deficiencies are identified that realistically increase the likelihood or severity of one or more risks, those risk entries can be updated to reflect those changes. Likewise, risk entries can be updated as improvements are made.
This approach should help organizations be risk-focused and more easily recognize which control conditions/deficiencies really matter, and which ones are primarily noise.
Jack Jones is Chairman of the FAIR Institute. To participate in the discussion on LinkedIn with Jack and other FAIR risk-analysis practitioners, join the FAIR Institute.
