Does GRC Belongs Outside Security? The Case for an Independent Second Line ft Charles Nwatu - GRC Engineering Leader

What if GRC shouldn’t sit inside Security at all—and what if the bigger problem isn’t automation, but what you do after you automate? In this episode, Raj Krishnamurthy sits down with Charles Nwatu (former Security GRC Engineering & Assurance leader at Netflix) for a candid, systems-level conversation about why “annual audit rituals” fail modern engineering, how GRC can produce high-fidelity signals that strengthen security decision-making, and why the next wave of GRC engineering is about analytics, specifications, and business impact—not just speeding up evidence collection.

Key Takeaways:

• GRC is a continuous discipline—point-in-time compliance can help, but it can’t be the end state.
• Automation is necessary but not sufficient: the real value is in turning collected evidence into actionable insights.
• Specifications enable measurement—without clear expected behaviors, security metrics become inconsistent and hard to compare.
• GRC can feed security with high-fidelity signals (like identity/access review metadata) that improve posture beyond audit readiness.
• Third-party risk doesn’t “finish”—the goal is visibility, data lineage awareness, and making the mess less messy. 
  
  

What You’ll Learn:

• Where Charles believes GRC should sit org-wise—and why Security should be a “customer” of GRC
• What “shift-left GRC” looks like in practice (beyond annual audits)
• Why “efficiency savings” don’t automatically equal “security value”
• How to think about metrics, specifications, and risk in a shared language
• Why third-party risk management is “unsolvable,” and how to build guardrails anyway

This podcast is brought to you by ComplianceCow — the smarter way to manage compliance. Automate evidence collection, eliminate screenshots, and scale your program with confidence.

Learn more: https://www.compliancecow.com

Watch more episodes: https://www.compliancecow.com/podcast

Connect With Our Guest:
Charles Nwatu | GRC Engineering Leader
Connect on LinkedIn: https://www.linkedin.com/in/cnwatu/

Rate, review, and share if you enjoyed the show!

Subscribe to Security & GRC Decoded wherever you get your podcasts:

Spotify: https://open.spotify.com/show/5pigcMwOrYIA6d9OOOsxqr?si=416b82ab5c474683

Apple Podcasts: https://podcasts.apple.com/us/podcast/security-grc-decoded/id1795144450

Transcript

Raj Krishnamurthy (00:01.017)
Welcome to another episode of Security and GRC Decoded. I'm your favorite host, Raj Krishnamurthy. Today we have the awesome, awesome Charles Noto with us. Charles Noto has more than 20 plus years of experience in running security and GRC teams. He started as a programmer and I had some illustrious career companies like Macafé, LinkedIn, and recently at Netflix where we ran security GRC engineering and assurance.

Charles, welcome to the show.

Charles (00:33.23)
Thank you, Raj, for having me. Glad to be here first time on here with you today.

Raj Krishnamurthy (00:37.465)
Charles, wanted to maybe let's go straight into the topic. What is your heart take? You've been there, done that, you've run the GRC teams, you've been in security engineering. What is one heart take in security or GRC that you

Charles (00:52.744)
the hot tech that I like to put on the table is that I don't believe that GRC should be inside the security function. I, my perspective is that if GRC operates as a truly, and I'll use some governance language here, a second line function that security is actually a customer of GRC and how do GRC teams get better at sharing the data and insights to

improve their decision making for their customers like security, privacy, and things of that nature. So that's my hot take, whether or not it will stick on, but I think it's an interesting conversation to have around GRC and the larger enterprise risk management with regards to security.

Raj Krishnamurthy (01:39.139)
So what you're basically saying is, in some companies, especially in large established banks, GRC is its own independent function. And then in addition to that, they have GRC being done as part of the cybersecurity teams as well. And your point is, we should take it away from the cybersecurity teams, make it part of this bigger umbrella called GRC. That's what you're saying. OK.

Charles (02:02.264)
Correct. And my other hot take would be GRC to me is continuous activities. there's, and you and I have talked about this before, it's like GRC plus assurance. It's the evidence provided that allows a company to be confident in the investments that are happening in the security program or the engineering investments that are happening on your privacy and compliance side. How do you actually take that to help?

drive business decisions or demonstrate business impact in the larger company.

Raj Krishnamurthy (02:34.104)
And I think the central thesis, I understand right, Charles, on why you're saying this, is that you're saying that GRC, number one, is an independent function. And let's make sure that it is. That's point number one. Point number two of what I'm hearing you say is that it's not just a technical or a technology function. It's about how do we effectively make business decisions. So allow it to be. Is that correct?

Charles (02:46.626)
Yes.

Charles (02:58.636)
You nailed it, Raj. That's correct.

Raj Krishnamurthy (02:59.83)
Okay, my question then is that I think this is a common back and forth that we keep going on, right, which is, let me get to that question, is how technical do cybersecurity GRC teams have to be?

Charles (03:15.586)
Good question. They need to be more technical than what they are now. And as you're fully aware with what ComplianceCal is doing, there are a lot of GRC teams that are building engineering functions. the whole GRC engineering push over the last couple of years, it's interesting to see the transition of folks being open to, well, how do I not just automate the work that I'm doing,

But how do I take the data that comes out of this automated work or leveraging technologies like AI to help improve decision-making decisions that are being made by my security practitioners or my privacy practitioners or my compliance practitioners? That's the next step in that evolution in terms of like how technical it has to be. Well, technical enough to be able to be able to get an API call and pull data and run local data yourself.

able to use some type of pandas data frame and know how to slice and dice data. I think there's elements to that that can be very beneficial for GRC teams to be able to have versus relying on potentially your security engineering team broader or maybe your data engineering or data platform team.

Raj Krishnamurthy (04:31.49)
The one challenge that I, and I can be wrong on this Charles, but the one challenge I see, whenever I see a GRC team as part of, let's say, a separate office, sometimes you see them in legal, sometimes you see them in this risk, wherever they are, they tend to be absolutely less technical than what you just said, right? So is there an inherent conflict between what you want it to be versus what it may become?

