The Evolution of Modern GRC ft. James Huang, Head of GRC @ Gong

Raj Krishnamurthy (00:00.514) Hey, hey, hey, welcome to another episode of Security and GRC Recoded. I'm your favorite host, Raj Krishnamurty. Today I have the pleasure of having James Huang with us.

James has been in the GRC business, if I can say that, for 10 plus years. He started as a risk advisor in Ernst and Young. He moved on to companies like Cisco, Salesforce. He's currently heading the GRC at at Gong and he has built security GRC programs.

and launched sort of many of these certifications programs for these companies as well. So James, welcome to the show. James Huang (00:35.522) Thanks, Raj.

Appreciate it. Thanks for having me. Raj Krishnamurthy (00:38.284) James, how did you become a risk advisor?

James Huang (00:41.234) I kinda stumbled upon it. going into college and wrapping up. I was actually a finance major with a MIS minor, grew up in the Bay Area and coming out of college I actually was one of those students who was like, I don't completely know what I want to be when I grow up as a like twenty one, twenty two year old.

I knew I liked tech. I mean I I grew up in the Bay Area and I was always good with numbers. Science was never my forte, so my my parents dream of like me becoming a doctor really never never materialized because I was never good at s like chemistry or biology, but I was good with numbers, right? So it really came down to two paths.

I either like look towards that Wall Street route or I go into kind of cybersecurity IT because I knew I wanted to be involved in that IT space. And coming out of college, Ernst Young gave me an opportunity and from there I've never looked back. it's been an exciting time. It's been a probably It's evolved so much tremendously in this past decade, like more than I could have imagined as well.

But here I am and and really at a at my core I'm a builder. I like to solve problems. So I'm excited to continue to be in this space and drive forward. Raj Krishnamurthy (01:51.

406) Got it. And so James, you have been in some of these big brands, right? And particularly companies like Cisco and Salesforce are known very well in the industry for their security compliance posture. And you're now at Gong, which is not a small company by any stretch, but relatively smaller.

How has the transition been? What what are the interesting things that you see or that you have seen as you sort of moved through these different companies and ended up at Gong right now? James Huang (02:17.994) Yeah.

I think what's progressively happened and and this probably aligns with the technology as well is just how quickly GRC has evolved. I think when I had first joined even EY, like I was the external auditor validating controls. It was pretty black and white. It's this is the control, this is the mapping, this is what you need to do.

Then I went on to Cisco, built their common controls framework. it was still it was more about scalability at that point. How do we reach the market? It's more of a market enablered, like to do business you had to get the cert trust show customer trust.

But then I think most recently, especially as Salesforce and even Gong, it's really become GRC has evolved into a really truly functioning kind of security function. you really don't see compliance and security as separate entities anymore. they should go one and together. Good security should enable compliance and governance.

And I think there's definitely areas of improvement. I think there's areas of catch up even globally. I think the US and and and a lot of these markets that we're in today, Europe, US, and certain regions of Asia and whatnot, we're definitely are advancing at very rapid paces. And sometimes even regulations are catching up to that.

And being a a key key knowledge base and advocate for like what are the most common trends? What are we seeing today? Especially I I hate to use the buzzword AI, but things are advancing more quickly than ever. And I I think that's what I've really seen as we've progressed.

is the momentum of how quickly things are changing. Especially at Gong, we're much more much smaller in size compared to like the Salesforce as or a Cisco. But from a risk perspective, we're still we're our our risk size and what we're attack factors and one at our are still the same. Like what what may impact Salesforce and will impact us as well.

so I think that's the nice thing about the industry is like we don't often face risks in isolation. Raj Krishnamurthy (04:03.457) Some. James Huang (04:13.

897) whatever is affecting us typically affects us Salesforce as well, typically affects a Cisco. And it's a very collaborative industry in that sense. And and we really work towards the betterment of the community in that sense. So that's probably the biggest change that I've that I've seen throughout my years.

Raj Krishnamurthy (04:28.313) I I I love the way you're saying it. A rising tide lifts lifts all boards. In some way or other we are all in the same yeah, in the same domain and we love to lift each other up.

What do you see? Wha let me ask you this. How do you what do you what do you see as the role of GRC? James Huang (04:43.

797) Yeah. In my opinion, I think there's always been this disconnect between security and kind of development and and even engineering in essence, or even legal and go to market as well. I see as GRC as that interconnection between all parties. It's a matter of breaking down into layman's terms.

