What Does ‘Technical’ Even Mean in GRC? ft Alan Luk @ Grammarly

Is it time to stop pretending GRC is technical? Alan Luk makes the case for a new kind of compliance leader—and it might surprise you.

In this sharp and unfiltered episode of Security & GRC Decoded, Alan Luk, Director of GRC at Grammarly (and former Microsoft and PwC leader), joins Raj to dismantle common myths about GRC—and why even your engineers might be thinking about it all wrong.

Drawing from over 20 years of experience, Alan makes the case for why GRC should be seen as a program management function, not a technical one—and how that shift unlocks better controls, less friction with engineering, and less painful audits. From audit war stories to his vision for continuous assurance, Alan brings blunt honesty, practical insight, and some well-earned hot takes to the mic.

🔑 Key Takeaways:

✅ Why most companies—and even GRC pros—misunderstand what GRC is actually for
 ✅ How PM skills (not coding) unlock stronger GRC outcomes and happier engineers
 ✅ What good compliance teams do before audit season to avoid chaos
✅ Why control owners—not GRC—should own the metrics (and what to do if they don’t)
✅ A bold vision for the future: GRC as an observability layer, not an evidence factory

🎯 Take Action:

→ Rethink what GRC really means inside your org: is it a service, a blocker, or a translator?
→ Audit your compliance program’s audit readiness—do you have metrics or just screenshots?
→ Share this episode with your PMs, engineers, or auditors who still think GRC is just check-the-box

👉 Follow Security & GRC Decoded for fresh insights on how to make your GRC program faster, smarter, and more resilient.
🎙️ Security & GRC Decoded is brought to you by ComplianceCow. Discover how ComplianceCow helps teams move from reactive compliance to proactive control automation.
🚀 Liking the show? Leave a rating and review to help us grow and keep bringing you bold GRC conversations.

💬 Connect with Alan Luk:
 💼 LinkedIn: https://www.linkedin.com/in/alan-luk-4027b29/
🌐 Company: https://www.grammarly.com

Transcript

Raj Krishnamurthy (00:01.378)
Hey, hey, welcome to Security and GRC Decoded. I'm your host, Raj Krishnamurthy. And today we have Alan Luke with us. Alan is a 20-year-old cybersecurity veteran. He started his career with PwC as an auditor. He built the compliance team at Microsoft, and he's going to talk a lot about that today. Started with Bing, eventually went into Azure, and now he works at, he heads the GRC team at Grammarly. Alan, welcome.

Alan Luk (00:29.421)
Thank you, Ross, for having me. Excited to be here. Yeah, I'm not a 20-year-old person. I'm 20 years in spirits, but I wish I was 20 years again. 20 years old again, but yeah.

Raj Krishnamurthy (00:35.272)
I don't know.

I said 20 year old veteran, but yes. Alan, I normally kick off this with, what is the one controversial opinion or a heartache you have? But I have a feeling that today, this entire podcast is going to be controversial. So having said that, so why don't I start with that? What is the controversial opinion that you hold about GRC?

Alan Luk (00:42.328)
Ha

Alan Luk (01:04.119)
Got it. I would say my controversial opinion is that GRC is misunderstood.

The that GRC provides is misunderstood by many teams. The expected skill set and role that engineers have of the GRC team while partnering with them is misaligned or inaccurate. And even some GRC practitioners themselves misunderstand the role that we play in an organization. All that misalignment and confusion sometimes results in a perception that

GRC is just there to pass audits or GRC is not technical enough. GRC is a blocker to engineering. So what I'm prepared to talk about today is what I believe are the core responsibilities of the GRC team, the ways in which we partner with engineers effectively, and why I think improving GRC PM skills is more important than technical skills to add the most value to an organization.

Raj Krishnamurthy (02:01.902)
And why do you think GRC's misunderstood?

Alan Luk (02:05.761)
Well, if I were to summarize the responsibilities of a typical GRC team first, I would say we aren't expected to be smeezed in any functional area other than GRC. Especially in SaaS companies, most GRC teams P0 is to achieve and maintain certifications needed to support GTM and sales. I know most GRC teams do more than just that. But if a company for whatever reason needed to downsize,

significantly. Passing audits is probably the most important task for whoever's left on the team. There's a ton of stuff that goes into passing audits, right? It's not just scheduling walk-throughs, routine evidence, routing evidence requests and screenshots between auditors and control owners, sending a billion nag mails when things are overdue, and blaming people for not understanding what's being asked or when there's an issue. That's what bad GRC teams do. I actually think good GRC teams don't get

enough credit for what they do. You mentioned my background in Microsoft, Bing, building a compliance program from scratch. First, you need to decide what to base your framework on that can both scale as you go and maintain, whether you're short-cutting that process by jumping straight to the ISO, Annex A controls, or doing the correct textbook way of doing a risk assessment first, and then deciding what controls are relevant.

Nobody does that by the way, they just go the annex a route. You then get your set of things you need to formalize in the way of policy procedures, control design, implementation, control effectiveness monitoring. For most controls GRC acts as a partner to control owners, translating standards and requirements into control wording that auditors understand, into policy procedures that engineers understand.

GRC teams are able to explain the overall risk and objective that a controller or controls need to address. Co-designing controls with the owners, not mandating that something needs to be done a certain way. So this part might relate to the GRC teams are not technical enough complaint. We do need to be technical enough to understand the domain and process of each control owner and their space. If it's a CI, CD pipeline related control.

Alan Luk (04:26.315)
Yeah, we need to know how code is developed, tested, deployed at end, but we don't need to actually ship code to be able to represent that well in an auditor in a compliance function. And then next would be control formalization. That's educating control owners on how auditors will test them, how to measure and monitor control effectiveness internally. There may also be some recommendations to implement complementary controls to support the main control.

for faster detection and limiting the impact from when the main control breaks. But then throughout the year, I think there should be regular control effectiveness monitoring happening. This is what people like Charles Nwatu at Netflix calls GRC plus A, A for Assurance, and what GRC engineering teams are being asked to do, what a lot of compliance automation tools are claiming to do. In my opinion, this should be the main focus of any compliance team.

a good continuous pulse on control effectiveness through your monitoring approach, then you shouldn't be stressing about audit season coming up. There's obviously different levels of maturity for implementing a control effectiveness monitoring solution. I like to use the crawl walk, run approach. To start with, you just need to make sure your control owners are properly identified and having them fully acknowledge and understand their responsibilities goes a long way. It might seem like an odd.

Raj Krishnamurthy (05:51.66)
So let me make sure understand. Let me make sure I understand. to interrupt. Let me make sure I understand what you're saying, sir. So what you're saying is GRC equals, a big part of that is compliance. And the P0 of GRC that you called, right, is about checking the boxes because that's their responsibility. And I'm not trying to undermine the word checking the boxes, but what I'm trying to say is that is what you see as the primary responsibility. Is that correct?

