When GRC Stops Watching and Starts Working

Raj Krishnamurthy (00:00.758)
Hey, hey, hey, welcome to another episode of Security and GRC Decoded. I’m your favorite host, Raj Krishnamurthy. Today we have the awesome Ryan Schiller with us. Ryan has a very interesting experience. has almost 10 plus years of experience running IT risk management, consulting IT risk management, and he’s currently running GRC program at Tracer Data. Ryan, welcome to the show.

Ryan Schoeller (00:28.386)
Thanks, Rush. Excited to be here, excited to talk more about GRC security and everything that’s happening these days.

Raj Krishnamurthy (00:34.986)
Yes, let’s do. And let’s go straight to your heart take. What is this one controversial opinion heart take that you have in GRC,

Ryan Schoeller (00:44.216)
Yeah, sure. You know, I think the current topic that I’m pretty passionate about is hearing folks say that control owners are the individuals who should be entirely responsible for monitoring their controls. GRC should more or less kind of stay in their lane, stay in their world and not step over that boundary and spend so much time trying to be the,

The stakeholder that’s monitoring controls when in reality it should actually be the control owner. I think in reality the line is more blurred and truth be told I think that’s for the better. I don’t think we need to stay in this legacy world where there’s the three lines of defense and you know that first line is control owner only and GRC should stay second.

second line of defense, think in practice, it is much more blurred. And I don’t think that’s an issue.

Raj Krishnamurthy (01:49.986)
So what you’re saying is that GRC is not just a passive participant. GRC can be an active participant. That’s what I’m hearing you say. And given your experience, Ryan, you’ve worked with big companies, you’ve consulted with big companies, you’ve run sort GRC programs for small mid-market companies, right? What makes you say that? Why should GRC be an active participant?

Ryan Schoeller (01:58.818)
That’s right, that’s right, and should be, and should be, not just.

Ryan Schoeller (02:18.702)
I think about my time in the various different organizations and just the different sizes and maturity states they were in and which felt the most successful as it relates to GRC. When I think about the organizations that I worked in, mainly like the large enterprise and specifically I spent a lot of my career in the software industry. So when I worked in the larger organizations,

GRC was very much at an arms length relationship from a lot of teams, virtually all teams. And in that world, I think the value that they brought to the table was pretty limited. And truth be told, I think that’s where you saw the most amount of compliance theater. I think that the smaller organizations, the small startups that I’ve worked at and the current company that I’m at, where we’re kind of in the mid-market space.

That relationship, the lines between control owner who’s monitoring these controls, it’s a lot more blurred. And I actually think that’s where we see more value being brought to the table by GRC.

Raj Krishnamurthy (03:31.116)
God, and so when you say blood, what I want to be very clear, because for a minute I thought that you are almost creating a direct correlation. The more active GRC teams are, the less is the compliance theater is what I thought you were saying. Am I saying this right, am I wrong?

Ryan Schoeller (03:46.093)
Yeah, I would say so. You know, the best example that I use currently today is the whole user access review domain. So in our world today, we use identity access management and governance tool. And when most GRC teams think about user access reviews and specifically that domain and that control, they think about, let’s go pull a user report. Let’s go.

down through the list and see, you know, is Raj an active employee? Yes. Is the entitlement to the grant for XYZ system that he has access to appropriate? Cool. Yes. Check the box. Let’s move on. But where I’m talking about getting more involved specifically like in that domain, with the tool that we’re using, we actually are moving forward towards a world where we’re monitoring more so in real time. Like we can actually configure alerts where we know based on

you know, kind of role-based access matrix. We know Raj is in the following sort of department. Let’s just say IT and we know, you know, IT typically has these sorts of permissions, system admins for a variety of systems. And we can actually configure an alert that says if in an hour someone goes and provisions Raj access in a different way that we expected.

we’ll get a real time alert. And typically, I think most people think that is more of like a security operations team that would look at events like that. But in this case, I don’t think that’s the case. I think that the way that GRC could provide more value is it’s still just, it’s just an expansion of a user access review program. And, you know, I hear a lot of folks talk and say that, well,

that should be the control owner that does that monitoring. That should be security operations. They look at access alerts or risks related to access, but I don’t think that’s the case today. I think that GRC can really expand and provide more value in that line of is security operations the control owner and GRC is truly independent and just looking at the actual effectiveness of what security operations does. Is that the right way to go about it?

Ryan Schoeller (06:03.158)
I wouldn’t say so. think it’s all at the end of the day really about the value that GRC can bring and expanding that.

Raj Krishnamurthy (06:08.426)
I love it. I think that’s a very clear example. But what do auditors say to what you’re saying?

Ryan Schoeller (06:19.916)
The way that I like to think about my relationship with auditors is that they work for us, we don’t work for them. And what I mean by that is, I’m not trying to go down the path of like independence and that sort of thing, but I really think that the auditor, their role and their responsibility is to come in and test your control. Whatever your control is, the way you’ve designed it and implemented it, at the end of the day,

When I tell my auditor, here’s what the GRC team is doing as it relates to this user access review control, their job is to test that. Now, whether it’s the GRC team that’s actually in this case, reviewing that alert or security operations team, unless they can really point out some sort of segregation of duties issue where, because we’re reviewing that control or I’m sorry, we’re reviewing that alert, we’re blowing up some sort of huge independence risk.

I think at the end of the day, they should audit our control. We don’t operate in a world where we do things because the auditors, I’ll put it this way, audits don’t drive our GRC program. We drive our GRC program in a way where we’re trying to provide the most value, address risk, basically do everything that a good GRC team should do.

And when the auditor comes in, it’s just a byproduct of what we’re already doing.

Raj Krishnamurthy (07:52.579)
I love what you’re saying, Ryan. It looks like the degree or how much active should a GRC team be will fundamentally be a function of what is the purpose of the GRC team, right? Where does the GRC team gets its purpose? What I mean by that is what you’re talking about is a very operational compliance perspective, right? Which is the GRC team’s a very active role.

And like you rightly said, there are going to be other viewers on the other side or views on the other side as well, where they may argue the GRC team should take a passive role. Where does the GRC team gets its purpose? Is it from the leadership? And if so,

Ryan Schoeller (08:36.215)
I think it’s the leadership, but also, you if I were to zoom out and just think of what is the purpose of a GRC team? And again, I…

I latch onto that word value. What is the value GRC brings to the table? We’re here to help organizations, in my opinion, it’s two things, grow their revenue and protect the revenue. Growing the revenue can come through in a lot of different ways, right? Going to get an additional ISO certification, that’s going to be growing the revenue for the organization. Protecting the revenue, that if for…

continuing along the lines of talking about compliance activities. That is actually maintaining the controls, owning the actual audit program, making sure that when your auditors are coming through, you manage that, the audit, you work with the control owners, you ensure that you’re ready for the audit. Everything that goes into that, that is in that protecting revenue category.

And to me, I think a lot of times GRC teams, when they think about value and purpose, they just latch onto the compliance piece and they largely ignore some of the other things like risk. Risk.

Ryan Schoeller (09:57.165)
Honestly, it feels like the most ignored part of GRC, albeit I actually think it’s the most important. I think it’s the hardest and most complex, but it’s the most important and brings the most value to an organization. Truth be told.

Raj Krishnamurthy (10:13.015)
Got it. So I think, maybe let me take a very obvious question. So this is something that I ask all our guests. Can you break down G, R, and C in the priority of how you see it? I think you alluded to that to some extent, let’s break that down.

Ryan Schoeller (10:29.763)
Yeah. I start with the R. Second would be the C and then last comes the governance. And I think that’s also the order of how challenging they are. A lot of teams today, when I look at what they’re doing with risk management, it’s extremely basic fundamental. And it is, let’s be honest, it’s just checking a box, right? They might have a risk register.

that satisfies an auditor sometimes even satisfies a customer’s requirement, just seeing that you have a risk register, you log things somewhere. But I don’t think it’s actually being managed in a way that’s helping your organization understand the risks they’re taking on and also managing it. The, the fundamental thing that I always talk about when it comes to risk management is how GRC practitioners have a hard time understanding.

What is a risk versus what is a maybe gap weakness or a vulnerability? A lot of GRC practitioners, just think of risk as truth be told, they confuse the two. They might say lack of MFA on a system is a risk. And then they go throw that into the risk register. When truth be told at the end of the day, lack of MFA is a weakness. It’s a gap. It’s a vulnerability.

that may result in a risk. And that to me is that fundamental piece that a lot of GRC practitioners miss. And because of that, it turns out that the value they bring to the table when it comes to the R portion of GRC is just completely, it’s a flop. It’s theater again, to go back to that. Compliance and governance. think compliance is truth be told, the easiest part.

And technology is definitely helping to make that easier, right? All these tools that help with evidence collection, automation, monitoring the controls. The compliance piece is getting a lot easier. The last part, the governance piece, that piece, think a lot of times to me, it comes as a by-product of doing the other things right. And I don’t actually think a lot of GRC teams even get to the governance world. I think that they spend all of their time in comply, well,

Raj Krishnamurthy (12:53.026)
you

Ryan Schoeller (12:55.983)
about all maybe, but 90 % of their time playing in the compliance world, they’ll dabble a little bit in risk. And then governance is just this thing that is attached to their name, right? GRC, but they never really do it. But again, I think it’s a byproduct. So if you’re doing the other things right, the governance piece, albeit I put it last, it is still extremely important, more so in larger organizations where…

Having a proper governance program in place across many departments, many divisions becomes that important. In a smaller company, know, start up saying move so fast. Governance is really hard to put in place and is less of a priority because you’re really just dealing with problems in the moment, challenges in the moment, not.

spending time methodically building a governance program because you have maybe 10,000 plus people, departments in all different regions and global and so forth.

Raj Krishnamurthy (13:58.339)
Got it, got it. So the one way I think about this problem, Ryan, is that there is this classic principal agent problem, right? Principal has all the power. They have no information or less information. The agent has all the information, but they have no power. And the idea is to sort of reduce the gap, right, and bring them together as close as possible. The reason I say that is that R, C, and G, the way you put it,

are all operating should ideally operate on the same plane of data, right? The vulnerability or the gap that you said an MFA does not exist results in a risk, one or more risks potentially inside an attack, you know, could be a whole bunch of other things, right? And it should also result in how effectively you are governed and actively you’re governing it. My question is that why is this so complex, right? Why do you see typically

R, G, R, C, and G operating on the same data plane so that we are deriving the same data, looking at it differently? Or why is it more complex to do risk within companies? What is that reason?

Ryan Schoeller (15:09.647)
I don’t think a lot of GRC teams get access to the data or, or not, or, and even if they did have access to the data, I don’t think they know what to do with it. You know, in my world, the organization I work for, we get access to a lot of systems. And that’s one thing that, that I really love about this organization. We’re not handcuffed and kind of put in a corner, so to speak, where we cannot just literally go log into a system.

to look at something, to either learn or gather more context about it. So I think the hard part that most GRC teams deal with is getting data to help them actually improve. Let’s just take risk management for example. Risk management, it all hinges on having data that helps you continually improve the context of these risks. If you don’t have data, if you don’t have

Um, it doesn’t even need to be kind of a continuous stream of data, but if you don’t have information flowing in the risks that you are managing, they’re going to be exactly, they’re going to be so old that it’s going to make your risk management program again, kind of turn into theater, right? Like what’s the purpose of having a risk register, uh, that maybe let’s say talks about ransomware as a risk scenario, but that

Raj Krishnamurthy (16:20.759)
Go still.

Ryan Schoeller (16:38.583)
risk scenario, the actual scenario has not been updated in, I don’t know, 12 plus months. At that point, nobody’s actually gonna look at your, whatever the output is, they’re not gonna look at it because it’s so stale that they can’t actually use it to make decisions, which to me at the end of the day is really all about, is really what risk is about. It’s helping the organization understand.

potentially when you’re doing it in a proactive manner, what decisions to make. And when you’re doing it in a reactive manner, like a backwards looking risk management program, which a lot of GRC teams are doing, not having updated data is going to also make the actual management of that program less effective because the data is stale to your point. mean, that’s almost making it worthless.

Raj Krishnamurthy (17:34.947)
That’s a great point. And why do the GRC teams not have access to data?

Ryan Schoeller (17:44.911)
To me, when I think about this problem, I think it comes down to the people side of the GRC role. I think that GRC practitioners are a little bit weak when it comes to developing relationships with other stakeholders. It could be your engineering team. It could be your IT team. It could even be an HR or employee experience team. Like it doesn’t really matter.

Emphasis they put on developing those relationships, gaining the trust from those stakeholders is typically pretty low. I often challenge my team to go out and have more conversations with people that you work with. Don’t just wait until the audit comes around to go have your first or your one and only annual conversation with some control owner. If you want to gain access to your system,

they might be a little hesitant. They might need to feel like you understand them. You understand their role, their responsibility, what they do. And then as you continue to build that trust, you might get to a world where they will give you access to that system. I just think that the people side is so under, it’s just not emphasized enough as a key component of GRC. And then to take it even further,

I think a lot of GRC practitioners, they get comfortable, they get used to not having access, and then they get okay with it. And they are like, that’s how things are. It’s always been that way. And I’m so much against that. My idea, or not idea, but my mentality, which I think aligns with a lot of folks in the working world is how can we do things better? How can we make whatever it is we do more

effective, more efficient, and drive more value. And just showing up and just accepting that, well, we never used to have access to AWS. This is just how things are. I think you’ve got to put more stock in the people side of GRC and developing those relationships and understanding your audience if you want to actually get access to systems.

Raj Krishnamurthy (20:06.871)
Makes sense. And I think that’s a fantastic point, right? So I’m sitting in GRC. Ryan is in engineering. And I want to build a fantastic relationship and a trust relationship with Ryan so that I can go talk to him, not just at the time of audit, but on a much more continuous basis. Then the next question becomes that when I go ask Ryan for access to this data, Ryan is immediately going to ask me as the engineer, what value are you in turn going to provide me?

How do I respond to that as a GRC professional?

Ryan Schoeller (20:42.723)
would say that when it comes to that relationship, there’s, there’s given, you know, it’s give and take. the GRC practitioner yourself in this case, you do need to come back with a proper response or an idea of, Raj, I’m sorry. Okay, Ryan, you’ve given me access now. Now what is the, not necessarily favor, but how is this going to help me at the end of the day?

And you definitely should have an idea of like, for example, well, now that I have access to the system, here are the things that I will be able to go gather myself. And here are the ways that I’m going to not disrupt you as much, maybe during your upcoming sprint, right? Engineers, they’re very much head down, focused on, here’s what I have planned for my upcoming sprint.

And I want to be able to get into, get into that zone, get into the flow state and work on what I’ve been assigned from the PM or whoever it might be. And I don’t want to be disrupted. So when you’re having that conversation and you’re helping them think about, okay, if I give Ryan access, or in this case, if I give Raj access to the system, you should be thinking about as it relates to the upcoming workload, what are the things that you’re going to be able to tell them that they.

won’t have to do. be getting screenshots and I know screenshots is kind of a dying thing, but let’s be honest with ourselves, there’s still some auditors that love it. And I just went through an audit and we had to do some screenshots against my better judgment. It is what it is.

Raj Krishnamurthy (22:10.915)
Blower.

Raj Krishnamurthy (22:15.747)
Ha ha.

Raj Krishnamurthy (22:22.147)
Now, love it. And I think this ties back to your earlier point, right? How active do the GRC teams need to be? And this is the point you’re trying to make, right? Add value, right? That is the key focus here. And do everything that can add value. Now, I think GRC teams seems to have the most complex of all problems. And the reason I’m saying this, Ryan, is that you actually are trying to

process data across a whole bunch of different teams, different systems, different contexts. You’re talking to engineering teams about Git, you’re talking to security teams about Firewall, you’re talking to your platform, SRE teams about Kubernetes, and these are wide expanse of different knowledge systems. How do GRC teams cope up with it? One thing is to get access. The other thing is to make sense out of the access in the data that you get.

How much do you keep up and how do you keep up?

Ryan Schoeller (23:27.279)
Well, the first thing I would say is you do have to get comfortable with acknowledging you will never know possibly as much as that other control owner, because you’re exactly right. Right now, I might have to go have a conversation with an engineer, but tomorrow I have to go talk to maybe someone in a non-technical role in HR, for example, and understand their processes and their systems. And that’s going to take time away from me from understanding more about that engineer’s world.

So the first thing I would say is you do just have to get comfortable with that reality. So you’re not going to always have the same amount of knowledge as that SME. And so be comfortable with asking questions and be comfortable with admitting to that engineer that, hey, you know, I don’t exactly know what, you know, branch protection means.

I do think you should also lean into AI because now you can really get more context and, know, literally seconds. can ask, doesn’t matter what AI tool it is, whatever your preference is, you can ask questions that you would have asked that engineer on your own time and get good information back to, to, to further expand that knowledge. So first thing first, yeah, it would be that just literal acknowledgement of you’re not always going to have as much context, but you need to be.

comfortable asking those questions. And then the second part is, again, current state, lean into AI, lean into those tools to get more knowledge about what, in this case, maybe the engineer that you’re working with, what they’re doing, and if it’s evidence you’re getting from them for an audit, learning about the evidence. There’s a lot of things that you have at your hands today where…

You as a GRC practitioner should be taking that initiative to learn more and not just kind of throwing your hands up and saying.

Raj Krishnamurthy (25:20.899)
100%, 100%. And I think the knowledge systems are no longer siloed, right? And now, given the of the maturity of the learning models and the thinking models, the information is much more prevalent today. Most of us have access to most information, right? At least in general terms. When I spoke to you last time, Ryan, I know you’re a big proponent of GRC engineering. And you said something that I wanted to quote. You said, a little bit of GRC engineering should be with all of us.

Ryan Schoeller (25:37.401)
Certainly, certainly.

Raj Krishnamurthy (25:50.381)
Do you remember that? What did you mean by that and why did you say that?

Ryan Schoeller (25:51.67)
Mm-hmm. Mm-hmm.

Ryan Schoeller (25:56.665)
GRC engineering is a very hot topic right now. Part of me is a little bit sad that it took us to 2025 for it to become a hot topic. Like it is kind of crazy if you think about the fundamentals of what GRC engineering is and the fact that GRC is not exactly a new domain. And it’s only now that we’re actually talking about this whole concept. What I meant by that is that in most

organizations, your non-enterprise organizations, you’re not going to be able to have one role dedicated to a GRC engineer. And so when I think about GRC engineering, I think about not just the whole world of can this person, can this role be, know, an SME and writing Python scripts and, you know,

doing everything that maybe a security engineer would do when it comes to playing in AWS, I think about some of the other things, literally things as simple as automating some of your other GRC related workflows. So it also doesn’t need to be writing code. I’m a big proponent of using low code tools. We, in my current organization, we use a couple…

security automation tools that nowadays it’s not, you you’re not being asked to go write any code. You’re literally dragging and dropping things into a story or a workflow. And then yes, you will have to have an understanding of, how does an API work? You have to understand how to go read API docs. But at the end of the day, you can lean into these tools to…

automate a lot of stuff. And I think GRC practitioners really need to embrace the idea that they might not have the engineering title. They may never work in an organization where you have a GRC analyst, a specialist, and a GRC engineer that sits underneath, not literally org chart underneath, but kind of sits underneath and builds whatever the analyst or specialist needs. But

Ryan Schoeller (28:19.649)
Most organizations, it’ll be the analyst or specialist that actually does a little bit of engineering themselves. You know, JIRA, JIRA is a super popular tool. Everybody, a lot of organizations use it. And one of the great examples I use is JIRA automation. You can go use JIRA automation and build a ton of things. And again, you’re not writing code per se, but it can take a specific process.

from being super manual, super archaic, and time consuming to being even a little bit more efficient and also probably more effective. And at the end of the day, a lot of people I think look at that and they go, that’s not really engineering. You didn’t write code, you didn’t open up the terminal, you didn’t open up quad code or whatever it is. And they think that, okay, that…

that sort of task that’s not engineering. Let’s leave the engineering technical work for other folks. But I just don’t think we can operate in that world anymore. And the other thing I would say is with AI, there’s a lot of tasks that GRC practitioners when like in the analyst role and the specialist role that AI is gonna really help.

take those tasks from maybe a few hours down to half of that time, not even half, maybe a third or a quarter of that time. And that means that they’re gonna have to look to expand where they can bring value to the table. And that could just be building better processes and leaning into an engineering sort of mindset where

they can automate certain things. And again, I just think it’s a mindset thing for most GRC organizations. I’m not gonna sit here and say that there shouldn’t be a single company that has a single dedicated GRC engineer. I think those will exist and I think those organizations will be in a great spot, but.

Ryan Schoeller (30:39.861)
I really challenge a lot of GRC practitioners to think about themselves as maybe a third GRC engineer. Like a literal third of their work is gonna be GRC engineering.

Raj Krishnamurthy (30:51.575)
That’s what he meant by saying a little bit of GRC engineering should be with all of us.

Ryan Schoeller (30:55.555)
Yeah, that’s right. That’s right.

Raj Krishnamurthy (30:57.783)
Now, I think you bring up a very, very interesting point, Ryan, and I think there are two aspects to it. One is, how do you get started quickly, and how do you go demonstrate value as quickly as you can? And you don’t have to overthink, you don’t have to be overwhelmed, you can use some of these existing tools and you can start going into your point, right? You can use.

Cloud and ChatGPD and OpenMN, any of those providers and models that you can use to get ahead. Then the second part is that how do you sort of sustain and execute this at scale? So where you go from these two, three controls that you have to maybe the 10s and 20s of controls, and maybe sort of creating it at scale where you can go meet the rest of the organization in terms of collecting evidence, processing evidence, creating risk models, so on and so forth.

How does the transition happen from where you start, where you can sort of be super nimble, to where you want to be, which is much more a steady state, almost like a very disciplined approach on how you should think about GRC engineering? Do you think about it that way at all? Do you see that as a challenge, or how do you think, how do you feel about sort of getting this to what I would call a steady state?

Ryan Schoeller (32:19.343)
I think about it from a prioritization standpoint. And specifically, I think about it from the lens of outside of GRC. Where can we provide the most impact and value? So what I mean by that is, yeah, we can go down the path of automating evidence collection. I can take someone on my team and dedicate them to building processes to

gather evidence in a super efficient manner so that we’re quote unquote ready for our audits. But I don’t know if I would say that that is the most important piece right now. I think that there’s a lot of other initiatives happening in our organization and frankly in probably all software companies where it would be more impactful to the organization if you took

someone from your team and have them go work with maybe your GTM function to build more efficient processes. And I’ll explain what I mean by that. So in my current role of GRC, we are also responsible for the customer assurance, field assurance, the sales assurance side of the house, right? Being that representation of security that goes and talks to…

customers, prospects, existing customers, whatever it might be as they have questions about our organization or security program.

That is a huge, huge topic for our organization.

Ryan Schoeller (34:07.905)
It’s a priority in the way of, I take someone on my team and say, we need to build better and more efficient processes. Let’s literally think about how we can engineer a better workflow to serve our sales rep or customer support when they come in to ask us questions. And to me, a lot of people would think about,

Again, going back, like a lot of people would say, I think, you we should just talk about evidence collection and we should talk about building better automation for pulling in evidence and not think about automating how you’re going to serve a sales rep when they come in with an ad hoc inquiry about some sort of security control that they care about.

Raj Krishnamurthy (34:51.991)
I think you’re making a very, very interesting and profound point. I think what I’m hearing you say, and correct me if I’m wrong, what you’re saying is that there is evidence collection, controls testing, almost looks like the back end of the problem, right, which deals with compliance and audit. What you’re saying is that maybe there should be a more emphasis on front-ending the problem, right? How can we make better processes happen with sales and each of these functions, right? How do we do better security reviews?

How do we do better change management? Rather than taking that for granted and focusing on how to automate the existing process, keep an eye out in terms of how we can constantly tweak the process to your context and make them much better, is what I’m hearing you say. Frontend the problem as much as you can. Don’t try to solve this in the back end.

Ryan Schoeller (35:42.541)
Yeah, yeah, that’s right. That’s right.

Raj Krishnamurthy (35:44.205)
Beautifully said, beautifully said. Now, I think those are fantastic viewpoints, Ryan. And as a leader, one of the challenges that I think I hear constantly is that nobody says no to automation. I’m yet to come across who says no to automation, no to generative AI. Nobody says that. I think the biggest problem there is that how do they go build this business case and justify to bring the right skills to the team, whether you can borrow that as a social capital from other teams or you may build your own, right?

How do you go about building a business case as a leader, right? So that you can, you have the resources and the money and the time and all that, right? To go do this, what you’re talking about.

Ryan Schoeller (36:24.719)
Well, the number one thing I always tell people is to not build your entire business case on just telling your leadership we’re going to save time. And I will admit, I’ve been there. When I worked at a prior organization and I was first getting exposed to building business cases, one of the things that I thought my leadership wanted to hear is, hey, we would save a lot of time if we bought this product and brought it in.

and quickly learn the hard way that your response of saving time as a justification for buying something will immediately be met with, okay, and so what? What else does that mean to me? So I often talk with folks and I tell them when you’re building those business cases, you gotta think like two or three follow-up questions later.

Yes, the first thing you want to tell your leadership is that we’re going to save time. Okay. They’re going to ask, and what are we going to do with that time? And you should be prepared with the response of, okay, we’re going to save a lot of time. Let’s say I’m going to have someone who’s going to save, I don’t know, 80 hours, a quarter, whatever that metric might be. Here’s where we’re going to put that person’s time. That person, maybe you.

Raj Krishnamurthy (37:27.523)
Hmm.

Ryan Schoeller (37:46.915)
going back to your risk register, there’s some items on there that you haven’t been able to get to. And now you can go tell them, all right, remember those items that we said we are going to work on in, let’s say Q1? I’m going to take the time from that individual who couldn’t work on it now. And when we actually think about where that time is going to go, going to use their new freed up time on the following.

And the second piece to that is you, I know security and GRC teams really avoid the financial side of the house, but you really do have to be prepared with a ROI that talks about dollars. So, you know, again, the time that that person gets back, they’re going to be able to go spending on maybe burning down stuff on the risk register, but that will work.

for some folks as a good, legitimate justification for buying something. But then for other folks, it’s going to come down to, how is this going to actually impact the organization at a greater level? And that’s where I always come back to those two values of GRC or purposes of GRC. And that’s the growing and protecting revenue piece. So if you can actually tie your business case to, again,

Maybe there’s a growing revenue element or maybe there’s a protecting revenue element that speaks volumes to your senior and executive leadership. And again.

Ryan Schoeller (39:27.011)
Your justification might not work for everyone. So you have to also tailor that justification or that business case to the audience. When I write my business case and I go talk to my CISO, who I report to, it’s going to be a little bit different when I have to go talk to our COO or CFO. Like it’s just not, it’s not going to be the same. What one individual cares about is not going to be the same as the other.

So when you’re writing that business case, just, you really also have to think about that audience. Who, who are you going to go talk with or pitch to? And in some cases, you might have to have two business cases. Like, I don’t know. People don’t want to hear that. You might have to write, here’s my business case. Exactly. Exactly. And it’s, it’s, it’s, it’s about knowing who you’re talking to. And that again, comes back to that people, the people aspect that I talk about a lot when it comes to GRC is.

Raj Krishnamurthy (40:07.667)
Version 1 and version 2.

Ryan Schoeller (40:21.577)
Nothing is one size fits all. The business case for your CISO where you’re talking more about maybe the burning down risk piece, it’s not going to work when you go talk to your CFO. It’s just not. So I think GRC practitioners or whoever it is that’s looking to bring in tools for automation or whatever it might be growing that budget to help out with automation. You really have to lean into the fact that saving time is not going to be

like your golden ticket to getting that tool. It’s just not.

Raj Krishnamurthy (40:56.375)
think that is great advice, Ryan. That’s brilliant advice.

You work for technology companies, and I think GoSight, for example, you were reporting to the VP of Engineering. You’re running the security GRC program, reporting to the VP of Engineering. Interested Data is a technology, fantastic technology company as well, and you report to the CSO. But you’ve been with other companies in consulting, where you’ve been with bigger companies, right? And you’ve seen bigger companies as part of risk management consulting, right? With Crow and others. Is there a difference in terms of how you approach

the different industries and different companies. If I take the advice that you gave me earlier, what should I change if it were a bank versus a large manufacturing company versus a leading technology company?

Ryan Schoeller (41:48.245)
specifically to business cases or just GRC kind of in general.

Raj Krishnamurthy (41:52.725)
I would say two aspects of GRC engineering and building a business case to demonstrate, to justify GRC engineering.

Ryan Schoeller (42:01.593)
Yeah. So when it comes to the different organizations I’ve been in, when I think about the smaller organizations, my TEMEC Go site,

you’re moving so fast. And when it comes to the idea of applying GRC principles, truth be told, when I was at Go site, I was doing a little bit of literally everything. And I am very thankful about my time there because it taught me so much about other roles. It taught me about IT. It taught me about engineering. Like before I actually got to that company,

Admittedly so I was one of those GRC practitioners who had kind of like a one lens view of the world. GRC was, you know, the most important thing and how could people not understand why GRC is important and why do I get pushed back and things like that. And when I got to, to go site and I was literally doing things like rolling out Jamf after rolling out Jamf, rolling out CrowdStrike. Like.

I was a quasi IT admin and when I worked in an organization like that, realized how.

how difficult some of these things are. And when it comes to what is important to each organization, it’s extremely different. So going back to your question, like how would I think about bringing GRC engineering into a small company like that? I actually am not so sure I would say that it’s that important. When you’re in a small company that is 50, maybe 50 people in total.

Ryan Schoeller (43:50.763)
GRC, truth be told us, is really not a high priority. They’re thinking about surviving to the next day. They’re thinking about growth. Compliance is not really on the top of the list. And that’s fine. That is just the reality of how software companies grow. And I wouldn’t have even gone to that company and thought about saying, we need to really focus on GRC and these specific GRC engineering topics.

because it would have just fallen flat on our face. The VP of engineering, he would have said, I’m not really sure that’s important. Like we need to think about product development. We think we need to think about shipping the next feature set, our next release. How are you going to bring the IT and security, you know, the value that those organizations bring? How are you going to bring that to the table today? Going to your enterprises, I think that’s where you’re going to get more of a focus on

efficiency and when I think about

And I’m losing my train of thought on your question, Raj, to be honest.

Raj Krishnamurthy (45:01.955)
No, I think you answered. You are basically saying you’re trying to compare. If you want to take GRC, engineering as a discipline, and build a business case around it, different organizations have different capacities to take them. So your point is smaller companies, that’s not a priority. Bigger companies, may be a priority. So understand the company in the context and build a business case towards it. I think is what you’re saying. Correct?

Ryan Schoeller (45:22.477)
Yeah. And, and truth be told, in some cases, GRC engineering might not be important for most organizations. So I mentioned Go site. there’s going to be other organizations in the consulting world. I, I’m not sure it would even come up as, something that they even care about. Like that’s, that’s probably a reality there.

Raj Krishnamurthy (45:42.243)
That’s just okay. Got it.

Let me ask you a slightly different question. So when we think about R, C, and G, I want to take your order because that’s a very good order. We talk about NIST 853. We talk about PCI DSS. We talk about ISO 27001, 42,000, on and so forth. Why are we not talking about DORA metrics, like the DevOps metrics? Why are we not talking about MITRE, ATT &CK, or DEFEND?

Or am I wrong? Are there people talking about these things that I don’t know about? Because these things don’t seem to come under the purview of the GRC team. Why?

Ryan Schoeller (46:25.359)
I think it’s foreign to them. I think that those examples, the MITRE ATT framework, let’s use that one as an example. I’m gonna guess if you go up to five GRC practitioners and ask them, hey, what do you know about the MITRE ATT framework? How is it applied? How do security teams utilize the MITRE ATT framework? And I’m sad to admit this. I don’t think a lot of GRC practitioners will have a well thought out answer.

They may say, it’s just a framework that people use to help and kind of oversimplify and overgeneralize what it is. But I think it really just comes down to that simple idea of these are foreign topics to GRC. And that kind of comes back to that question of, or what you brought up earlier about how can GRC practitioners begin to…

build their knowledge set. I would say that whether it’s the MitreTech framework or it’s DevOps metrics, I think that when you talk about a new compliance regulation such as Dora, I think when you see those things, you have to go spend time and talk to those stakeholders to learn about those things. You have to go talk to maybe your SRE team.

or folks in the engineering team to understand about maybe the DevOps metrics. You have to go talk to your security ops team, your SOC or whoever it is that owns maybe the security monitoring side of the house and understand like what are they actually doing and how do they think about the MITRE ATT &CK framework? Because let’s be honest, they’re closer to those things.

So, you first step, yeah, you should go read about these things and get an understanding at a high level. But then you actually, gotta go talk to the folks that are closest to some of those examples that you cited. And at the end of the day, I think a lot of security operations team, for example, they’ll talk about the MITRE ATT framework and they’ll talk about how impactful it has been after…

Ryan Schoeller (48:38.159)
after the MITRE Tech framework came out, that they’ve been able to think about threats, know, attack tactics and techniques in a different way than they used to and how it’s helped them advance their program and again, just kind of evolve and innovate. But it just comes back to these topics are foreign and a lot of times also I…

