The Five Layers of a Mature GRC Program

Media Thumbnail
00:00
00:00
1x
  • 0.5
  • 1
  • 1.25
  • 1.5
  • 1.75
  • 2
This is a podcast episode titled, The Five Layers of a Mature GRC Program. The summary for this episode is: <p>On this episode of GRC &amp; Me, Andy Ruse, LogicGate’s President of Field Operations, sits down with Cooley’s Mike Santos, Director of Security and Information Governance, to discuss his five-layer maturity model for building effective GRC programs, the different things a risk practitioner has to consider in decision making, and his own recommendations for maturing any risk program.</p>
Business driver for ISO certification
02:18 MIN
Risk management maturity model
04:54 MIN
Tips & tricks for a mature GRC program
04:13 MIN

Megan Phee: Hi, I'm Megan Phee, and this is GRC& Me, where we interview industry thought leaders in governance, risk, and compliance on hot topics, industry specific challenges, trends, and more to learn about your methods, solutions, and outlook in the space.

Andy Ruse: Hello everyone, and welcome to another episode of GRC& Me. I am Andy Ruse, President of Field Operations at LogicGate, and I'll be your host today. For this episode, I chat with Mike Santos, Director of Security and Information Governance at Cooley. Mike talks about the five layers to the maturity model of risk, the different decisions a risk practitioner has to consider for decision making, and his own recommendations for maturing a risk program. So, here's my conversation with Mike. Mike, it has been awesome sitting around, and working with you over the last couple days as we've been meeting with a lot of other risk practitioners. So, I appreciate you taking the time to sit down with me here. I thought maybe we'd start off about you sharing your background in GRC, and your risk journey, and your current role as Director of Security and Information Governance at Cooley.

Mike Santos: Well, thanks for having me here. My background was, I started off in the Navy, and the Navy had a lot of processes, and put a lot of thought into thinking about risk. What is the risk of doing certain things? How do you minimize the risk of working on ships, working with weapons systems? You want to always make sure that in the end nobody's getting hurt that shouldn't be getting hurt, I guess. I then went into the IT world after the Navy, and the IT world is, back at the time, I think cyber risk wasn't a really big deal. But there's still IT risk, the risk of a system going down, a risk of a change affecting something. And then, cybersecurity came along, and I kind of fell into that realm, and I was the person standing there going, " Sure, I'll do it," when nobody else wanted to do it. Because nobody thought it was really much of anything. So, I took over cybersecurity for where I work right now at Cooley, which is an international law firm, and I started doing cybersecurity, and lo and behold, cybersecurity just blew up. I got to the point where my organization wanted to really get involved, and get ISO27001 certified. And part of that is developing a risk management program. And that's really what threw me, and my team into risk management was ISO27001, because there's a lot in there about, " What is your risk program? Are you doing your annual risks?" and everything else. And that's about where I got started with risk. It was kind of an eye- opening experience. I mean we'd been dealing with cyber risk, but not in the same way. In cyber risk, you go, " Oh well, I got to make sure that I have anti malware." So, it was more of a checklist at the time, and this was really thinking through, " Okay, well what are the risks that are out there? What are the risks of a nation state? How do you mitigate what you're going to accept?" and those types of things. I got involved that way, and that has led me to where I am today where we have a broader risk management program that not only includes cyber risk, but business continuity risks, as well as the risks that you see with just handling information, and the governance of all the information that we have at a law firm. And then, privacy has really come in strong in the last couple years. So now, privacy is a big part of our risk program as well.

Andy Ruse: And I'm curious about the ISO certification process. What was the business driver that initiated that need?