Alan Luk (06:16.995)
Correct, correct. And check in the boxes, again, is like a, you know, just the surface level is like the top. There's a lot of stuff that goes behind that, you in order for check in the boxes to actually be successful and to be like a real thing instead of just kind of, you know, superficial thing. But yeah, mean, you know, compliance, G or C or C C, for compliance, I know the G and the R stand for other things, but compliance is really, you know, the end to end kind of program of making sure that, you know, the risk and the...

that you need to meet are formalized and governed in a way to where it's manageable and it's operational. But GRC team holds a special skill, right, in being the translator between the audit world and the regulator world and the frameworks kind of terminology and translating that into engineering terms that engineers understand to actually implement in a way that is natural.

Right, like the worst thing you want to do is have GRC come in and say, hey, we have this requirement of control that says XYZ and you got to do XYZ. And the team is like, well, we don't do XYZ, we do ABC. And the GRC team is like, no, you got to do XYZ because that's what this says. It's like, no, you got to be able to translate that. It's like, what is it really, you know, the

Raj Krishnamurthy (07:33.71)
So when you say GRC teams and when you put an emphasis on the premium over GRC team and you said the word, they don't have to be technical.

and they have to have the of the project managerial skills. What you're actually trying to say is that they are, they actually have superpowers. They are subject matter experts, a different set of kind of subject matter experts, right? They need to understand compliance. They need to understand the business process. They need to understand the business context and translate what compliance means to an average engineer. Is that a reasonable thing to say?

Alan Luk (08:07.735)
Correct, correct. technical skills is relative. I don't even actually even know what people really mean when they say GRC isn't technical enough. I assume every GRC person has a level of foundational knowledge in security, in IT, in software development. To be able to represent, to be able to understand what the process is, understand what

the objective is of compliance within that process and the risks that controls are intended to address. And be able to represent that and be able to test that, be able to audit that. GRC is probably one of the very few teams in an organization that knows how to question and ask those probing questions, right? And uncover the blind spots and challenge when engineers say,

Yeah, this is good because we do this because it's configured a certain way and nothing changes. There's so many things I can go around. You're one code change away from breaking something.

Raj Krishnamurthy (09:15.458)
I want to pick you up, can I take that example and maybe I want to drive a little bit deeper so that, I think what you're saying is very, very important, Alan, and I want to make sure that people understand. Let's take that example. Let's say that we as a company are writing a lot of code. We are a software company and obviously just like most people are, we are using copilot to develop code. So from a risk perspective, you want to make sure review is very important, right? That most of these codes just don't go through without any reviews and approvals.

which means that you're gonna put some sort of a review control, branch protection policies and review controls on your GitHub. Now, let's say that this is the context. As a GRC professional, what would you do to translate that requirement to an engineer? What will be the role of the GRC engineer to review those branch protection policies, to review those reviews? And what should be the role of the control owner or the engineer? Can you break it down for us?

Alan Luk (10:10.305)
Yeah, so there would be a requirement from a standard or framework from SOC 2, trust criteria or ISO, or whatever kind of framework that you need to baseline against. That would say something like, OK, you've got to have a change management process, SDLC process, includes the legacy segregation of duties requirement, which requires a second set of eyes to do a code review or to do an approval. So one developer cannot push.

their own code chains through end to end without being logged or second set of eyes. So that GRC would come in and say, hey, this is the risk and the overall intent of this requirement. What are we doing today that you believe engineering team or security team that you believe can meet this requirement in the natural flow of your process, of your engineering process? don't want to, if you're not doing something,

natural, like I don't want to force something that's unnatural, right, just for compliance. So they're to say, OK, well, we're using the CI CD pipeline. We use GitHub or GitLab. And hey, we have this configuration available in the tooling that says all merge requests, all pull requests require code review or approval when you're merging to main branch, for example. So then GRC team would be like, OK, well, yes, that's an option if you're doing that.

Raj Krishnamurthy (11:08.942)
Totally.

Alan Luk (11:34.941)
that's great. mean that does a very common way of implementing a control to meet this requirement. But after that it's like that doesn't stop there. You some teams like that you check the box great and the auditors coming in like is that box checked? Great. Is it centrally you know enforced? If so, great. That's all that's the only screenshot you need. If it's not centrally enforced and all the different repos can configure it differently then you know it gets more messy. You got to test more things. So the GRC team that's you know the superpower

that I believe the GRC comes and says, okay, you set the configuration. Who can change it? If something changes, who gets alerted? How do we get notified? Are there any ways to bypass this? Because there's always like a bypass method that's off of the happy path. Like everybody's thinking about happy path only. GRC comes in and says, okay, what is the non-happy path? Is there a way to kind of bypass this? And how do we, and that's the biggest risk areas. Like how do we,

Raj Krishnamurthy (12:27.96)
Nice.

Alan Luk (12:33.315)
develop, build monitors or alerts to be alerted, to be notified, to identify when these things are. So I think closing the loop on things like that is where really only GRC team is focusing on that. It's really a highlight.

Raj Krishnamurthy (12:49.198)
No, I think that's a great example. And in that context, Alan, would you want the GRC team to at least understand what are GitHub branch protection policies? Should they log on to GitHub, look at it? Maybe they don't have to log on. What I'm trying to understand is that what is technical and how far should they go?

Alan Luk (13:08.545)
Yeah. Yeah, I think obviously you have to understand what the configuration is intended to do, right? And whether the functionality of that configuration and that setting or whatever it is, that piece of code is actually doing what is intended in terms of meeting the risk or meeting the audit requirement. But the superpower is not, we do not claim...

to be the in knowing all the different configuration settings that GitLab or GitHub have to offer and be able to select the one and be like, hey, this is the one that makes us good. It's like we have the conversation with engineers, like, we translate the requirement. This is what the intent is. This is why. It's not even just like this is the requirement. This is the bad stuff that could happen. This is the stuff that could go wrong, that could introduce risk to our environment.

Raj Krishnamurthy (13:44.824)
Totally.

Alan Luk (14:02.089)
if this happens. And I find that the ability to do that, you know, for a lot of GRC teams is missing. They just go straight to like the control requirement or whatever, like this is the goal, the control says. It's like, no, you got to explain to them, right? Your relationship will be a lot more effective, you know, with the partner teams, especially engineering. you explain to them, what are you trying to, what objective do you have? Like, what is the thing you're trying to prevent?

Or what is the thing you're trying to implement to prevent some bad thing happening or some non-intended thing happening? Then you have the conversation. you work together. Once that is understood, then it becomes easy. like, yeah, we have this. we have this. we can do this. And then you just lay out all the options together. And together, pick the right option. That is natural and then right flow.

Raj Krishnamurthy (14:52.46)
Makes sense, makes sense. So the GRC team is more almost like a prosecutor, right? You're asking questions and you're trying to sort of get to a logical conclusion, right? And trying to sort of bring people along with you towards that conclusion. The developer obviously, in this case, an engineer does not also understand what the branch protection policies are because that's not their job. So who is supposed to understand or provide guidance

