Exploring GRC Engineering

Grace Gately: Alright, happy Friday, everyone. I can see some of you already joining in, so we will go ahead and kick things off in just a minute. Before I hand it over to Alan, I wanted to take a moment to thank our moderator and panelists for being here today.

Alan, at this point you are a seasoned guest moderator on Dune's webinars and we are really excited to have you back. Alan works in GRC Engineering at Microsoft, so not only is he living this topic day to day, but he is also one of the most genuinely curious people we get to work with, so he will definitely be getting deep with the questions here.

We are also joined by an incredible panel: James Tabron from Aquia, Ethan Troy from TRM Labs, and Ryan Schoeller from Treasure Data. They are some of the best people you can learn from on this topic, so we are very lucky to have them here.

GRC Engineering is a topic that is getting a lot of attention right now, but is still evolving and means different things depending on the organization, so we are really excited to dive into this conversation. And with that, I will hand it over to Alan to kick us off.

Alan Luk: Hey everybody. I am very excited to moderate this topic. This new term — GRC engineering — has blown up across LinkedIn, job descriptions, and conference agendas over the last year or so. But in reality, I think it is still one of the least clearly defined roles in modern security and compliance programs.

Most organizations are feeling the same pressures: audits are increasing, environments are changing faster, and traditional spreadsheet and ticket-driven GRC just does not scale. What we are seeing emerge is a new function that blends engineering, automation, and system design directly into how risk and compliance are managed.

Today's goal is not to add to the buzz about what GRC engineering is. It is to unpack what it actually means to different people who are doing this work at their organizations — how their teams define it, how it operates day to day, and where it is delivering real value versus just automation theater. I am really happy to be joined by these three gentlemen who have years of experience living and breathing this topic and are going to share what GRC engineering means to each of them and what they are actually doing at their organizations.

Welcome, gentlemen. Let us go in the order of James, Ethan, and then Ryan. The question is: how do you define GRC engineering, and how is it working at your organization?

James Tabron: Thanks, Alan. I am really glad to be part of this panel because there is a real shift happening in GRC right now. Teams are realizing that applying engineering-focused methodologies to common GRC problems is highly cost effective and, in my opinion, drives revenue to a greater degree.

When I think of GRC engineering, what stands out to me is the moment when GRC professionals — whether or not they come from an engineering background — start pushing past the natural boundaries of traditional GRC programs to solve the common, repetitive, manual, and time-consuming tasks that exist across every dimension of the function. The G, the R, and the C each represent a completely different set of activities that can look very different depending on the organization. But when professionals start to think in a more systems-oriented way and use every technical tool at their disposal to compress time, reduce cognitive load, and create efficiencies across each of those activities — that is GRC engineering.

Previously, there were real boundaries around collecting evidence, assessing controls, and managing audits. Each of those activities takes a long time to do well. GRC engineering says: I can automate that. At every function, the question becomes — how can we automate this so it requires less time from everyone involved? How can we save time, money, and energy so that GRC professionals can start thinking long-term and strategically rather than short-term and manually?

At a high level, GRC engineering collapses or removes the boundary that was previously present in traditional GRC programs, and replaces it with the question: what technical tools and resources do I have to compress this time, automate as much as possible, and make this more efficient for every stakeholder involved?

At Aquia specifically, we have traditionally helped federal agencies achieve their Authority to Operate for the systems and products they want to deliver to the public. That process — based on NIST 800-53 — can take 12 to 18 to 24 months. What we have built at Aquia is a compliance automation engine that maps all of the controls for a given agency, identifies what can be inherited from cloud infrastructure, and then builds automation to close the remaining gap — compressing that 12 to 24 month timeline down to somewhere between 12 and 16 weeks.

We squeeze as much value as possible out of the cloud, inherit as many controls as possible, and then build automation on top to address the rest. The system security plan — which traditionally runs over 400 pages and takes weeks to generate and review — can now be generated programmatically from continuously flowing data, and the authorizing official can make authorization decisions based on continuous signals rather than a static document. And the three-year reassessment cycle, which also takes a significant amount of time, becomes far less burdensome when you have continuous data flowing into a dashboard or GRC tool. So we are compressing that timeline so the federal government can deliver products to the public much faster.