It comes back to the very first thing we talked about about control owner, the three lines of defense. The GRC practitioner sits there and goes, that is that team’s responsibility. And we’re not talking about it because it’s actually over there. I will go talk to that team when I need to, but at the end of the day, minor tech framework is not my responsibility until maybe audit time comes around.

Raj Krishnamurthy (49:20.269)
Got it.

Raj Krishnamurthy (49:33.973)
And is it because that it is primarily driven through the compliance lens and am I too wrong if I say that the tail is backing the dog?

Ryan Schoeller (49:44.675)
think that’s spot on. I think that’s spot on. Again, to me, it’s who’s driving the car? Is it the audit and compliance requirements or is it risk? In most orgs, you’re going to see compliance and audit. And Dora also, feel, is, we’re still in the early days of Dora. I think that there’s a lot of…

Raj Krishnamurthy (49:53.59)
Zoro

Ryan Schoeller (50:14.575)
It’s still being fleshed out, truth be told. And I’ve worked with some of our customers who ask us questions about Dora and I’ve asked them what their interpretation of some of the requirements are. And they’re actually sitting there saying to us, I’m not really sure. I’m not sure how we will treat you. I’m not sure if you are going to be considered a critical service provider or not. So it’s still very early days, I would say, when it comes to that.

Raj Krishnamurthy (50:41.293)
This is the EU DORA you’re talking about, European Union.

Ryan Schoeller (50:44.036)
That’s right. That’s right.

Raj Krishnamurthy (50:46.477)
We are approaching the end of the segment, Ryan, for a person who is entering into the GRC field, right? And this person can be in audit, right? Or they may be fresh out of college. What is your advice in terms of how they should they think about entering into GRC? And what should they keep themselves with?

Ryan Schoeller (51:16.697)
Well, I would hope that they don’t think about GRC as just the audit function. That’s the first thing I would say. I think that the GRC engineering movement is great to help break that mindset. We’re going to lean into automation. We’re going to lean into being more technical. And let’s be honest, people, when they think about audit and compliance, they don’t think about those words.

So when I think about a young college graduate and they’re looking at job opportunities and they’re seeing GRC roles, I want them to think about the R side and I want them to think about the fact that it is getting more technical. And so what I would tell them is lean into learning about risk and furthermore, lean into learning more about

how companies think about risk. Because at the end of the day, that’s the most important piece. And even I would imagine if you talk to security professionals, they might even explain what they do in their day to day is help mitigate risk. They do it in a different way than GRC does, but at the end of the day, they’re trying to mitigate breaches from happening. They’re trying to mitigate incidents from happening. And so it all comes back to risk. would say read, read about risk.

FAIR is obviously a great resource. The Jack Jones book is a great resource to look at and join some of your, join some of the local chapters, get involved in that. That’s gonna be a way to actually learn beyond the book, right? Just the high level theory. And yeah, go from there.

Go from there. Just really think about GRC from more of a risk lens and think about GRC from an organizational point of view because in reality, it’s not black and white.

Raj Krishnamurthy (53:30.735)
And I just want to give a big shout out to, so we had Tony Martin Wake on our podcast a couple of weeks ago, and he made a fantastic presentation about risk management, particularly the risk levers, as he called it. He called about six risk levers. Some pretty insightful discussion in terms of how people should think about risk management. So I just want to do a shout out for Tony.

Ryan Schoeller (53:37.358)
Mm-hmm.

Ryan Schoeller (53:53.667)
Yeah. Yeah. Yeah. Tony’s great. Follow him on LinkedIn. He’s got so much useful risk related content. I would say like he’s helped me think about risk in a different way. And that is one of the things that I think more GRC practitioners, honestly, not just those thinking about going to GRC teams should focus on. It’s just having conversations with other GRC professionals.

reading content, listening to blogs, like get more involved in learning about GRC outside of your nine to five. Because it’s an opportunity, like when I read content on LinkedIn that Tony’s put out, it helps me when I come back to my day to day and think about certain challenges we’re facing that if I just sat here and stood at my desk and I don’t know thought.

thought to the end of the time, I might not actually figure out how to move forward.

Raj Krishnamurthy (54:57.763)
If people want to reach out to you, Ryan, talk to you more. What is the best way to do

Ryan Schoeller (55:05.739)
LinkedIn is the best place I would say for sure. Check out my LinkedIn and if you have questions, if you want to learn from my experience at either level from the audit days that I still enjoy talking about and sharing horror stories about to today and the various software companies I’ve worked at, just reach out on LinkedIn. I’m very much willing to have conversations with people, even if it’s folks outside of GRC that…

want to learn more, and potentially even break into GRC.

Raj Krishnamurthy (55:41.315)
Okay, that was a pretty insightful conversation, Ryan. Thank you for joining us on the show. Thanks a ton.

Ryan Schoeller (55:48.227)
Yeah, thanks, Raj. I appreciate it.