Charles (04:49.998)
Mm-hmm.

Raj Krishnamurthy (05:00.544)
if you move them to different sort of arc.

Charles (05:06.444)
I don't believe that the placement of the team should impact their ability to be technical or not. Part of that is, does the team have the access to the data to actually do what they need to do? And part of this is also the mindset shift, like with the GRC engineering work that you're seeing, it's not just, you know, we want to be audit driven or compliance driven or task driven to do this type of work as well. How do we start building systems? How do we start building services? How do we start building platforms?

that enable us to do our job. So I think that's why part of it is co-located in terms of it being within like the same team, housed within the same team. Whether that's like, I don't believe it should sit under legal, but you know, I think what makes sense for that particular business, I think is what is appropriate. But I do think there's a level of technical capability that is needed in GRC engineering teams and GRC practitioners to take GRC to the next level.

And I've said this before, I think the DevOps experience that security underwent sort of left GRC behind. And so how do you then bring that DevOps experience to the GRC domain and pull that, you want to call it shift left concepts to this particular area?

Raj Krishnamurthy (06:23.875)
want to come back to that. I think it's a very interesting point, Charles. I want to double click on that. But before I do that, want to, looking at your experience, you ran security into some extent sort of compliance engineering at LinkedIn, Twilio, SwitchFix, and then at Netflix recently. Is there a common theme of what you're, and all these are technology companies. Is there a common theme of how,

Charles (06:30.147)
Mm-hmm.

Charles (06:43.202)
Yes.

Raj Krishnamurthy (06:49.539)
Technology companies approach GRC versus others in your opinion?

Charles (06:55.97)
So if you have like a sliding scale, it's already challenging enough if you're an engineering dominate organizations to be a security team. Cause then, you you hear the ratio about how many security practitioners to engineers. But then if you think about like from a compliance standpoint, if you're asking folks to do some form of governance risk compliance and assurance activities on top of security, you're almost even left behind on that. Unless you have mandated things around like maybe your PCI, your SOXI.

your standard playbooks that you see everyone talking about that I can get this within two days or two hours. That's probably the driving factor where before is how do you think about the relationship of your governance activities with your engineering principles? Like is there an alignment there in terms of like the rules or the unwritten rules about how we operate as a business and how do we enable the rest of the business to understand that to make those decisions easier to perform?

Raj Krishnamurthy (07:51.524)
Okay, got it. And what do you think is the general view of leadership within these companies when they think about GRC?

Charles (08:04.62)
Unfortunately, I think it's dependent on the field for that business. Like I have a sentiment that the folks that have talked to some of the financial sectors, like there's a big tie to how do we think about the governance and risk and the security of the work that we do because of the sheer type of data that we're processing versus healthcare or medical tech. In some industries, it's, you we need to do enough to get enough done. And that might be the appropriate investment, but how do we do that in a way that enables, like I said,

business decisions, whether it be on the compliance side, the risk decision making side, or the governance side. Cause at the end of the day, whether you're in a big FinTech or a small startup, like your goal is to have some level of assurance and trust. Whether your competitors are looking at you and determining whether or not, like are you a trustworthy platform? Or actually do you have a secure platform? And so I think as a customer to these platforms, you're going to be asking, well, like, do you protect my data in a particular way?

Like you're trying to build that continuity so that people's like, yeah, we like to use your platform because we have like this understanding, this assurance, this trust that you're going to do what you're going to do about the product of the platform.

Raj Krishnamurthy (09:15.361)
Okay, I think even though, I think everybody understands that G, governance, R, risk, and C, compliance, I think everybody gets that, But what we generally see when we see in the world of GRC is much more an annual audit ritual cycle. That's what we typically see, right? But you said something very interesting. You said that you talked about GRC shifting left, meaning what sort of integrating getting closer and closer to DevOps.

Charles (09:34.126)
Correct.

Raj Krishnamurthy (09:45.265)
Why? How would that solve? Number one, what is your take on this annual audit ritual problem? And how does that fit into sort of your perspective that GRC should shift left?

Charles (09:58.968)
I mean, to the point that the word annual in its pure definition is once a year. And if we're trying to demonstrate a level of confidence and assurance in the platforms and services that we build, wouldn't you want to have better instrumentation and better observability into the workflows that exist? Would you like to have clarity around the principles and rules that exist on how we engineer?

Raj Krishnamurthy (10:05.262)
Yeah.

Charles (10:27.982)
and design things, something that is very unique that I don't hear too often in security and GRC is like, how do we build to specifications? Like what are the specifications that we actually test when it comes to authentication mechanisms? And do we do that in a way that makes it easier to provide those findings to another company? like, yes, you can trust us, which is a more of a subjective feeling, but here's the assurance.

through the types of test cases we run and the specification that we either have developed or extended about our identity. So to me, that goes back into like the governance work and how do you shift that into a more programmatic, pragmatic approach. So like you said, like annual, like I don't wanna know that my tires are safe one time a year. Like there's a reason why we have tire pressure monitoring.

Like it's constantly making sure that you have the proper pressure in your tires when you're on the road. I wanna make, like as a company, I wanna make sure that we're doing well within our security program constantly. And what does that look like? What are the data points we need to collect, et cetera?

Raj Krishnamurthy (11:36.218)
And when you put it like that, right, I don't know how anybody can argue against it, but the reality is that most of what we do in the industry is not as continuous as what you want it to be, right? I today it is still extremely discreet, and the frequency is very, very sparse. So where is the gap here? You're making a very common-sensical logical argument.

But what we are seeing in the field is still the difficulty to get to move towards that. Why is that?

Charles (12:14.904)
So there's the idea of like the value proposition of the work and where does it show up and what is the value of doing that type of activity. You and I have discussed this before, like even point in time assessments have value. They have value at that point in time. Continuous, which is no day to day, whether no second by second, like maybe there's a sliding scale here and I do believe there's a sliding scale.