Alan Luk: That sets up very nicely for FedRAMP 20X, which is the next major requirement. Was that foresight, or coincidence?

James Tabron: Mostly coincidence. The programs we had gotten into were already underway well before 20X came out. We were just trying to solve the problem of delivering solutions to federal spaces more efficiently, and it turned out that approach aligned closely with where 20X was landing.

Alan Luk: All right, Ethan — go for it.

Ethan Troy: That is a tough act to follow. My definition of GRC engineering — and I think a lot of people watching will relate to this — is that the term is still elusive, even to me. In the beginning, I just did this stuff without knowing there was a name for it.

I got really frustrated during an assessment where I was on a call for eight hours a day and kept thinking: I could automate all of this. I could just run a script to get this information. So that is what I did. I went to the FedRAMP Marketplace, pulled a CSV of the top twenty reused services, figured out that there was an API for each of them, and built a local project I jokingly called "boring audit automation." I looked up each service, reached its API, connected it to the compliance requirement, and generated output that could serve as evidence. I bring that up because I think compliance automation is often the first thing people are introduced to with GRC engineering — but it is only the tip of the iceberg.

It starts with automating the boring stuff, the slow stuff. Then you ask: how can we do this better? And that question keeps expanding. What more information can I get? What more can I do for the business? For me, being part of the FedRAMP 20X process with early clients made it really clear that this is all about going back to the business. For years, security teams did great work and the way to demonstrate that work was to pass an audit. GRC engineering is the evolution of that thinking: instead of just getting a certification, how can you continuously show trust and assurance to potential customers by embedding engineering principles and automation into your program?

The question FedRAMP 20X asked was: instead of doing an assessment once a year, how could you show continuous security posture 365 days a year? And I think that is where the whole field is heading. Organizations that can continuously demonstrate trust will be more competitive than those that can only point to an annual certification.

The too-long-don't-read on what GRC engineering is: look at what you have to do — whether that is just one audit — and ask how you can do it better. Then follow the rabbit hole from there. How can we provide more value to the business? How can we show the work of the security engineering team, which often goes unnoticed until a breach happens?

I also think independent certifications will become less important over time, and organizations that can show robust security continuously will out-compete those that can only show a certification they earned last year.

Alan Luk: Thank you, Ethan. It sounds like you were doing GRC engineering before it even became the cool new term — and thankfully you did not coin the phrase "boring audit automation." GRC engineering has a much better ring to it.

What are you working on in your new role at TRM Labs?

Ethan Troy: It is my first week, so it is really early to say. I will be working on building out the GRC engineering function at TRM. The company is very publicly AI-native — our CEO has written about how managers across the company have built their own agents. I have been doing a lot of this work on the side for years, posting open-source approaches to AI on LinkedIn. I have been involved with AI since GPT-1, and James and I used to have to have secret groups to talk about this stuff because it was considered taboo. Now everyone wants to know about it. I am just going to be contributing to those efforts at TRM and figuring out how we can do things better.

Alan Luk: Ryan, go for it.

Ryan Schoeller: I will give my concise version because honestly I agree with a lot of what these guys said and do not want to repeat it.

GRC engineering is elusive — I agree with that. A lot of people in the GRC world have been doing parts of this for years without a name for it. And in some ways, calling it GRC engineering is an open acknowledgement from the community that we know we need to do better, and this is our commitment to doing it.

For me, GRC engineering starts with mindset. Systems thinking. Design thinking. I always tell my team: zoom out. Whatever your task or challenge is, zoom out and see the bigger picture. Who are you working with? What is the broader context? And when you are thinking about how to solve something — if it is repetitive, which most of GRC is — ask how you can do it better. Audits, risk assessments, vendor reviews: most of the GRC program is fundamentally repetitive.

If you show up one day and say "I am going to do it this way because that is how we have always done it," and it is making your stakeholders frustrated and taking forever because it is manual — that is the opposite of GRC engineering. GRC engineering is someone showing up and saying there is a better way, and not just thinking about the better way for today but for how it scales in the future. Automating for the sake of automating is not GRC engineering either — that will come back to bite you.

