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:
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.