What is exactly is the risk that you're trying to cover, explaining it in a meaningful way to have all parties agree that this is something that we should engage in. and agree that this is a risk that genuinely should be remediated and as such we would naturally get our compliance certifications, compliance obligations met as well. so I think of it think of us as kind of like that middle ground, almost like a teacher, right? Like we read all these books, we don't always understand what it means when we read the book.

But a teacher is there or tutor is there to break down these concepts for us into very, very simple terms so that we as students understand and how we can grow on that and also vice versa, right? Maybe the book is outdated, maybe there's something new in the industry that the students are seeing, and we up bring the arrow backwards to say maybe the book needs to be updated, maybe the concepts need to be updated as well, right? So I really see GRC as that mesh that brings all these parties together to really enable security and compliance as an across an organization to also meet business needs and make security an enabler and not a blocker in that sense.

Raj Krishnamurthy (06:06.313) And and I think the key, the emphasis that you're making here is managing risks across the organization in some ways acting as sort of the middleware, if I can use the term, across the organization to bring things together to effectively manage risk. Did I hear that right? Okay.

Got it. One challenge that I see is that you've been an auditor, you have run G you've built GRC programs, you've run GRC programs, you have run global cloud compliance, you've done a lot of this. The big challenge James Huang (06:17.825) Absolutely.

James Huang (06:21.683) Absolutely. Yeah, that's a good way to put it. Raj Krishnamurthy (06:36.

279) To me as an engineer that I always find extremely difficult is that when you look at the control frameworks, whether I mean either these are ISO 27001 or NIST 853 or whatever they are, right, they tend to be extremely abstract. Right. And how do you and you've built a lot of these programs yourself. So how do you correlate between what you typically have this body of work from a compliance perspective, and how do you translate that to effectively managing risks?

Are they one and the same? Are they very different? How do you view it? James Huang (07:09.

611) Yeah, I think they're one and the same. And I I think it's natural for our industry to also be super risk adverse because at the end of the day it's all about trust, right? If I think there's a natural hesitancy to to trust, just like meeting people, there's your initial inclination is more defensive than than like, hey, I'm gonna be your best friend from day one as well, right? Like so a lot of these frameworks, the way they're designed, and they're not updated constantly as well, right?

So they also that's also why they are kind of more rig not rigorous, but very kind of black and white in some senses. because they only go through so many updates. They're trying to stay ahead of the times and ahead of the technology as well. So they're they're overly kind of just again I I would use like black and white.

Now what I like to ground myself at the end of the day is not just reading whatever these frameworks NIST ISO sock at face value, but really try to understand at the end of the day the risk that they're trying to address. And By doing so, that's where I mean they they come hand in hand. They don't, they're not one separate things because if you can understand the risk, you can have those conversations with different assessors. You can have those conversations with customers to say that, like, hey, I know the standard may say this thing, this is the risk that it's ultimately trying to address, but there's a little bit of flexibility there where we can do our own risk assessment, show that this is ultimately the goal of the control and how we meet it differently as well.

And that's also how we engage our engineers as well, right? Like I don't actually like to engage engineers and and our partners to say, hey, this is the control. This is how we've got to do it. That's just the way it is.

I actually go into these conversations to say, hey, this is a risk that NIST has brought up. What is your this is the way our team is thinking about it from a solution perspective, but we would also love to hear like what is your option right maybe this control or risk isn't even applicable to us based on our business model and how we handle customer data or consumer data as well right so I think if you tackle it from a risk perspective and bring in that lens it opens up the conversations to be more proactive and not necessarily gray but focus on really accomplishing the goals of like what a good or robust security program should be doing.

Raj Krishnamurthy (09:24.653) And you built the common control framework at at Cisco and I know that you subsequently did that at Salesforce as well. What were some of the ch what is the objective of building a common control framework? May sound like a very obvious question, but I want you to sort of explain as a person who has lived through it.

So what is the objective of CCF and what challenges did you face, especially at large companies like Cisco and Salesforce? James Huang (09:48.373) Yeah, absolutely. ideally, like if in an ideal world, all of our regulators, all of our all of the countries that we work in would be talking to each other.

We'd have one universal standard across the board that would cover all like the security requirements. But in the world that we live today, it it is very segmented. in the US we have SOC two, in Europe, ISO is a big thing. In Japan, Ismap is a big thing, in Australia, IRAP's a big thing.

And So on and so on. Like it it just is never ending in terms of requirements that these governing bodies and even requirements from a customer by customer basis is is is constantly changing, right? So if you were to look at every one of these frameworks at face value, there's hundreds, if not thousands, of controls. I think Australia's IRAP standard itself has a thousand controls, right?

So if you take all these together and you took all of that face value, it's not scalable because you're taking you're you're assessing every single one, every single control, every single time that you have to to do a re a report or an audit. But if you really look and cross compare a lot of these certifications, they're focused on the same domains and same risks. And if you consolidate all of that, you can really bring together these themes into like a central set of controls that would give you coverage across the board.

And our goal is to build this stair step model because we do recognize that not all standards are created the same, like FedRAMP and DIST 853 is one of the highest bars. so there is a stair-step approach where you as an organization, what are you gonna set as your baseline? And then every time you look to expand into a new region, expand to a new certification, what's that stair-step approach in turn in terms of incremental updates? And I think that's the power of a CCF.

It brings your compliance program into a scalable manner, but at the same time, it can also break it down when you need to expand into those markets. People process technology because usually what's the biggest uplift typically are technologically or technology updates where you have to reconfigure the system or rip out and replace the system just because it doesn't meet the bar of a certain compliance framework as well, right? So if you can break that down, it just becomes very, very easy to understand.

It's I almost James Huang (12:03.124) Think of it like a cheat sheet for calculus or a cheat sheet for accounting with all your formulas. You just have the core set of formulas that you need to work off of. And once you have all the numbers and whatnot, you just plug it in and it gives it all to you, right?

So in essence, that's what I I think the common controls framework really brings value. Now, that's only one piece, right? That's only step one A. I can anyone can create a common controls framework, but getting buy-in and getting understanding is is a separate thing.

And I've always been a big believer. at the end of the day that again, controls should not exist for the sake of just existing. Controls should tie to a risk that then gets supported by a policy and standard. And the good news is like with a lot of these frameworks that we are talking about, they don't just create controls for the sake of creating controls either.

They try to base it off a risk off of a domain, off of something that they're noticing in the industry that needs to be addressed. And At the end of the day, that's where you need to get like the have those honest conversations. You can't create a CCF in a silo of me in a room with Claude and all these tools to help me build CCF and at the end of the day just say, Hey, we've launched CCF, that's it, we're done and dusted, like we can do all our syndications now. You need to understand like every business is different, every business's risks are different, right?

So even though like a certain framework, what I was saying earlier, may ask for a certain level of encryption. Based on how your product works, it may not you may not be able to encrypt that a certain layer. You may need to look more downstream or upstream in terms of what you're you can because if you follow that framework to the dot, it may break your product as a whole. Right.

So when you create a CCF, that's only one piece of it. But the evangelization, the conversations you have with partners, talk bringing in legal, bringing in engineering, getting their thoughts of like how how do they think of this framework? How are they addressing certain risks at the end of the day? That's really key.

when when establishing a framework because if you don't do that, no one's gonna read your C C F anyway. Like they're just gonna take it at face value and and just say, Okay, great, like that's good to know but we're not gonna do it that way. Raj Krishnamurthy (14:07.486) And I think that makes absolute sense.

And I and I think you said it beautifully, where you're you're basically not only harmonizing the controls, but they have to correlate with your risk profiles. And my question to you is that let's take Cisco as an example, right? And that's true to some extent even with Salesforce as well. It's a company of companies.

There are tons and maybe I don't know, hundred is a number or not, but of companies that exist within Cisco, each or almost many of them are independent, right? And they have their own risk profile. James Huang (14:17.856) Exactly.

Raj Krishnamurthy (14:36.342) How do you bring these together from a harmonization perspective, right? How do you how can you say that here are a common set of you know controls, let's say 200 I I don't remember the CCF number on top of my head, 180 if I remember right, something like that. Correct?

And how do you say, yeah, and then you have cross map across all the other authority documents, but how do you do this across all the different lines of business within Cisco? And how do you get buy-in? James Huang (14:50.986) Yeah, no problem.

James Huang (15:01.054) Yeah. Yeah. So transparently speaking, like things get very, very difficult when your tooling is very segregated, right?

I think the biggest difficulty at Cisco and Salesforce, and even like a a gong that we're facing are like your your the toughest parts of compliance are when you have acquisitions because there's different technologies, there's different teams, there's different tooling and I think that's the first thing we always try to do is we try to consolidate tooling as much as possible. We try to consolidate processes as much as possible. And even if you took like another example, if you took compliance out of it, just think about like from an HR perspective, you always want the first thing to do from a mergers and acquisitions is bring them onto your central HR system, bring them onto your central AD.

You don't want to be managing two workdays, two separate ADs, because it just gets very, very messy in that sense, right? So I think first and foremost, we always try to align on processes to really scale in that manner. But at the same time, I think there are certain risks that at the end of the day are common regardless of the type of business you're in, right? At the end of the day, even if you take an up level and don't want to go by a control by control risk, you can focus on more generic domain risk, right?

And what I mean by that is access controls or access risk, inappropriate access applies to any business regardless of the type of business and inappropriate changes, backups, disaster recovery. These are things that businesses as a whole need to plan regardless of the type of technology and field that you're in, right? So it's a matter of up leveling the conversation even further to higher themes if you need. But it is very difficult.

Again, like I said, it is difficult to to treat and mitigate as long as there is independence, so to speak, of like I'm gonna follow my own processes versus like I wanna consolidate. So regardless of like wherever I've been, even like at Salesforce and Cisco where we've done a lot of acquisitions, I think as part of that and A process, the first thing that we've always tried to do throughout any business that we bring on is bring them into like a a core set of consolidated processes.

And that's also where the CCF comes into play in in terms of a driver subscriber model. We try to have James Huang (17:13.735) a subscriber model to the full extent of s possible where like 80% of our controls if they can be subscribed to, it makes that much easier from a business perspective. And it's also it allows us to have that conversation with the b each business of like this is the value of subscribing and coming on to our processes.

Is security and compliance are just gonna be that much easier for you to manage. Because you don't need to have a bespoke sim sim solution anymore. You don't need to have to have bespoke like access controls or or or recovery controls and whatnot or or encryption configuration. If you can consolidate it under one master account, that's really the goal.

And I think that's that's the industry that we're seeing today. I think in the past it's always been let's use our own credit card, let's go spin up our own AWS can our G C P account. But in the past couple of years what we've really seen is try to bring it all under one umbrella to the full extent as possible for from a monitoring perspective. Raj Krishnamurthy (18:10.

293) Got it. Let my I want to make sure I understood. I think that's a very important point that you made, which is the driver subscriber model. What I heard there are a couple of things.

One, you're basically providing a central guidance and allowing each of the parties to adapt or adopt as they feel fit. Did I is that correct? Okay. Two, is that you want to be able to centralize on as much of technology as possible so that all the controls that you're applying on into those central technologies can be leveraged in almost instantaneously.

Is that correct? James Huang (18:26.975) That's right. Yeah.

Raj Krishnamurthy (18:41.375) The third question I want to ask you where I see the gap is that each of those divisions can have their own process. So what you said makes absolute sense from a technology perspective and leveraging common technologies. But how do you sort of harmonize the process?

Because Meraki could follow a completely different process than WebEx, right? As an example. So how do you harmonize these processes and how do you bring them to the control? And my particular sort of question is how do you then take all of this as a global cloud compliance statement, go convince the auditor that it is collect once and map many.

James Huang (19:14.975) Yeah. So I think as part of CCF, the big thing that we try to also cover is typically processes and procedures and even what an also auditor is looking for, right? So even though the process may be different, at the end of the day, you just want to demonstrate how you meet the risk, right?

So what I mean by that is like one company could have zero trust. Another company could still be on more legacy like UB Key or or like even biometric authentication and and whatnot as well, right? So I think it's just a matter of again, like when you have those conversations with assessors and even when you talk to each of these teams is focus on what the risk is because the control is there to mitigate the risk. And typically you don't want to create a control that is so specific that You don't want to shoehorn yourself into just saying this is the only way to meet the risk.

That goes back to what I was saying earlier of like when you have these conversations with engineers, if you come at it from a risk perspective and you understand the different ways of implementation, you can create a control that is malleable to cover all different aspects of each business's processes to do things, right? like if you created a control that was so specific that said you have to use this type of technology to do all these things, you're you shoehorn yourself into like it forcing that across the board.

But if you create it more holistic to say, hey, access to production requires or access to production is man or endpoint devices are managed through zero trust like codes and authentications, then that opens you up to to kind of more conversations in in that sense. Raj Krishnamurthy (21:01.035) Got it, got it. No, I I and I wanted to maybe try to take you've been a big advocate of automation and continuous controls monitoring, James.

So what is your view of continuous controls monitoring? I think we have talked a lot about controls and it's maybe a just a logical question. And how do you see C C and what do you see as the challenges with C C James Huang (21:23.421) Yeah.

I think the mindset of controls monitoring has significantly shifted. And and what I mean by that is traditionally when GRC functions were first spinning up, controls automation has always just been like, what does it mean to make the audit easier, like the audit less seamless? And I think that's the definitely something that's important and shouldn't be lost. But the true power of automation is real-time feedback of the control effectiveness in that sense.

Right? You don't want If your control automation is only there to help your audits be more seamless and be simpler and zero touch audits, that's a good byproduct, but it doesn't improve your overall security posture. Right. So this is where I'm saying security and compliance go hand in hand.

Good security enables compliance automatically, where if your automation is now picking up every instance backup failed or every time someone was provisioned access without authorization or someone used emergency access and you were automatically notified of that. Right, then that brings you into a more proactive state of monitoring, a more proactive state of security and compliance, where not only are you making your audits easier, but you're actually improving your security posture as a whole.

And I think that's the biggest misconception of or not misconception, but improvement point of automation that we've seen is like we no longer want automation just to be an efficiency value at Raj Krishnamurthy (22:48.093) And and I'm not trying to throw a cowball at you, James, and the way that you're positioning this is that security, meaning compliance, risk, are sort of enhancing attributes to security and vice versa, right? And that's the sort of the argument that you're making.

But in reality, if you go talk to most security engineers and CISOs, they won't believe in that argument. They don't believe in that argument. Am I wrong? James Huang (23:11.

72) Well I think it's also it's a byproduct of a misunderstanding. And then I think it's also a byproduct of again the w the previous concept of automation. I think this is a newer concept of like that I think has recently come to light because I think there has still been a lot of focus on automation only being an efficiency value. But because that's always been the number one kind of argument of security is like, my goodness, I have to do all these things manually, I have to demonstrate.

Raj Krishnamurthy (23:39.667) I'm taking hundred screenshots, how do I take it f take them faster? Okay. James Huang (23:43.

291) Exactly. It's like not only ha did you ask me to implement something, now I've gotta spend a quarter like just taking screenshots, showing evidence, pulling user access reviews, pulling configurations and all that, right? So I think traditionally that's where the message has been lost is like, Hey, this has only just been doing this for us, right? which has led to a lot of leaders also just saying, Hey, like, how does it enable security if it's only doing this?

But I think in the Gentec era with agents now taking it even further that can notify, can do a lot of these things, be your like police officer almost in a sense sense, virtual police officer for you. I think it's t changing that conversation now to bring in real time monitoring, bring time it's almost I almost treat it as if like it's like an incident response command center for GRC, right? Like you get proactive feedback, you bring it into your risk matrix, and it's it's not stale anymore.

Whereas traditionally automation is that point in time. You just do it for the audit. Now it's twenty four by seven monitoring that that gives you fresh data as you go. So I think as we continue to advance and and the narrative of automation for GRC evolves, that's where we'll go ahead.

That that narrative will change. Raj Krishnamurthy (24:56.24) I I love what you're I love what you're saying. So your argument is if there can be a security operation center, why can't there not be a risk operation center?

That's the question you're asking. Beautifully said. You talk that's a great segue into agentic, the idea of AI, large language models, agents, and GRC. How do you see agents and and language models?

I don't want to basically say large language models or thinking models. James Huang (25:04.446) Exactly. Yeah.

Raj Krishnamurthy (25:24.308) How do you see them transforming the role of GRC? James Huang (25:28.766) So it's an exciting time.

in one hand, it's made us incredibly more I don't want to say efficient, but it it has certainly enabled us to own more and look at more and scale more as well. but in the other hand, it's increased the amount of work that we have too from a third-party risk risk perspective aspect as well, right? So the best way I put it is like this. Traditionally, without AI and LLMs.

we had a risk, we would throw yourself we would have to either we would usually have to build that solution internally. But now in today's world, I think there is probably a vendor or a solution out there for every single problem that you as an organization face. And that's really been enabled by the scale of how quickly AI has been able to adopt. It's enabled all these companies to come up and say, like, I can target this niche risk niche market and really provide value and I think that's also why we're seeing this huge boom in startups right now, right?

but at the same time, we wanna be we're like a kid at the ice cream store. We wanna try, we want we face all the same risks, we see all these problems, we wanna try every single thing that we c we see, but at the same time, like we don't know the security posture of every single company that we use, right? So it's opened up us it it's opened us up to a lot of new risks, but then in some ways it's also helped us remediate maybe old more kind of industry normal industry risks that we've seen for years on end, more quickly.

Raj Krishnamurthy (27:05.098) God. I I we actually recently had a guest and he said something very, very interesting. And the way he said is that he sees third party risk as a curated data of the first party risk, meaning, but in reality, there is a big disconnect between what happens in the curation process and how the data is presented.

And you talked about third party risk. And so I want to get your take. How do you see third-party risk and how do you preserve that there is a continuity in which we can continuously collect evidence and do controls tests and how it is translating into third party risk. Do you see a line there?

Do you see gaps and opportunities there? How do you see this? James Huang (27:44.05) Yeah.

I think there's still improvement areas. There certainly are. I think with a lot of these technologies, there's still the industry as a whole, the security industry as a whole, we're still learning as we go. Right.

And I think that's also one of the reasons why I love being in this industry is there's never a stale moment of like I've solved it, I figured it out, and like we can just in one year that that approach may be stale and you've gotta change again, right? so transparently speaking, I think with third party risk it it is a problem today. In terms of how we continue assess, it's been very traditional in the sense of show me the latest SOC2 report you have, show me the pen test you have.

It doesn't really build in that continuous evaluation because it's also from a managerial perspective very, very difficult. Right. So just the way I build up CCF as well, what we're really trying to do, especially at Gong now as well, is how can we tier our vendors based on the data and sensitivity? of the data that they have and then tier them into risk categories as well.

I think traditionally third party management has been much more simpler. You don't have this huge inventory of third party vendors that you're using. You can take the same approach for every single vendor regardless of the size that we're they're at as well. But third party risk management now is a living and breathing kind of program that continuously changes.

You have to take into company size, you have to take into Even location now. Location is huge of like where is the data being stored? Where are the where is the company being located? Where are their security and engineering teams located and everything, right?

what are their pen test results and and whatnot? And so at our what we're trying to do is one, we're we're really focusing on two factors. One, we're trying to look at the type of data that they'll hold, the type of connection, and even what how that connection between our companies would be made. And then two, We do try to take in account the size and kind of the maturity of the organization as a whole, right?

Like we don't want to take a same size fits all approach of like we need twenty, fifty artifacts from every single company that we look at because there are certain levels to this in terms of maturity at an organization. And we don't wanna send the same set of questionnaires to r everyone regardless of what what they do and whatnot. And maybe a service we could be using a service to just send James Huang (30:05.285) apparel out to our team members.

Does that need the same level of scrutiny as an AWS who's gonna like support our back end and databases or GCP and and and BR infrastructure and whatnot, right? Like so that's where I think TPRM has really evolved and and finding that right middle ground of being having that consistent follow-up and and conversation And versus just like once once in a once in a year am I gonna reach out once every two years. I think it really now is a partnership between parties of how can you trust me and how can I trust you type of thing.

Raj Krishnamurthy (30:38.801) Okay. And I wanted to go back to that so the one example why the way that I see, for example, the large language models have become phenomenally successful, especially and it's phenomenally successful in some areas, like for example, coding, right? Automated, autonomous coding.

And one big reason and I can think of is that for example you can use Copilot to write code in Python or Go, but there is a deterministic runtime. You catch them at compile time, you catch you know, you can write code in Python, but you need a Python interpreter. You can write code and Go, but you need a Go runtime, right? You need a Go compiler.

So in some ways you are taking the probabilistic set of inputs, try and then converting them into deterministic outputs, right? And that's how we are able to sort of reduce the verification cycle. How do we apply this in the world of GRC? What I mean by that is how can I take natural inferences that from a control narrative that I can translate to some aut pieces of automation.

But how do I deterministically execute them every single time in the in the world of agentic GRC? Have thought about that? Have you come across that? James Huang (31:48.

741) Yeah, that's a good question as well. I think it just this is where like if I'm thinking through this, you really don't want to design your automation based on the control language at the end of the day again. You want to design the automation based on what the risk you're trying to cover so it can be malleable and it can can can adjust based on the situation that it's neat in. Now I think there's always there's debate, right?

Like I I'm not here to debate like what is the best model, what is we we use all different types of models. I've I've had experience in all different types of models. I think really what I see at the end of the day is like there's a trust but verify. Like that's that's probably the number one thing we say in in our industry, right?

Like it's good to use these tools, it's good to it helps us do a lot of work more it allows us to do more in our our day than than without it. Raj Krishnamurthy (32:36.563) Trust but verify. James Huang (32:48.

359) But at the end of the day, you need to do a still you still need to do a level of testing. You still need a level of verification. We're very big on at the end of the day when it comes like to decision making processes. You're responsible for whatever you run, right?

So you wanna have someone verifying what comes out of it. Even if automation is working and showing no findings or no results, you wanna test that every once in a while to see that is it truly working the way you've you've designed it, or has it gone sideways and has it gone gone awry. And I think that's the good thing about automation is at the end of the day, when it comes to like testing and and whatnot, from a compliance perspective, you can't test 100% of the sample. It's just impossible from from an auditor's perspective.

Automation enables you to get more visibility, but at the end of the day, if it broke, the worst case scenario is you just for that one period go back to your manual ways of like, okay, I'm gonna have to pull a population for this short period again. I'm gonna have to test manually, but then you fix your automation and and bring it back up to speed again, right? So I think that's the way I see it is that you wanna have someone consistently testing. You want someone to be there to check the results.

Don't just say take over cloud, take over codex, run with it, and I I'm gonna close a blind eye, because that doesn't bring any value at the end of the day. Raj Krishnamurthy (34:08.147) So you need to be able to create a deterministic, repeatable, consistent set of outputs, right? It's almost like what we call idem potent, right?

And underlying state doesn't change, the inputs don't change, you expect the same output. You need to be able to demonstrate that. You said something very interesting. You said that is one of the reasons why you said you should not go off automation of the control language or the My question to you is that are aren't controlled narratives supposed to incorporate your risk statements as well?

Isn't that the purpose of these control narratives? James Huang (34:37.645) Absolutely. They should.

And and I think when we design a CCF actually there's the control language and then we do have a narrative that supports the the control language as well. So from a narrative perspective, you should document ultimately like actually that's probably that's a very good point, Raj. I think you you you should design your automation even off the narrative as well, 'cause your narrative will translate the risk in a way that the agent probably will understand more clearly as well. So Raj Krishnamurthy (34:48.

936) I see. James Huang (35:06.525) I do think that the narrative is there to to it it it's almost like at the end of the day they said an agent is only good or agent is only as good as what's the term? An agent is only as good as how well you prompt it.

I think the narrative is almost essentially your prompt of this is what you should be looking for, this is the risk that you're trying to cover at the end of the day. Raj Krishnamurthy (35:21.245) Prompt them, yeah, correct. Raj Krishnamurthy (35:29.

801) I think no conversation today around security or GRC will end without talking about Mythos or Glasswing. What is your take? How how much did it shake you? How much did it impact you as a GRC?

I'm I'm asking you as a GRC leader, what is your take on mythos and how did you react to it? And how do you want to react? James Huang (35:53.137) Yeah.

This is a very hot topic even with our leadership at Gong and and Salesforce and it wasn't at Cisco because Mythos hadn't come out yet when I was at Cisco. I think it was an initial shock. It was like, my goodness, the world is falling when when it had first released. but at the same time I think it was viewed as an incredible opportunity.

what I mean by that is like for the it gives security an opportunity to really focus on improvement and and fix this. Like if you look at it at face value, there's two ways to see it. It's like, my goodness, our threat actors are gonna sh be able to see every single vulnerability that comes out or that our our product has. But if you also flip on it, it's gonna be like, my goodness, now I have visibility into every problem that like maybe I couldn't catch in the past as well.

Right. So just as much as it's a benefit for our threat actors, it's a benefit for us internally to be able to use something this powerful to See what do we need to focus on from a remediation standpoint? And at the end of the day, I think if you took mythos at face value, it's it's overwhelming. You can't just take it and say, like, I have thousands and hundreds of risks and issues and vulnerabilities and whatever it may be.

But you need to find a system to really quantify that and really target. Because if you just say, I'm gonna go in and patch everything, I'm gonna go in and update everything, it's it's just not possible. if I had a Unlimited resources, unlimited budget. Yeah, sure.

I'll go ahead and do that. But realistically, every team, every organization just has a constraint when it comes to like being able to patch and being able to fix issues as as we see. So that's where I really like to focus. I think Mythos has really opened us up it it's opened us our eyes up to focusing on the likelihood of things.

It's no longer just the impact. Something could have a very high impact, but if it's not it's like very, very low likelihood, then does that take a lower precedence than something that is a still a high risk, but not as high, but very, very high likelihood of being exposed at that point, right? So if anything, that's the way I see it is like it's brought more focus into the order of operations or or order of how you want to remediate versus just like, my goodness, like it's opening us up into a world of trouble.

It's helped us prioritize. It's almost like helped us build a planner out in a sense. Yeah. Raj Krishnamurthy (38:12.

646) Makes sense. But I'm reminded of I'm just to do a a counter argument on this or devil's advocate on this, right? I'm denial of service attacks. So when there are too many of it, right, you tend to lose focus and you know, and you typically bring up the entire service down.

And my question is that the security in the GRC apparatus is already suffering from a lot of noise. Do you are you afraid that Mythaz is gonna create more noise and as a result it's gonna make it worse than better? James Huang (38:45.338) It could.