Alan Luk (15:07.457)
Exactly.

Raj Krishnamurthy (15:18.55)
on what are the right policies that they should be using and if you are using the right policies or not. Who should make that sort of determination?

Alan Luk (15:27.565)
Well, I disagree with it, maybe. think the engineers or somebody on the engineering team should know what all the branch policies are and what they do. So I don't believe that GRC should be the expert on knowing what all the branch policies are and which ones are the ones to turn on to meet a requirement. Again, the flow is like, hey, this is what we're trying to do.

what kind of options, what kind of implementation options do we have using the tool set and using the natural flow of your process, right?

Raj Krishnamurthy (15:59.468)
Got it. No, just to be very clear, my argument was not that the GRC teams should be experts on GitHub branch protection policies. What I'm trying to ask you is that most likely, if I'm an engineer, I'm developing a Go or a Python app, right? And I'm actually, I know the basic commands on Git. I know the policies with respect to merge and how do I promote code through a pull request and all that. But I'm not an expert on all the security features on GitHub. That's the security team's responsibility.

Alan Luk (16:26.019)
Correct. Correct. Correct.

Raj Krishnamurthy (16:26.74)
Right? and so what I think I'm going back to earlier statement, so the GRC becomes a blue in all of this, right? You are bringing security along with you because they are technically supposed to have the insights on this. And then you're bringing the engineers along with you because they're operating on some of this on a daily basis, right? And the role of the GRC is to oversee these two functions and make sure that we are all sort of working together. Is that a reasonable thing to say?

Alan Luk (16:51.085)
Correct, and doing it in the context of compliance. So doing it in the context of, okay, that's like half of it. That's like picking the solution to meet the requirement is half of it. The other half is implementing things to monitor to make sure that continues to be effective and continues to be operational. And that's the part. And also uncovering the blind spots. like, yeah, that's happy path, but what about the not happy path? What could go wrong?

Raj Krishnamurthy (17:12.322)
Got it. Got it.

Raj Krishnamurthy (17:19.81)
Beautiful. So in some ways, the role that QA used to play, or at least the traditional QA that we know of, in software development chains, where they are able to look at the code and they are able to understand all the different paths, not just the happy path. You said something that it is just passing audits involves more than what you think. I think you made that statement. What did you mean by that, Alan?

Alan Luk (17:33.955)
Correct, correct.

Alan Luk (17:44.033)
Yeah, so bad GRC teams, An audit comes up, they're crossing their fingers, they can't sleep at night before the audit comes because they know there's problems. They know engineers are going to hate them when the audit season comes because they're going to dump a bunch of requests and have to send a bunch of nag mails. So that's what bad GRC teams do. Good GRC teams, the audit should be...

should be a repeatable process, right? That's kind of planned and budgeted for with no surprises. And this goes back to like the importance of having a good control effectiveness monitoring program. If you have that and that's healthy, the audits shouldn't be stressful, right? So like there's a lot of stuff that goes into audits before the actual audit happens. But when the actual audit actually happens,

And this goes back to how do you become a good GRC partner to your stakeholders, to your engineers, is planning. It comes back to PM skills, PM 101 skills, planning, work back planning, negotiating with your auditors, what are the milestones, what are the SLAs for turning around evidence and reviews. A lot of that is on the auditor side, which I hold them accountable for a lot because

You know, they have their own timelines and sometimes their timelines impact ours and the worst thing you want is like something that was closed or you thought was closed for like two months and then the week before audit report issuance, they open something up because manager review, you know, caught something that the team missed, right? So yeah, executing on a coordinate of the audits, like you gotta let your engineers know like it's coming.

Ideally, if it's like a recurring audit, you have all of the prior evidence easily referenced and stored somewhere and be able to access so they can quickly look at what was provided in the prior year and it'll jog their memory because engineers don't remember. They don't remember what, like they see a request and they're like, what did I give them last time? this is what I gave them last time. Boom, I know exactly what to give them now. So having that, giving them way ahead of time, like, you know,

Alan Luk (20:08.961)
submitting a ticket in their regular flow of the tool that they actually work in, normally from day to day, with a due date that's reasonable, at least two weeks, none of this two day turnaround stuff. If they can't meet that due date, have them propose another one, and then hold them accountable for committing to that one. And then only sending the NAG mail after that and any kind of escalations that are needed at that point should be not a surprise, because they committed to it.

and issue resolution, right? Like being able to take an engineer through an instance of where like an auditor is asking a question, but they don't really know how to answer it or interpret it, like doing that translation interpretation. Representing the domain on behalf of engineers is also a trait of a good engineering team.

If you're competent enough and knowledgeable enough to represent that process or control on behalf of an engineer to the auditors, then the engineer's life is like, great. Thank you, GSC. You took care of it for us. Being able to self-serve evidence ourselves, you know, goes a long way as well. Like the hardest part is actually just getting approved to access the systems, you know, but after that, it's just a quick meeting with the owner to walk you through, you know, what buttons to click, where to go.

Raj Krishnamurthy (21:20.504)
got it.

Raj Krishnamurthy (21:37.324)
Yeah. So what does.

Alan Luk (21:37.443)
and then boom, you're gonna get that. So there's a lot of, again, GRC misunderstood because a lot of things that GRC does behind the scenes that shields the other stakeholders in the organization are not kind of.

Raj Krishnamurthy (21:47.63)
Totally, totally. So what is fascinating to me, I don't know, I think you make a fantastic point about the project management skills of a GRC, right? And the ability for them to be able to coerce these things together and to be able to keep things on time on target. But some of the arguments that you make around...

being that representative and the voice of the engineer to auditors are exactly the same reasons why others are making the argument that GRC should be technical. But yet you are making it, I don't know if you are saying the GRC team should not be technical, but you're using the same arguments to say that there are more project managers than technical, I don't want to use the word engineers, than having engineering jobs, why?

Alan Luk (22:28.449)
Yeah, so recently I've been doing a lot more browsing on LinkedIn. In the past I haven't really done much of it, but recently I've noticed that there's some more interesting posts and discussions that I like to engage myself in. So like GRC engineering, GRC isn't technical enough. They should be learning how to run scripts, build things to automate evidence collection faster.

Raj Krishnamurthy (22:54.732)
You're referring to the GRC.engineering, Ayub Fondi, a bunch of Charles, okay, got it. Yeah, please go ahead.

Alan Luk (22:58.561)
Yeah. Yeah, yeah, yeah. Along with other just like the general kind of statement of like GRC is not technical enough. again, technical is I'm not really sure how like what everybody has a different definition of what technical means and what not technical enough means. I just believe that, you there's you obviously have to understand the processes and the controls and the domains, you know, that each each control is about to be able to at a high level.