Can we pose the question, can I at least be better than point in time? Can I batch my work where I can do it weekly? Can I batch it where I could do it monthly? Do I have to have a day to day? Maybe there's industries where it makes sense to have that assurance on a day to day basis, or you have the opportunity to do that. In some cases, maybe point in time is correct. But I believe it's a little bit more than just point in time. And so to your point about like what we're seeing in the field, well,

I don't believe there's been, I'm unaware of, is there been pushes to sort of like, what does continuous look like? What is the investment of continuous? Because if you look at like, know, continuous CI, CD, like there had to been a push to get to that point. You don't say move fast and break things without trying to move fast and break things. So you actually had to build to get to that point. Same with GRC. Until we actually try to move fast and break things in that concept, what does that look like for our profession?

I'm going to go on a limb and say it's more than point in time. What that looks like, I don't know the variance yet because I like that's the, I think the stage of the development we're in that I see on LinkedIn and on talking to other professionals like yourself, like where are we trying to get to?

Raj Krishnamurthy (13:54.85)
And Charles, should have said this in the introduction. You are one of the founders of the GRC engineering movement, right? It's a very, very pretty awesome folks. And some of them have been on this podcast as well. Why did you start? What was your incentive or motivation to be part of that and to start it?

Charles (14:13.422)
Um, you know, there's many players in this space. Uh, and for me personally, um, when I was asked to sort of take over the GRC work, um, while at Netflix, you know, I, I, I paused and said, because, you know, there's this perception, good, bad, or indifferent that, you know, GRC folks are non-technical. We led part of this conversation, even talking about that. And when I sat down and really started to explore the idea of governance of risk.

of compliance and this idea of assurance, I walked away and said, there's actually some really great information here. There's actually great data and metadata about the work that the rest of our security partners are doing. How do we extract this in a way that is more than just a point in time assessment or compliance activity tied to a PCI or an ISO or a SOC? Like there's really great insights that as a security leader, I would want to know about the state of my

security program and its investments. And so that sort of got me thinking from like from as a security leader and as an engineering leader, what would I need to see? What are the questions that are missing that we don't ask our GRC practitioners to provide beyond are we PCI compliant this year? Or what are user access reviews looking like? So those questions sort of spurred in me like this idea like, there's got to be a better way. And my pain point

quite honestly, was user access reviews. Like when I saw this process and screenshots and JIRA tickets, like I had like a visceral reaction, like why? Like why are we doing it this way? How are we doing this way? Is there anything better that we can do than this way? There has to be. So that's where the sort of the genesis for my like spirit came from. They said like, okay, there's gotta be something else.

Raj Krishnamurthy (16:03.545)
No, I think we can all agree to that. In 2025, we are doing screenshots. It doesn't bode well. But the one thing I want to ask you is that how do you, as a leader, you've built these GRC engineering teams, you've built these security engineering teams, how do you demonstrate the value to the leadership in terms of how they should make investments in this space? And how do you sort of communicate this to them?

Charles (16:33.198)
This is part of the tricky area because I think part of this is how do you talk about risk? And even in that space with all the work that's going on with the cyber risk quantification and I will say more openly, like the decision science around decision making, I believe is what makes GRC, I think unique in this aspect. How do you bring your governance, which you can know maybe you identify as your rules or your unwritten rules within the business.

along with how you talk about risk and the impact to the business operations of risk. And then what are the things that you're being held compliant for, whether it be from obligation or self-imposed. So how do you bring all those things together in a way that as a leader that I can say, what are my KPI metrics or whatever measurements you're looking for? And I'll admit that it can be challenging because most of the times you look at GUC as an activity.

We successfully got our PCI check. Like there's a tangible outcome, but sometimes we don't understand, well, how do I use our user access review process to understand our onboarding and offboarding of accounts within our systems? As a leader, what are the metadata? Like how many users have that access? Should they have that access when we think about like our role-based and zero trust type of strategy? Like, so there's elements of that data that can be used as a security leader to inform other.

parts of your security dashboard or your security insights. How are we, once again, not just taking the action and activity, but using the data to inform security.

Raj Krishnamurthy (18:10.873)
I love it. I love it. So what you're basically saying is that security needs a whole bunch of signals, right? And GRC can produce an enriched set of signals. In some cases, I can claim that nobody else other can. I think that's what you're saying. So these are very high fidelity signals that can go from the GRC team back into security for a better security posture.

Charles (18:34.99)
Correct. It's the feedback loop. It wasn't going back to the technical aspect of the conversation.

Raj Krishnamurthy (18:36.377)
That's a feedback note.

Charles (18:46.19)
GRC practitioners have to be able to extract the metadata of the services that are around them without potentially having the need to lean into those individuals that are owning those systems. Now, I understand scale and size of your GRC team will always play a role, but I think if you have the right GRC archetype, they can do that on behalf of a larger organization or on behalf of the GRC team. So when you start pulling in the data,

then there's the analysis of that data to then either drive your governance, to drive your risk understanding, to drive your compliance understanding. And most of the times you hear, Jersey talked about more of a reactive nature. And one of the elements I've been trying to push, well, how do you talk about it as an opportunistic way? Can we talk about our governance in a way that when we onboard a potential &A that we have confidence that our rules and understandings of how we do our cloud infrastructure.

makes it a better bet for us to do that because we can go do not just, we can do a point in time assessment that will lead to a continuous assessment of this new entity coming into our environment. And we can overlay our governance. We can extract our risk. We can figure out what are the things we need to be held in compliance with through our engineering efforts we've made in GRC. That's opportunistic. That's not reactive. It can be part of like the &A approach.

Raj Krishnamurthy (20:10.413)
And when you think about GRC, Charles, do you make a distinction between the product lifecycle and the IT security lifecycle?

Charles (20:23.505)
Sorry, say thank you, Marash.

Raj Krishnamurthy (20:24.163)
Do you make a distinction between the product lifecycle? What I mean by that is how products are developed, delivered, deployed, especially as a continuous process, that the product teams and the application engineers do, versus back office security, your SaaS applications, your back office applications. Do you make a distinction in terms of how you approach from a GRC perspective?

