How to Build Trust Between GRC and Engineering

Raj Krishnamurthy (00:00.642)
Hey, hey, hey, welcome to another episode of Security and GRC Decoded. I’m your favorite host, Raj Krishnamurti. And today we have Tristan Engold joining us. Tristan is a Security GRC Program Manager at Meta. Tristan, welcome to the show.

Tristan Ingold (00:16.504)
Yeah, Raj, thank you so much for having me. I can say that I’m avid listener of security in GRC decoded. So it’s happy to, I’m happy to be on the other side of it right now. It’s a pleasure.

Raj Krishnamurthy (00:26.892)
Appreciate it. Tristan, what brought you to Metta? What was the journey like?

Tristan Ingold (00:32.652)
Yeah. So I spent five years working with KPMG as part of their, a couple of different teams, technology audit, technology, risk management, technology assurance. I have quite a few names when you’re working with, and like the big four ecosystem for the body of work that really is, testing controls, designing controls, running risk assessments. and I had a cup, I had the opportunity to work across a couple of different industries, retail healthcare, big tech.

financial services as well and you just can’t beat the size, the impact in my mind that those big tech players have and when I had the opportunity to join as part of the security GRC team that they were trying to build at the time in 2024 I had to take it. It’s been fantastic. I work with lot of smart folks and I’m happy to be there.

Raj Krishnamurthy (01:27.926)
And so you work at the product risk and compliance team at Meta, right? So that is an interesting transition, right? From where are you doing audits at KPMG? Were you doing assurance or advisory? And then you moved into Meta?

Tristan Ingold (01:31.692)
That’s correct. Yeah.

Tristan Ingold (01:44.118)
Yeah, so I think maybe the best way to think about it is I split my time 50-50. I think the first part of my time with KPMG was doing true external audit work. So there are Sarbanes-Oxley engagements that is testing internal controls over financial reporting. I’m testing IT controls as they relate to the appropriateness and accuracy of financial statements. And so…

In that capacity, I am working externally to a company to validate that they have controls in place. And then the second part of my career, really worked as part of more as like an IT compliance professional. I’m working with engineers. I’m working with first line security folks, integrity folks that are owning applications. You can think of like control owners as well. And really what I’m doing is

explaining what the true nature of a control is, defining control attributes, maybe helping them run a risk assessment, but really at the end of the day, helping them design controls or redesign controls based on changes in their audit spaces or new applications that they’re bringing online. I helped a lot of companies in that time with SDLC changes, so companies that are going from waterfall or

more rigid agile methodologies to like shoot DevSecOps teams and redesigning like what controls look like as teams begin to deploy through those methodologies. And then integrating into like cloud platforms. So I feel like in, at the start of my career, I worked with quite a few clients that were like, hey, we’re gonna move from on-prem into cloud. So what does that mean? And how does that impact our SOCs, our SOC one, our SOC two?

And do we need to update controls? Which new ones do we need to bring on? How much is that going to cost us? Those kind of questions are really what I was answering as part of engagements.

Raj Krishnamurthy (03:43.406)
Okay, now there is a general perception, and I have to ask you because you work at Meta, there is a general perception that engineers think that security impedes progress, right, or they slow them down. Security teams think that the GRC teams slow them down, and the GRC teams think that the auditors slow them down. And maybe not so much the GRC team, but do you see this in the field when you especially work with engineers? Do you see the friction that exists between these different teams?

Tristan Ingold (04:14.38)
Every day. Yeah. I think in the past you’ve, you’ve asked some of the folks that have been on like, what’s your controversial opinion? And, and I don’t know if it’s controversial. I think maybe it is to say that like compliance really is a function within the organization that works every day to, to slow down the business. And it’s because we’re not the primary driver for, for revenues and for bringing customers to the platform and

I think anytime you’re talking to a group of folks whose main driver is we need to increase revenue incrementally by this much. Those are our engineers. You have folks within the organization that are true security. And so those folks are talking to engineers and they’re saying, hey, we need to make sure that we’re implementing access control and make sure that bad actors can’t get on the platform. It’s a very base level control that we’re putting in place. And you know,

Engineers, think at this point are very receptive to those kinds of conversations because it’s like, yes, we can’t run a platform where everybody’s just running around like the wild west. But when you start saying, know, engineers and security engineers will say, we’ve put this best practice in place and a compliance person will come around and see like, yeah, it’s best practice, but it doesn’t quite fit the letter of like what this regulation is saying.

And so I think it creates a lot of frustration. And I think it’s because security engineers are good at their jobs. And sometimes auditors, compliance folks can make them feel like they’re not understanding it. When compliance objectives are written, a lot of times when you think about like regulatory or industry best practices by true compliance professionals, by lawyers, by policymakers. And that doesn’t always drive with the technicality of what engineers are trying to put in place.

Raj Krishnamurthy (06:07.32)
How do you solve that friction then? it looks like there is a lot of sort of silos of thought here, right? The way that I see things versus where you see things. I here being an engineer and you here being security or GRC or auditors, right? How do you sort of bridge this divide?

Tristan Ingold (06:23.894)
Yeah, I think…

I think the onus is really on the compliance professional. And maybe I’ll tighten our conversation to like, what can the compliance professional do? Because that’s how I have the most experience trying to encourage, as I’ve been a consultant, as I’ve worked in the industry as well, the best thing that you can do is show some empathy for the security folks. You gotta understand what their main motivations and drivers are.

is one big thing. So, it helps to talk to maybe not even the engineer, but maybe the product manager, because that’s where, if you think of a lot of like technology organizations, you’re going to have engineers, but engineers work off of sprints. Their work is mandated by a backlog. It’s sitting in Jira or some sort of like, a platform that’s similar to that. And, they have a very strict,

kind of flow of work that they’re trying to get done. And so maybe it’s worth talking to a product manager or program manager and say something like, where can we fit this in? Where’s the budget? What are you motivated by? What are you trying to get out of the door? And when they tell you those things, say, hey, listen, we have some sort of compliance objective. We have new controls that need to go in place. And it’s going to ultimately help you either land this product, make sure that it stays.

in our product pool, make sure that it’s a feature that continues to be released to our customers. But we need to hit the letter of the law according to the EU, according to federal government guidelines, according to the standard, whatever it may be. And I think that when you can frame up the conversation like that and start that conversation early and get it into a backlog so that engineers know it’s coming, you have a lot better.

Tristan Ingold (08:26.455)
implementing some of those things that you want from a compliance standpoint.

Raj Krishnamurthy (08:29.996)
think that’s a brilliant thought. So what I’m hearing you say is that if compliance is phrased as a feature, and obviously you’ll have to justify that feature to the product manager, then it fits into their stream of work. Trying to do anything else essentially disrupts, and that’s where this friction comes from, is what I’m hearing you say. Is that correct? OK.

Tristan Ingold (08:38.541)
Mm-hmm.

Tristan Ingold (08:51.596)
Yeah, exactly. And I think it’s also important to point out that as a compliance professional, you’re really there to provide, I think what we like to call, a credible challenge. So as new features are being pushed, whether you’re talking to a true frontline engineer that’s building functionality for an application or a platform within your organization that customers or internal employees are relying on,

security engineers are building the controls, understanding the risks, vulnerabilities, getting threat intel to make sure that we’re covering off on our applications correctly. Compliance is really there to provide that credible challenge to say, hey, I think we’re either doing this appropriately, not appropriately, running that, what you would call like a gap assessment to understand where we’re at and where we need to be. And then having a good structure conversation around where can we go from here as opposed to

which is a good conversation to have. And I think a lot of folks that are in an organization are receptive to that, as opposed to saying like, well, the auditor says that we need to have this, so let’s implement it, which is not necessarily a conversation that especially the technical folks would like to have.

Raj Krishnamurthy (10:05.57)
Got it.

Raj Krishnamurthy (10:12.846)
Got it. So GRC, I can put them into two buckets, broadly speaking. One is more a back office IT side of GRC, where you’re essentially evaluating your compliance posture or your risk posture on a periodic basis. Let’s say, for example, you’re doing a PCI DSS certification or a SOC 2 attestation or whatever that is. And then there is the aspect of compliance and risk being integrated into the product lifecycle.

Tristan Ingold (10:39.822)
Hmm.

Raj Krishnamurthy (10:40.43)
Have you done both? It looks like what you’re talking about in Meta is more towards the product side of the compliance and in the past your experience with KPMG has been more on the sort of the back of his head of compliance. Is that a fair way to phrase it?

Tristan Ingold (10:54.55)
I think my role today really spans kind of both sides of the organization. I think maybe the best way to think about it is we have different compliance obligations within an organization, especially when you start talking about large technology corporations. You start to get a blend of what we would consider like,

commercial or business or industry standard audits. That’s like your PCIs, your SOCs, your SOC 1, SOC 2, your ISOs. But then because we’re, because big tech companies are such heavily regulated entities, you start running into a lot of these data privacy or security regulations that are impacting the organization as well. So you can think of like the Digital Operational Resiliency Act, DORA.

DSA, DMA, especially for our large market providers, GDPR. And so that’s when you start really thinking about product. And to be honest, since I’ve gone into industry, this space of product regulation is new for me. And honestly, you know, for folks that are new to this space of product compliance, it’s really about like product safety, not only for the consumer, but for

the company as well. So how do we make sure that we’re protecting the data of our consumers to make sure that we’re consistently meeting a level of rigor for data protection, data integrity, data confidentiality, but also when you talk about resiliency, our availability. So how do we make sure that our platforms are continuing to stay up so that folks can use them?

Raj Krishnamurthy (12:42.702)
And how do you see the intersection of what you are doing typically in the security space and privacy? Because a lot of what you talked about is part of the security apparatus, right, in terms of how you manage applications and services. But the big emphasis in companies like Meta is also privacy, right, data privacy. So do you manage both, or do you see them as distinct sort of functions?

Tristan Ingold (12:53.825)
Mm-hmm.

Tristan Ingold (12:59.886)
Mm-hmm.

Tristan Ingold (13:07.286)
Yeah, think that, I’m sorry, Raj, I’ll have you ask that question one more time.

Raj Krishnamurthy (13:13.026)
So security and privacy, when you go talk to these product engineers about integrating compliance into their work sprints and sprints, do you talk both about security and privacy? is there somebody dealing with privacy and you deal with security? How does that come together, security and privacy, for you?

Tristan Ingold (13:31.82)
Yeah, I think in many organizations, those are two distinct groups. I think there’s overlap. And I think that comes from the fact that the process for managing both security as a domain and privacy as a domain are similar. So we’re talking about identifying risks. We’re talking about implementing controls. We’re talking about having issues. What are our policies and standards? How do we run exceptions for that?

What are our third parties doing? Those are questions that we ask as risk professionals both in the privacy space and security space. I think that it’s helpful to bifurcate the two within an organization just because the requirements for privacy and security where they come from are quite different and the reason that we’re implementing them is different as well. And so

I think that while you can get signal and mildly may report into the same individuals from like a director or VPShip level, I think it’s appropriate to keep them separate within the organization. Although there’s a lot of overlap and I think that those people should communicate because for example, right, you might be implementing controls to meet security obligations, whatever they may be. And you might already be covering off on some of those privacy considerations that you’re trying to cover.

Raj Krishnamurthy (15:00.098)
Makes sense, makes sense. Because typically you see them report under two different departments, right? You have the privacy typically held by the chief privacy officer or the chief data officer, and the security is part of the seashore’s org, right? And you see that distinction. So I want to take a step back. What is your view of GRNC?

Tristan Ingold (15:18.574)
Well, think that the interplay in an organization between all of those units has to be as tight as possible. And I think that it needs to start with good governance. I know that I feel like the response is different depending on who you talk about. I’ll say I consider myself like a true security governance professional. I think it starts there. I think you need to have top-down leadership.

representing folks within the organization that want to implement good policy, good standard, good procedure, folks that are putting together playbooks, folks that are creating oversight, people who are there to generate good KPI, good KRI so that leadership and the folks within the organization can get signal. That’s really what governance means to me. Risk is a whole body of work that I think is held by both

like first line folks and by second line. So you have the first line engineers who should be running risk assessments, who should have a good beat on vulnerability, your threat intelligence should be bringing that into the fold and defining what good risk means in a centralized location. And you should have second line folks in the compliance space that are reviewing those risks, running the risk assessments when needed and contributing to that risk register of the portfolio as well.

Compliance is to me a little separate from governance and risk. I think that compliance needs a lot more hand holding. It consumes this huge body of work that is really control assurance. It’s that issue management. It’s the, we talking to our regulators? we responding for requests for information?

We’re meeting our obligations, are we running our own internal and external audits? And some of that is with internal audit, right? Which is a third line function. It’s not necessarily like in the GRC space, but our folks are really need to be working as close as we can with first line and the third line to bridge that gap, to make sure that they’re getting the evidence they need without disrupting our business processes too frequently. Yeah.

Tristan Ingold (17:42.382)
I think that’s kind of my view on GRC as a space right now.

Raj Krishnamurthy (17:46.314)
And what do you think if the leaders, the managers of the organization, how do you think, especially in a very tech forward company like Metta, right? And I’m using Metta as an example, it can be any company. What do you think is their view of GRCS and what value it adds?

Tristan Ingold (17:59.192)
Yeah.

Tristan Ingold (18:05.644)
Yeah, I think that at all of these large tech companies, you’re going to find that we have armies of GRC professionals working in various parts of the organization. So a big thing to understand is I think when you’re at a smaller company, you might have a group of engineers that either their products, so their customer facing or their internal than doing like what we consider like back office, corporate services, running payroll, those kinds of things. so

You have engineers that have a primary job, which is to deliver new features to our applications. And we have the security folks that there to help.

I lost my train of here. All good.

Raj Krishnamurthy (18:55.832)
Don’t worry, I think Eric will edit and post. Don’t worry about it. You can start from wherever you want.

Tristan Ingold (18:59.0)
Gotcha.

I think we’ve.

Raj Krishnamurthy (19:03.874)
You want me to repeat the question?

Tristan Ingold (19:06.798)
No, it was just like how GRC is seen within big tech organizations.

Raj Krishnamurthy (19:12.726)
Exactly. Especially with the leadership teams. We’ll take a pause so that he knows where to do this.

Tristan Ingold (19:16.941)
Yeah.

Yeah, I got you. GRC within any big tech organization, especially for us is super important to making sure that we’re continuing to protect the data of our customers and ensuring the integrity of our platforms. I think that we’re continuing to expand these teams.

Raj Krishnamurthy (19:24.355)
Go ahead.

Tristan Ingold (19:47.926)
especially as new regulations come out of the EU and other international players. You’re seeing tons of new requirements being distributed from governments like India, Singapore, Australia, related to specifically a lot of new requirements related to like ransomware and operational resiliency.

And so I think they looked fondly on the organization, but you have to tow a fine line because engineers, a lot of big tech companies are like a protected class. They are very important to the organization. They’re paid very well. They’re very important. And they’re the main driver of revenue, right? When we’re talking about the biggest features that we’re trying to push out the door are technical. so we have to…

constantly lobbied to make sure that we’re setting up processes from a GRC standpoint that are most efficient for our engineers to interact with. And so that requires us to be as technical as possible so we can go into those conversations with very pointed questions around what does risk look like in the types of things that we need to put in place.

Raj Krishnamurthy (21:05.014)
And I wanted to read out something that you said before. I thought that was sort of fantastic. You said that GRC or IT compliance is like a sparring partner. They are there to make the organization feel the pain a little bit before externalities negatively impact the business. That’s a brilliant way to put it. Double click on that and explain.

Tristan Ingold (21:22.19)
Hmm.

Tristan Ingold (21:26.766)
Yeah, I think that each each day security folks are, you know, they’re implementing what they see as best practices. And sometimes that’s motivated by stuff that’s worked in the past. Sometimes that’s motivated by new technical capabilities that we’re realizing both at an industry level or inter company level. And so

there’s a lot of opinions in the security team. And I think that there should be a lot of opinion in the GRC space as well. And I think that there’s room and I think that that conflict really allows a company and teams to come up with the best solution. And so I would encourage any GRC professional to be opinionated, to have a strong view on what works and what doesn’t. And this is why, you know, I know you’ve talked to

Raj Krishnamurthy (22:19.427)
gathered.

Tristan Ingold (22:26.082)
to folks in the past about GRC folks needing to be more technical. Maybe that doesn’t mean developer, but it does mean that you need to be able to step in the conversation and say, hey, I think the way that you’re reviewing access or the way that you’re providing privileged access to users within this environment is appropriate. It’s not appropriate. We’re under a certain level of scrutiny based on our compliance objectives. And I don’t think that this meets that objective. So in explaining why.

And I think that you can find common ground with security professionals when you’re able to have that conversation at a level playing field in terms of knowledge. And the funny part is, or maybe another part to note in this is that not only should we be a sparring partner for the first line security folks or application security folks, is we should be a sparring partner with the…

with the audit teams as well, with our internal auditors, external auditors, depending on what types of conversations you have. Sometimes you don’t talk to the external auditors from like a GRC standpoint, sometimes you do. But they’re gonna have the same opinions and they’re gonna come and talk to your engineers and say, hey, you need to do things differently. And I think it’s important for you to provide early credible challenge to your first line folks to give them a flavor of what you’re gonna get from the auditors. And then once you agree or come to a consensus on what’s appropriate for the organization,

you should be willing to go to bat in a unified way in front of the internal audit teams, the external audit teams to say, hey, this is what we think is best practice for our organization. I think like one of the most, you know, we’re not naming names, but I think that one of the most like odd clients I’ve ever been on is I was part of an IT compliance team and IT compliance team didn’t get along with the first line, didn’t get along with their internal auditors. So when external auditors asked questions, it was like four people at the table.

trying to argue over what’s correct. And I just was thinking to myself, know, we’re all working for the same organization. This should be one unified front talking to an external auditor right now. This is not only not a good look for us, but not really helping us get to where we want. yeah, there’s kind of sparring on both sides. It’s a lot of sparring in the GRC space.

Raj Krishnamurthy (24:45.228)
No, I love the analogy. And I love the analogy because I think more than sort of the adversarial nature of this, what I’m hearing you say is that you have to build the trusted partnership in the advisory role that the GRC teams will have to play with other teams, right? And that’s what is coming out of this conversation.

Tristan Ingold (25:01.942)
Yeah, when, I think this is something that KPMG is probably like coined by now, but I know that when I was working with them, I referred to myself as much as I could as just a trusted advisor more than a consultant. I wanted to be in the company. wanted to be in the conversations. I wanted to be providing good advice as much as possible, both downstream into like the product engineering ecosystems and also

on the other side of the fence towards our internal and external audit teams. Yeah.

Raj Krishnamurthy (25:35.084)
I want go back to one of the points that you made earlier, which is that you work with the product managers in order to demonstrate that some of these compliance have to be featured within the product. And that eventually helps the company, right? Which essentially means that you have a sort of a, what is your role vis-a-vis the customers of the product? And that you here being the GRC team, what do you see as the GRC team’s role?

in terms of customer advocacy and interacting with customers.

Tristan Ingold (26:06.274)
Yeah, so to folks that are maybe new to the GRC space, there’s so many different places that you can end up with inside a company. And maybe it just depends on the size of the industry or really what kind of role you’re in. I think that when you’re talking about maybe a newer startup kind of company, you’re just starting to put controls and risk assessments in place, you’re passing a couple audits, those are probably your SOC 1s, your SOC 2s.

you’re really thinking about, okay, who are our customers? Who can we provide our platform to? Usually a technical platform. And you’re trying to essentially establish that like, hey, we’re going to protect and secure your data. So you should use our product. So that’s a good product facing or customer facing way of thinking about GRC. For…

myself who doesn’t necessarily deal too much in like the commercial audit space, we’re going to sales cars, we’re giving customers. It’s really about like, what does it mean to protect data and the privacy of different folks? Making sure that people can have access to their own accounts on a platform to make sure that the product is always available, to make sure that they can connect with other people that are on the platform.

And really what I’m thinking about is what would I want? To be honest, a lot of times when I’m dealing with, when I dealt with customers as a consultant now in industry, every time I come to one of these conversations around security, I’m thinking about not only what best practices are, but what would I want from this platform? What do I think is appropriate? And luckily I…

I like to think I have a good gauge of what I would like to have in a platform and hopefully that overlaps with some of the other customers of our products as well.

Raj Krishnamurthy (28:02.52)
So looks like your GRC team is a team of empathy, right? You empathize with customers, you empathize with engineers, you empathize with security, you empathize with everybody.

Tristan Ingold (28:10.67)
Yeah, I mean, you, you, there’s a lot of competing.

There’s a lot of competing attitudes. What’s the word I’m looking for?

There’s a lot of competing initiatives within an organization. And I think that it’s on the onus of the GRC folks really from like an information security data security standpoint, from a product safety standpoint when it’s applicable to be able to stop and say like, hey, are we doing the right thing right now to protect the customers? And I think even more so than those first line security folks that have.

typically a very niche part of the product or part of a platform or service that they’re protecting, we kind of come at it with a people first mentality of, I know we have these compliance requirements, I know you’re doing a lot of work, but how can we make sure that we’re putting controls, we’re off risks in a certain way that allows us to make sure that our customers are really protected. yeah, empathy is a big part of that. think any like,

interview I’ve been in in a GRC space that’s come up as part of it. Like how can you put yourself in somebody else’s shoes? Do you have the way to do it?

Raj Krishnamurthy (29:26.894)
That’s just beautiful. Okay. What is your view of GRC engineering, Tristan?

Tristan Ingold (29:34.892)
Yeah, I think that it’s super popular right now and I think that it’ll continue to get more popular. think that there’s a couple…

Raj Krishnamurthy (29:43.052)
Why do you think it is popular?

Tristan Ingold (29:45.728)
I think it’s getting popular because this space of like technical control, technical risk assessment has been ripe for automation, for enhancements, for a gain in efficiency for a long time. So when I started testing like ITGC, like IT general controls as part of SOX, several years ago, you know,

We were still running, let’s take a user access review. So on a periodic basis, you go into a system, you validate that everybody who has access to the system is good and you package that up and retain it that’s a control. Those companies were still generating user lists by hand, sending it to a PDF, emailing it or printing it out, having someone read it, sign it, scan it back into the system and retain it. That’s incredibly burdensome for an organization or

a director or someone that’s not their primary function or role within an organization. And it felt like everywhere else in an organization was getting faster, smarter, whether it’s sales, marketing, everything was getting a tag of programmatic with speed first. And it felt like I think because the letter of the law, a lot of times within your compliance organizations is so strict, it leaves.

a lot less room for interpretation or enhancements. which is odd because I feel like, especially when you talk about control assurance, so testing controls, a lot of that is very, honestly, I feel like simple to automate. I know that’s maybe incorrect to say in some environments, but when you’re talking about validating user lists, validating hashes to make sure that.

what you’ve pulled from a system is actually what’s still in the system. Those are things that are, you can write scripts to pull and validate on a continuous basis. And so I think that’s one, why it’s becoming so popular and two, why it’ll continue to stay popular. And of course, like AI coming into the fold now, companies using agents, specifically like,

Tristan Ingold (32:03.724)
AI agents or these types of AIs that can talk to each other and use APIs to pull information across the organization to aggregate risk posture or where controls are failing within an organization and bubbling that up. That’s gonna be super important for organizations going forward.

Raj Krishnamurthy (32:21.05)
I hear you say a couple of things. Number one, you talk about productivity. So you are equating security, GRC engineering, to automation, which it is. And then you’re talking about the improved productivity. I want to ask you, is this a productivity for the GRC team? Is this a productivity for the engineering team, security team? Whose productivity are you talking about?

Tristan Ingold (32:41.762)
Mm-hmm.

Tristan Ingold (32:45.418)
Maybe the GRC folks, but ultimately our first line folks we’re working with. needs, always, and GRC folks should, I would actually be curious to know if other GRC folks feel the same way, but we always need to keep the first line in mind. Anything we’re doing needs to be, how can we make it easier? How can we make it more efficient for them? How can we make it so that they can continue to push feature, do their day job?

Raj Krishnamurthy (32:49.88)
Got it, got it, makes sense.

Tristan Ingold (33:13.759)
and still get the evidence that we need at the level of scrutiny that the auditor is asking for.

Raj Krishnamurthy (33:19.65)
Got it. Got it. One of the reasons that security engineering became a big thing, in my opinion, and there are many reasons, and one of the reasons I can think of is this idea of shifting left, right? So much so that the term is completely abused now, in my opinion, right? But the idea is to bring security closer to developers and try and catch them as early as possible in the lifecycle than later, right?

Tristan Ingold (33:33.998)
I don’t know.

Raj Krishnamurthy (33:43.384)
Do you see a very similar role for G, R, and C, particularly risk and compliance from a controls perspective? Do you see a need for them to be shifted left?

Tristan Ingold (33:53.824)
Yeah, definitely. think that anytime you get a pitch deck from like a tech advisory group that comes into your organization, they’re talking about how can we shift left. I think that it’s important for efficiency gains within an organization. But I also think it’s just a better way of doing controls, right? When you take a very simple

a very simple type of control like change management. And I think one of the simplest ways that we can think about shifting left is you used to, you know, generate a bunch of code and then you try to push it to production. But before you did that, you had an approval right before it got deployed. But now when you see a lot of change management controls, you’ll have coding that’s done and immediately there’s a first or second approval.

on the code that’s been changed before it goes into integration, before it’s getting deployed to production servers. And so that’s a very simple example of what it means to shift left. But I think that does two things. One, it’s typically automated, so you do it faster. And then two, you can get something rejected and pushed out of the line before it comes back in. And so I think that, yeah.

I think that you’ll continue to see this idea of shifting controls left be echoed by lot of like GRC advisory people.

Raj Krishnamurthy (35:23.938)
God, and this may sound extremely controversial and maybe even naive and idiotic, Tristan, but if you can shift controls left and you can increase the frequency with which you’re executing these controls, right, these audits, so as to say, and you bring the auditors closer to the first line of defense, is that a need for a second line of defense? Is that a need for a GRC team?

Tristan Ingold (35:32.952)
Mm.

Tristan Ingold (35:47.892)
Always. Yeah. Yeah. It’s funny. I feel like I’ve been asked this question recently. 100%. There always needs to be at least somebody within the organization that’s putting some challenge on the first line to say like, Hey, I think we’re doing this wrong. Or I think we’re doing this right. And maybe it’s just me like with my auditor hat on. But when I come to an organization and they’re saying, okay, you know, we’re running regular risk assessments, we get good signal.

We have controls in place. We’re testing those controls and validating that they’re operating effectively and that they’re designed appropriately. That’s fine. But again, I’m like you as a first line person, when I’m talking to an engineer, I know that you own this control, but this isn’t your primary responsibility. And I trust you that you’ve implemented something that works appropriately. But ultimately I want to see that you have.

your company has hired somebody within the organization that isn’t me as an external auditor coming in who comes in every once in a while and says, Hey, I think that what you’re doing here is good or what you’re doing here is okay, but we need to increase the maturity or we need to adjust the way that we have constructed our control attributes or we need to look at other parts of the system. And I think that that’s just healthy. like

scrutiny to have within an organization, especially when it’s so big. And I think that if you completely take that away, you’re going to have more scenarios where auditors come in and say you’re not doing this correctly and stuff doesn’t get done. Essentially like an IT compliance organization or GRC professionals within an organization, think are just like lobbying for good practice constantly.

Trying to motivate teams to do that and sometimes it feels like we’re losing but at the end of the day like I don’t think the organization necessarily needs everything that the DRC organization is trying to implement But you can’t you can’t take that away if anything over the next few years maybe the pool of folks that you need within the organization will get smaller and I think that’s an important point because I think you’re already starting to see some of that with the hiring freezes that are going on at

Tristan Ingold (38:07.352)
like some of the big four organizations, especially at the lower levels. And as unfortunate as that is, just some of those activities are getting fully automated as part of rollout of new technical capabilities.

Raj Krishnamurthy (38:25.24)
Got it. If I break down the GRC team’s functions or activities, right, into policy management, evidence collection, controls testing, risk quantification reporting, and compliance reporting, and maybe there are other things, where do they spend their most time today? And not everybody does everything, I understand, especially in big organizations. But where do people spend most of their time?

Tristan Ingold (38:39.66)
Mm-hmm.

Tristan Ingold (38:50.648)
Gosh, I would hope it would be in…

I would hope it would be in risk, like understanding your risk posture, understanding how to look at risk in an effective way, understanding your threats, your vulnerabilities, in coming up with ways to manage risk in a way that makes sense for the organization and bubbling up, this is where like governance in my mind goes to when you ask this question, it’s like, how do we get good indicators from

the risk quantification that we’re doing to say like, hey, this surface or this bundle of assets within the organization is going to see based on these new vulnerabilities that we have an increased level of risk that’s maybe outside of our appetite.

And, sorry, can you ask that question one more time?

Raj Krishnamurthy (39:45.966)
I think you answered it. So I think what I’m hearing you say is that the more you automate compliance, what I’m hearing you say is that the GRC team should more and more move towards G, which is the collection of metrics and the management of metrics, and R, which is reporting on the metrics and the quantification of these metrics for impact.

Tristan Ingold (39:58.958)
Mm-hmm.

Tristan Ingold (40:02.506)
Yeah, exactly. Yeah. I think that’ll be.

a really important space for GRC people to focus on in the future. think that control activities are fantastic. And to be honest, I think that’s where a lot of folks in GRC spend a lot of their time is how can we build like the best controls to put in place? And a lot of times when you look at reporting dashboards, I was listening to a, this is a series is another podcast on Spotify.

They had some folks on the other day that are CISOs and they were talking about how reporting a lot of times when you get it at like the C-suite level is like, here’s how many controls we’ve tested over the last like quarter. And I am not a fan of that kind of reporting. I want to know when there’s truly a risk that we’ve realized within the organization that’s going to hurt something. And let’s have a conversation around what that looks like. How much money do we have to like put into this to…

Remediate it. Is it something that we’re willing to accept? What does acceptance look like? Those are the conversations I’d like to have as part of those Like big discussions governance and oversight discussions as opposed to talking about how many controls we’ve tested and hopefully like that continues to get automated so that governance professionals can’t you see professionals can really use their brainpower to solve more complex problems than just

I was just going to say pulling screenshots. feel like that analogy is overused, but yes, pulling the old screenshots.

Raj Krishnamurthy (41:38.158)
Checking evidences, collecting evidences, check the boxes. Pulling screenshots. Do you think the leadership team understands what you’re talking about? what I mean by that is, what should be your role in making them understand that?

invest more in automation, can reap benefits in terms of continuous improvement from a governance and risk perspective. Do they understand that argument?

Tristan Ingold (42:11.094)
I think they do. think a lot of directors, lot of, let’s say this, lot of folks that have the budget within your security organization or information organization are restricted by the amount of investment that they can put into your group. I think there’s, you know, a lot of money that’s going into how can we drive business and they’re doing a lot with a lot less nowadays. And I think that

you’re feeling that with the size of contracts that like audit organizations and other IT compliance professional services firms are getting as well. And I think it’s important for, I think it’s important for us to realize that we, I’ve completely lost again.

Tristan Ingold (43:07.374)
What was the question again?