Explain and relay to an auditor of like this is how the control operates, right? This is the risk and this is how the control operates and this is how you test it This is where the evidence is This is how we monitor it. But you know, I think a lot of the technical part is like Complaints is like GRC should be doing more right than that GRC should be Building metrics, know building assurance signals, you know and monitoring that as part of the C part of GRC

I kind of disagree with that, right? Like if that's the area that we're talking about, you know, in terms of technical skill set, that's the area I kind of disagree with, right? I think building metrics, building assurance metrics, building health signals should be the responsibility of the control owners, right? Of those teams that actually own.

Raj Krishnamurthy (24:17.74)
And what if the control owners are not doing it?

Alan Luk (24:21.313)
Then you have another option that's like, maybe you do need to build a GRC engineering team, right? But I'm saying accountability goes a long way, right? It kind of goes back to like, you know, just what I said was like a small thing is like control owners need to acknowledge your responsibilities and be accountable for their controls kind of end to end, right? It's not enough to just say, yeah, I implemented the control and I operate the control. How are you going to, if you're a security engineer, how are you going to look your CISO in the eye?

and be like, yeah, my control is healthy, right, when they ask you, without having a metric that is continuously pushing out some signal. And I don't think GRC should be the team that's building that or owning that. They should be the ones that are building and owning it because they're responsible for it. And then if GRC wants to kind of do some aggregation or reporting to pull in the signals to kind of gauge, you know,

score control effectiveness and that's fine but like the core inputs signals you know should be coming from the control owners. Now if they don't do that then then yeah I mean maybe like a GRC engineering team you know has to be built but even at Microsoft like massive organization like we didn't really have a GRC engineering team like we got a dedicated engineering team to support the compliance team in terms of like tooling but

Even then it was still pulling from signals that each of the control owning teams were pushing out. Because that accountability is key. Without that...

Raj Krishnamurthy (25:52.578)
Got it, got it. Let me, I think you're bringing up an excellent point. So what you're basically saying is that you're not opposed to this idea of signals and metrics. In fact, you're making an argument that they should exist, and that goes to the idea of repeatable sort of compliance that you talked about.

What you are questioning is that who are the owners of it? Where should it actually the responsibility lie or the accountability lie? Is it the GRC team or is it the control owners? And your argument is it should default to the control owners unless for whatever reason they are not able to do it, then the GRC team can take responsibility. But the default position should be with the control owners. That's your argument.

Alan Luk (26:35.265)
Yeah, I mean otherwise like GRC is always gonna have to play catch-up, right? I mean how many times does control change, right? Or we're moving to another tooling stack, right? We're implementing a little differently like GRC is gonna have to keep up all the time and be a little bit behind all the time to update the metrics, the assurance signals, like the control owning team makes a change like hey, the expectation is you own a control, you implement it, you design the implementation, you own the monitoring, right? The control effectiveness monitoring, pushing out the signals that

Raj Krishnamurthy (26:44.749)
Yep.

Raj Krishnamurthy (26:50.328)
Got it.

Alan Luk (27:04.493)
teams can use to assess the effectiveness score.

Raj Krishnamurthy (27:07.598)
But the one question I want to ask you on that is that do you see this as a shared responsibility? And let me explain. So if you remember in the age-old days of the ideas intrusion detection system, intrusion prevention system, right? You write all these different rules and everybody has their own idea in terms of the network team has a way in terms of looking at network packets, the security team has a perspective, on and so forth. But there is a common platform.

that is written on which you write these rules. So somebody maintains the platform and others participate in writing these different rules for the different use cases. Do you see this as a shared responsibility between GRC teams and the control owners, or do you think that the entire automation generation of signals lies with the control owners?

Alan Luk (27:54.743)
Again, in my opinion, if those signals are intended to measure the effectiveness of a controller or process that's owned by those teams, then they should be the ones that own it. Now, GRC is heavily consulted and heavily influencing the design of it because a lot of times, let's be honest, even security engineers, you tell them to create a metric to measure the effectiveness of a control.

Their metric is going to be some metric that doesn't actually really measure control effectiveness. Again, only GRC team thinks like that because they're typically ex-auditors. They didn't know how auditors test and validate the effectiveness of controls. Most other teams outside of GRC aren't thinking like that. So GRC needs to be heavily involved in saying, this metric is fine. This metric is good if you want that.

But it's this metric over here that's measuring coverage, that's measuring operating effectiveness, right, that we need to feel good about compliance and passing audits.

Raj Krishnamurthy (28:54.776)
Got it. Got it.

Raj Krishnamurthy (29:01.336)
So I think what you're basically saying, Alan, is that your argument is that the GRC, and I use the word ex-auditors, the GRC team is essentially prosecuting these requirements and standards for compliance and security. And they are sort of ex-auditors, and they have to be technical enough to an earlier point. But you don't see that as an engineering function. And you think the engineering function is best left with the engineers. That's sort of the crux of the argument that you're making.

Alan Luk (29:28.387)
Correct. And going back to my GRC misunderstood opening statement, specifically being, specifically engineering teams or even security engineering teams, having the wrong expectations of what GRC teams skill sets are and role is like, think about it this way, right? I never see so in all these security teams. Most of them are security engineers.

Most of them are security engineering teams that are actual engineers. For the GRC teams that sit under security or the CISO, they're probably the only team that are not actual engineers. I consider us PMs, not products. P is not for products. It's for program, compliance program managers, and project management as well, some program and project.

Alan Luk (30:26.879)
Most engineers are used to, you know, PMS being like TPMs, right? Working with the devs, the engineers to do all the kind of the... Correct, correct, correct. And the T is the key part of that, right? When you put the T in, most of the time, like you're straight up, like heavily partnered with the devs and day-to-day scrums like design.

Raj Krishnamurthy (30:36.194)
TPMs as in technical product managers.

Alan Luk (30:55.651)
you know, continuously planning when things get off track, like solutioning, like all that kind of stuff, right. And I like personal experience, right? Like we had to come to come to Jesus moment, you know, with one of my, security engineer, dev, you know, managers and they're like, well, like we expect the GRC to, to, do all these things, right. To like lead the design, lead, lead the, the solutioning, like when things go wrong, you know, put us back on track.

And that was really eye-opening because I was like, really? We don't do that. We're not TPMs in the traditional TPM role within an engineering team. We don't do that. We're PMs. We're masters and we're experts of the compliance program of the organization. we're not engineers. Most of us don't have engineering backgrounds to program to like...

be able to catch all these things and provide that direction and challenge things when people are shipping code. It's like we explain what the end goal needs to be. We provide guidance on like how, what was going to stand up when we get audited and from a general compliance perspective. And you guys bring us along. You guys do your thing. We'll check it. We'll validate it. We'll co-design it.