Mike Santos: So the business driver was we were getting... and we still do actually... We get a lot of assessments from our clients. So, they want to assess that our security, that our standards, and everything is up to par, because they're eventually going to be giving us some sort of information. And for most companies, the stuff they trade on the legal end is really important. It could be about a merger. It could be about a public offering. There's a lot of things that you're keeping very secret, but you need to share them with your attorneys. So, we were getting a lot of these, and it was really hard to say, " Well, to what standards should we be shooting for?" as opposed to, " Well, this one comes in, and they say we should be doing this. And this one comes in, and now we should be doing that." And instead of learning as we went, we decided, " Well, let's pick a standard which will hopefully encompass most of what they're asking for so that these go a lot easier when they come in." The real hope was that if we got ISO27001 certified, maybe we can say, " Well, we're ISO27001 certified," and the assessment would be over. That really is not how it turned out to be, but it does give us a good baseline. Because most questions that we get asked can be related back to some sort of ISO control. So, we at least know, " Well, we at least know we do it." We at least can show the policies, the procedures, the evidence, and it makes the assessments go a lot smoother. So, that was the real driver for getting our ISO27001 certification. We chose that over things like aligning ourselves with NIST or just saying, " Sure, we do CIS20." Because one, you actually get a certificate, because there's an actual audit process that you go through the Certificate Authority. So you actually get your certificate, and you can say, " It's not just, well, I did it myself." You're saying, " Well look, there's my piece of paper." And a lot of law firms were tossing it up, and trying to decide which one. And a lot of law firms eventually decided, " Well, if we're going to do anything, it's going to be ISO27001." A couple of law firms had already gone through the process. So, it was a natural next step for us. And it also covers a little better internationally. Things like NIST, CIS20, people are like, " Eh, that's... " But ISO is an internationally recognized body for a variety of certifications. So, you know you're covering yourself across the globe.

Andy Ruse: I'm always shocked about this. As a career software leader, you think about third party risk management. And I'm filling out customer forms, and everything, and helping with that. But then, they're inquiring from me. To hear that a law firm also is thinking about, " I need to have not just my own third party risk to assess my vendors, but I have to be ready to respond to my clients so I can do business."

Mike Santos: Absolutely. It's a big part of what a portion of my team does is just answer these constantly.

Andy Ruse: Yeah, for sure. I know the feeling. So, it sounds like as you started to establish this risk management program, you had to build a model, and we were talking about a little bit in a few sessions this week. Maybe you could share a little bit about your maturity model of risk management they built?

Mike Santos: Sure. So, what I was discussing in my session was, "What's a model for decision making, risk- based decision making?" There's a lot of maturity models out there for a risk program, and a lot of those get into the granular of, "Well, what parts of the program do you start? When do you start them? What's the order?" And I didn't want to get wrapped up in that, because that is so specific to everybody's journey. For us, when we started our journey in risk management, we'd already been doing third-party risk management, so that was done. But if I was to redo it all from scratch, I probably wouldn't start with that. But I was already there doing it. So, it's really hard sometimes with those models, but making decisions based on risk, when you start your risk program, everybody's starting with essentially the same spot, which is ad hoc where you're just, "I'm winging it, and guess what happened yesterday? Oh, I guess I got to figure out what's going to go on," or, "Oh, gee, it goes into effect tomorrow. Well, I know they've been talking about it for a year, but I guess I better put something together because tomorrow's coming." I spoke about how you make these decisions on risk, and it went from starting ad hoc, you're wing it, then you build your core, which is your policy. So, now at least as an organization you've decided, " Well, by policy, these are the things we say we do, and don't do, and want to see happen, and not happen, and what our tolerance levels are." So, at least you now have some... You're not just like saying, " Well, this came up today, let's all sit down, and figure this out." It's more like, " Well, this came up today." We can at least start with the policies, and say, " How does the policy drive this decision?" From there, it went to a risk model decision making, which I think is where a lot of people wind up, and it's really a very good place for everybody to be, and even stay. If you don't ever get past level three, I think it's fine. I think most organizations will be very successful being in that realm. And in there, you've basically said, " Well, here's my risk model, and I'm going to run my risks through this model." That model's then going to give me some sort of output, whether it's qualitative or quantitative, depending on how advanced your model is. And then, that is going to help me decide what to do with those risks, because I put them through an actual model. And again, I think that's where a lot of people wind up. And like most maturity models that you see out there, if you can get to and stay in level three, you're probably going to be okay. And as you start to go into level four, most models, including this model, is you really start to have to almost do a risk analysis, because it's a risk/ reward. Because you're going to start putting in a lot more resources to get a lot less out of it. When you start going to level four, it's now your risks decisions are now based on systems. So in level four, what you're trying to achieve is some integrations where your systems are plugging into your risk model. So, now, not only do you have just your risk model that you're running things through, but part of that model is information you're getting from other systems. It could be your vulnerability management system. It could be your service desk ticketing system. It could be a lot of different things that are now feeding, hopefully automatically, in the beginning crudely manually. And now, that's helping drive your decisions. Because you're not just saying, " Well, here's not my model," but, " Here's actually what I see in this world." How bad of a risk is business email compromised compared to ransomware? Well, I can run it through my model which is going to give me results. But those results could change company by company, even month by month, even sometimes day to day if you start saying, " Well, here are the service desk tickets that come in, and here's what the email telemetry says." And one day, it could be ransomware, and two months later, you could say, " Nope, it's definitely business email compromise now." So that's how really it gives you a little bit more real time, and personal analysis. And the last one was risk driven decisions where you have these integrations in place. They're most likely automated at this point. And now, the systems are almost telling you, " Here's where your risk is, you need to go deal with it," as opposed to you saying, " Well, here's my risk." I'll run it through my model. I add in my metrics to finalize my model. Now the systems are plugging in so much information to your GRC. Your GRC is now able to make some intelligent decisions, and they're not completely automated. But now they're saying, " Today I'm telling you, based off of everything I've seen, and your model, I'm telling you today, business email compromise is what you need to worry about the most." Three weeks from now, it could be, " Hey, it could be that office that you have in Florida with the pending hurricane that may or may not be coming." It's telling you now almost what to do. I think I almost referenced, not almost, I did reference it in my slides as Skynet from the Terminator movies. I told people, " Hopefully you're not dealing with anything nuclear, but you're letting the system almost tell you." Now, you're making final decisions, because you might still need to decide mitigations, and everything else. But there's so much automation going in there, it's almost become alive.

