In this episode of Risk Grustlers, Nicholas Muy (CISO and VP of Engineering at Scrut Automation) sits down with Alan Luk (Principal TPM, Microsoft) to talk about the identity crisis sitting inside modern GRC.
Alan has spent more than 20 years in the field, from audit and consulting at PwC to GRC roles at Microsoft and Grammarly, before returning to Microsoft to work on automation and GRC engineering. That experience gives the conversation a useful range: the traditional audit world, the scale of big tech, the reality of smaller SaaS companies, and the current push to make GRC more technical.
The episode starts with GRC engineering, but it does not stay there. Alan and Nick get into where GRC should sit, what happens when audit work collides with engineering priorities, when an audit finding actually deserves urgency, and why automation is only useful if teams know what they are trying to prove.
They also get into a harder question: whether GRC is still giving enough attention to governance and risk, or whether the function has quietly become too focused on compliance alone.
Listen to the full episode here.
Here are some key highlights from the episode.
Nick: You have worked across audit, consulting, Microsoft, Grammarly, and now GRC engineering. GRC engineering has become one of those terms everyone is using. What does it actually mean to you?
Alan: At some point, GRC engineering became a thing. It started getting attention on LinkedIn, and I tried to be part of the “cool kids club” by saying I was doing GRC engineering too.
But the term is broad. Some people hear it and think GRC professionals now need to become highly technical. They think it means learning how to code, write scripts, automate workflows, and act more like engineers.
That is one version of it. But there is another side that still matters just as much: the business context side. GRC professionals still need to understand standards, frameworks, policy, governance, and how to translate all of that to stakeholders.
So when people say “GRC engineering,” they are not always talking about the same thing. What it means changes depending on the company, the size of the team, the role, and where the function reports.
Nick: A lot of that probably depends on where GRC reports. Where have you seen GRC sit?
Alan: I have personally seen GRC sit under security, under the CISO, and under legal.
When GRC sits inside security, the advantage is proximity. You are closer to the teams that operate controls and do the work. But that does not mean everything is automatically aligned.
People often say “we” as if the security organization is one unified group. In practice, it is made up of different sub-teams: ProdSec, AppSec, IT, security engineering, and others. Each team has its own priorities, incentives, skills, and performance measures.
Most of those teams are engineering teams. Most GRC teams are not. GRC teams are often made up of program managers or analysts. They usually do not own the systems or processes. They own the audit process, certifications, and compliance program, but they depend heavily on the domain owners and control owners who actually operate the controls.
That is where the tension starts. GRC gets measured on how the audit went, how many findings came up, and how disruptive the process was. So GRC can easily become the team that is always asking, always bothering, and always saying no.
Nick: What changes when GRC sits outside security, say under legal?
Alan: There are pros and cons.
If GRC sits outside the security organization, it can have more distance and broader escalation paths. It may also get closer to enterprise risk management, which is bigger than cybersecurity alone.
But the downside is that GRC can become farther away from the operating teams. Legal teams are not always close to engineering planning cycles. They may not understand how work gets prioritized, what has already been green-lit, or why an engineering team cannot just drop everything next week.
So GRC gains distance and a broader perspective, but it can lose operational closeness. That tradeoff matters.
As a CISO, you have probably had to make the tradeoff call. GRC finds something that could become an audit issue and wants it fixed immediately. Engineering has its own roadmap. How do you think through that?
Nick: I try not to have a knee-jerk reaction. I first ask for detail.
Which audit does this affect? Which framework? Which specific controls? Has the control owner already been contacted? How long has this been going on? Why is it being raised now? Was it flagged by the platform we use to monitor controls?
If there is something real, but I am not convinced about the timing, that is when engineering needs to be part of the conversation.
At that point, it is not only a GRC issue. It is a prioritization decision.
Alan: That is where the “so what” factor changed my thinking.
When I moved from a large, mature, highly regulated environment to a smaller SaaS company, the reaction to audit findings felt very different.
At a large company, an audit finding can feel like the world is ending. Everyone understands the stakes, and there is a strong shared belief that findings are unacceptable.
But at a smaller company, the question becomes more direct: so what?
Are we going to lose customers? Are we going to fail to close a deal? Are we going to be unable to sell the product? If the answer is no, then maybe we fix it, manage the risk, and move on. The worst case may be a finding on the report with a management response. It gets fixed over time. Life goes on after the audit finding.
Nick: The framework matters too. When I was at Expedia, PCI felt much more serious because we were a level-one merchant collecting, storing, and transmitting cardholder data. There was a belief that if we did not get a clean report on compliance from the QSA, it could be a major business problem for an e-commerce company.
Alan: Exactly. SOC 2 and ISO are different from PCI.
SOC 2 and ISO are often voluntary trust signals. A reader of the report can decide how much a finding matters to them.
PCI is more prescriptive. It is rule-based. If you are non-compliant, that is the label. So the same phrase, “audit finding,” can mean very different things depending on the framework and the business context.
Alan: So, how broad should GRC’s scope actually be? From policy and governance to control design, control operation, audits, continuous monitoring, and assurance, where is the handoff?
Nick: GRC should have the access it needs to understand whether a control is working. It should also have tools to do something useful with that information.
But I think it is unfair to make GRC design controls for everyone.
GRC can provide standard guidance. It can consult. It can say whether a control is likely to meet the bar for a compliance regime. But designing and operating the control often sits closer to security engineering or the team that owns the system.
GRC knows the compliance expectations. Engineering knows how the system works. You need both.
Alan: That is where the GRC engineering debate gets interesting.
There is a whole movement saying traditional GRC professionals may become obsolete if they do not become more technical. Some people argue that GRC should own more of the metrics, monitoring, and continuous assurance work.
But the other side says that starts stepping into the control owner’s territory. If domain owners and control owners operate the controls, should they also be responsible for monitoring their health?
If the CISO asks a control owner, “What is the health of your area?” that owner should have an answer. If GRC owns all the monitoring, the control owner may stop caring because the work is out of sight.
So there are genuinely two sides to it. GRC can add value by seeing data, surfacing insights, and showing risk. But if it absorbs too much ownership, accountability can get blurry.
Nick: I land closer to enablement.
You can have a core group of GRC professionals with expertise that other teams do not have. But automation itself is not the hard part. Knowing what to automate and whether the output is useful for GRC is a valuable question.
You can automate all day. But if it does not tell you anything useful, it does not matter.
In that sense, GRC professionals are a lot like product managers. The value is not just building things. The value is knowing what needs to be built and whether it answers the right question.
Alan: There is also the broader question. If an organization never had to pass an audit, earn a certification, or answer to a regulator, would security teams naturally hold the same bar?
Nick: I have seen security teams with completely uncalibrated views of where the bar should be.
Sometimes security engineers want to lock everything down from every possible angle. Technically, that is security. But without tuning, it becomes unhinged and impractical.
That is where I see GRC as one way, not the only way, to translate business context into security decisions. A security team without even a basic risk model is rudderless. There is an endless list of things to do in security. Without a risk context, you do not know which work actually matters.
Alan: And I have seen the opposite, too. Sometimes GRC stays in its lane so tightly that its bar becomes higher than the security bar.
If GRC is focused only on minimizing audit findings and getting through the audit, it may push for fixes that do not line up with how the security leader sees risk.
The issue may be in scope for the audit. The auditor may be testing it. GRC may be monitoring it. But that does not always mean it is the thing the business should drop everything to fix.
That is where GRC can become narrow. It is not looking at the crown jewels or broader business risk. It is looking at scope, samples, controls, and findings.
Nick: That brings us to the running joke in the episode: the R in GRC.
Alan: The R has quietly become just a letter.
A lot of teams are really running compliance, compliance, compliance. The C is heavy because every GRC team has to get and keep the certifications needed to close deals.
The risk piece often becomes a once-a-year risk register that sits on a shelf. Governance does not always get much attention either. When was the last time a GRC team said its big focus was governance? Almost never.
A lot of that traces back to how audits are designed. They do not always account for risk appetite. With PCI, you meet the requirement, or you are non-compliant. Even ISO, which on paper is supposed to be scoped through risk assessment, can slide back into a checkbox exercise because there is often an expectation that the statement of applicability is nearly complete.
So even when frameworks talk about risk, the operating reality often pulls teams back toward compliance.
Nick: You have also seen third-party risk from both sides. What stood out to you there?
From the vendor side, I saw customers in regulated industries ask for assurance without always being clear on what risk they were trying to assess.
I would offer to walk them through the risk model, threat model, data flow, authentication secrets, traffic flow, and trust boundaries. But often the response was: just give me your SOC 2 report.
There was maybe one customer who actually wanted to dig deeper. Most just wanted the report so the process could move forward.
Alan: That matches what I have seen. Most TPRM teams are understaffed and underfunded. Sometimes it is one person who picked it up as a side job.
The status quo has been reading SOC 2 reports for so long that the skill of doing a proper vendor risk assessment is often not there, and not even expected.
If you are hiring for a TPRM role, the job description often asks for someone who knows how to read a SOC 2 report, not someone who knows how to run a proper vendor risk assessment.
So the work becomes collecting PDFs, reviewing reports, and keeping vendor onboarding moving.: Which points to the mismatch between what companies say about TPRM and what they actually fund.
You can tell how much something matters by what people do, not what they say. A lot of organizations say vendor risk is critical, but the operating model says something else.
I have rarely seen TPRM truly stop vendor onboarding. It usually slows it down.
The place where I have seen deeper care is M&A due diligence, because there is urgency, money, and contractual leverage. In routine vendor onboarding, the process often becomes procedural.
The bigger takeaway
This episode is not just about GRC engineering. It is about a function being pulled in too many directions at once.
Alan’s central point is that GRC engineering cannot be reduced to coding, scripts, dashboards, or automation. The technical side matters, but the harder work is still judgment: knowing what matters, translating frameworks into business context, understanding who owns the work, and deciding when an issue deserves urgency.
The conversation also makes one thing clear: compliance has become the loudest part of GRC. Certifications close deals. Audit findings create pressure. Evidence requests create urgency. But if governance and risk keep getting squeezed out, GRC becomes a compliance machine instead of a business function.
That is the real identity crisis.
Modern GRC needs to be more technical, but not blindly technical. It needs automation, but not automation for its own sake. It needs to work closer to engineering, but without becoming another source of unplanned work. It needs to care about audits, but not treat every finding like the same level of business risk.
The future of GRC is not just more tooling. It is better judgment about what matters, who owns it, and how compliance work connects back to risk.
%201.png){kind=icon}