Charles (20:46.136)
think there might be subtle nuances because it depends on the audience that you're serving. Like my experience has been with on the product side, you're going to have either product managers, you're going to have engineering leaders that are going to have particular cadences that they're going to be engaging in. On the backside of the house, you're more serving the larger business. So there's probably security services or data instrumentation that you would do differently because of the audience that you're serving. So think there's nuances there.

But it's probably an area that I would dig a little bit deeper into to figure out more.

Raj Krishnamurthy (21:19.341)
When you talk about GRC engineering, where should GRC engineers sit?

Charles (21:25.772)
Ooh, that's a good question.

I envision a world where they're just part of your security team. Like the elements of GRC engineering in terms of your heavy cloud infrastructure team, like it's built into what a cloud engineer does. It's another attribute. So maybe there's two ways to look at this. You can have GRC practitioners that potentially may want to graduate into maybe doing cloud, or they may want to stay using their technical skills to do.

the GRC assessments of cloud. think very nuanced there are no one being semantics on the language, where they sit, I'm not sure. I don't know if I have a preference either way about where they sit. I think it's more about the impact and business impact that they do with their work right now.

Raj Krishnamurthy (22:18.073)
Okay, so, but I think when you started, your position was that GRC should be outside of cyber security, but do you expect the GRC engineering to be part of the GRC team, or should they be outside of the GRC team?

Charles (22:25.368)
Correct.

Charles (22:32.237)
So I think this comes to a point like, does GRC engineering still become a thing where the practitioners are just engineers that have GRC attributes? that's what it to me, it's like semantics. Like in the long run, there, I think there's a place where the GRC practitioners, when they sit outside, are more about the aggregation of all the data points. They do all the analytical thinking of all the data points that are being collected or performed by like a security function or GRC function.

Raj Krishnamurthy (22:35.555)
Mmm.

Charles (23:01.08)
Like there's this distinction and separation like it's a second line, whether they sit in a security org, like my preference is outside, but I was like more of like a, like my long-term vision of like, would be what Charles would want to do. But if they sit within a security org, like I see these folks playing very close with, no, how do you do this within our AWS or GCP or Azure? How do we do this on our application security side in our CICD world? Like I envisioned those.

teams getting closer, and I always forget to say this to privacy folks, there's a lot of data protection work that highly aligns with GRC practitioners and how do you bring those worlds together. So to me, I understand why they sit within security, but I think there's an analytical part that sits outside of your traditional security engineering team.

Raj Krishnamurthy (23:50.392)
And I want to double click on that a little bit, Charles, which is what differentiates a GRC engineer from a security engineer or an application engineer or a platform engineer?

Charles (24:02.274)
In my mind, I don't think there is none. I think part of this right now is just the distinction that GRC can be engineering. Like just to say that. Correct. But the practitioners at the end of the day, what makes a cloud infrastructure person not understand how to think about the GRC requirements and controls? So to me, there's like a learning.

Raj Krishnamurthy (24:11.555)
Beautiful. The discipline, it's an engineering discipline.

Charles (24:31.554)
like a cross learning that takes place. And I hopefully would love to see these skillsets more ubiquitous across security practitioners to some degree. Like if we make it more accessible now, may not work. That's like my bet. You know, if not, then we'll always have a place as GRC engineers to sort of build that, platforms, those services for the rest of a security organization or an engineering organization or a larger business.

So in my world of worlds, I would say they should be ubiquitous. There should be no distinction. But we know in terms of the market, GRC engineer is perceived differently than an AppSec engineer, which is perceived differently than a cloud infrastructure engineer.

Raj Krishnamurthy (25:13.581)
and by perceive differently what do mean?

Charles (25:16.652)
I would say that the skill sets that are required, I would say the comp sometimes that goes into those roles. would just, know, straight shooter say it like that because it's to an earlier point of the questions you made, like how does GRC viewed by the organization? Well, if they're viewed purely as point in time assessors, like the value doesn't show up right away in terms of like, we got you your SOC, we got you your ISO, we enabled business because we got the certification game. So I think there's a lot of...

Raj Krishnamurthy (25:18.392)
Okay.

Charles (25:44.312)
whether it be perception or a lot of like the value that needs to come into a way where it's very clear when you say AppSec. It's very clear when you say product security. It's very clear when you say cloud infrastructure. You get that from your traditional engineering infrastructure organization. But when you start saying like GRC, you're like, huh? Like, where do you all show up in this? you're the audit folks we see once a year. You guys make my lives like challenging because you're telling me to fetch this information and everything else.

Well, let's flip it. Let's build infrastructure that you tell us where your data is and how it's organized, how it's structured, where we can go pull it, structure it, and format it for consumption by the people that we need to serve.

Raj Krishnamurthy (26:26.213)
beautifully said Charles, brilliantly said. Now as a leader and you build these GRC teams, what challenges have you had in really building them up?

Charles (26:38.134)
One of them said like buy-in from your other peers and leaders. I had the ability to work with some great leaders that were open to like the risk conversation and how do you do the cyber risk quantification work that allowed for GRC to sort of step into a place to say, hey, like these are the controls that have value. We can.

measure this value by the control work that's happening in AppSec. Like the push for MFA, MFA is a control. We're doing it for a reason. Well, how does that impact show up? How does that impact show up in terms of our incident response team not having to take incidents that are dealt with identity related challenges because we're doing some form of multifactor work? Like there's a tie in there where making that picture clearer for leaders.

makes the buy-in easier. But the psychological hurdle sometimes of talking about risk, risk appetite, like risk management, all those risk related words can be challenging. And sometimes that relegates you to, all right, so what are the compliance hammers that I can throw out at folks? You have to do this because of X. Like you have to create this separate environment because of Y. Like how do we...

where appropriate move away from that type of language and saying, hey, we're incorporating this because it enables us to demonstrate this control, which may help us address this class of attack from an AppSec perspective or cloud perspective. And we're going to monitor that through our GRC function.

Raj Krishnamurthy (28:18.233)
When we spoke last Charles, you said that efficiency gain is necessary but not sufficient. Do you remember that?

Charles (28:29.422)
Sorry, say that one more time.

Raj Krishnamurthy (28:29.763)
You said efficiency gain is necessary but not sufficient. Why did he say that?

Charles (28:34.434)
Yes.

Charles (28:38.094)
You know, this is just me being, just observing, like I said earlier, like there's a lot of great work that I see on the GRC engineering space and the tools that are being created. And in particular, I was thinking about third party risk management, about how do we do that at scale? And this idea of automation, just because we can automate like the intake doesn't necessarily mean we are creating like the value and impact.

I was reading up on this concept of the theory of constraints. because we can do more, intake more, doesn't mean we can process more because that process is a separate set of characteristics or individuals or services. And I'm mindful that as while GRC engineers and practitioners are talking about, hey, I can be more efficient with my audits. Well, that's not the end of the story.

If you're efficient with your audience and you can do more of your audits across different infrastructure types and data types, and maybe you're including more now privacy and more data protection. Well, what are you doing with that insight now? Like you now have a trove of information. So how are we now compiling this and analyzing this to either help inform, Hey, security leaders, this is what the investment on our apps sec team has yielded us.

Hey, Cloud Infrastructure, great job on X because it's yielded us some returns here that we're seeing. How do we start changing, once again, the language of the output of the work that GRC practitioners do from a task base to more of an analytical, how do we provide insights to the work that our peers are doing?

Raj Krishnamurthy (30:26.649)
I think that's brilliantly said. think the Mosey Platt, who you very well know, I think said this brilliantly. I mean, he actually said something very similar to what you said, which is that I think there is productivity savings and there is value. And the argument he was making is very, very similar to what he was saying, which is if it takes me 100 hours to take screenshots, I can save, I can do some automation, and I can maybe make this in 40 hours. And that's great. The question is,

Charles (30:53.993)
Yes.

Raj Krishnamurthy (30:55.779)
am I going to do, what am I going to do with the 60 hours? And more importantly, is by doing screenshots, does it push me further into the next level of maturity? Or should we fundamentally think about how we collect these evidences and process these evidences? Which is exactly the point you're making. That's brilliantly said.

Charles (31:14.446)
And I'll even expand and I love talking to Mozi about this. Even with the 60 hours net difference, does that enable that individual to go do something different? Or even with the screenshots they're taking, if it still goes back to the team, even gaining those 60 hours, if that individual still has to go back to the same team, was there truly a net value there?

versus I just condensed and sped up the front loading of the work, but the processing, like I talked about, that the constraint still exists within that team AI driven or not.

Raj Krishnamurthy (31:54.522)
Totally, totally. Brilliantly said Charles. Charles, what do you think is the current state of GRC?

Charles (32:04.206)
think everyone's trying to find their place. The marketplace, there are many tools out there that are trying to solve, think, the first step of the problem, which is the automation. I think there are some platforms that are moving into the workflow elements of how do we make it easier to move data. I can't remember who I was talking to, but I made an analogy. Back in the day when SOAR for the detection and response.

domain came into being. Some of the same principles you could apply to GRC, like something either happened, I need to go collect something, can you come pull it back? Can you analyze it? Tell me what it is, store it. A lot of these functions in a weird way are very similar from a process mechanism. I think companies are trying to figure out how do we leverage these informations once again to provide some value beyond that.

we can automate and get your SOC 2 in X. You put whatever time you want after that. So I think that the industry right now, there's a lot of innovation going, but I don't think there's a market leader in terms of like, what's next? I think there's a lot of people, a lot of companies building like the automation workflows, but where's the analytical part that comes with the collection of that data set?

Raj Krishnamurthy (33:24.089)
Got it. And I think you beautifully said, I think you're basically taking two parts, right? One is the security orchestration automation and response. So if there was something like that for GRC, maybe we should call it GORE. You should create your own Gartner quadrant or something, Charles. And then the second part is that, that is about taking data, processing data, but where are the insights? And how do you sort of provide the analytics? I think you're saying that it is still evolving, I think, in this market.

Charles (33:53.518)
Yes, and I think that's why you can still have GRC Teams function that sound like a spreadsheet is still powerful to me because I can still control the efficiency, the impact, the correlation, the metrics, the analysis with a highly fine-tuned dashboard. And that's why said in some cases, that is warranted. So that's why I said for GRC, the scale is a little bit different because depending on your size and what you need,

You could be as powerful by using a spreadsheet all the way to a full orchestration platform. You just have to figure out what problem you're solving.

Raj Krishnamurthy (34:29.241)
100%, beautifully said. I think you look at the functional value, right? But the one question I want to ask you is that for the last 25 years, GRC platforms have sold on the single premise that you don't have to use your spreadsheets anymore, right?

And do you think that, but unfortunately, the challenge is also that they don't go deeper in terms of some of the engineering aspects of what you're talking about. Do you see that as a challenge? And do you see the consumption of data for GRC changing from user interface, the traditional user interfaces, to something else, especially in the chat, GPD, and the cloud world, do you see that changing?

Charles (35:20.674)
Insightful question, you got me thinking.

Charles (35:26.4)
One way to possibly think about this is the idea that the interface of the data will change. Like you said, like CLAW, Chat, GPT, and all those things. Well, if we build like the GRC data lakes or the GRC data stores, then in theory, you may not need to have the spreadsheet. It could be natural language process driven where like, tell me about X.

Show me all the users who had access to this PCI environment over the last 30 days and put that into a report that has maybe some CSS like controls to make it look pretty. But I don't think we're there yet. Well, I would love to understand where people are pushing us in that direction. Because I think that changes the way GRC practitioners were engaged with the data. If the data was in a format.

a store that if all they had to do was ask it a question or type out a question in whether it's natural language processing and it just gives you the information and yet confidence in the return output, I would go on to say like maybe you don't need the spreadsheets anymore. Maybe this data gets connected into other engineering workflows that help inform users, your engineering users like,