At my organization, GRC engineering can come in many different forms. It does not always mean someone is writing Python code. They might be leaning on an AI coding tool to generate that code for them. We use a lot of low-code and no-code tools for orchestration and other workflows. It is really just the mindset: I have a task that is probably repeatable, I want to do it better, I want to use the technology available to me to make things easier on my stakeholders, and that is going to advance the program. People outside the GRC function have been waiting for this for a long time.

Alan Luk: Each of you touched on the fact that this shift has been a long time coming. Why do you think it has taken this long? If this were an engineering team, automating repetitive tasks would have been obvious from day one. Why has GRC been so slow to get here?

Ethan Troy: I have a strong take on this. I think it has been this way for so long because of how people get paid. A lot of this work is billed hourly, not based on outcomes. What is the motivation to do things better when doing them longer means getting paid more? If you look at how audits are structured, how internal teams bill hours for this work — most of it is hourly-billed, not outcome-based. There is no incentive to finish faster or find a better way. But if you told someone they would earn more by getting the work done in half the time, there would be motivation to improve.

A lot of people feel like the current approach is not broken because it is working for them. But they are not thinking about how much better it could be — for the business, for the engineers, for everyone. There is also a real communication gap between legacy GRC professionals and engineering teams. Engineers, when you actually talk to them and listen, will tell you: I am working on something important and I just got pulled away for six weeks to do this assessment. I had to sit in eight-hour meetings. That is painful. The answer to that is to start embedding GRC earlier — put some GRC in the pipeline so teams are not blindsided at the yearly audit.

The other issue is that we do not work in an outcome-based environment — it is largely hourly. That needs to change. GRC engineering is powerful in part because it lets you show value very differently. The concept of key security indicators in FedRAMP 20X is similar to key performance indicators for a reason: businesses know how to track KPIs but we have never had an equivalent in security. We just have controls — check this box, move on. Moving to an outcome-based environment will make people want the best, fastest, most capable solutions — and that will drive the field forward.

James Tabron: I will provide a slightly different perspective, though I think there is some correlation with what Ethan said.

Early in my GRC journey, about a decade ago, I had the desire to learn Python. A leader at the time asked me: what are you learning Python for, you are in GRC? Back then, GRC was seen as a gateway into security engineering — a place where people landed who really wanted to be security engineers or hackers or one of the "cool" roles. GRC was not seen as cool, and nobody really wanted to do the work. The result was a large group of people who could build strong, well-paying careers in GRC without much technical acumen, because the work was largely manual, interpretive, and relationship-based.

I want to be clear: there is nothing wrong with that. I came from that background. I was a GRC professional with some technical skills that grew over time, and I played a significant part in my company's journey to go public. But there was a mindset that needed to be broken down — not just with words, but with evidence. It took pioneers willing to say this profession does not have to be non-technical. It can and should be more technical, and here is the data to prove why.

Once you start to see the data around time saved in audits, and more importantly around how much your security posture improves when you have systems generating continuous data and analyzing real-time signals from your cloud environment, you get that aha moment. You realize this is actually how it should have been all along.

I will give you an example. I once built a rapid risk assessment process that I had gotten very good at running. Same questions every time, same process. I went to a leader and said I was going to automate it — build an application, send people a link, have them fill out questions, apply some business logic, and generate a risk score and a set of controls automatically. The leader told me no. His reasoning was that the human connection — the interaction between them and the GRC team — was what he needed for the security program. He did not want to reduce touchpoints and become a black box. I had to respect that. But that same leader today would probably say: why did you not automate that sooner?

That mindset shift has occurred in a lot of places, and it is not going back. The genie is out of the bottle.

Alan Luk: Switching gears — everything you do needs to be funded and prioritized. How do you pitch GRC engineering work to leadership? How do you make the case that this is worth investing in, and can you share an example of a project that was prioritized?

Ryan Schoeller: Honestly, the conversation is not that hard at my organization because automation is already top of mind for leadership. In many ways, they are pushing us — asking why we are not automating things. So when we can show them a specific task we are going to automate and the outcome they will receive, there is very little pushback.