but we're not gonna be operating like an actual TPM. Once they figure that out, they're like, okay, I'm glad we had this conversation because we saw GRCPM in your guys' titles and roles and we expected you to kind of operate as a TPM in terms of what they've been used to, like in larger tech organizations. So that...

realization kind of was eye-opening for both sides and after that it was great because it was like okay well now we don't longer have this expectation, now our expectation for what GRC is providing as part of this initiative or this effort is clarified as clear to us what you what you guys are doing and what you guys aren't doing and after that it was great you know we're like yeah I mean this is this is what we do very well this is what we know how to do very well this is what we don't we're not doing and then and then you know

Raj Krishnamurthy (33:14.072)
Got it.

Alan Luk (33:17.517)
we're successful that way.

Raj Krishnamurthy (33:19.266)
You gave a shout out to Charles Nwato, and particularly, I think, in the context of what you were saying is repeatable compliance, and you said Charles sort of, I think, is a big proponent of this idea of security GRC plus assurance. You talked about continuous assurance. In the context that you just described within your organization, how do you create continuous assurance?

Alan Luk (33:40.481)
Again, ideally, control owners would be responsible for pushing metrics or signals that would represent control effectiveness, continued control effectiveness. like metrics, right? Metrics in an MBR, for example. Each sub-team under the CISO owns their areas of controls, owns their areas, and pushes out metrics on a monthly basis that get reviewed in an MBR all up to the CISO.

they're at like P zero metrics, right? So you see all the things that are green, all the things that are yellow, all the things that are red, and then it's right there. It's like, okay, and you map the controls to them, right? Like this metric maps to this control, this GRC control over here, right? So you're very, it's easy to see the status and the health, you know, things, and it's easy to pinpoint kind of the problem areas that are either, you know, risky, at risk to security or at risk to passing our audits. And

know, GRC was involved in the designing of those metrics to make sure, like I said, a metric might be useful to security, but it actually is really irrelevant to compliance, to GRC team in terms of getting assurance that the control is operating effectively for audits. And we periodically audit those metrics too. We had a security leader that was proudly...

sharing a top level metric that was all green to the board. then a few months later, we kind of poked at it a little bit and found out something was broken. The metric was actually inaccurate and reliable. So GRC team, again, are the only ones that are really kind of poking at those things and thinking about, hey, everything seems good. But is it actually good? Under the hood, is it actually good?

Raj Krishnamurthy (35:32.162)
Yeah, yeah.

Alan Luk (35:37.491)
That's another thing like automation. A lot of people are pushing automation and experience more inefficiencies getting audited. But I'm like, that sounds nice, but who's auditing the automation? The automation needs to be audited too. You can't just blindly trust.

Raj Krishnamurthy (35:55.128)
Fair point, fair point. I think what I'm hearing you say is that, especially in the context of continuous assurance, you're almost sort of advocating two things. One, the.

publisher consumer model where control owners publish information, GRC teams consumes. And then the second point that I'm hearing you say is that you almost talk about the GRC team as an observability plane. They are almost the auditors. I don't know what the connotation for the word auditor is in this context. You're auditing the process and the standards and the requirements of the organization, and you're reporting on it, right?

Alan Luk (36:27.523)
Correct, correct. had a partner, like, director of security on our product security side. He was like, hey, Alan, I want your team to battle test this. Like, I want you to keep us honest. If you can audit our metrics and audit our controls, I want to be battle tested against your team. And I did exactly that. I was like, awesome. That's what I want to do. And some of those exercises uncovered.

Raj Krishnamurthy (36:37.454)
Mm.

Alan Luk (36:56.321)
Weaknesses or inaccuracies, know in in the assurance signals that they're pushing out the metrics that are pushing out. They're like, okay Well, actually the way you've configured this query to push out this metric is missing You know the inclusion of new services coming in that are you know constantly coming in? It's just looking at old stuff and not updating right which makes the metric meaningless, you know to a compliance perspective because when it already comes in they're gonna catch that right there to catch that exclusion right of coverage

Raj Krishnamurthy (37:23.736)
Do you any favorite assurance metrics?

Alan Luk (37:27.587)
I mean it's gonna be based on whatever the controls is, right? So like my... I like out of SLA, you know, metrics right now. Like if you're just talking like a volume control, right? Like okay then again security engineers, their metrics that they're gonna push is like how many are critical, how many are high, how many are medium. I'm like great, that's fine. That might be useful to you, but I'm actually concerned about which ones...

are out of SLA per the step level. So that's an example of how GRC can guide on what are the right metrics that actually measure control effectiveness. So really, I don't have a favorite metric. I'm more concerned about the right metric that can measure effectiveness of each control. And this kind of maybe doves tail into another topic about auditors.

Raj Krishnamurthy (37:58.316)
Yeah, totally.

Alan Luk (38:26.179)
in controls. There's a deception, there's a big deception in the audit world where SOC 2 produces unqualified opinion and everybody thinks everything is good, security is great, blah, But the way the auditors are testing, even for SOC 2 type 2 audits, which is a period of time, which is not a point in time, it's a period of time, so the intent

or the expectation is that you're covering the whole period of time. It's like, how do auditors test automated controls? It's a point in time test. It's a point in time test. They tell you to show the configuration, and if it's before the period end date, that's how they test it. But it could have not been compliant the 10 months before the point in time snapshot of the configuration that they did in November, if your period end is like calendar year.

So how I would like to see the audit industry move forward and also improving overall security assurance is through looking at the metrics, looking at encouraging continuous metrics. So let's say you have a monthly metric that pushes out green or red.

right, for this configuration, this peer review, merge request, going back to the other example, GitLab, GitHub setting, you know, for all the repos, if it's not centralized, to be green. Well, in that control, like an auditor will usually test black or white, it's binary, it's like, okay, is your setting set? Yes or no. At this point in time, in November, yes or no. If it is, then you're good, right, that control is green, passes. If it's not...

then GRC's teams kind of scramble and make it green. And then provide that snapshot. I'm just being real here. But that's farce, right? Because everybody knows that's the limited way of auditors doing that test. And that means one thing. It doesn't mean the whole story. So if you had a metric that was pushing out

Alan Luk (40:45.493)
a signal of which repos are set properly and which ones aren't. And you're looking at that regularly, like monthly, and you have a fast turnaround to identify a problem and then rectify the problem or remediate the problem. And then auditors shift towards testing that as a monitoring control, as opposed to a binary control.

Right now, nobody's going to do that because you're essentially saying, hey, auditor, here are all the times when it was red. So the auditor is going to be like, oh, exception, exception, exception, like all the five times throughout the year, you were noncompliant. Thanks for giving us all your dirty laundry. But I would like the audit industry to move towards changing those controls to be kind of continuous reviewing and monitoring these continuous...

metrics and continuous assurance signals and say, okay, it's okay if you have a red, as long as you have a process to review them and rectify the situation within some sort of SLA that you have. The CSA has issued continuous auditing, continuous metrics for a few years. I saw Raj, you're part of the working group that contributed towards that. I sat on a couple sessions before and I'll be honest, seems like it was slow moving. I think auditors, I think auditors,