Raj Krishnamurthy (43:08.47)
their leaders do they understand?

Tristan Ingold (43:11.138)
Yeah, they do. It’s important for us as GRC professionals to ensure that, here’s what I want to go on this. We need to be a little bit more creative in the solutions that we’re coming up with. And it’s on us to understand that our leaders are working with a very limited amount of budget within an organization. And so what you can do is lobby for yourself with other first line.

Folks whether their product whether the security engineering folks in saying hey I have this idea of something that I think is gonna cover off on risk or making your life easier And it’s going to take a little bit of engineering. It’s gonna take a little bit of Usage of AI it’s gonna take maybe an onboarding of this platform that I really know how to use and so I’ve talked to my director. We’ve had an honest conversation We don’t have the budget for resource hours or whatever it may be

does your VP or director have some of that budget? Can we implement something like that? And so I think those are the conversations you have. think you have a lot of upstarts, know, folks within an organization that are like, I can do better. And they’re communicating it to their directorship and making them understand what’s needed. But I’m not entirely certain that everyone has the, you know, the know-how to go to those folks and say,

I understand what motivates you. understand why you’re hesitant to implement some of these things, but here’s how we can do it in a way that makes sense for organization.

Raj Krishnamurthy (44:42.35)
Got it.

Raj Krishnamurthy (44:47.702)
What do you see as the current state of GRC tools?

Tristan Ingold (44:52.482)
gosh, there’s there’s so many of them. There’s so many of them. but I think that this is exactly what we need in the space. And I think that the competition, I think because there’s so many of them, you’re seeing a lot of really good competition in terms of features. I’ve never seen more demos than I have in like the last three or four months of different products. And it’s really exciting.

Raj Krishnamurthy (44:54.893)
Yeah.

Tristan Ingold (45:16.846)
And maybe to give folks an understanding of what’s out there in the ecosystem of GRC applications. think that there’s a couple different like buckets. I think that there are some good checkbox kind of applications. So this is you’re bringing onto your platform. You are a startup. You need a stock one, you need stock two, you need FedRAMP. You’re going to bring in this company. They’re going to help you dump all of your evidence into these things, test controls.

checkbox, checkbox, checkbox, and then they have a really good front end trust center so all your customers can come and say, they have these certifications, this is fantastic. I think you’re seeing another group of applications that’s really focused on integrating into your business. So can we put a web hook into your, or can we put some sort of hook into your AWS, your Azure accounts? Maybe we have a way to pull information from your on-prem servers.

we’re gonna create this like data lake of understanding around IT asset management, vulnerabilities, we’re pulling in how often you use these, what kind of data is on those platforms, and we’re gonna put it in this lake, and then you can either use our front-end product to understand your risk product posture, or you can create your own internal dashboards and use it, and we’re just kind of like a data aggregator. And then of course, there’s a lot of legacy platforms that I think are still…

hanging around like your service now, your archers, that are essentially their same, it’s the same products they’ve always been, but they’re throwing a ton of AI at it. And they’re saying, hey, you can get enhanced capabilities from this based on the kind of agents that we’re kind of building into the platform. So that’s kind of the landscape of tooling that I’m seeing right now.

Raj Krishnamurthy (47:05.196)
Got it. Meta is actually a harbinger in AI, right? I think Lama is an amazing open source model. But one of the challenges I think particularly the GRC teams have in my opinion is that they are trying to bridge the probabilistic world of AI, where you can ask questions and you’re probabilistically sort of getting some responses with the deterministic output that you need to produce to your auditors.

Tristan Ingold (47:26.382)
Thank

Raj Krishnamurthy (47:34.05)
Do you agree with that characterization and how would you as a GRC professional manage that gap, that the idea of taking probabilistic inputs and producing deterministic outputs?

Tristan Ingold (47:46.604)
Yeah, I just, I feel like I’ve been reading this a lot in the news recently, this probabilistic versus deterministic struggle, especially in spaces like you’ve said, like GRC, where when you’re talking about providing evidence to a regulator, an auditor, it needs to be very pointed, very specific, it needs to be very accurate. And I think that, you know, it’ll

There’s going to be a huge emphasis as a lot of these tools and agents get brought online to say, how is this working and how is the data being pulled in? So I think a lot of times when I talk about AI governance with folks, one of the biggest things that I harp on is transparency. Like, do you have a good way of showing us what is actually happening and what kind of data is actually being used?

And if it’s being manipulated in some way, do you understand like how it’s being manipulated? I think AI is going to like continue to struggle in a space like this. you know, I think that organizations largely from what I’ve heard, not specific to meta is when we’re putting together audit reports or risk assessments or those kinds of things, we can get kicked off with an AI tool.

to help us frame up how we want to show this information. But when we start to look into the details, a lot of that is still done by humans. And I think that it.

It will be until we have AI systems that auditors can get comfortable with. And to be honest, I feel like that’s something I’ve been rattling around in my head for a while too, is what would that look like to get an auditor comfortable with like, we are using some form of like AI assistant to really help us like,

Tristan Ingold (49:54.412)
around the source was going to test this whole body of controls and provide it as part of this audit. An interesting space. I wish I had a better answer for you.

Raj Krishnamurthy (50:02.456)
Two. I think there are two parts to it. One is in terms of how do we use AI for governance risk and compliance and potentially audits. The other perspective is that how do you see AI as product engineers start using AI in their products as a GRC professional? How do you, I mean, do you work with any of those product teams that use?