this system has a compliance impact or this system has these metadata that would impact our, or some type of regulatory thing. Like how do we start pushing that as part of like the system builds and your interfaces versus like a third party, like I'm going to go do an audit report on you.

Raj Krishnamurthy (37:09.977)
And so you definitely see these consumption layers changing, right?

Charles (37:14.348)
Yes. Short answer, yes.

Raj Krishnamurthy (37:18.917)
I think you made a very interesting point when you were talking about GRC engineering. So one part of it is about how do we take the data that exists, make sense out of the data, and whether it is satisfying compliance or whether it is quantifying risk, right, or implementing governance used in M &A example as an example, right, and then maybe producing signals back into the security apparatus. That is fantastic. But there is a front-end problem here, which is

How do you ingest data? And the reason I'm asking that question is that a lot of that is number one, contextual, Especially large companies and companies that like that you work for Netflix, right? There are many different teams. They are closer to the problem. They are closer to the applications. They know what data to be produced, right? So what do you see as a separation of duties of what the GRC team should do post ingestion? And how do you as a GRC or a security leader

enable those teams to become productive in what they ingest.

Charles (38:23.918)
There's just the proverbial saying connecting the dots.

And as you collect this information, think Jersey practitioners understanding the risk, whether they be business driven or technology driven, while they may not have the direct insights into the teams per se, the workflows will highlight what's important and what's not. And then once again, I think there's a project program management component of this where how do we work this into

whether they're a geosystem or they're, what's the word I'm looking for? Sprint system, where we can help them from the security and compliance and maybe data privacy side, help them understand like what are the important things to work on if you only have a set amount of hours to work on. And I think there's that feedback loop that comes back from the customer side of saying, well, actually this is not.

the thing we should be working on. Here's the context with that. So I think part of this is also creating the platform to actually have that engagement where right now, I think we're sometimes sitting on the outside and then we interject when we know it's very particular to certification X compliance thing Y because we know that that's very deterministic. But how do we get to a point where we can just...

ingested understand information where we can be more proactive and say, is this, we're proposing something we're learning from you based off of your signals back. So we're sending you a signal, you're going to either validate or not, want to send it back. So I think this is like a bi-directional communication where it's more of a partnership. But I'm, I'm just trying to figure out like, how does that, how does that work at scale? think that would be the other question, like how do you scale that? But the idea that I need signals too, and

Raj Krishnamurthy (40:23.735)
Absolutely.

Charles (40:25.42)
versus just it's a PCI audit time or it's an audit in general time. That's the only time I get a signal. That's not continuous. Going back to your earlier question, like annual. Like I don't wanna see you just once a year, but there's signals that we need to be using throughout that can inform the state of risk and the state of security.

Raj Krishnamurthy (40:45.497)
No, think in my opinion, you're absolutely spot on. So for example, I think most of our infrastructure has become much more evolved today. I think we are all in declarative infrastructures that we can automatically reconcile. At least, I think that's a big promise of cloud and Kubernetes and things like that. And a lot of this can be for a better security posture. It can reflect on the past data.

especially curated past data that can be presented in the form of heuristics as part of an incoming admission control process. And GRC is nothing but the curated past form of data that is extremely enriched and very focused. So I think fantastically said, Charles, I love it. The one challenge that I have always heard from customers when they move towards GRC automation, GRC engineering.

Charles (41:22.819)
Mm-hmm.

Charles (41:29.486)
Correct. I agree.

Raj Krishnamurthy (41:43.17)
is that GRC is extremely contextual. That is true for security as well, but that is true for GRC as well. So the one size fits all actually does not fit anybody. I'm interested in getting your take. How do you think about these problems in terms of how to solve, right, as you stand up a GRC project?

Charles (41:54.392)
Correct.

Charles (42:04.504)
Yeah.

Charles (42:09.336)
Thinking about this broadly in terms of the experiences I had, one of the few things is really understanding how does the business works. How does the business make money? What is the role of engineering in that? What is the role in finance? Because the thing about GRC, it's not just serving security and engineering. There's also business workflow parts of this that come into question because you have some, maybe you have enterprise resilience and continuity as part of that conversation, along with your governance, your risks, your compliance and assurance.

So there's these different fields that you just have to think about holistically. How does it all come together? And so like, if I had to go back and relook at where I would do this again, in terms of like, what would I do? I think the first step was going back to the risk, like understanding what are the things that the business actually needs to perform? And then from top of that, okay, then from a risk standpoint, what are the assets that support that?

then those assets potentially are deployed and have vulnerabilities or have systems and services. So then you enumerate, you catalog them. And then to some degree, you're going to do some type of prioritization of these particular assets. that's one view on the internal infrastructure. Then you have the third party side. There's third party, first party that you use as part of making business go. Do you have an inventory of those things? How do you assess the risk of?

how those platforms are configured to enable your business outcome. That's a whole nother line of work. So to me, like as you start thinking about the business objectives and then what are the engineering, security, the data protection, the privacy components that enable that, you start to deconstruct and attempt to make simpler systems show up that you can address more directly. Cause a lot of these things are complex. So.

What's the first thing, do you do with complex things? You try to break them down to more simpler components. So that would be my thing, would be thinking about the business outcomes. What are the things that support that? Can we deconstruct them to their simple terms? And then what are the things that support that from a process, people, technology aspect?

Raj Krishnamurthy (44:23.798)
Got it. No, it makes sense. And Charles, you actually had a fantastic, from a risk team, had folks like Tony, Martin Wigg, Prashanthi Gautha, some pretty sophisticated folks. So this is a general question, which is that to the extent we talk about GRC,

from a technical perspective, right? GRC engineering, I mean, do they understand Go or Rust or Python at a very tactical level? Why are we not so much talking about what the R side of it, right? In statisticians and statistical analysis and machine learning and tensor models, why are we not having that conversation at all? Or am I missing something here?

Charles (45:07.906)
I don't think you're missing something. I think there are folks having a conversation. think that like I love Tony dearly and I think he's providing some conversations in that space around how folks should think about just performing cyber risk and talking about cyber risk. I mentioned earlier the idea of decision sciences and decision making. The idea of how do you model data? How do you clean data? How you do exploratory data analysis? That also exists.