Raj Krishnamurthy (42:05.688)
Yeah.

Alan Luk (42:08.995)
were the biggest hang up, right? Because they just can't get over the hump of not testing it like a binary control. And it's not all their fault either because some of the standards like PCI, for example, are mandating that it has to be like that, right? All the time, right? So it's like you get into this game that everybody plays. like, OK, how do we get clean for an audit?

Raj Krishnamurthy (42:33.55)
You're making a very interesting point. think what you're basically saying is that in

you want the audit industry to move from, I'm just summarizing exactly what you're saying, which is from a snapshot view of audit to much more a continuous monitoring view of audit, which means that you want signals to be pushed periodically. You want this to be evaluated based on assurance metrics, right? And sort of you are actually advocating for a lot more automation than what exists today, right, in order to make this happen. Now, one question I want to ask you is that I think one of the challenges that

Alan Luk (42:57.827)
correct.

Alan Luk (43:04.098)
Correct. Correct.

Raj Krishnamurthy (43:09.564)
most engineers feel and I think it almost cascades, right? Engineers want to give only enough information to security teams. Security teams want to give only enough information to the GRC teams and the GRC teams want to only give enough information to auditors, right? It's almost like just, you know, only on a need-to-know basis. But if you are advocating for continuous monitoring, in some ways you are actually being much more transparent, right? How do you sort of reconcile this?

Alan Luk (43:34.915)
100%. You've been much more transparent. You have way better security assurance, way better maturity in your program. But the thing that puts that all to a halt is customers expecting perfection in vendor's Sock2Reports. Or else a whole bunch of headache comes with that.

Raj Krishnamurthy (43:57.838)
Hmm.

Alan Luk (44:02.915)
follow up questions, oh, why did you have an exception here? What are you guys doing about it? Like, imagine responses only go so far, right? I think until the industry changes and shifts, you're from expecting perfection in SOC 2 audit reports or vendors, like, and auditors and or auditors accept this new way of designing controls and like testing the controls to where you can still produce

a clean audit report, it'll continue. No company is going to be like, hey, I want to be the first to be like, just disclose everything, disclose all our dirty laundry from all the mess. Even though it shows that your program is way more mature than another company that doesn't do that and just kind of plays a song and dance during an audit.

Raj Krishnamurthy (44:41.538)
Yep. Yep.

Raj Krishnamurthy (44:53.176)
Totally, totally. You were an ex-auditor, Alan. What do you think the auditing industry should do to move towards what you're saying?

Alan Luk (45:05.129)
I think auditors just need to be more open. I see this maybe dove-stab into the differences I see between large firms, like big four audit firms, versus smaller ones. Pros and cons of each, and it's also team-based. But think auditors just need to be open. They just need to be open. Like, SOC 2 controls are very customizable compared to PCI and other more prescriptive standards.

Sock2 Control is very, very customizable. So I think there's going be open for a GRC team or an organization to be like, this is what we're doing, and we feel like it's better. We would like to move in this direction. We would like you to be our partner in innovating and evolving with us to move in this direction and be OK with it.

I would love to put an auditor, an audit team on the spot and be like, hey, why do you think you can't move to this kind of model? Now before all of that though, easier said than done because you can have all the health signals, all the metrics, but you've got a ton of reds. Are you able to rectify timely? That's another problem first. You've got to fix that in house internally first and be solid before you even pitch this.

Raj Krishnamurthy (46:25.696)
Yep. Yep.

Alan Luk (46:32.859)
this approach to an auditor. But I think after that, you just got to pitch that to an auditor. And they need to be open to it. They might need to audit extra stuff, though. They're going to need to audit the metrics. They're going to need to audit the automation. They're going to need to audit all the things that are the complete inaccuracy of the things that we're pushing over as new evidence, as a new form of evidence now.

So I think it's just openness. I

Raj Krishnamurthy (47:08.23)
Do you think we are, I mean, is there anything else that is stopping the auditors today from moving towards it other than being transparent and open and curious to learn?

Alan Luk (47:17.443)
I mean, I think a lot of auditors are lacking, you know, okay, now that we're talking about lacking technical skills, maybe this is where comes in, you know, a lot of auditors haven't been part of second line of defense, you know, like a GRC team. Like I, I, my personal experience, I started out as a PWC. I'll be honest, I'll admit it. I was a checklist auditor. I didn't know what I was doing. I was learning, soaking everything in as a sponge, trying to, trying to survive and trying to.

Raj Krishnamurthy (47:24.174)
You

Alan Luk (47:45.249)
not sound dumb in meetings when I was talking to people that I was auditing, that I was supposed to be auditing. But it didn't come quick and it didn't really sink in until I joined a GRC team as part of a company, as part of Microsoft and Bing. Because then I was sitting next to engineers working with them every single day, helping them design, develop, monitor, the whole program to where

I really understood how they're thinking, what their ways of working were, and how we could actually integrate and translate and marry the compliance stuff with engineering processes. So I think it's just, a lot of auditors are junior too, junior team members just fresh out in their careers, which you can't ding them for that.

I think the more experienced team members need to step in a little bit more and be more open and understand, OK, this is how they're doing it, and this is why it makes sense. And we should change our testing approach to validate what they're doing, as opposed to the checklist auditor test procedure style for this type of control, selecting 25 samples, taking a screenshot of whatever it is.

Raj Krishnamurthy (49:10.542)
Do you, in your current role, Alan, at Grammarly, do you work with customers today?

Alan Luk (49:18.817)
Yeah, so as part of moving from a large organization, big pond, little fish to like a smaller pond, wear more hats. so I frequently get pulled into like sales conversations, right? When customers, prospective customers or existing customers have questions about our security, our compliance. And we also do TPRM as well, right? So assessing money.

Raj Krishnamurthy (49:42.862)
When we spoke last, you said something very interesting. You said, a broader, broadly speaking, the GRC teams are better at talking to customers. Am I right? And can you explain, elaborate for our listeners why that is?

Alan Luk (49:58.947)
better at talking to customers, better at talking to auditors, better at talking to anybody that's not part of their own team, right? know, security engineers are very intelligent, right? They're the most intelligent people, partners that I've worked with. But it's almost to like a fault, right? So, lot of conversation, you ask them a question, they're gonna answer the question, right? They don't really know what the actual question was sometimes.

And that's a fault of an auditor too, like an auditor asks very open-ended vague questions, know, as a trap, you sometimes as a trap too. And they're catching engineers, you know, like by interpreting a certain way, like the absolute truth and, you know, saying all bunch of other stuff that's like not really relevant to either customers or auditors, right? But GRC team, because...