Tristan Ingold (50:19.566)
Mm.

Raj Krishnamurthy (50:26.254)
agents and large-scale models and obviously write an MCP host and build MCP servers. I’m sure you do. How do you audit them? Because they are in a new world of audit. This is not the traditional audit of screenshots and APIs anymore.

Tristan Ingold (50:41.794)
Yeah, I think that there isn’t a whole lot of, there isn’t a whole lot of like industry knowledge out there yet on what good looks like when you’re talking about auditing these models. And I think that Meta as an example is doing a fantastic job of being at the leading edge of building trust and integrity into those platforms.

and having a good concept of what AI governance will look like to make sure that we’re meeting future compliance requirements. When you talk about, do we need to build controls into our space, into our AI systems, our large language models? I really think that yes, we’re doing that. Yes, think that providers of large language models will continue to do that to make sure that we are keeping users on the platform.

Cause I think that you have a, you know, you have a fiasco like Grok did in the news. You don’t need to get into the details, but it was, it was bad. And I think that that people see that and they’re like, okay, I’m kind of adverse to using the model. And I think that that is going to keep engineers on kind of the straight and narrow in terms of how do we make sure that we’re building trust into these, into these models. Now, from a compliance standpoint, from a GRC professional,

where do we get our, our kind of work from? Like, why do we reach out to our first line folks and provide credible challenges? Because we understand the compliance requirements. And the thing is right now, unless you’re going out and getting like ISO 4,201 certified, and maybe there’s some others I’m missing. We don’t really have those clients compliance requirements yet. The EU AI act was, or, or is kind of our biggest.

enforcer in terms of getting obligations and requirements for large language models. And you’re not going to see requirements for that being enforced for the next couple of years. And even now with the requirements that have been enforced, it’s they want model cards, technical documentation, some level of risk assessment. So we’re not necessarily seeing that we need like a full suite of like controls or control assurance activities.

Tristan Ingold (53:05.164)
related to LLM models. And that’s, I guess, like across the industry.

Raj Krishnamurthy (53:10.232)
Got it. We are approaching the end of the segment, Tristan. I wanted to ask you for the new person, the new graduate, right, who’s coming out of college or somebody who just started their career in IT or security, how would they build a, how do they move and build a career in security GRC? What would your advice be?

Tristan Ingold (53:31.64)
I love this question. I get the opportunity every once in a while to go to the University of Washington or the University of Seattle and talk with students that are, have degrees like myself in business with a focus in information systems, or maybe they have a degree in security and they’re like, hey, I’m not sure how to approach this. The world of GRC and security is so broad. How do I kind of like make my, make my way in here?

I think that you should begin going to events and talking to other professionals about the work that they do. I was just talking to somebody the other day. They have almost the same title as I do, but they do threat intelligence. And that is a completely different world from like controls testing where I’ve come from. But maybe let’s have a discussion around like what makes you attractive to an employer, right? A lot of folks that I’ve talked to are very quick to say, okay, well,

I’m gonna learn Python and I’m gonna learn SQL and I’m gonna be able to script. And I tell those folks, know, hey, well, if you wanna do like pen testing, if you wanna do some controls automation, that’s like really helpful. you know, I don’t necessarily, I mean, could, if you really, really wanted me to, I could put some Python together, but it’s not necessarily something I do on my day-to-day job. So,

Become technical, but become technical in enterprise platforms. Become technicals in tools and platforms. And so what do I mean by that? I mean, do you know what Kubernetes is? Do you know what Docker is? Do know what Ansible Jenkins? Do you know what PeopleSoft is? Epic, SAP. you know all organizations worldwide are implementing those types of applications into their organization and they process lots of data, sometimes sensitive data.

They’re absolutely business critical. And are you able to step into organization and say, you know, hey, we have some security controls related to SAP that are very important. Can you explain to us like why those are important and be able to explain like what that application does or that platform does in communicating effectively why it’s important to make sure that we’re maintaining

Tristan Ingold (55:49.932)
the confidentiality, integrity, availability of those systems. So that’s one piece of it. Know the platforms, know the tools of the trade. And you don’t need to start up instances of these things and use them right away, but be able to talk to them. And then the other thing is understand business process. I think many times, even talking to seasoned GRC professionals sometimes within an organization,

One question you ask is how does your company make money? How do you bring revenue into the door? How do you recognize revenue? How do you run payroll? How do you pay your suppliers? If a customer returns a product, how do you make sure that you’re bringing that product back into inventory and giving that customer their money back? Now that’s a financial compliance conversation a lot of times, but those are still systems that are holding

maybe credit card data, maybe customer address, maybe a customer first name, last name. And so those need to be protected from an information security standpoint. And so I encourage new folks, again, learn the platforms, the tools of the trade, also understand business process and be able to have those conversations because it’ll make you that much more attractive when you’re talking to, you know, director, manager.

and you’re saying like, I can be good, a good asset to this company, not just from an information security standpoint, but I understand what you do and how we make money. And that makes you attractive to those first line stakeholders as well.

Raj Krishnamurthy (57:30.742)
I think that is great advice, Tristan. And now we come to the end of the show. Thank you very much, Tristan. This was fantastic speaking with you. And good luck.

Tristan Ingold (57:39.438)
Thank you so much, Raj. I really appreciate it.