Andy Ruse: I love that model, that they have five different stages. If we go back to, I think it was stage three, and just getting the decision making process right, and the framework there. Maybe you could share a little bit of tips and tricks? Because I think like stage four, stage five, super aspirational, but you get there a ton of value. But many of us are stuck in level three here.

Mike Santos: Yeah, the two parts. So, I think to get to level three is, first, you got to build your baseline. You build your policy, and then you got to come over with a model. And that model could be different for everybody. And I tell people, " Look, pick a model that's already out there. You can use this NIST risk model. You can use ISO27005 as a model. There's so many of them out there. You could use the FAIR model." But I tell people, " Well, and that's not a easy one to start with. You may want to start with one of the easier ones before you really jump into something as serious, and as gorilla- like as the FAIR model." And you know got to say, " Okay, well, let me start with this model. Let me see how this model works. You need to run your risks through the model that you see." And then you need to say, " Well, did I like those results? Are they true?" I mean a lot of times you can look and say, if it comes out, and says, " Well, the threat of an environmental issue is huge," and you go, " But it's really not. We've never had that incident, so maybe this model is not right, but where did the model go wrong?" And then you begin to say, " Okay, well, what telemetry do I already have?" Because you don't want to have to create it. You're just starting your model. But what do you already have that you can add in? I mean most models you start off with, " What's the probability of it happening? How does my mitigating controls affect it? Are there any vulnerabilities?" And you kind of bring those together, and you come up with something. But you can start adding other things. You can say, " Well, what's the initial threat to this risk, and how does that threat affect me? What's the score of the threat, and then how do I apply that to the actual risk?" I know for us, we added in threat. Then, there was probability. Because we had probability, vulnerability, and mitigations. And then we added in, " Well, what's the ability to exploit the vulnerability?" Because I mean, you can have vulnerabilities, but if they're not exploitable, we then add it in, " Well again, what is the threat? How do I base... What threat is actually attacking this, and how serious of do I think that threat is?" And sometimes, you pull off these generic threat models, and we're using one from Europe. And one of them is physical attack from animals or something. So, obviously, some of these threats score really, really low. But again, you can even say environmental. For us, like for instance, hurricanes based where we have offices. I'm not really worried about them. I'm more worried about earthquakes and wildfires to our organization than I am to, say, hurricanes. Where somebody who's based out of Florida or the Southeast might be more worried about those than they are about earthquakes and wildfires. So, you know, make those choices. And then, we even added in, " What is the cost?" not from a monetary perspective, but what is the effort to actually fix this risk? And it actually scores higher if it's easier. Because if you're not taking the candy that's laying out there, then what are you doing? So sometimes you're like, " Well, it's just writing a policy." All right, that's easy. So, it actually makes it a higher risk because the mitigation is easier, where if the mitigation is really hard, it actually makes the risk less. Because again, you might have to just accept it, right? You might just have to accept the fact that that's just too hard to fix, and every business is in the business of risk. But a lot of people ask me, " How do you get out of level three?" And we are actually in level three, we're kind of like a level three, level four. We're kind of teetering on four. But people say, " Well, how do you get out of level three?" And I always say, " Well, this is how I'm going to get out of level three. The first thing I'm going to do is re- look at my whole model." Because my model has to be solid before I try to do integrations. Or if I start plugging in integrations to a bad model, and I want to fix it down the line, it's going to be a lot of work. I want to get those integrations the first time. So, I need to see what my model is, and how my model changes. So, I always tell people, " First you got to just almost do a step back, and say, " I need to version up my level three. I need to version up. My level three needs to be solid. There can be any problems with it," because now I'm going to introduce all new data sets." So, that's how you get out of there. That's how you get there. And like I said, if you stay there, and just make minor tweaks to it, and maybe do some level four things, but maybe you never really get out of level three, you'll probably be just fine, yeah.