We are a customer ourselves of other vendor tools, event cloud services that we are assessing and reviewing. We know what auditors are wanting to know or need to know to kind of complete their audit. We have that context. So every time we hear something, I know this is what they're actually asking. You ask the same question and if I'm like out of the picture and it goes directly to the engineer, they're going to interpret it in a totally different way.

Raj Krishnamurthy (51:18.808)
Mm.

Alan Luk (51:19.235)
give some response that's gonna like go down the rabbit hole and like you know just roundabout thing that's like unnecessarily long. So yeah I that's that's I think that's a superpower that's the true superpower of the GRC team right it's not technical like being technical and like knowing how to code and like build all these tooling and you know cool scripts to like pull signals it's it's it's the translation right it's providing the guidance.

for achieving the objective of passing an audit or getting through an audit or answering a customer inquiry on a questionnaire.

a meeting with the information security team on a prospective customer side.

Raj Krishnamurthy (52:00.002)
Got it. You have Microsoft, have dealt with hundreds and possibly thousands of frameworks, standards, requirements, you have been an auditor. And I think your role in PWC used to work with smaller companies, is that correct? You're right.

Alan Luk (52:13.251)
I it's small. I started with a class and it was kind of like some people got deployed onto large engagements, like the same client for multiple years, like staying there. then other people were deployed onto smaller projects, many clients. Pros and cons for both. I went the second route where I saw a lot more clients and did smaller audits. So I was able to see

Raj Krishnamurthy (52:39.778)
Got it. And then.

Alan Luk (52:41.857)
a lot more variety and my impact on my role was bigger because those teams are smaller versus like a larger client with a bigger team.

Raj Krishnamurthy (52:50.69)
Got it. Got it. The reason I was asking is what is your view of the existing standards, whether it is Mistake 1053, ISO 27K1, ISO 42K1, PCI DSS, any of those standards, how prescriptive are they and how prescriptive should they be?

Alan Luk (53:11.043)
Yeah. Yeah, each standard kind of serves a different purpose. PCI is required for credit card, taking credit cards. Sock 2 is very customizable. ISO is kind of in the middle, like sort of prescriptive, but also sort of customizable. I think they all serve a purpose. I think they... It's kind of a difficult question to answer because if you're more prescriptive, then there's more, I guess, standardization from a TPR perspective.

If a customer is evaluating vendors, if it's all standardized and it's more prescriptive, then it's like, okay, if they have this cert or they have this at-test report, then that means they have all these things that generally the industry and every kind of vendor would have. On the other hand, it doesn't work well because...

Every organization is different, right? And every organization is at different maturity levels and sophistication levels in terms of implementing the controls to meet risks or standards and frameworks. I actually had, in the past, actually had a security lead say, hey, you know what? I'm walking in new, and I inherited all these controls. And they're probably a few years old.

where they're designed and implemented. Like, it doesn't make sense. A lot of them don't make sense to me. We're doing them, but we're only doing them because they've been implemented in the past and GRC team, compliance team says we have to continue doing them or else we're gonna fail audits, right? We're actually doing a lot of things that we think actually meet the requirements that are not written down in the same way that these controls are, right? So I'm like...

Absolutely, like I'm gonna go on that journey with you. Like let's sit down, let's understand what the requirements are, what the intent is, what the risks are, and let's align with what the team is actually doing that you believe addresses these requirements. So let's revamp the controls list. It does not make any sense to continue doing something if it's not like, if it's not actually effective and it's not really needed and it's not.

Raj Krishnamurthy (55:28.162)
girl.

Alan Luk (55:30.563)
accurately representing what is actually being done.

Raj Krishnamurthy (55:34.19)
So am I correct in hearing you, you're basically saying that the standards cannot be too specific because then every context is different, every company is different. And so they're intentionally somewhat abstract. But because they are abstract, they may not necessarily apply to you as a company. And you'd to evaluate what applies to you and what does not apply to you.

Alan Luk (55:59.523)
Yeah, and the challenge is, you know, if it's not prescriptive or it's not standardized, then companies doing TPRM, you know, have a difficult time doing their reviews, you know, over vendors because like everybody has a SOC 2 report, but one vendor SOC 2 report can mean one thing and then another vendor SOC 2 can mean another thing. They're both unqualified reports, right? But one security program, you know, in compliance maturity can be way...

Raj Krishnamurthy (56:13.218)
Yeah.

Alan Luk (56:29.303)
you know, more mature than the other one. So that there's challenges, right, for doing that as well.

Raj Krishnamurthy (56:34.648)
Got it. Got it. What do you think is the current state of GRC tools, in your opinion? Where are we?

Alan Luk (56:43.171)
Hard to say. And I'm not the expert of this because I used to work at Microsoft where we didn't buy any tools. We had a software company where we like, screw that. We're not buying anything. We're just building it ourselves. So we had our own tools for GRC and compliance effectiveness monitoring.

Raj Krishnamurthy (56:49.909)
Yeah.

Alan Luk (57:05.282)
The little bit that I've kind of explored and read about and talked to other people about tooling. First of all, a lot of them get a bad rap for being the sock in a box, like low cost, know, sock compliance way of achieving a report quickly and easily, but not really meaning much. So that is kind of like that stigma, know, stereotype. And then, you know, for some companies that I've talked to, it seems like it works.

better for less mature organizations that just want to jumpstart, get something in place, get the ball rolling, to have something to where they don't really start from scratch and build all these things. For more mature organizations that probably have more sophisticated control implementation and things of way of doing things, it's probably a lot of work to integrate these tools into measuring what it is that needs to be measured.

If it's like general stuff that's like AWS or GCP, know that kind of like security stuff then I think you know the tooling the tools probably work out that way but From where I stand right now, I think at a certain scale and size the tools are probably Be insufficient, right? Yeah, why just because of specification just because the sophistication level, you know and the customers customization and like just the

Raj Krishnamurthy (58:23.862)
And why? And what, wait.

Alan Luk (58:32.471)
the velocity of how fast things change, how controls change, then you're have to keep up with it somehow.

Raj Krishnamurthy (58:36.643)
Got it.

Raj Krishnamurthy (58:42.252)
Got it, got it. And I think no podcast is complete without talking about generative AI, I guess, in today's world. So what do you see is the role of GNI, large language models, small language models, in GRC?

Alan Luk (58:59.939)
GRC? Yeah. First of all, I don't think AI is going to replace any of our jobs anytime soon. AI is good at some things and it's not good at other things. And things that it's not good at is the critical thinking, the blind spot in covering, the probing, and just all the other things that I said, GRC kind of has that super power for it to do.

Yeah, it can do great things of efficiency, know, like analyzing data, know, populating, pre-populating stuff, making workflows kind of more efficient, populating, you know, security questionnaires, right, like automatically. But I think that, like, again, the true value in GRC is what I'm talking about is like that human aspect of it, right, the PM skills, the translation skills, the critical thinking skills, the, hey, what about this, you know.

