Risk Register, Findings? You got Issues!
Today CyberOne discusses the difference between a risk and a finding, or issue, and the need for both a risk register, issue management, and continuous monitoring… You got Issues? We’ve got you covered!
It seems like it’s that time of year again, or should I say, “when isn’t it that time of year” for auditors. My team has been busily working with a number of clients on readiness and surveillance audit preparation for SOC 2, ISO 27001 and in some cases both — not for the faint of heart, unless you have a tool like CyberOne of course (forgive the shameless plug)!
Your audit requirement for a risk management program is that it provides a comprehensive evaluation of risk and issue management, requiring you to demonstrate management of all known risks and issues, which includes likelihood, inherent risk, and residual risk to the business.
Residual risk in Risk Register: after you evaluate the control what is the leftover risk. Understanding this is critical, as there is never 0 risk, so you need to know your risks to the business. Auditors want to see this because the risk framework methodology requires proactive risk, impact and mitigation, AND leftover risk. This is end to end risk management. Empirical data is missing very often in big companies, which is in itself an issue. We recommend that you always have empirical evidence to be as strong as possible. This is the selling point for CyberOne.
We have had a lot of questions, and get a lot of these in general, about Risk Registers versus Issue Management and Risks versus Findings or Issues. Questions range from ‘I am a risk manager — how should I prepare (see below: 101) to how to build out a risk register, to when it’s needed, and most commonly, perhaps, the difference between a Risk Register and an active Issue Management program?
We are delighted to share our thoughts here. We also would invite our fellow risk experts to comment and add anything I miss, or explanations of your own. Let’s share some knowledge — read on!
Audit Requirements for Risk Management
If you’re gearing up for, or maintaining either ISO 27001 or SOC 2, you probably know already the requirements to demonstrate risk management, including a risk treatment plan, which should include the creation of a Risk Register, as well as active Issue Management and Risk Mitigation.
Proactive AND Reactive (it’s not an either, or…)
In the simplest terms, think of Risk and Issues proactive and reactive data sets. In other words, it’s either an issue — “Houston, we have a problem!” or a risk — “That big red button blows up our spaceship, so we should label it ‘Please do not press’”. It is happening, or it could happen. And there are certain ways to handle both.
Proactive Risk Management
Let’s be proactive first of course! Your Risk Register enables you to evaluate and understand all potential risk that could impact the business and the likelihood of that risk becoming a reality. In doing so, you can then evaluate the strength of your in-place security controls (Internal Controls), identify any gaps, and, where there are gaps, make informed decisions about resolving those gaps, usually by adding new or strengthening current controls. This proactive approach aims to avoid or limit risk, as opposed to mitigate and resolve it down the line (reactive). We all know you can never completely eliminate risk. The objective here is to limit occurrence and impact to the business by identifying risk and creating corrective action plans where needed, which leads us to our issues…
Reactive Issue Management:
OK, now, let’s talk about our Issues! We define Findings (CyberOne terminology) as a threat, vulnerability, or issue that is actively impacting business, its operations, or assets, i.e. it is a current problem that needs resolution. We need to react and resolve it. Issues may come from a multitude of internal or external sources. For example, your internal or vendor assessment may uncover issues with your own or vendor’s security practices. We all know this is one of the most common forms of vulnerability faced by companies are either their own employees or the supply chain.
Identify, Evaluate, “Treat”, Verify
Internal issues can be as simple as policy gaps, process, or implementation gaps, documentation, or general “upkeep” issues discovered via compliance testing, and as grave as missing security patches, logical or physical vulnerabilities, active threats like malware or ransomware and so on. There are keys and locks to successful issue management.
Is this guy in charge of your Vendor’s security program? This is an example of an issue!
The first key is being able to collect and see all your risk on a single pane of glass. The lock is understanding your risk environment, i.e. prioritizing risk effectively to enable your (probably stretched) team to focus on resolution (mitigation) of the highest priority risks. Obviously, if you can’t see all of your risk in one place, then how can you know what are your most pressing risks?
Our process for issue management is to identify, evaluate, treat, and verify (5-minute video)
For more information on risk treatment options, see our article: Steps to Creating a Risk Treatment Plan.
Final Steps
So, I hope that helps you separate your risks from your issues as you build out your risk management program.
In conclusion, I want to quickly touch on 3 final points.
First, verification as part of the issue management process. We call this continuous monitoring and we believe it is critical to successful audit preparation. Whatever your audit requirement–SOC 2, ISO 27001, 9001, CMMC, PCI/DSS, HiTrust, GDPR–as you progress, as your business grows and your security program needs to mature, you need to apply continuous evaluation of your security processes, controls, mitigation plans, and of course your evolving risk and issue environments.
Second, a quick mention of the importance of knowing Residual Risk:. Your auditor will ask this question of you. You need to know the remaining risk after evaluation and/or mitigation. Here’s a hint. It will never be 0. This data should be stored in your Risk Register. Often, companies gloss over residual risk with broad statements in risk reports. We always recommend empirical data as the best defense and greatest assurance of the strength of your security program.
Finally, in regards to continuous monitoring and generally understanding your risk environment, I hope this article demonstrates that this work cannot be done effectively, or at the very least efficiently, in a spreadsheet, nor can it be done with a niche compliance, or risk management tool.
You will need a comprehensive, full suite GRC automation platform. We just happen to have one! So, this is my final plug for CyberOne, but feel free to check out our customer reviews on Gartner’s review site
Or just drop us a line/give us a call and we will be happy to help you out.
Don’t forget — we guarantee readiness and certification. You’re in good, automated hands!
Reminder, this guy is not an employee of the company!