Andy Ruse: I love this practical advice around starting simple but then going back, and continuous improvement, and continuous improvement, and then in doing a reassessment of your program, and making small adjustments along the way. I think what you're seeing, and we're seeing just the complexity of the data systems that are out there, the pace had change, and risks that are out there, it's just becoming more frequent and at a higher pace. But that continuous improvement piece really I think is quite helpful advice.

Mike Santos: It's big.

Andy Ruse: You've been using the LogicGate Risk Cloud for a little bit. How has it changed your risk management experience?

Mike Santos: In my session, I was telling people that GRC in and of itself is not necessarily a tool. It's processing people, and policies. The tools you use enable you to do things better, more efficiently. They are part of the continuous improvement. We were ISO27001 certified for two, three years on spreadsheets and Word documents. And I know a lot of organizations out there, maybe they advanced themselves to SharePoint lists, and PowerBI. They may or may not have a full fledged software, but that doesn't mean they don't have a great GRC program. I do think what any GRC tool does for you, including LogicGate's, is it begins to enable you, and make some of these things easier. It begins to take away some of the tasks that you may have been tracking that were very manual, and it helps you begin to automate some workflows, and enhance that experience for all the people involved. The more you enhance the end user experience in risk, the more likely they will participate in the process. And you just have to have as many people participating, and take it seriously. If there's a lot of almost paperwork, or bureaucratic, or manual barriers, people are less likely to go in and do it. And one of the examples in the IT world is if you have a ticketing system for your IT department as a service desk system, and you tell people, " Well, every time somebody calls you, you need to go in retrospect and enter in that ticket," there's a low likelihood that's going to happen. They're going to help the person who called them, and then they're going to say, " I got to do that later." They're never going to get to later. It's eventually going to get thrown away, and you miss that data. Now if there was a way that you can say, " Well hey, once you're done, just send an email, and you don't have to type anything in," or, " Hey, we're going to set up a service desk." So they call the service desk, and they will put in the initial ticket, or you tell people, " Well, email this email address, and then the ticket will come to me, and then I'll help you," you see, because now that you've involved the system in there. And there's less manual stuff, you see a lot more success. The more success you have, the better data you have. And in anything you do, especially risk, the more data you can bring in, the better decisions you're going to make. Of course, you don't want to have too much data where it paralyzes you, so you always have to ... Because these days, you can get a lot of data. So, you got to find the relevant data, pare it down, and then apply it. But yeah, I think all GRC systems, what really makes them great is they just enable you in the process, and anything you can do to make any process smoother is going to be successful for you. Because there's always going to be things you cannot automate or workflows you cannot put in an electronic system, things you just have to do still in a Word document or whatever it is. Those are never going to go away. But I think what a lot of people are experiencing right now is you just can't hire enough people. It's either too costly or they're just not there. You can't find them. So, you have to begin to use systems to make up for that gap.

Andy Ruse: I love getting that process embedded in somebody's daily workflow. If you can get it close to their job, they're not thinking about how I move out of my service desk job, and do something for the risks team, and so forth, and embedding that workflow and the data in their daily work. That's the way to go.