in the risk side of the world. Once again, going back to that proverbial connecting the dots, how do I take the data that we have from a risk standpoint? How do we articulate our risk statements from a business impact perspective and tie that to the compliance work that happens, the governance work that happens, the security investments that are going on, the engineering designs and development that's happening? So that as a security leader, I'm talking...

as close to apples to apples that I can in regards to the things that we prioritize to do and the things that we're not doing and then the rationale behind why we're not doing that. So if you can get better consistency around connecting those dots across GRC, your security engineering, your larger engineering organization and rest of business, it becomes very clear, I think, like how your investments will show up in the potential impact.

And something that you brought up earlier, you mentioned, you know, cloud and everything else, the non-engineering side where I think that the natural language processing of the GRC shows up, it's like on the finance and marketing side. Like how do we enable, once again, there's, there's risk and compliance on that side of the house. That's not, that may not show up to say whether you're building a GraphQL endpoint or you're building a service, it's going to look different. So that's why I said GRC practitioners.

are very unique that there's, the technical nature of it is technical. That technical can show up whether it be doing Python or even how you do surveys to get folks to answer questions. All that to me is very technical. It's just applied differently.

Raj Krishnamurthy (47:21.07)
Got it. One of the challenges that I see is that in the world of finance, if you want to take metrics like return on net assets, right, Rona or whatever, there is an underlying foundation on which this is applied, right? A simple process of gap in terms of chart of accounts, what is debit, what is credit, right? And a statement of an operating procedure around it.

The challenge that I see with metrics, whether it is risk or compliance, right, and particularly risk from a cybersecurity perspective is, where is the chart of accounts? What is the commonly agreed upon language for cybersecurity? What is your take on that, Charles?

Charles (48:08.718)
My take on that is like I believe that we should have a common lexicon with regards to the metrics and risk. Now everyone was like my company is different. If everything is sold, all right. Can I pause and do that again? Okay, that's a good question.

Raj Krishnamurthy (48:26.981)
Yes, sure. I'm going to call up Eric because whenever you're ready, because he will take this out in post-charge, no issues. Whenever you're ready, let me know because I'll say Eric so he knows those two markers and then he'll search for it and then he'll remove.

Charles (48:35.61)
Okay,

Charles (48:41.422)
Okay. Okay. Can you repeat the question one more time?

Raj Krishnamurthy (48:45.541)
So I was basically saying, and this is not going to come out, we'll retain the original question. if you remember the financial, there are a basic chart of accounts. You basically say, if you make an expense, if you recognize revenue, there are some. So the entire metric is built on top of that.

Charles (48:59.374)
Okay, now I got it now. Okay.

Charles (49:05.229)
Okay, I'm ready now.

Charles (49:10.56)
One of the things that we talked about earlier was specifications. So without clear specifications, it makes it really challenging to know what to measure. And in the security field, I think there's an opportunity to be clear on what are the things that we're measuring so that you do have those foundational things that carry over to security program, to security program, to security program, whether it be everything from your AppSec deploy work, and I know there's like work in Dora and things of that nature.

Raj Krishnamurthy (49:39.343)
And this is the DevOps Dora. You're talking beautiful. Yeah.

Charles (49:39.446)
all the way to, yes, correct, to, I know folks may not align with this, like maybe this NIST CSF or there's NIST regulations that align to that commonality. And I think the challenge there is that security practitioners can sometimes tend to think we're unique and different.

Maybe that uniqueness and difference is causing the challenges in terms of how do we talk about the work that we do and measure the work that we do so that others actually understand it. Like we may understand that well, but does that translate well to other folks? Which is why I think grounding the work in risk is the foundation to building that terminology, to building that lexicon. And when I mean risk, I'm not talking about the red, yellow, green. I'm really talking about the financial impact.

of the decisions around security and the control measurements that if you're going to be investing in, how does that show up in terms of return on control investment?

Raj Krishnamurthy (50:41.563)
So if I were to understand what you're saying, if I say that, and it's a very sort of a basic stupid example, that we have to enable MFA, right? And if I wanted to use that as a security metric, and a simple metric could be what percentage of users do we have MFA enabled for a given population? It should be 100%, right? I don't think anybody's gonna settle for anything less.

Charles (50:50.647)
Okay.

Raj Krishnamurthy (51:06.436)
But that becomes a metric that can feed into other things to be able to establish and quantify risks. Is that what you're saying? So what do you mean by the word specifications? And how do we break it down?

Charles (51:17.944)
So, okay,

Charles (51:24.078)
So I like the example at a high level because like MFA, like people understand, but as a security leader, I would maybe push a little bit and say, yes, I would love 100 % MFA, but I know that's not actually a viable option in some cases. So for the systems that actually have revenue impacting, impact to revenue, what are our secondary control factors for MFA there? And what is the percent of not just coverage, enforcement,

and actual like reliability. Cause it's not just whether or not the control exists. As you're fully aware, it's like, does the extra control work? And is the control working the way we expect it to work? And if there's deviations from the controls working, do I know that? like this, going back to specifications, if the specification enumerates how the technologies are supposed to work, in theory, I should be able to test against those specifications within my environment.

they should admit some type of good, yes, good, no bad. Like there should be some outcome that I can then track over systems that we've identified as part of like business impacting or revenue generating or whatever the stipulation is that you have called out. So that's what I mean by specifications. Like we should be able to test against something that demonstrates this is an expected behavior or unexpected behavior. If not.

What does that show up in terms of my measurement?

Raj Krishnamurthy (52:53.819)
And do you think that we have arrived at some common specifications that we can all agree upon?

Charles (53:02.071)
No.

Do you think so?

Raj Krishnamurthy (53:05.807)
No, don't know you that's actually a good I don't have an answer to this, but this is one of the efforts that quite honestly, I think a bunch of folks, including Mosi Charles, you may remember you were actually a big supporter of that. We were trying to do with the CSA continuous assurance metrics, right? But it did not catch enough steam at that point in time. our objective was very simple. Can we take breakdown each of these domains, whether it is asset management or access control or

