After identifying and analyzing risks, organizations must prioritize, plan, mitigate, and monitor those risks to drive real improvement. This content covers practical prioritization methods—including ROI analysis, the quadrant method, and others—along with mitigation workflows and the continuous monitoring cycle.
Risk Management Process
It's not enough just to identify risks — we actually have to improve things. If there's no action taken, then what's the point in going through all this exercise? So let's talk about what the next steps are.
Let's say for our company we've already done some identification, where we've identified risks to the company. Not only that, but we've done some risk analysis, and we have some ideas of what the cost of these risks are, and maybe even some ideas of what some solutions are. At this point in time we need to go through prioritizing, planning and mitigating, and perhaps even monitoring these risks, so that we can reduce the risk to the company.
Almost universally you're going to have a limited number of resources, a limited amount of time, and way more projects than you know what to do with. So there's going to have to be some really heavy prioritization on which projects you're going to do, which risks you're going to tackle, what you're going to invest your time into. We need to do some sort of prioritization.
One way we could do that is return on investment. In my opinion this is the single best way of prioritizing all your work. It should be your default, although there are other reasons to go outside of this and prioritize based off of other needs or other situations.
Here are some other prioritization methods that I've used in the past. My default is return on investment — any time I can, I try to use the ROI to evaluate the different priorities. However, this is a little more in-depth of an analysis, and sometimes something doesn't call for that much analysis before you tackle it and take action.
Another method that you could use is something like the quadrant method. I'm not going to get really in depth into any one of these, but this just gives you an idea of some of the different methods, and the fact that there are different methods that are out there.
Sometimes I'll rearrange the order based off of contingencies. There are some contingencies which require certain things to be done in certain orders, and there's also something called a critical path, so you may take that into consideration and have to shuffle things around. There are also some resource constraints that might make you shuffle things around into a different order based off of what resources you have available to you — specifically, say, the talent you're using, the employees you're using and what they kind of specialize in.
There are also times when certain projects have multiple benefits to them that fall outside of just the strict return on investment measurement. There's also something I call the snowball effect, where you can start knocking projects off the list, and getting that momentum can really help you power through a lot of projects at once. And then there's also this squeaky wheel effect.
So these are some other methods of why I might override this idea of return on investment and shuffle things around into a different order.
Ultimately what we want to do is really prioritize this work in a logical order, and the important part is really to get to taking action. So we don't want to get too bogged down in prioritization, but also not doing enough of it could really make us invest our time into the wrong area.
I also find there's this kind of back and forth between prioritization and planning and analysis, so all of this kind of happens at once. In fact, I've got this little diagram, these little windows, that show that there's a lot of back and forth with this. For some of the things to be evaluated right — for instance, return on investment — we really have to have an idea of what our plan is, so we sometimes have to skip ahead and plan a little bit to figure out what our return on investment is and do some heavier evaluation. Then we go back to the prioritizing and prioritize things in a certain order, and then we realize, well, now we need to do a little more planning to understand our different priority list. So there's kind of this back and forth that happens between these different levels.
But evaluating this and then moving on — like I say, the most important thing is that we're taking action, that we're mitigating things. So then we go into the mitigation phase.
I don't get in depth into this, especially not in this module, because everybody's work, or mitigation, or the way you tackle work, is a little different. What my experience has been, if you're a security department just working on risks, that's great, but in my experience you end up tackling a lot of other projects and priorities and things that are coming up, and so this tackling risk kind of gets inserted with the rest of your workflow and however your other workflow works.
This is just an example of scrum. I primarily use scrum and Kanban as a way to do work, and so this is the workflow that I've used with the teams that I've managed in the past. But you're going to have your own workflow and how that work is done. The point here is that you a lot of times have to integrate your risk mitigation levels into the rest of your workflow and get them queued up in your queue or your team's queue.
Then we get into the monitoring phase. Really at this point in time we need to check to make sure that what we've implemented is actually working, that we've actually mitigated the issue. So we're going to start monitoring the systems and see what is going on on those systems and if we've improved things, because that's really what we want to do, we want to improve things.
There is a lot of reporting that happens in here, because what we've done is we've made these changes, and the company has invested time and energy and money into these changes, and they want to know that it's being efficient and it's actually working. So you might have to report up to upper management, or there are also customers that may come to you and say, what have you done to mitigate your issues, and you might have to report to them. So there are different scenarios here. I've gone over that in other lessons within this module, but that gives you an idea that at this point in time we kind of transition into that monitoring and reporting.
Now, during this monitoring phase, what you're going to discover is there are going to be things that didn't go quite as planned and now you need to adapt to that, or there could be new things that you discover that you didn't think about before or that didn't exist before. So really we go back into this identification phase, and we're going to have to do some analysis on it, and the cycle begins all over again.
That's great, because every time we go through the cycle we're going to improve upon things, we're going to improve upon this process, and we're going to decrease the risk to the company.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →