How To Tailor Key Risk Indicators (KRIs) To Your Organization’s Specific Threats
Every organization faces risk each day, but no two organization’s risk landscapes look exactly the same. It’s the…
Looking for a GRC tool but not sure where to start? Szuyin Leow is here to help! She’s a Director of Customer Success at LogicGate and an expert in onboarding and implementation of risk and compliance projects. In this episode, she offers some valuable tips on how to get started as well as some ways to avoid common pitfalls.
EPISODE NOTES
Top 3 Takeaways:
- Focus on critical items first and make sure you have people and processes in place beforehand.
- If technology is flexible, you can continue to scale and grow and change your processes over time.
- Start simple, drive value in one place, and then build that over time.
Resources:
Episode Transcript
HOST KELLEY SPAKOWSKI: Hi, I'm Kelley Spakowski and this is GRC & Me, a podcast where I interview industry thought leaders in governance, risk and compliance on hot topics, industry specific challenges, trends and more, to learn about their methods, solutions and outlet in the space. I have Szuyin Leow with me, or Meow as we like to say, because she is a cat lover. A cat lover by night, but by day, she loves helping clients in onboarding and implementation of risk and compliance projects. Welcome Szuyin.
SZUYIN LEOW: Thank you. Happy to be here.
KS: Thanks for joining me. So I wanted to have you on an episode to tackle the topic of implementation, because it's a big part of a project like this and certainly an area of challenge and pitfalls and I want to help inform my audience about what they need to consider and also help them avoid some of those common pitfalls. So, I'm really excited to have you on and I want to understand first and foremost your background in consulting and why you got started.
SL: Sure. Yeah. So, before joining LogicGate, I worked at PWC and was a cybersecurity and privacy consultant, and in that role I worked with a lot of customers in various industries and worked with them on helping them to develop and operationalize their cybersecurity programs. So, that ranged from actually performing some cybersecurity assessments myself to writing policies and procedures to helping more of the C level develop their cyber security programs and strategies. And throughout all of that work, really a common theme I found was that there were challenges in terms of collaboration across teams. There were challenges in terms of really getting to operationalize and automate processes and have centralized views into data. And then when I found out about LogicGate and some of the other technology solutions that were available, really opened my eyes to the opportunities in technology beyond just spreadsheets. That's what got me excited about working for a company where we could really help to build and implement solutions in a more powerful way.
KS: Awesome. So when clients first come to you for an implementation, what are the common challenges about getting started? Because one of the things that I find during the evaluation phase is clients commonly, they don't know where or when to get started. Timing and maturity are both things that they're considering. A lot of times prospects will tell me, "Well we haven't quite figured out how we want our framework or method to look, or we don't even have a risk register started," for example. What do you recommend to clients in that situation and where and when should they get started?
SL: Yeah, it can be really overwhelming. There is so much to consider in the world of governance, risk and compliance, so definitely can relate to what those customers are facing. In terms of getting started though, there are some key things to keep in mind. First of all, if you are going to invest in a technology solution, you want to make sure that technology is actually going to be implemented successfully, right? So, one of the big things we've found is you can buy as much technology as you want, but that technology is only going to work if you have the people and the processes in place to actually support that technology. And as someone who works at a technology company, maybe there are some people who wouldn't want me to say that, but it's so, so true. So definitely when implementing a GRC solution, you'll want to make sure that, first of all, you have the right stakeholders at the table to provide input on what that technology should include and how it should work.
Then you're also going to want to make sure that you have the right processes developed and defined to support that technology. So, definitely getting alignment on those process requirements before you start to even get your hands into a tool I think is the number one thing that I would recommend. Another thing is when customers come to the table often for a GRC solution, they are looking for the full package, right? They want a fully working GRC platform, and if they could have that yesterday, they would want that. While that would be amazing, it's just not realistic. So, a lot of technology solutions out there do have templates available that you can use, but oftentimes you're going to need to have some sort of customization built into the tool, because not every single organization is unique and so your business is going to have its own unique requirements that you need to build into that technology.
And that can be a challenging process when you have multiple people involved. And so another thing we found is by focusing on one module or use case first rather than trying to build a full GRC platform all at once and trying to boil that ocean, you can instead focus on one that you think is going to be super valuable and critical to your organization, roll that out first. Give value to your end users so that first process initially, help them buy into that technology solution through that first process, and then get them involved to help roll out the rest of your GRC platform going forward. Both of those things I think are super important in terms of focusing on a critical item first and also making sure you have the people and process in place beforehand. Another thing I would mention is oftentimes customers will get super excited when they see what they can do in a technology solution and that's super empowering and that's great, but sometimes that can lead to customers wanting to try and make whatever they're building initially perfect and they are going to try and almost make it too complex or robust on the first go.
And so another thing that I would definitely encourage any person who's implementing a new technology solution to embrace is the concept of keep it simple and less is more, because that will often help that technology to be easier for end users to actually adopt and also just keep it easier for admin users to manage going forward. And certainly if that technology is flexible, you can continue to scale and grow and change your processes over time.
KS: Yeah, I think that's a good point. I think it's also something to consider when you're looking and evaluating software. When you are looking at something that is really complex with lots of bells and whistles and that's trying to boil the ocean for you, is that really going to be a good fit? And is that something that you can adopt and get value out of? It might not be.
SL: Definitely.
KS: Yeah, I like that simple start and driving value in one place and then building that over time. So, in your opinion, is it difficult for small and mid-sized companies to ditch the, we like to call it duct tape and bubblegum, but spreadsheets and email and implement a software solution, and what's holding them back or keeping them in that status quo space?
SL: Sure. One of the biggest challenges for small and mid-sized companies is often that risk and compliance teams in those companies could be a one person show or maybe a two or three person show. And because it's a small team that's managing all of these responsibilities, those people are juggling a lot. And for them to throw into the mix, the thought of implementing a brand new technology, that can sometimes be too much to handle and ...
KS: Daunting.
SL: The scope. Totally. In the scope of all of their other day to day activities. And so I think that's often the biggest challenge, is getting over that fear that by implementing a technology, you're going to lose out on time in other places. Now, that may be true, but what you have to look at is the light at the end of the tunnel, which is by investing that time and implementing the technology that should ultimately, if that technology is good, that should save you so much more time after that technology has been stood up.
So, that's one of the things I think that technology providers can look at is showing users how that technology is going to change the way they work and change their effectiveness and their jobs. So, that's definitely one piece. Once you get over that hump, I think there's obviously still some more change management pieces that come into play. It's hard to get people to change their habits and learn something new. So, another thing is if that technology that you found is user friendly and really intuitive to use, obviously that's going to make it easier for these owners of GRC programs to be more willing to invest in that technology and buy into it.
KS: Yeah, I totally agree. No pain, no gain, right?
SL: Exactly. Yes.
KS: But you take into consideration when you're building out an implementation schedule that people have day to day jobs, so ...
SL: Absolutely.
KS: That's all a part of it as well. Don't bite off more than you can chew and take the time to be thoughtful in how you schedule the implementation activities. So with risk and compliance programs trying to support constant change, how can they be more strategic and proactive, and how can they avoid essentially chasing their tail on these regulatory changes, business changes, as that can be driven by external factors?
SL: Yeah, absolutely. I think you hit the nail on the head there that oftentimes we don't have control over those changes. They are so often driven by external factors with changing regulations, changing standards. So I think it's first of all being aware of that and understanding that and then making sure that as an organization you're prepared for that. So again, it comes down to your people and processes, making sure that you have a process defined to handle those changes, and once you've defined that process, making sure that that is clearly communicated across the organization to the appropriate individuals so that they can respond in the right manner.
This is something that ideally your GRC technology will be able to support you with as well. We've worked with many customers to help them put together workflows to keep track of these changes and notify the right individuals. So, that's part of developing that process and that program. If you can automate that in your technology too, even better. I think another piece of it is just being aware of trends in the industry to help you be proactive. A great example would be GDPR was all the talk last year when that finally went live, and for smart individuals here in the U.S. Who maybe didn't have to comply with GDPR, because they don't have any EU citizen data. They probably realized that that trend happening over in Europe was eventually going to come here to the states and we're already seeing that with California and CCPA. So, just being aware of where the industry is going and what some of those changes are that might affect your programs and your requirements can help you get a head start on moving your program in the right direction.
KS: Right. So, my next question is implementations are risk-taking endeavor in and of themselves. How can companies prepare for and ensure a successful go live and how do they avoid losing that momentum post implementation?
SL: Great question. Yeah, so one of the things that I would definitely recommend, really anytime you're making an investment, but especially in terms of implementing technology, is making sure that from day one you have thought about how you're going to measure and communicate your success with that solution. So, that's thinking about what are your objectives and goals in terms of implementing this technology and what metrics are we going to use as an organization to prove that we've actually met those goals and objectives. This is something that we try to work with all of our customers to do in terms of being a implementation provider, because not only is that going to help our customers realize the value of the technology that they're pouring so much time and effort into, but also helps us as implementers to see, okay we've checked the box on these requirements that our customer has asked us to fulfill and we are able to see that we are actually driving value at the company through what we've built and configured.
So definitely communicating about those metrics and putting processes into place to collect that data and then report on it later, I think is super critical. One thing to think about in terms of defining metrics and objectives is making sure that you are covering all of the different audiences involved in your implementation. So that includes the end users who every day are going to be working within that technology. If you are working with external partners, like vendors for any sort of third party risk management, getting feedback and input from them, and of course thinking more high level in terms of managers and approvers, directors and sea level, and your board in terms of what high level insights they're looking for from all of your data. So, one of the things we've definitely found with customers is they might not think about these metrics when they're first looking for a technology solution.
They start to think about them, obviously once they've gone live and they've built a process, but by that point, it can be hard to make sure ... If you haven't been thinking about metrics beforehand, it can be hard to make sure that your process has actually been built to capture that data appropriately. So, by thinking about it from the very beginning, that can, one help you just stay focused on your target, but also two, make sure that you're building your program and your process and your technology in the way to actually support those metrics. Once you've actually gotten those metrics, I think the other big thing is in terms of communicating the results to those different audiences that we talked about, making sure that you are using those numbers and that data in a way that's going to engage and empower those users and those different stakeholders, especially at the end user level. By having them engaged in that conversation around success and objectives early on, you're going to get so much more buy in from them and really empower them to feel like they are impacting that process and driving change in a meaningful way.
And I think that's true both within your risk organization or compliance organization, but also across the business. So, any other stakeholders that you are asking for in terms of action or data that they're providing you, making them feel like they are a meaningful part of the process for sure.
KS: Great. When you talk about metrics at a high level, it's things like time spent, cost, right?
SL: Definitely.
KS: And also resources, like how many resources are involved in executing on this one thing? And what's the cost of those resources? I mean, these processes are involving high level resources, and when they're bogged down by this administrative work, it's really not a good use of that resources time.
SL: Definitely.
KS: So, those are some high level areas. Anything else that you would recommend they look at for a high level metric?
SL: Yeah, I think one thing I'd expand on with the example you just gave, which is a great example, is people will think about time savings as one of the metrics they want to capture, but oftentimes they might not think about it one step further, which is now that you've saved that time, what are those employees that are having that time saved, what are they able to do now with their extra time? And oftentimes you'll find that the efficiencies gained in maybe some of that administrative work they were doing previously, they are now able to spend on some much more valuable, meaningful work that's contributing to your business objectives overall. There are plenty of other things you can look at in terms of metrics. In the GRC space, obviously one of the things we look at is risk levels, and not only necessarily looking at how are we able to overall drive down this risk score for XYZ risk, but also being able to bubble that up to a more holistic perspective across your organization. And you could that down by departments, by geography, by products, by services. So, thinking about the different lenses from which you want to view all these data points is important as well.
KS: Yeah, that's interesting. I'm going to go off on a brief tangent, but just today I had a call with somebody who wants to implement the fair risk methodology, which actually quantifies risk and also quantifies the cost of mitigating that risk. And they ...
SL: Absolutely.
KS: Want to use that to actually go and lobby for budget for things, because they're able to say, "Hey, yeah, it's going to cost us this much to make a change to mitigate, but the risk potentially could cost this much," and kind of use that as a way for getting buy in on budget, which I thought was really interesting.
SL: Yes. I think that that is definitely a trend we're seeing as well, being able to use these metrics. Anytime you can put a dollar value on the table, that's going to be more impactful, right?
KS: Exactly.
SL: But yeah, being able to use the metrics to drive business making decisions and in cases like that, especially when you can put a dollar value on, here's the potential impact that this risk could have, but also when you've then tied to that risk to maybe high level business drivers that your company is working on, or high level objectives and they can see from that objective level, well this objective could be impacted by this risk and this risk has number of dollars associated with it in terms of impact. But then this objective could also be impacted by two other risks that also have dollar values associated with them. And then they can bring all of that together and see the total dollar value of impact that could potentially occur on that objective. And then compare that with the potential dollar value of mitigations you can put in place. I totally agree that, I mean that's so much more data in terms of being able to make smart business decisions on what risk are we going to accept versus what are we going to address proactively?
KS: Awesome. So, what trends are you seeing and what solutions are making the biggest impact?
SL: Sure. Right now in terms of what our customers are asking us most for, in terms of implementing their GRC solutions, I think there are, we kind of have our big three right now, which is enterprise risk management, of course. Third party risk is huge. A lot of people are looking at ways to get a better handle around the vendors and suppliers that they're working with and what type of risks they might be introducing to their ecosystem. And then the third one is controls management or controls assessments. Those are the top three use cases or modules that we're seeing are being asked for the most. And I would say also have the biggest impact. One thing to point out about those three use cases is all of them have tie ins across the board, across your GRC platform, right? So, from the enterprise risk management perspective, a lot of times those enterprise risks are tied to controls or policies.
And so having a platform where you can manage both your enterprise risk management solution and your policy and procedure management solution, and then tie those together and see the relationships between them, so critical. Same thing for third party risk. You'll often want to be able to see your third party risk assessments in the same solution where you're managing procurement and contracting of those vendors, and link those to IT risks or enterprise risks that you're tracking in your GRC program. So, definitely that points, I think too, another big trend to just overall, which is getting a place where you can centralize your data and get a holistic view into risk across your entire organization. In those three that we just mentioned, there are so many different teams across an organization that impact all of those different use cases, compliance teams, risk teams, IT security teams. There are so many people that work together to get that overall GRC program to run. And one of the biggest challenges that companies often face is they don't have a solution that allows those teams to really seamlessly work together and collaborate. So, one of the biggest things that technology solutions can bring is that centralized repository where teams can make decisions together and really see those relationships across their different business units.
KS: Yeah, I would agree with that. And I think that vendor risk management being one of the key areas that's a hot priority right now is it relates back to that, making the case for the dollar impact, because vendor management is enabling you to do business with other vendors, which is helping grow your business. So, I think that's indication as to why that's one of the hot areas.
SL: Definitely. Yeah. And in general, I think that whole concept of using risk to inform your business making decisions just ties into the overall trend of trying to be more proactive and strategic with the information we're getting from our risk programs and making sure that from the very beginning we are tying our risks to business strategies and objectives.
And when we do that, we are, as we alluded to earlier, able to make GRC something that is cared about at the board level and make it just a much more meaningful conversation topic.
KS: Yeah. Changing it from a dark rain cloud above your head to actually something that is meaningful and easier and exciting to discuss, because you're able to see ahead and take action and make a change that's positive for the business is key.
SL: Definitely.
KS: Yeah. Well thank you so much for joining me on this episode of GRC & Me. I hope to have you back, because there's so much more to discuss. I think we just scratched the surface. But implementation is definitely a major area of concern when clients are looking at these projects, and I'm really glad that you came on and kind of shared some of your techniques and advice for that process and I think it was really, really helpful.
SL: Well, very happy to be here. Thank you Kelley.
KS: Thank you.