but I think very similar to like end of the day like what we're focused like even something that we're really big on today is like availability right so what I mean by that I know b availability is totally kind of separate from security but like what I mean by that is you need to focus your scope. At the end of the day what is the scope to your core business? Like there has to be things where like okay if this service went down it's an acceptable risk level versus like I can't have my core infrastructure go down.

But if this specific side service that supports our infrastructure goes down and as long as our main service is available, then we're still okay as well. Right. So I think with Mythos, it you have to be very, very targeted and very specific in what you you want to go. It's almost like I can travel the world and there's so many locations and I don't know where to go because I just want to go to all of it.

But if I am very targeted in terms of like, in the fall I want to go to this specific area and in the winter this is the best area to go to and pinpoint that location or pinpoint what your key services that are like your absolute non-negotiables, I think that will help you sort through the madness of what's to come in the sense. because it it really comes down to at the end of the prioritization. You can't just it it's just impossible to take everything at face value all at once.

Raj Krishnamurthy (40:12.722) For the g teams, the for the folks that are new to GRC, right, few years into GRC, what are your ad what would your advice be in terms of what do they need to equip themselves for the future of GRC? James Huang (40:26.832) Yeah.

I think it's an incredible time. I wish I had odd AI back then because coming into I still remember my staff years. My my old managers would tell me I was probably like very hard to work with because understanding the concepts of of like socks and sock and all things were very foreign to me in the beginning. So it took some it took me like a good year, year and a half to really ramp up to understand like what the concepts of risk and all these things were.

Right. I think AI like shortens that timeline incredibly. I can ask like, what is the point of this control? What is this?

Like AI does it does a really, really good job of breaking down control and the why reason, the why of why we test things. but I my one advice to to up-and-coming GRC professionals is Even in my interviews today, I think there's still that legacy mindset of GRC is separate from security. It we're here to get certifications, we're here to grow help go to market. I think it makes it still they're they're stuck in that conversation of you have to do this because the control says it, so just do it.

But I think if we can start to evaluate, especially with those in the new GRC space, if start to think again, focus on the risk, that breaks it down a lot easier. That breaks it down the conversation with your partners a lot easier. how does it fit into our overall company's risk appetite? Because again, like you do have to risk prioritize.

Not every risk can be remediated from day one, right? So that's the way that's my biggest advice for for up and coming GRC professionals is. Don't be so focused on what these frameworks and compliance frameworks say at face value. Design your CCF to be malleable.

Design it to be risk it can mal it can change with the risk profile that that you've designed and have conversations like that. It it brings it goes a much longer way than just forcing a control down people's throats and makes you a better partner in that sense. Raj Krishnamurthy (42:37.266) Makes sense.

And what would advise would you have for GRC managers in terms of how they should think about investments in the GRC space and particularly how do they convince the leadership, their leadership to make those investments? James Huang (42:50.757) Yeah, That's a question I'm dealing with day in, day out, right? I think the old GRC mindset has always been like, we we've got another certification, let's throw more manpower at it, right?

I I think that's a natural kind of first inclination, is like we need more people, we need more people. but I think every time we get a new product, and I get it as well, right? Because we're given with this tremendous value, this tremendous go to market value. If we get it, then it's gonna enable ten million dollars for us.

So Let's just get it as quickly as possible. Right. So I think sometimes it's a as a manager, it's about taking a step back, taking it all in. You have all these powerful tools that can help enable you as well now.

not everything just needs to key throw more manpower, more manpower. I think what we're really evaluating, even myself as a manager, is with AI, like our nine-hour day. Typically, maybe we could have accomplished five tasks. Maybe that's expanding the eight to ten to fifteen tasks now because of just how how many things AI enables us to do as well.

Right. So that's probably my biggest advice from a managerial standpoint is like every time there's something new, like the initial reaction is to free like you have your initial gut reaction, just like I was saying with Mythos, the initial gut reaction is like, my goodness, the world is falling. We're gonna get hire a hundred more people to figure this out. But take a step back.

Think about it. Think about what you're trying to do. Think about what your team's priorities are. Just like risks are evolving, different risks are a bigger party, the team's priorities could change.

Maybe someone can shift over here and there. And then once you've digested and really understand, then make a decision. Don't rush to a brash decision of saying, I need to do this in this way immediately. Because James Huang (44:42.

725) That's also the problem with creating a control. It's like I'm just gonna create a control for the sake of it and then no questions asked, just do it. But if you take a step back and really focus on the bigger picture, it allows you to to to take different strategies to it. Raj Krishnamurthy (44:55.

89) James, this has been a very fascinating conversation. I thank you very much and best wishes. James Huang (45:03.046) Thanks, Raj.

Appreciate it. Thanks for having me.