One of the big things we are working on right now is what I call an insights function. Rather than thinking of the GRC team's job as getting the company audit-ready, we want to be able to look at any point in time at actual control operating effectiveness across any department. Maybe some of that is monitored through a GRC platform, maybe some is stitched together with other tools. But the goal is: let us look back at the last thirty days and ask how a given organization's controls actually operated. And it is not because we want to be ready for the audit — the audit is almost an afterthought at this point. It will come in September, nobody is thrilled about it, but it is what it is. Doing this continuous insights work is what makes us audit-ready as a natural byproduct.

The department leaders we work with want this too. If their controls are failing more frequently than they should be, that informs them about risk in their own processes, and they want that visibility. Our culture and leadership have passed the maturity level of expecting GRC to just get us through the audit. They want us to take it to the next level, and that framing makes pitching GRC engineering work relatively straightforward.

Ethan Troy: Business buy-in is much easier now than it used to be. Nobody is shuddering at the word automation anymore. I think for years businesses talked about automation without really knowing how to execute it. Now the tools are so accessible that the decision becomes obvious. I was talking to someone recently about whether there is even a reason to learn Power BI anymore, since you can just ask an AI to build a dashboard for you.

For organizations that are still struggling to make the case, the key is to always point things back to the business. GRC engineering is not just about eliminating risk — it is about helping the business make more aggressive, informed decisions. If we take a data-centric approach to security, can the business move more aggressively than it thought possible? Can it be more competitive? For example, when you have full visibility into your cloud spend, you can tell your leadership which tools you are paying for but only using one out of ten features on — and make a case for switching to something cheaper and better suited to your actual needs. How do you do that without data?

The same applies to AI governance. Everyone wants to implement AI right now, and the GRC engineering team can help the business move aggressively on AI without running into compliance problems down the line. That is a value proposition leadership responds to. The bottom line is always: point it back to the business, show how it helps make better decisions, and be that cross-functional translator between legal, auditors, the security team, and the engineering teams.

James Tabron: I do not have much to add to what Ryan and Ethan covered. It is really about showing the outcome, showing the results, showing the data. And right now, the case is easier to make than it has ever been. You can tell leadership: your engineers will not need to spend time on the audit, and we now have far better signals to tell us exactly which systems need attention because of critical vulnerabilities we did not previously have visibility into. You can use AI to perform assessments, use MCP servers to pull in external data, and make better risk decisions based on a broader set of factors. The tools available today make obtaining funding much more achievable — and the zeitgeist of the moment is clear: if you are not using AI to produce better results and be more efficient, you are getting left behind.

Alan Luk: Once the automation is built and the system is running — what does a GRC practitioner actually do with their time? What higher-value work becomes possible?

James Tabron: I think if the systems are built and running, the first thing to focus on is optimization. Ask whether the systems can be better. Are the metrics right? Can the thresholds be improved? It is never fully done.

The second thing is to start thinking about how to solve problems outside of your typical domain. GRC touches so many parts of the business, and once you have built something that works, you start seeing the company very differently. You see things others cannot see. The most valuable thing a person can do is understand how the company makes money and tune their efforts toward building solutions in areas that help the company generate revenue. Leaders love people who go beyond their defined lane — who master their own domain and then find ways to contribute elsewhere. Start there, and you become very valuable.

Ethan Troy: I agree. You should be using AI to build something regularly — weekly, not just as a chat tool, but to actually build, learn, and grow. Start thinking about solving problems outside your typical domain.

I also want to say something about analysts and less technical GRC practitioners — there will always be value in having diverse perspectives on the team. I had someone come onto my team straight out of college, no experience. But she could look at things with fresh eyes and ask why we were doing something a certain way. She used ChatGPT to build an automation for counting numbers on a spreadsheet faster. Nobody else had thought to do it. By the time I left, everyone was using her tool. She did not need ten years of experience — she just had fresh ideas and was willing to act on them.

Knowledge silos used to be very valuable. You were the one person on the team who knew everything, and the company was dependent on you. We do not live in that world anymore. Knowledge is cheap and easily accessible. What is valuable now is creative and unique ideas — and that applies even at the analyst level.