threaten vulnerability management, whatever they are, and identify some basic metrics that we can use to measure. I think we came up with a list of 34 metrics. I think that needed to be continued to expand. But that was the first attempt towards that. But I'm not aware of any other thing where we are trying to come together as a community to find those specifications.

Charles (53:53.62)
One, I probably wanna go back and revisit those specifications, those metrics to see what you all are measuring. And I know there's been work that myself, Justin, and some other folks with like our Shor framework for third-party risk management where we're trying to think about like, are the minimum set of controls that you would want to have for this? they come from your SOC 2 or whether like, we don't care. Like what are the core things that every business may...

inquire about when it comes to dealing with a third party. Like very similar to what you're saying, like, okay, are there a set of metrics across these domains that you can distill? Like what would be the least of minimum viable that you would want to know? And then everything on top of that's additive. But what's like the, if it's the core 30, like what are those core 30 that are consistent that if you came to me and I came to you with my 30, we should be able to exchange that.

Raj Krishnamurthy (54:34.843)
early.

Raj Krishnamurthy (54:48.091)
Exactly, exactly.

Charles (54:50.222)
and have a level of not once again, we get to move beyond trust, which is a subjective behavior and activity too. Like you can assure it programmatically by testing and enumerating or taking the deliverable I've given you and validating it and saying, okay, Charles, I trust your 34 metrics. I know you're in order to get to this point, you're doing, you're measuring, you're enumerating, you're doing whatever is that's happening.

Raj Krishnamurthy (55:16.611)
I think maybe we should, I would love to get a link to the Azure framework and third party risk management that you talked about, maybe put it as part of the podcast so that folks can see. But one thing I definitely would be in a mess if I don't ask you this question. Mosey says that third party risk management is an unsolvable problem. Have you ever had this conversation with him? Why does he say that and what is your take?

Charles (55:26.638)
What do?

Charles (55:40.258)
Yes, I have. And I told... I actually agree it's an unsolvable problem. My goal is just to make the problem less messier.

Raj Krishnamurthy (55:52.207)
But why is that an unsolved problem, in your opinion? Or in his opinion?

Charles (55:57.838)
I won't speak for Mozi, but Mozi, I would love for him to chime in on this when we post this, but the accessibility to third party is so easy. Like anyone can bring a third party into some degree in some organizations, whether they're their employee domain account or potentially moving data from their laptops to, I want to go try this thing.

Like that's just how easy it is. go, see this new thing, I click, sign up. Okay, I can't use my domain account. I'm use my personal account. I may have some data on there. I wanna go test over here. Ooh, this works great. How do I bring this back to my larger team? My larger team starts playing around with it. Now you got a new product that's part of a workflow that exists in making decisions within the business. It's so easy to bring something on board.

within an environment. So scaling this is hard because there's so many apps that exist on a day-to-day basis. How do you regulate that? So I know like the way I look at this space is, well, if we know that people are signing up for these things, how do we make it easier for through the procurement process that we get awareness? Can we least get visibility? Can we then start understanding the data proliferation that comes with having access to all these types of third parties?

And how do we work with our data protection team, our privacy team, and everything else to understand where does the data move? What's the data lineage now? Because I just look at this as an extension of a data exfil type problem. It's nothing against these applications. They all exist to serve a workflow. It's like you're going to need data to make that valuable as part of the workflow. So I think part of it's just that it's never ending.

Like I don't expect this to end. expect there's going to be a new whiz bang SaaS application that someone's going to like. We want to put their data in it and then, okay, then it becomes a thing. So part of this, well, how do I just give visibility? And then to our previous question, if there were controls and measurements that they could share out that would give me assurance around what they're doing in their platform, it makes them that

Charles (58:13.72)
conversation different. But since there's the challenging of the specifications, that's why security teams feel they have to go, okay, let me have to assess this platform. How do they handle the day? they do? Do they have any SSO? Like what does the SSO process look like, et cetera, et cetera.

Raj Krishnamurthy (58:30.531)
I think to that, I don't want to speak again on behalf of Mosi. He would absolutely agree with what he just said as my take. I think what you're basically saying is that the idea where there is an electronic exchange between your trust center as a vendor and the customer who can consume these signals and interact back and forth in as much standardized as possible. cannot take subjectivity out of this, but as much as you can is going to be super helpful.

Charles (58:57.134)
Correct. Agreed.

Raj Krishnamurthy (58:59.013)
Totally, no, 5%. We are approaching the end of the segment, Charles. I would love to get your take for a new person who's watching this show, Fresh Graduate, right, and who's looking for a job in GRC. What would your advice be? What steps can they take and get into this particular field?

Charles (59:21.102)
I would say there's some great resources that exist on GRC.Engineering. So definitely check out the website. There's a vibrant community of many other folks out on LinkedIn. So I would definitely say build a portfolio. We have some really cool self-hosted applications that can give you an experience and build your portfolio up. The community is very open, so you can reach out to many folks and they will reach back out.

Um, and I'm speaking on behalf of many folks, so I apologize for them in advance, but I think one of the things that we've been open to talking about is like, we know that there's a change happening. There's a transformation happening in this space and we want to bring as many folks along on that journey. Um, I don't think GRC is actually, um, like with the AI things, actually it's going to increase. I actually think there's a marriage between the data side of the world and the privacy side.

So you think of GRC engineering, I can also pair up data and privacy engineering to be almost like a brother and sister, like they're going to need each other. And so I actually think there's going be more GRC work that's going to happen, especially around data and privacy with all the platforms and services that exist. So if anyone's looking to get into it, I would definitely look across not just GRC, but also privacy and data and reach out to folks that you see and just ask the question. Never hurts to take the shot.

Raj Krishnamurthy (01:00:48.027)
No, that's fantastic. And Charles, it was fascinating to have you on the show. Thank you very much.

Charles (01:00:56.888)
Thank you, Raj, as always.