Beyond Checkbox Compliance: Why GRC Must Become an Engineering Discipline ft Sheron Chakalakal, Head of GRC @ UiPath

In this episode of Security & GRC Decoded, Raj Krishnamurthy sits down with Sheron Chakalakal, Head of GRC at UiPath, to explore why the future of GRC looks far more like systems engineering than traditional audit management.

Drawing from his experience at Salesforce, Deloitte, and UiPath, Sheron explains why point-in-time audits and checkbox compliance are failing modern engineering organizations — and why risk-driven, continuously monitored GRC programs are becoming essential. The conversation dives into AI governance, continuous risk monitoring, customer assurance, GRC engineering, AIUC-1, and how security, compliance, and engineering teams must evolve together.

This episode reframes GRC as a technical reliability function that helps companies reduce operational risk continuously instead of simply passing audits once a year.

Key Takeaways:

• Modern GRC programs must evolve from audit functions into engineering-driven reliability functions.
• Risk—not compliance—should be the central language for communicating with leadership teams.
• Continuous controls monitoring is essential because point-in-time audits create “checkbox theater.”
• AI governance requires technical evaluations, agent testing, and continuous assurance beyond traditional frameworks.
• Future GRC leaders will need technical depth, business context, and the ability to bridge engineering with executive leadership.

What You’ll Learn:

• Why Sheron believes compliance should be designed into products from day one
• How UiPath approaches continuous risk monitoring and GRC engineering
• Why AIUC-1 introduces a fundamentally different approach to AI assurance
• How GRC teams can become the “translation layer” between business and engineering
• Why future GRC practitioners must develop technical and systems-thinking skills

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:
Sheron Chakalakal | Head of GRC | UiPath
Connect on LinkedIn: https://www.linkedin.com/in/sheronpaulc/

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:00.834)
Hey, hey, hey, welcome to another episode of Security in GRC Decoded. I'm your favorite host, Raj Krishnamurthy. Today I have the privilege of having Sharan Chakalakal as our guest today. Sharan is a 15-year-plus veteran, started as a software engineer, and he currently heads the GRC program at UiPath. Sharan, welcome to the show.

Sheron Chakalakal (00:14.037)
Yes.

Sheron Chakalakal (00:25.547)
Thank you so much. Thank you for the invitation and I'm really looking forward for this conversation.

Raj Krishnamurthy (00:30.722)
Chakalakal, that's the right way to say it, right? Chakalakal. Boom, Chakalakal, okay.

Sheron Chakalakal (00:32.855)
Yeah, think about Bumshakalaka. Yeah, you get the term pronounced right. After so many years in US, I've just coined that term. It just makes it easy for people.

Raj Krishnamurthy (00:42.894)
Thank you, Sharun. So Sharun, I want to start with this. You've been at Salesforce, you've run the security compliance at Salesforce, you've been with Deloitte, been in the audit cycles, you now head the GRC team. What is your heart take or one controversial take on GRC?

Sheron Chakalakal (01:05.334)
Yeah, I've been thinking about this for a few days. What is my heartache? It's funny with all the drama that is happening in our industry right now with everyone giving so much weightage. I have non-GRC friends, non-tech industry friends asking me about GRC because of all the drama that's going on. So I would say maybe we should start doing Fair Play Awards for any great reports, any socked reports, anything that, what do you call, you know.

Raj Krishnamurthy (01:29.976)
Fireplay Awards.

Sheron Chakalakal (01:34.037)
that is an actually good report. The stick is not working. mean, giving back the, what do call, hundreds of questionnaire, giving back lot of, know, feedback is not working. Maybe we start doing awards for that so that at least we get some better reports.

Raj Krishnamurthy (01:48.168)
Let me make sure I understand. So number one, you said there's a lot of drama going on. I think I understand what you're saying. Are we talking about some of the recent fiasco around SOC 2 reports that happened? OK, got it. We don't have to name the name companies or anything, but I think I get it. And maybe let's double click on it. What do you mean by the Fair Play Award? What will qualify for a Fair Play Award?

Sheron Chakalakal (01:59.893)
Yes.

Sheron Chakalakal (02:07.862)
Yes.

Sheron Chakalakal (02:12.829)
For me, lot of the aspects go in, right? Like nowadays.

It's become a cookie clutter tailor-made SOC 2 report where section 3 becomes like almost same for every single person in company. If you compare lot of the things, I would wish if people actually talk about the risk, actually talk about all the changes that have happened in the last one year in their report and how those changes have been ingrained. Actually giving some what do you call meat to the changes that have happened in their company versus just zero changes in their SOC report.

Like section three for me is where you can actually give lot more information to your customers where, so that they are happy with lot of the things, know, testing aside, independence aside, they can also get a lot of information from the section three side where you talk about all the things, all the processes in place. I would love to see that more of a weightage. Plus if there are any formation of continuous monitoring controls called out, anything progress they have made, we have moved away from this manual to this continuous one.

kind of like having that ongoing dialogue with customers that would be really nice.

Raj Krishnamurthy (03:19.606)
And why do you think customers are not doing that today? Or vendors are not doing that today?

Sheron Chakalakal (03:24.663)
It's, I think it's just an overall cycle of an issue, right? Everyone is asking for a SOC2 report and an ISO report from a small startup to a big enterprise company. And they expect kind of like the same quality, same rigor everywhere. So a lot of the places where people can actually, you know, people have a lot more questions coming in, a lot more, what do you call it, overhead coming in with all these customer facing stuff.

they're trying to get away from it. So having a checkbox audit, having a clean report gets them into the, what do call it? Table to have that conversation. And that just became like a, what do call it? Like a trend for everyone, at least for lot of the companies. There are many companies who do it great. There are many companies who sock to report actually provides a lot of value. But at this point, yeah, I hope AICP and others actually take some action and we have some more weightage.

coming in this October.

Raj Krishnamurthy (04:24.299)
See, I think I used to, this is many, a couple of years ago, many years ago I should say, that I used to work with the CTO of a very large banking and financial services company. And she used to say this. She said that, you know, Raj, I have to, all my sort of star engineers get sucked into compliance, right, and have to comply. And I actually may not get a pat in the back if I do a great job.

but I'll surely get fired if I don't. That's stuck with me. Maybe that's a little bit of exaggeration that stuck with me for a very long time. The reason I'm asking that question is what I typically see is just work hard enough not to get fired, right? Maybe that's a very crude way of putting it. So how do you see the incentives? What incentives do you think we need to create for vendors to be much more forthcoming or to your fair play award, if you will?

Sheron Chakalakal (05:23.058)
I think it's it's top to down. Leadership should look at security as ingrained into their what do you call product design itself. You will see it is slowly coming up with lot of the customers asking for product features. You're seeing a lot of governance features coming in all our products. If you have this product do all of this, you already have SOC 2 features built in ISO features built in. So it's good to see that but.

I think leadership and the culture of the company really dictates how much they're going to invest in security and that dictates everything else.

Raj Krishnamurthy (05:57.878)
Interesting. So what you're saying is that you're almost making an argument that compliance has to be designed in. It's almost by default, right? And that has to come topstone. That's your perspective.

Sheron Chakalakal (06:11.605)
Yeah, 100%. Compliance should go hand in hand with security, and security should be right at the start of the conversation when business strategy is being made at the start of the year, and then continues throughout the year.

Raj Krishnamurthy (06:21.751)
Correct. And what is the role of

folks like you, right, leaders in the GRC team, to convince your leadership of this, because this is not going to automatically happen, right? This requires investment, this requires, you know, re-skilling in some ways, re-tooling. So what are you telling these leaders so that they sort of support you in this endeavor?

Sheron Chakalakal (06:45.087)
I think it's a thing of help us to help you, right? One of my mentor used to tell us, Sharon, look at GRC as a pit stop crew for an F1 race. Like the driver and the race, both your objectives are to win the race, right? The driver wants to go as fast as possible. And your main objective is to make sure that the car actually survives till the end of the race. So your objective is pretty much the same.

making sure that the leaders also understand that. For example, they want to expand internationally. Hey, you can tell them, hey, let's bake this in right from the start. You want to go to Australia? Let's do IREP features right from the end, bake in from the design so that you're not doing it at the last stop. Based on that, you can add in built-in security features, your data residency issues, lot of those other things. So...

If you meet with them in the middle of you can see this as an enabler of more sales, more customer trust, more of a lot of their objectives, then they would come back and talk to you more, ask your advice more.

Raj Krishnamurthy (07:51.97)
So you're saying that, think one, if I paraphrase what you're saying, the conversation has to happen in terms that the business leaders can understand so that they can work with you, they help us to help you sort of thing, right? Okay, but do you, because one question that almost, if you're a non-GRC professional, is that you see all these phenomenal,

Sheron Chakalakal (08:15.778)
Mm-hmm.

Raj Krishnamurthy (08:21.357)
breaches, and I'm not going to use the word fantastic because that gives credence to it, but the idea is that you see all these massive breaches that happen, and all these companies that have been breached is not because they don't have your compliance frameworks. They have all the compliance frameworks, but still they get breached, which means that fundamentally there is something wrong operationally. The audit and the assessment of risk does not tally with what's happening in the ground.

And leaders tend to carry these perspectives as well. So how are we trying to convince them beyond saying that if you get this certificate, you will close this deal? What is their incentive to make this continuous and have the continuous visibility into operational compliance?

Sheron Chakalakal (09:03.574)
I think the moment you start equating compliance to security, you will lose that case. every other breached company might have some compliance report.

That doesn't mean that they're secure or there might have been some issue, right? I think the way we channel our conversations is away from compliance itself. We channel it via risk. talk to our board and our risk buy-down model. talk about year is the investment that we need to get this risk from this particular year, or what we call dollar value to this particular dollar value year, the investments. And we go throughout the year to talk about it from a purely risk quantification angle.

call out, here are the way other companies got breached and here's the way where we would have not got breached because of the controls. So slowly you tend to have that dialogue of they can slowly see that it's not just creating value, but also stopping a lot of the things that could have happened.

Raj Krishnamurthy (10:01.397)
No, I love it. I love it. So you're saying that obviously the word G and R and C we talk about, we go around in circles, right? Everybody understands these terms. But your argument is that you will have to position this from the perspective of risk in order to resonate. Now, how do you tie that with continuous visibility or continuous controls monitoring? What is the term that we use, right? Why should I make it continuous? And how is that going to resolve in any better risk posture?

Sheron Chakalakal (10:14.253)
Yes.

Sheron Chakalakal (10:29.426)
I when compliance teams, when GRC teams started getting integrated into engineering, you can see all.

operational engineering teams having some form of continuous monitoring in their processes. Whether you take release management, you take SRE, you take DevOps, every single one of them have some form of continuous monitoring principles in them. I mean, we talk about SRE on our side. We take a lot of inputs and learnings from them. Their own SRE principles are the same, have continuous monitoring in place, reduce toil, automate anywhere possible, monitor all wherever you can.

because for them it's not just about a particular SLA, it's also about if something goes down, that's a dollar value. So for them, it's another risk buy down model to make sure that things don't go down. It's an actual cost. So it's similar to us. If you talk about everything from a risk perspective,

If we go from a point in time perspective, it's just a checkbox at that point. But if we go from a continuous angle of, is my 18,000 databases in my whole inventory, and here are the places where we have read, let's go to the engineering team and check why they are read. Let's go and check why they are not encrypted or why their backups are not in place and have those built in and automated. That's the only way you can progress. Otherwise, it's just going to be a theater show.

Raj Krishnamurthy (12:03.09)
I love it. I love what you're saying. But what do you see? So you sit and you've always sat within the security, is that correct? Under the CISO's.

Sheron Chakalakal (12:12.736)
It was interesting. in Salesforce, we started inside the legal team, GRC, and we eventually in the later half of my career in Salesforce, we transitioned into the security team. And I love that because no disrespect to legal and everyone, but for me, GRC belongs within security and belongs very close to engineering.

Raj Krishnamurthy (12:17.462)
Okay.

Raj Krishnamurthy (12:35.243)
Why?

Sheron Chakalakal (12:36.288)
Because we are working on the product side. We are working on the product, we are working on the security of the product and the infrastructure that's delivering the product. So we work very closely with them, the controls, the risks, the processes that are built are around delivering a product in the end. So we should be close to the engineers, to the products, as well as that helps us to tie in lot of the, you know, where our actual crown jewels are.

We also have on the other side, the controller side, the HR and the legal, they are all the crown jewels as well. But this is where you are actually making the money for the company, right?

Raj Krishnamurthy (13:12.8)
No, I think that's beautifully said. I like the contrast. But what is the role, maybe I go into the basics, what is the role of the GRC team vis-a-vis the security engineering team and the security operations teams?

Sheron Chakalakal (13:28.768)
I don't see their goals as any different. Everyone, even the security operations team, the security engineering team, like we all reported the CSO. And one way or the other, everyone's job is to reduce risk.

on their special category. Like we look at the whole company as a whole and we help them to understand in a better way which risk can be taken care of or which risk should we be attacked in the next, what do call it, particular year. So this is something which my team is building is a continuous risk intake model where we are taking vulnerability reports, we're taking threat analysis, we are looking post mortems and all of that and eventually create threat signals. And that would help us to think about

where all the new risks are coming in and build projects under security engineering, under security ops, under SRE so that we'll continuously buy down risk.

Raj Krishnamurthy (14:23.678)
Interesting, interesting. love this. So you are almost advocating, we use these terms, GRC engineering and all these things, but I think you're basically advocating that, did I hear that right? Maybe I should ask this question. You want the GRC team to be able to ingest all this different data and produce meaningful signals from a risk perspective and potentially even feed back into security engineering and security operations. That's what you're advocating.

Sheron Chakalakal (14:50.582)
Yes, it's a loop. It has to be a loop. Yeah.

Raj Krishnamurthy (14:53.292)
It's a loop, brilliantly said. Now, so that means that the GRC team has to be sort of technical enough to be able to do this. Is that correct? What challenges have you come across in trying to build such a

Sheron Chakalakal (15:01.496)
Yeah, correct.

Sheron Chakalakal (15:08.694)
I think it's the transition of GRC being accepted as an engineering team. In the past and lot of the time, and I wouldn't say that it has to be complete engineers. It has to be a mix of people who understand business.

Raj Krishnamurthy (15:14.913)
Mmm.

Sheron Chakalakal (15:26.476)
people who understand frameworks and people who are actual engineers who can build systems. Because that's the only way you can become an engineering team one way or the other. It's like in the SRE team, you're finding all the SRE engineers, but you're gonna have very few TPMs or PMs with them. It's because it's an engineering function and their first role is to build systems to safeguard systems. It's the same thing that we want to do. We want to get there, but.

Typically, it's not been how it's been seen in the past. And it's also because how engineering, how GRC teams were fed. Like for me also, the entry was from Deloitte, which was a big four. We were doing audits the whole time and then we moved to the industry. I think what I've realized is as you go more and more into a company, which is like engineer driven, you need to get more and more technical, speak the language, be at the same, what do call?

You don't have to code, at least you need to understand code. You need to read code. need to understand the architecture diagrams and so on.

Raj Krishnamurthy (16:28.736)
But I think beyond coding, think the argument you're making is very central. think what you're basically saying is you're seeing GRC as a systems engineering discipline. That doesn't have to mean that everybody has to code, but everybody has to think about this from a systems engineering principle, the first principles. That's what you're saying. Now that is brilliant. The last time we spoke, you said that you see GRC as a translation layer, as this main glue that stretches these things together.

Sheron Chakalakal (16:46.114)
Yes, correct.

Sheron Chakalakal (16:58.422)
Yes. I think it's because we understand where the business is going. We see, here are the new regions that they are trying to address. Here are the new vectors or industries they are trying to go to. We talk to the GTMs, we talk to the support teams, we also talk to the legal. So we branch out much more than the products and engineering. So in that way, we are more closer to business than any other security engineering team. So we become their voice.

Raj Krishnamurthy (16:58.432)
What did he mean by that?

Sheron Chakalakal (17:28.14)
we also become the reasoning at that point. And that way, anything what they wanna know how where the business is going, we kind of become the portion. The risk also drives a lot of those conversations. That's how we kind of like become like the glue between business and engineering.

Raj Krishnamurthy (17:47.252)
Okay, makes sense, makes sense.

I think the entire, our conversations are fundamentally being, also being transformed, right? I think JNI is becoming a very central piece. You are on the AIC consortium, right? I know that you did some presentation with Rajiv as well. You are a consortium member. Explain to our audience what AIUC-1 is, what AIC is, what AIUC-1 is, and what is your role as a consortium member? What do you do there?

Sheron Chakalakal (18:20.354)
Yeah. For me, AIUC as a whole is an organization who's trying to advocate agent security. Every day, they're looking at different domains of how agents are going to evolve and how we as an industry can build in a more secure fashion. That's how they introduce the AIUC-1. Now AIUC-1, what I liked about AIUC-1 when I start looking at it, it is risk-based. Great.

It is governance based, which has ISO 42001 frameworks. gives you overall framework, but it doesn't stop there. It has technical evals. It actually, it's one of the first framework that asked me how my product works. It's not just looking at the infrastructure. It's looking at the product. It's looking at how it's working. It's looking at how the customers are adding data into it, how the data flow works, and it's doing technical evals. Think about audit plus pen test.

That's how I would phrase AIUC1. And that's one of the reasons I really liked it. The approach more than anything. And I think it will go a long way. And I think that's where the industry is trending, where you will have a certain section for governance and policies and the company strategy and everything. organizations are start going to demanding more technical evidence of where you are exactly.

Raj Krishnamurthy (19:39.991)
Help me, I'm not very familiar with AIUC-1 and I wanted to sort of familiarize myself with that as well. But what do you mean by technical evals? Can you give us a very clear, tangible example?

Sheron Chakalakal (19:52.3)
Yeah, they attack, not attack, they look at multiple domains, right? Reliability of an agent, safety of an agent, security of an agent and so on. And so when you are working with them, they will evaluate your product. They will run thousands and thousands of technical evaluations. It could be on prompt injection. It could be on...

misuse of the agents, harm to the agents. It could also be trying to extract data leakage and trying to extract information with them on a commanding way. Many different patterns how an agent can really behave in different circumstances. They are really stress testing your agent in a live scenario. For me, that was interesting because it's not a simple pen test. They are going through every single angle of how can I exploit an agent to try getting the data because in the end,

AI is a data security problem, right?

Raj Krishnamurthy (20:48.811)
I see. Got it. So how would you, so for example, if I have a bunch of agents and I'm delivering those agents through MCP, right? I have a bunch of MCP servers that are sitting behind. How do you, hand over these agents to AIUC and they just prompt their way in to try and figure out all these different aspects? Is that how it works? How do they do the evals?

Sheron Chakalakal (21:09.452)
So to give an example, they took a testing environment of our product. We built what you call like a typical customer data repository would look like, like a data set would look like. And then they worked on the staging product, the testing product, and built all their evaluations based on that. And we were looking at all the evals and how it would actually work with our product that typically a customer would sign up for.

Raj Krishnamurthy (21:37.065)
Got it, got it. And each of these eval is essentially a prompt that is looking for a certain thing. It's looking at an output and it is benchmarking, right? Got it, beautiful, beautiful.

Sheron Chakalakal (21:44.76)
Correct. Yeah. it's like, we could have done that on a separate way. Like we could have done our own pen testing, right? It's fine. People do it. But this is where the pen test, the scope is not in our control. That's governed by the standard. So there's very little room for us to play with that. That forces your hand to actually improve your agent.

Raj Krishnamurthy (22:10.133)
Got it, got it, fair enough. what, I mean, so you did this as part of UiPath, and you wanted the UiPath product to be certified on AIUC-1. What was driving that decision? Was there anything particular that was driving on why you took the AIUC-1 route?

Sheron Chakalakal (22:29.674)
multiple ways. So there was nothing really actually out there. There were pen tests and stuff, but there was nothing really out there to actually give assurance to our customers. We were getting more and more questions about our agents, about the security of the agents, to the point where we are getting addendums of AI. And when we looked at this, we were like, this might help us to reduce a lot of that. Plus also,

test our own products, like, let's see what comes out of this. And there were also a lot of things that helped us to improve things about our own product. We did a pre-eval, we fixed a lot of things, then we did the actual audit, then the report came out and stuff. It's a great question you're asking because my leadership asked me the same thing. What did we get doing the certificate? And we were able to show them, here is where the product was initially, and here are the changes that we have made after the evaluation.

Raj Krishnamurthy (23:24.459)
Got it. And how long did it take for you to go through this process? Four to six months. Okay, got it. By the way, I have to congratulate you because I think you're one of the early companies that went through this process. I know you, so I think that takes a tremendous amount of courage and challenging status quo. So I want to definitely a huge congratulations to you and your team for having done this.

Sheron Chakalakal (23:28.67)
I four to six months. Yeah.

Sheron Chakalakal (23:39.052)
Yes.

Sheron Chakalakal (23:49.048)
What worked for us was the message that it would come out. Like our CISO was a founding contributor in the AIUC standard, which helped what you call it with the communication to the, you know, the broader leadership channel. It kind of helped us to drive the engagement. And if we are helping in building the standard, why not stress test it? Why not do it internally as well?

Raj Krishnamurthy (24:15.647)
Got it, makes sense. I wanted to sort of move this from the, I want to understand the intersection of the, so AI UC1 absolutely makes sense from a product perspective because UiPath is building a bunch of agents. What is that correlation of that to the GRC work that you and your team do for UiPath?

Sheron Chakalakal (24:28.824)
Mm-hmm.

Sheron Chakalakal (24:38.146)
So within GRC, also are ownership of, we have the ownership of data security. So we have data governance. So our AI governance overall program domain sits within the data governance because in the end it's a data problem. AI UC security is only on the processor side, right? It's only helping.

not only, but it's helping what you call show, demonstrate our customers, like the stress testing of the agent. But we have the controller side also, like our own employees using different agents, own employees using shadow AI apps, downloading it, using random things. I mean, you saw the recent security breach that could happen to anyone. So our AI governance program goes much more than AIUC. It would take what you call industrial

risk, the top OAPs risk, all the other risk categories that have been called out. think MIT also came with mid-trade risk. So lot of those combinations, build out. Yes, my track list. And then we take all of that and build our own control history repository and test it based on that, both on the controller as well as on the processor side.

Raj Krishnamurthy (25:42.975)
You're talking about the Midr-Atlas. Okay, correct.

Raj Krishnamurthy (25:53.823)
Makes sense, makes sense. Now, the reason I'm asking, I was asking that question as that I think AI UC is looking at this outside and almost like a black box pen test, right? But there's a lot of things that have to happen within because your agents are fundamentally composed of large language models and APIs and there is a whole layer behind it in terms of making the operations happen. How do you validate that? By the way, do you apply AI UC 1 to your vendors?

Or do you expect it to? How are you thinking about AI UC1 and how you are consuming within the AI path, UI path, with other products that you are using?

Sheron Chakalakal (26:33.014)
I think we are asking the same. We haven't made it compulsory for anyone. We are asking the same questions to everyone. Like how do you stress test your agent before using it?

Raj Krishnamurthy (26:37.929)
Okay.

Raj Krishnamurthy (26:44.436)
Beautifully said. Beautifully said.

Sheron Chakalakal (26:46.272)
It could be anyway, this is, this was a way we chose. And eventually I think the industry might go the same way like people did when they had confidence in high trust. It might go the same route, but for me, it was more so like, want to stress test your agent. If you already have proof, let me know. Otherwise we will ask you more questions around it. And your question around the infrastructure part, that is also pretty important because AIUC is looking on the product side, but you have other tools that actually set a link to your models.

linked to your notebooks, linked to your GitHub repositories wherever the code sits and it scans on a continuous basis and it forms kind of like a what do call it like a risk repository similar to a viz. So think about it as like viz for your models. So

There are multiple different angles you can go with this as part of AI governance. AI UC just becomes one jigsaw puzzle. There's another tool called Nomaseq. They have become another jigsaw puzzle. And then now we have using tools like tools that will sit on your browser. They will look for anything if people are using prompts, if you're putting any customer data into the prompts. browser-based tools, application-based tools. And the funny thing about AI is,

has given a lot of problems but it has also given rise to so many startups and so many companies that are looking at this problem. It is a chicken and a egg always.

Raj Krishnamurthy (28:09.93)
100%. 100%. 100%. No, I think you said it beautifully. So one is that I think as a software provider, right, you have layers of services that you're building. You're using your cloud services, you're building your own application infrastructure on top of it, and then on top of it, you build your agents, and then you're sort of testing your agents and you're handing this over to your customers. And I think you talked about AIUC from the perspective of a brilliant perspective of pen testing tops down.

or sort of outside in, are there frameworks that you work with typically, the usual GRC frameworks that demonstrate assurance continuously for the infrastructure within?

Sheron Chakalakal (28:55.072)
Unfortunately, We have to build our own. I think we started off with like a base of your own SOC 2 ISO, your HIPAA and everything, but we quickly realized that they would just always go in a high level. So the controls kind of remained the same at a high level, but the requirements started getting more and more in depth.

we started playing one more plus one. Let's go into infrastructure. Let's look at all the databases. Why not just production? Let's look at dev tests and see where we have some gaps. So we also started building domains based on, we're starting to, we haven't, I shouldn't say that, on incident response. Based on incident response, you build down more controls on.

specific to the attack vectors to your company. So in that way, eventually it modifies very specific to your company versus like a standard framework.

Raj Krishnamurthy (29:48.091)
I know I love it. Let me make sure I understand what you're saying. So when you say that you're building and extending these controls, and we don't have to talk anything specific about any company here, but in general terms, when you say you're extending the controls into specific areas, right, why not just deal with product security database? Why can't I expand? Are you saying that you're implementing these controls by yourself? Does that fall back into a standard or do they all fall back into the standard stock?

Sheron Chakalakal (30:18.818)
They all don't fall into the standard SOC 2. In fact, we use GRC, we also have GRC tools, but we never use it for audits. We use it for continuous monitoring. We are building what you call infrastructure controls through a lot of the things which we can't, you pull from our own agents and from our own robots. We are using other GRC tools so that we can get all type of, what do call it, data points that are running on our infrastructure and then build controls around it. Yeah.

Raj Krishnamurthy (30:44.906)
Got it. No, I'm with you. I'm with you. I'm with you. That makes, that makes. So.

Sheron Chakalakal (30:47.8)
So in the end, could be like encryption at rest, right? It's a simple term control, but that could be in variations of different types of databases, your backups and so on and within those types.

Raj Krishnamurthy (30:52.351)
Got it.

Raj Krishnamurthy (30:58.782)
Yep. One of the challenges that we hear from the practitioners, I should say generally speaking, especially people who are getting into GRC engineering, right, is that most controls are notoriously abstract.

And engineers think very concrete. They don't understand abstract. So how do you balance these two? Because you seem to have sort of crossed into this. We have done a lot of the implementations of it. But you're also trying to satisfy this through a broader risk control or risk management perspective. How are you bridging this gap?

Sheron Chakalakal (31:40.088)
We cannot talk to engineers from a control language. It's just too high level for them. We would have to talk about what do call, we make like these blueprints, what do you like an infrastructure blueprint or for like a service blueprint. If a service is going through these particular audits, here is the specific, what do you call, like almost like a Terraform template for them.

Like this is the template you would have to follow for your particular service and so on. So it just helps to talk about in a language which they would understand versus here is a control statement which is pretty ambiguous at a high level. So we also keep the control language pretty ambiguous because that is more so for us, like at a high level everyone can understand, but the one level below that, which is like the requirements that will go much more in detail.

Raj Krishnamurthy (32:30.599)
And who's responsible for translating the policy statements to the control narrative, to the requirements, to the implementation? Whose responsibility is that? I'm saying which team is responsible to do

Sheron Chakalakal (32:45.24)
So policy to control to requirement becomes responsibility of the GRC. And then we work with the SRE teams, the SecOps, the SecEngine, everyone to help us to bridge the gap of the technical layer of it.

Raj Krishnamurthy (32:58.983)
Got it. And where does the role of GRC engineering within your GRC team, what role does that play? Where do they come in?

Sheron Chakalakal (33:07.148)
I think that's where it will slowly transition, right?

Right now, we take the first half business to technical layer, but we are not going full depth into the technical layer just within my team. I just have one principal GRC engineer. He cannot be everywhere. But we take the help of security champions in different service teams. We take help of security engineering and all the other security functions. Eventually, it should come back to GRC engineering because in that way, we will know the full layer of a particular control requirement to implementation.

Thank

Raj Krishnamurthy (33:43.189)
100%. And security engineers are already, when I think of them, I think of the whack-a-mole, right? I they're constantly trying to sort of solve the production problems. How do they react to when you go talk about GRC or GRC requirements to them? Do they ever say, have my day job, let's talk about it next month, or do they ignore you? What happens in that relationship and conversation?

Sheron Chakalakal (33:49.624)
Yeah.

Sheron Chakalakal (34:07.352)
It's been a funny transition. At the start, it used to be a pain because GRC has a bad, what do call it? It has a bad story, backstory from the start. People have been introduced to compliance as, my God, this is such a painstake. No one wants to check the box. No one wants to look at it. But then when they slowly understand your objectives are the same, they sometimes use compliance as a carrot or a stick.

Raj Krishnamurthy (34:19.721)
Mm.

Raj Krishnamurthy (34:25.085)
Just check the box.

Sheron Chakalakal (34:35.96)
Or you've got to do this for SOC 2, my security engineers are telling this to someone else. And I'm okay sometimes doing that because in the end our goals and the objectives are the same to get a particular risk down one way or the other. So if they're using compliance as a carrot, fine, go ahead with it. So that way I help them in that and they would help me in the actual implementation works out.

Raj Krishnamurthy (35:01.485)
When we sort of briefly spoke last time, were talking about, correct me if I'm wrong, you were talking about GRC extending into customer assurance. Am I saying this right? What is your view on that? What did you mean by

Sheron Chakalakal (35:16.822)
I think, so we sit very closely to our customer facing team. I applaud them, I can never do their job because they always get bombarded with all type of different questions and always on a customer facing side. But we sit very closely with them to understand the signals of the customer. We try to see, hey, you send out an audit reports to them. What was the feedback? Did you get more follow up questions? And what type of questions?

They in fact have a role in dictating some of our control warnings and some of our control implementation statements that would help customers to have more faith in our reports and so on. So it's kind of like a back and forth dialogue with them. We help them to reduce their burden in front of the customers and they would help us to be very close to the customers on how they are looking at our products, how they are looking at our controls and having that feedback on.

Raj Krishnamurthy (36:14.001)
One of the challenges that I've always found is that people talk about first party risk and third party risk, right? And it is sort of very interesting, especially if you're a vendor. And what happens is that you're doing a lot of this assessment and like you were talking about a significant amount of controls that you're testing. know, every single user that has MFA enabled, non MFA enabled. The reality is that it is very difficult and it's a very complex environment. But when you present this to customers, we don't present any of this information, right?

you're giving them a very basic high level overview, which is what you're supposed to do. And my question to you is that you have a lot of insights into what's happening on a daily basis. And you are trying to pass this information almost like a curated information to your customer success teams or customer assurance team. How does the translation work? mean, does this information, do they ask you for details and does the details give them confidence or what happens in that convo?

What happens in that conversation?

Sheron Chakalakal (37:14.978)
So we have architectural discussions with our customer facing team ourselves, like not just us, they talk directly to the security architecture team as well, security engineering team as well, because they want to know as much as possible to answer customers questions so that they don't come back time and time again to the engineers. But for me, if we put everything out there, does every customer really want to go on that level, right?

So we give a layer to them. Here is the minimum bar layer, which we give everyone. And you can poke at us, you can ask more questions about us, and we can happy to go in more in detail. For me, this is not just about the customer, but also the internal crown jewels, not just looking at it as a processor, but also looking at it as a controller. So I need to have the whole view on it versus just what the customer needs.

Raj Krishnamurthy (38:05.736)
Got it, got it. Have you explored, have you come across zero-knowledge proofs in GRC before? Okay, so the idea of a zero-knowledge proof, and by the way, there is no implementation, this is theory, the idea of a zero-knowledge proof is to provide assurance without providing details. So for example, I mean the easiest example people say is that I have two doors, you're sitting on the other side, you are the verifier,

Sheron Chakalakal (38:12.534)
No, I haven't. What does that mean?

Raj Krishnamurthy (38:35.278)
You want to know if I have the keys to those doors. One way is to do is that I give you the keys and you can go plug in the keys and you will know if it works and as a verifier you know that what I'm saying is right or wrong. But in that case I'm going to give you what the keys are, what my secrets are so that you can go test and that's not going to work. The other way is that you ask me a bunch of questions. You say come through door one, come through door three, come through door five and every time I come through it and that way you know that

Sheron Chakalakal (38:37.986)
Hmm?

Raj Krishnamurthy (39:04.942)
I can come through the doors, which corollary means that I have the keys, without giving you the keys. This is a sort of a rough example, and this is actually very much in the blockchain transactions. the reason I'm asking is that, I'm saying this is that we have not had these conversations in GRC. And in my opinion, GRC is very ripe for some of these conversations. That's why I was trying to understand.

Sheron Chakalakal (39:25.589)
I think the balance is important. Giving enough information that a customer needs, but also not making your, what do call the security story as a burden to the customer facing team. That balance is definitely important so that they can, you know, don't have over it of just addressing customer questions so much.

Raj Krishnamurthy (39:48.84)
100%.

Sheron Chakalakal (39:48.854)
And also at the same time, having that many follow-ups to read. So there always has to be a balance. Yeah.

Raj Krishnamurthy (39:52.841)
It's a balance. 100%. I wanted to ask you a slightly different question. I think in the last few weeks, everybody's talking about MITAS, right? And what is your opinion of the pace of sort of, I would say, the likes of MITAS? And particularly, we know how it impacts the security teams. My question to you is that how does that impact the GRC team?

Sheron Chakalakal (40:20.408)
I think at this point we are just taking in because things are coming in at such a rapid speed. Like today we are ingesting a different type of attack that has happened.

Raj Krishnamurthy (40:25.265)
Okay.

Raj Krishnamurthy (40:28.871)
rapid.

Sheron Chakalakal (40:35.544)
Suddenly next day, something else pops up the other day, my thoughts pops up the other day. We looked at the recent data breach at what was had. So there's so many different aspects and so many different attack vectors are coming in. are slowly trying to understand how does this impact my company? If we had gone through the same scenario, would we have been attacked? And if we were to have been attacked, what controls we should add or what processes we should have so that we shouldn't be getting attacked in that.

Raj Krishnamurthy (40:52.37)
Got it.

Raj Krishnamurthy (41:03.56)
Beautifully said. think that, no, the reason I'm asking that question is that this ties to what you were saying earlier, right? Because your point is that you're seeing compliance and governance directly tying to risk. And the way that you're thinking about this is that, what can I do? And this is your argument towards the GRCS in engineering or continuous controls monitoring. Your argument is that, how does that sort of bring down my risk posture? That sort of your...

Sheron Chakalakal (41:04.344)
That's all.

Sheron Chakalakal (41:29.496)
That should be the only conversation. like, like we do talk about opportunity because that is also a way to align our business objective with the company. But in the end, primary goal has been always to reduce risk. Like in the, in the journey of reducing risk, if we create more money and more opportunity for the company, great. I'll jump on it.

Raj Krishnamurthy (41:33.416)
If

Raj Krishnamurthy (41:57.125)
And when you communicate the risk to your leadership team, is it always on dollar terms? Do you talk about like, is there a FAR model? Do you communicate this in dollar terms in terms of what each risk means? Is that how you communicate?

Sheron Chakalakal (42:13.016)
Yeah. So we have a variation of a fair model. It's like a fair model itself. But we internally kind of coined it with our enterprise-based team, kind of like a risk-buy-down model. It is following the same principle, having the dollar value, the probability, the ratios of when it's going to impact, and so on, the final calculations. Everything sits with us.

Raj Krishnamurthy (42:25.926)
Got it.

Sheron Chakalakal (42:38.014)
eventually it branches out into a dashboard which the leadership can look at. We are trying to make it more continuous for them eventually, but that's where we are trying to experiment with agents and seeing how we can pull information, make it more continuous.

Raj Krishnamurthy (42:53.192)
Are there practical challenges in moving, going from sort of the signals, the risk signals? I'm talking about, for example, number of users, percentage of users with MFA access or not MFA access, percentage of users that have not logged in for more than 45 days, things like that, right? Are there challenges going from those signals and bubbling them and surfacing them in terms of dollar value? Do you see some practical challenges, any advice that you would give our listeners?

Sheron Chakalakal (43:18.028)
Yeah.

There's lot of noise. If you need to start collecting data, there's so much data to collect. mean, on our data governance side itself, we see so much that it becomes like, let's cut through the noise and see which data really matters to us. So my advice would be only start small.

look at the first four or five risk, see how you can get quantified and slowly expand. Like you don't have to go with hundreds of risk and then you will never get anywhere. Start with five and then slowly expand into it.

Raj Krishnamurthy (43:52.072)
I think that's a very sage advice. So your point is try and create a baseline and iterate through. No, beautifully said.

Sheron Chakalakal (44:03.042)
What do you think? I'm curious on your side, you talk to so many customers, leaders on a daily basis as a vendor. What do you think on your side? How do you see the industry talking about risk, compliance, engineering? Is everyone asking you, should I look at a SOC 2 or should I reduce my risk? How the conversation flows on your side?

Raj Krishnamurthy (44:28.611)
No, I think it's a very interesting question. I'll tell you, because there is a big disconnect between conversations and reality. And that is because these are very difficult things to do. Because one of the challenges that we see is that there are these silos of what risk is, and what governance is, and what compliance is, and what audit is. Everybody agrees that end of the day, is about managing cybersecurity risk. But

the politics of it, especially in slightly larger companies, actually derail a lot of these conversations. Because at the end of the day, these are very different facets to the same conversation. So to your question back, I think one of the biggest challenges that customers face is where to start. And in many ways, that's why I like the advice that you gave, which is that sometimes it is actually very difficult to go, you know,

I mean, don't want to, this analogy may sound wrong because I'm not about cutting trees or anything, but the idea is that if you really want to cut the forest, right, you want to start with a few trees. You definitely want to understand how big the forest is. You want to be able to at least assess for yourself what it means and how to prioritize, but you can't just dream about cutting the forest. You'll have to get, you know, you can watch the game from the bleachers only so much. So you'll have to get in and cut some of these trees. And as you cut them, you start clearing your way.

Right? So the point is that I think in many ways the iterative model is where you need to start. You may want to have a broader understanding, but I think it is maturing. I think the talk about operational compliance is becoming very central. But I think there is still a long way to go in terms of how to make that happen.

Sheron Chakalakal (46:14.87)
Yeah, I think even us, I'm not going to say we are still learning every single day. There's so much going on that sometimes we feel that it's a whack-a-mole. But at the end of the day, we come back and like, okay, let's go back to basics. Let's go back to the board. Here is unknowns. How much of it can we know ourselves with all the data points who can help us to understand others? Let's start building on that slowly by slowly.

Raj Krishnamurthy (46:39.015)
No, 100%. How do you think about build versus buy, especially when it comes to the GRC engineering as a discipline,

Sheron Chakalakal (46:50.688)
I like both. Whatever gets me to my objective within the within the I'll be more practical, right? Because you only have this much dollar amount to spend, whether it's people, whether it's tools and everything. So combining all of that, whatever gets me there closest and fast, we will combine both. For us personally, the way we look at

If there are solutions that we can build internally through our own products that can be sold as a vertical solution to someone, right? Let's focus more on that. Let's build on that. If there are like these one-offs things, then we can use other build things and then use that.

Raj Krishnamurthy (47:20.709)
Yep, yep, yep.

Raj Krishnamurthy (47:30.555)
Got it, got it, make sense.

Sheron Chakalakal (47:31.288)
It's the same thing we are doing with Cloud versus our own agents. Like if we have like a continuous kind of vertical solution, we are trying to build with our own agents so that we become customers for that and we can provide more feedback to our own products. But if it's something like a one-off thing, then we will just use Cloud or something else that can be like a quick way to fix.

Raj Krishnamurthy (47:52.616)
Got it, got it. And I think you've done a lot of work around agents, and particularly both on the product side and also on the back office. My question to you is that, how do you explain this to your auditors? Because inherently, these are model-driven and probabilistic in nature. Have your conversations changed over the last few years, the way that you used to handle traditional GRC, and the way that you're using handling the agentic GRC? Are there changes in conversations with your auditors?

Sheron Chakalakal (48:20.76)
I think my, the start of my conversation has never changed with them. Cause my question to them is it's funny. A lot of the time they will, they've come with random questions and I like pause. What risk are you trying to solve? Like asking me that question. And then we.

deep dive into that risk question and then provide them proof of how do we mitigate that risk. So whether it's using AI, whether it's using non-AI, whatever it is, when we are there, the answer starts from the what risk you're trying to solve.

Raj Krishnamurthy (48:52.731)
I think this is that, that is super helpful. We are approaching the end of the segment, Sharon, and I wanted to ask you, for a person who's gonna join, right, and we are in an exciting world, how should they think about GRC, where should they start, what should they sort of listen to, any advice for the person who's entering the GRC field?

Sheron Chakalakal (49:18.572)
The way I see roles are gonna consolidate more and more. You may not have a separate risk person, a separate vendor risk person, a separate governance person. You may have one person doing all of this with multiple agents. So be flexible, be like, try to understand your basics, try to get your technical skills ramped up, but also have a breadth knowledge of how GRC connects together and be flexible enough to jump between domains.

That way it helps you to be not just what you call, come in into one category and go between GRs and see you become like that focal point for everyone. Like if you have your technical skills set, like you learn your engineering principles, your how other teams do it. At least you can start building on it, but also be what you call it. Don't fixate on one particular domain. Like be open to the whole program of GRC and then start being flexible around it.

Raj Krishnamurthy (50:18.32)
No, I think this is super helpful. And Sharon, one last, before we wrap up, any shout out to anybody that you want to call or that has made you successful, that has sort of helped you in this journey.

Sheron Chakalakal (50:34.048)
I would say lot of my mentors from Salesforce, they were pretty brilliant. I'll give you one example, it was funny. First year of my career, there was this auditor who missed a quarterly access review. And I was at the start of it and I was like, great, they missed it, I'm not gonna tell them. My manager then shout out to Marzi, she like, no, you have to tell them. And I'm like, why? She said that, well,

our chief compliance officer signs on the letter saying, we are telling you, we are being truthful to you. And for me, that was a light bulb moment. And that's why I put a lot of impetus on the leadership. Like leadership has to take a lot of that, what do you call it, you the drive for the team. Because otherwise, how are you going to educate the next generation?

Raj Krishnamurthy (51:26.842)
Now, I love it. And I think that's a brilliant example as well because in many ways we forget that these audit letters are signed by the management team. It has their name and their ink on the paper, which means that they are standing by whatever is said there. And many times we forget that. now, that, Sharon, this was a brilliant conversation. Thank you very much for spending the time with us today. Best wishes.

Sheron Chakalakal (51:38.754)
Yeah.

Yeah. Yeah.

Sheron Chakalakal (51:52.898)
Thank you so much, Raj, and thank you for the invitation. This was really fun. One of the few podcasts I listened to, because otherwise my toddler would always want to listen to Taylor Swift. Thank you again for creating this very interesting.

Raj Krishnamurthy (52:02.169)
I appreciate it. you. We are up there with Taylor Swift. Thank you. I appreciate it. Thank you. Eric, you can come on.