Ryan Schoeller: When I think about where GRC engineering skills have mattered most on my team, it is in the risk function — specifically in the prioritization of remediation. We are getting very good at identifying risks. But just because you have identified something and slapped a severity label on it and your policy says it must be fixed in sixty days does not mean it is actually going to happen. Policies are words on paper and the most often are not what is happening on the ground.

What I do not see any tool or AI agent replacing is the human work of having repeated conversations with risk owners and stakeholders. You have to talk to them frequently, understand their roadmaps, help them commit to prioritization, and then stay on top of whether those commitments are holding. Risks that do not have that human follow-through just sit in the register. That is not good for anyone.

That requires humans. That requires relationships. As James said earlier, relationships and conversations with stakeholders are extremely important. No tool, no agent I know of is going to replace the fact that I need to go talk to someone to really make sure they are prioritizing something and understand the things that might not be written down anywhere. Sometimes that is exactly where we get our biggest wins — just being on the same page and having those conversations.

Alan Luk: Are there still less technical roles that are valuable on a GRC team, or is everything becoming GRC engineering?

Ethan Troy: There will always be value in having diverse perspectives and experiences on the team. Organizations that have been stuck in the cubicle mindset — everyone stays in their lane, does their thing — are finding that approach less effective. People with generalist skills and varied experience are proving more effective now.

And at the analyst level specifically, I genuinely believe fresh perspectives from newer team members will always be valuable. Knowledge is now extremely accessible. What separates people is creative and unique thinking, and that applies at every level.

James Tabron: I would add: the most important thing is to start thinking about how your skills apply to problems outside of GRC. Once you build something and see it working, you start to see the company differently. You can see things that other people cannot see, and that makes you very valuable across the organization — not just within your domain.

Alan Luk: We are at the end of the session, but one more thing before we close out. James and Ethan — can you give a pitch for the GRC Engineering Club? For anyone watching who wants to level up in this space, what is that community and how do they get involved?

James Tabron: It is a life-changing community, and I do not say that lightly. We have had many people give exactly that kind of feedback — that joining this community exposed them to things they would not have encountered anywhere else. I am one of those people. I started using N8N as an agentic workflow automation platform after someone in the club shared resources to get started, and that opened my mind to a completely different way of solving problems.

It is a community of kind, supportive people. There are labs to help you get started with the terminal, with operating in the cloud, with building automation. The AI channel is probably the most exciting channel in it — Ethan is in there constantly posting AI-specific resources, and you will never fall out of touch with what is happening in AI if you are in this club. But beyond the content, it is just really good people and good leadership. Everyone is genuinely invested in helping others learn, upskill, build confidence, find the GRC engineering role they want, change their trajectory, and be prepared for the future of this profession. I cannot speak highly enough about it.

Ethan Troy: Being alive right now is genuinely challenging — there is a lot going on. People are trying to find their way. Having a community of people who can be a sounding board, who can tell you things are going to be okay and that they have struggled with the same things you are struggling with at different points in the journey — that is really powerful. It can make people feel a lot less alone with everything going on.

There is a structured path for those who want it, and for people like me who do not like structured paths — who have ADHD on hyperdrive — there is space for that too. At the end of the day, with all the technology and AI in the world, we are all just people trying to figure out how to provide something back to our businesses, our families, and society. Being part of a community is great for exactly that.

Alan Luk: Not to mention some pretty cool swag, as evidenced by the shirts you are both sporting right now. All right, we will wrap it up here. Thank you so much, gentlemen — one hundred times over. This has been a great Friday for me, just getting to pick your brains. Thank you, and I think our viewers thank you as well. Grace, let us close it out.

Grace Gately: This was a really great session. It is clear that GRC engineering is playing a significant role in how organizations are moving toward more scalable, automated, and resilient security programs. Thank you again, Alan, Ryan, James, and Ethan for breaking down how this role is actually being defined, built, and measured across organizations today. And to everyone who joined us, thank you for being here. The replay will be available on our website shortly after the session ends, and we really hope to see you all at the next one.