Mike Santos: That's the point of even those level four to level five is to begin to integrate that, so that if somebody's doing something in the service desk system, when they're complete, if it's relevant, it sends it over to your GRC, which then accepts it, and hopefully kicks off whatever it is, and then your governance people can take it from there. You're not asking that person to go, and use another system, and do yet another task in their day. Unfortunately, like I was saying, getting to those points in the level four, and the level five area, sometimes you got to ask. It's a lot of resources to move the needle just a little bit. In the beginning when you're like, " Well, I just got to write some policies." You can move the needle a huge amount with very little effort, and very little resources. I mean you need Word, or Google Docs, and a human being. Maybe you have to socialize in, and get it approved by other human beings. But in the end, at four and five, you're talking about, " Okay, well, how does this API work?" and, " How does that API work?" and, " What kind of development resources do I need?" and, " What's that going to cost?" and, " How long is it going to take them to figure out these two APIs to even talk to each other? And hopefully in the end it does what I want it to do." You could be looking at six, seven months, and tens of thousands of dollars to say, " I pulled in one metric. Yay."

Andy Ruse: It's so true. It's a great tip for... Maybe my next question is, as you think out there, you're working through moving up through three and four in the model, and more automation, and data integration. But when you think about things that are out there on your roadmap... everyone has a roadmap, right?

Mike Santos: Right.

Andy Ruse: But from a vision standpoint, what do you got your eye on over the next year or two, whether it's a technology, or a methodology, or anything like that?

Mike Santos: Well, I do like to dream big. I may not always execute big, but I like to dream big. So, yeah, I dream of level five, I want to get there. I want there to be more automation in the process. I want this. I've told all my team, " I feel like we have a lot of great systems, but we're at the high school dance, and nobody's dancing with each other. Everybody's standing in a corner. Every system is in its own little corner." I said, " What I want is I want a dance. I want the systems to dance together. I want them to be relational. I don't want them to be so disparate. I want them to feed each other information, and even at times, depending on what thresholds we may say, set take action." I mean, it's possible. Again, I joke about the whole Skynet thing, or maybe it's I, Robot or whatever your favorite scary AI movie is. But to me that's where, again, there's just not enough time to do everything. So, if you can build your models, and build your processes, and then program those in, and program the systems to talk to each other, my goal would to walk in the morning, open up my GRC, and it say, " Here's the risks you need to be concerned about right here, right now. Here's what yesterday's were. Maybe they're even the same, but here's what's going to be a problem today." And heck, if it could even tell me, " Here's coming up in the future," so you can start dealing with it. And you're not dealing with stuff that's not a problem. Because you can only deal with so much. Because you might even say, " Well, great. I might have a whole bunch of risks I really need to deal with. But I know that as an organization, we really only deal with three things at a time," only show me the top three risks. Just don't even bother my mind with four through 10 at this point. Take it in digestible pieces, and as I knock one off, it'll bump one up. There'll always be a top three, but just taking little bites at a time. So, that's where I want to get my team, too, is I want to get them to the point where the process is solid, so that we can begin to actually make these systems work together.

Andy Ruse: Yeah, I think that'll be great. I always have this, " One thing at a time," and all that. It's the first recommendation, and the first decision, and you make those incremental steps.

Mike Santos: Yes.

Andy Ruse: Well, thanks for spending some time with me this week. It is absolutely been great. Any big plans? Anything you're excited about on the personal front?

Mike Santos: In about a week and a half, I'm going to Hawaii for the week, so celebrate my 25th wedding anniversary, which was actually supposed to be celebrated two years ago.

Andy Ruse: Right on.

Mike Santos: But COVID came along, and Hawaii shut down. And then, Hawaii wasn't completely opened up last year, so this is it. Third time's a charm. So, we'll do 25, 26, 27, all in one trip. So, no, really excited about that. And I'm sure it's going to be a great time.

Andy Ruse: Fantastic. Well, congratulations.

Mike Santos: Thank you.

Andy Ruse: That's a huge milestone. It's been great hanging out with you this week. Safe travels.

Mike Santos: Thank you. Thank you for having me.

Andy Ruse: To learn more about how Risk Cloud can help mature your organization's risk model, visit LogicGate. com today.

DESCRIPTION

On this episode of GRC & Me, Andy Ruse, LogicGate’s President of Field Operations, sits down with Cooley’s Mike Santos, Director of Security and Information Governance, to discuss his five-layer maturity model for building effective GRC programs, the different things a risk practitioner has to consider in decision making, and his own recommendations for maturing any risk program.