Bypassing like how do we measure actually monitor this and just like risk risk management, right? Like I mean, how is the AI? mean, I guess they could but like at this point, you know, it's still a very human thing to to be assessing risk, right? I don't believe you can just look at data points and like come up to like come up with the decision You know how to do things is always comparative is always subjective, you know based on you know the context and based on where the organization is is

Raj Krishnamurthy (01:00:13.196)
Okay.

Alan Luk (01:00:25.251)
based on the risk appetite of leadership. Yeah, that's my thing.

Raj Krishnamurthy (01:00:32.354)
Got it. You were saying earlier, Alan, that the control owners produce signals, and you want them to produce at a rapid clip, right, at a very high frequency. And eventually the GRC teams consumes these signals and presents them to the auditors. And you talked about some of the challenges with being transparent, right, you sort of very clearly articulated.

But if the control owners can produce signals and the auditors can directly consume signals, why would we need a GRC team?

Alan Luk (01:01:11.043)
Great question. mean, my North Star, at one point, my North Star for compliance in GRC was to actually work myself out of a job. It's like in a world where we have these continuous assurance signals being pumped out and then being available, like some dashboard available to auditors, dashboard available to even customers to help them with TPRM assessments. Yeah, mean, GRC teams can be slashed.

Raj Krishnamurthy (01:01:19.639)
Okay.

Alan Luk (01:01:39.671)
We no longer need to handhold so much and coordinate and facilitate like audit, evidence collection, and all that kind of stuff. So I'm not saying like, you

Raj Krishnamurthy (01:01:46.542)
You are one of the bravest men I've ever seen.

Alan Luk (01:01:52.939)
Now, it's not going to fully replace us. We're going to move on to other things to manage and find our next role and find our next area of impact. But yeah, why not? You have the data. You have the assurance signals. You have the metrics. You have the data to do all the validations that you need as an auditor or as a customer. Yeah, auditing all the metrics, all that kind of stuff that still needs to happen. You can't just trust a trust center.

Raj Krishnamurthy (01:01:58.254)
Totally.

Alan Luk (01:02:21.153)
showing green check marks. But yeah, mean, that would be the goal. No more pulling evidence, manual evidence pulling, all that kind of stuff. It's just like you change all your controls towards metrics and health signals, proving, evidencing, control effectiveness. And no more two months stressful audits. like, no, can, dashboard's available, you can check it throughout the year as an auditor, as a customer, whatever you want. It's got a look back period. You can see.

like the pattern and the trend, like form your own opinions about is this okay or is this something I need to ask them more about, like what happened here? And that's, yeah, the future is like kind of all self-serve, of validation and auditing. Working myself out of job. Out of my current job, at least.

Raj Krishnamurthy (01:03:07.274)
Okay. So if you are hiring today, what skills would you look for in hiring a GRC professional?

Alan Luk (01:03:20.929)
Yes

Like I said, most of the personas in a GRCTM is going to be like X auditors, X big four or whatever. But I can separate it into technical skills and I'll call it PM soft skills. So on the technical side, familiarity with a variety of standards and frameworks, like the ISOs, the SOC 2s, PCI HIPAA, whatever you need, GDPR, CSA, CCM, high trust fed ramp. And then control, design, and implementation experience.

So working closely with engineers to translate requirements, building something that fits into their natural flow, control remediation experience, control effectiveness monitoring, through metrics, health signals, being able to explain risks, the risk or objective behind the requirements in the standard frameworks so engineers understand. Audit experience, ideally as third line, not just being an auditee because both sides of the fence is valuable to know what the context is.

fully and then know efficiency using tools like workflows in JIRA or Asana, Airtable like know GRC tool that you're gonna purchase being able to just be tool savvy to know how to configure things you know configure modules to design workflows and then the PM and the soft skill side just like yeah like I mentioned planning is a big thing like when you're managing an audit which is a project

knowing how to do work back dates, establishing milestones, contingency plans, scoping, stakeholder communication, right? Just it's critical to know who your audience is and adapt to their preferred communication medium, attention to detail, whether it's like audit requests, engineer responses, evidence submissions, like you gotta own all of that to make sure there's no kind of miscommunication or like misinformation that'll lead to a long-winded clarification.

Alan Luk (01:05:22.761)
standing firm, like being competent and experienced enough to know when to stand firm in terms of like when to push back on an auditor, when they're asking for something kind of out of scope or ridiculous, you know, knowing when to hold the line with a control owner if they're pushing back, knowing when to escalate up the management chain, and then just being, you know, adaptable and continuous learning, right? Like always learning new things, new standards, regulations, way of doing things, know, AI.

We, grandly, just recently achieved the new ISO 42001 AI Management Standards Certification and that was a new area for us. mean, it doesn't really overlap too much with security and privacy like the ISO 27000 series does. So that was something kind of new to us.

Raj Krishnamurthy (01:06:12.714)
Got it. We are approaching almost the end of the podcast, Alan. Any podcast, audio books, any books you read, any mentors you follow, anything that you want to shout out that you want our listeners to hear.

Alan Luk (01:06:29.219)
Yeah, like I said, I haven't historically spent a lot of time on LinkedIn or searching for these things, but I did recently start based on what I've seen so far. I'd say some of the posts that I either find myself saving for later or engaging via comments and discussion are a few, and I'll try to represent different sides. So like on the audit side, there's a gentleman named Troy Fine.

who's representing like on the SOC 2 auditor side. David Foreman, who's the CEO of Mastermind Assurance, their ISO audit expert on their side. And then on the GRC engineering side, we talked about Ayub, Ayub Fandi. AJ Yon is also a big proponent of GRC engineering. See a lot of activity from him. Other general kind of GRC practitioners or security, TPR, don't know, like Sahar Dehan.

is a VC So, pushing out a lot of great content that I've been saving for later. Henry Stanley, I think, is on the TPRM side, pushes out some good stuff. And from the tool vendors too, like Compliance Cowell or yourself, and Anecdotes, podcasts, right, like this one, GRC Decoded. IEAB also has one for GRC Engineering. The three or four guys have the qualified opinion with...

Raj Krishnamurthy (01:07:43.053)
Thank

Alan Luk (01:07:56.567)
David Forman, AJ, and Dixon. And then James Kavanaugh, like pushing out a lot of great stuff about AI safety. Just like amazing, amazing stuff. Like really comprehensive stuff. Mappings, control implementations, risks, all about AI safety. So I think those are the people that.

Raj Krishnamurthy (01:08:07.374)
Hmm.

Raj Krishnamurthy (01:08:20.558)
That's fantastic list and I think we will put this list in the comment section as well for folks to see. But Alan, this was a fantastic conversation and I think you took us through a ride through your very rich experience and thank you. Thank you for being on the show.

Alan Luk (01:08:40.995)
I appreciate it. Thank you Raj for having me on. It was a pleasure.

Raj Krishnamurthy (01:08:45.656)
will stay on for a bit.