Search “GRC” almost anywhere, and you will find a hundred guides on how to land a GRC job. Search “GRC engineering,” and you get a couple of conference talks and not much else.
That gap bothers me, because the practice is spreading fast inside real security teams. The discipline is ahead of its own content. So instead of writing another explainer from the outside, I went to the people doing the work.
This guide is built from long-form conversations I had on the Cyber Stories Podcast with two practitioners who shaped how I think about this space:
Ayoub Fandi, GRC Engineer at Lovable. Ayoub co-authored the GRC Engineering Manifesto and hosts the GRC Engineering Podcast. His path runs through Big Four consulting, a startup, Salesforce, and GitLab, where he was a Staff Security Assurance Engineer when we spoke.
Izzy Vixsama, a staff-level GRC professional at Datadog. Izzy has spent over a decade in information security, working at the intersection of cloud, compliance, and engineering teams.
I added my own experience from years in security engineering, building automation so humans wouldn't have to do repetitive work by hand.
What follows is curated, not transcribed. I organized their ideas into one path: what GRC is, how GRC engineering is changing, what software can and cannot automate, and how to build a career in it.
Part 1: What GRC Actually Is
Before engineering anything, it helps to understand the job.
Ayoub describes GRC as “the conduit between the business and security [and] the engineering org.” It sits between engineering, corporate security, legal, HR, finance, leadership, and the board’s audit committee. Engineering thinks in sprints and releases. The business thinks in quarters. GRC has to speak both languages.
That makes the skill set unusual. In Ayoub’s words, you need to be “an inch deep but a mile wide.” You do not need to be the deepest expert in every area. You need to understand enough of each to connect them.
Done well, that position gives GRC real leverage. When a security team wants to enforce MFA, add scanning, or put controls on incoming merge requests, GRC can help “win those battles” by tying the request to business impact: a customer deal, a certification renewal, a real risk to the company.
Why GRC got a nontechnical reputation
Many engineers think GRC is paperwork. Ayoub is honest about why. Audits can feel like check-the-box exercises. An audit might cover a narrow slice of the company while the certification gets presented under the whole company’s name. Engineers know the critical systems with the real problems, like unencrypted S3 buckets or keys that never rotate, and they watch the auditor ask about something else. It is easy to conclude the whole function has nothing to say about security.
Izzy pushes back on the idea that GRC means nontechnical. She describes a spectrum:
People who are hands-on keyboard
People who used to be hands-on keyboard and now translate technology into strategy
People who are not hands-on keyboard but understand how information flows, what users need, and how systems operate
“You really have to understand where you fit in that spectrum and then how you enable compliance will kind of naturally flow.” Izzy Vixsama
When Izzy got access to an AWS account, she went into the console and started looking at S3 bucket configurations. She looked at how often teams committed code and how often scans ran. She was not building those systems. She wanted to understand them well enough to make better recommendations. That curiosity is the bridge into GRC engineering.
Why GRC is becoming more technical
The cloud changed the ground under compliance. Static perimeters and fixed IP allowlists gave way to dynamic IPs, short-lived instances, Terraform, and Helm charts. Frameworks like ISO have updated to emphasize cloud environments, and auditors have had to follow suit.
Izzy frames cloud risk plainly: moving to the cloud is not inherently riskier. “It’s the same risk. You just either transfer it to someone else or you are choosing to ignore the risk.” The shared responsibility model still applies. The provider secures the cloud. You secure what you put in it. And somebody still has to govern, assess risk, and prove compliance.
“As a security professional you should trust and verify, but you should still move forward in the direction that technology is taking you.” Izzy Vixsama
Part 2: What GRC Engineering Is
GRC engineering is what happens when you apply real software engineering practices to governance, risk, and compliance. You encode controls as automated tests. You run them continuously instead of once a year. You plug compliance checks into the systems your engineering team already uses.
Ayoub breaks it into two goals.
Goal 1: Make GRC more effective
Traditional GRC tests controls once a year, every six months, or every quarter. GRC engineering aims for real-time data on control health and risk posture, with alerts when a control stops working. That applies even when a certification does not explicitly require continuous monitoring. The point is knowing, not passing.
Ayoub describes the end state as a “Minority Report dashboard”: one view across application security, vulnerability management, and every other function, showing what is healthy and what is drifting.
Goal 2: Integrate GRC with engineering
Most GRC teams only talk to engineering during audit season. GRC engineering puts compliance inside engineering workflows instead.
This is where policy as code comes in. Tools like Open Policy Agent let you express a control as a machine-checkable rule. Ayoub’s example: a control that verifies SAST runs in every CI build. The check does not have to block the build. It can simply record a violation when SAST did not run. Over time, those violations show you patterns, and patterns tell you whether you have a people problem or a process problem.
The same idea extends to governance. Policies can live in Markdown in a Git repository, so every change has a history, a reviewer, and a reason.
Checks do not have to block. Sometimes the most useful thing a control can do is tell you, honestly, how often it fails.
Where it is today
When we spoke, while Ayoub was still at GitLab, he estimated the companies doing this seriously could be counted on two hands, with teams at places like Netflix leading the way. He called GRC engineering “just the beginning.” If you think you missed the window, you did not. The manifesto lives at grc.engineering, and it accepts pull requests.
Part 3: Five Questions to Ask Any GRC Platform
A lot of software now says it “automates compliance.” I went deep on this in my video GRC Engineering Explained: What GRC Software Actually Automates (and What It Doesn’t), which uses Vanta as a worked example of a modern compliance automation platform. If you want to see these ideas applied to a real product, start there. Here are the five criteria from that guide that I use to separate real GRC engineering from a compliance checklist with a nicer interface.
1. Is it continuous, or point-in-time?
If you have ever owned a SOC 2 audit, you know the old way. Inventory every resource. Screenshot a setting to prove it was configured correctly on the day someone asked. Do it again next quarter, because a January screenshot proves nothing about April.
A real GRC engineering setup runs automated tests against connected systems on a continuous schedule, often hourly. When a passing control starts failing, say a security setting gets reopened by accident, you hear about it within the hour, not at the next audit.
Ask: Is it actually watching, or is it a nicer spreadsheet?
2. How deep does the coverage go?
Plenty of tools technically “integrate” with your cloud provider but only check a handful of surface-level settings. The real test is whether the checks map to something you would actually be audited against. For AWS, that usually means the CIS AWS Foundations Benchmark, the same reference an outside auditor would recognize.
Ask: Does it map what it finds to a benchmark someone outside the company would recognize?
3. Does evidence work across frameworks?
Most companies do not stay on one framework forever. You start with SOC 2 because a customer asks. Eighteen months later, someone asks about ISO 27001 or HIPAA, or an EU customer brings up GDPR. If your tooling only speaks one framework, you rebuild your evidence trail every time.
Good GRC engineering treats evidence as reusable. The same connected accounts and control tests should map across SOC 2 Type II, ISO 27001, HIPAA, GDPR, NIST CSF, and CMMC.
Ask: If I add a framework next year, do I have to start over?
4. How much of the real work gets automated?
This is where the category has moved most in the last year or two. Automation used to mean testing. Now some platforms use AI agents for the busywork around the testing:
Policy drafting. An agent asks how your business actually operates and drafts a policy that fits, instead of handing you a generic template.
Trust centers. Instead of answering the same 50 questions from every prospect’s procurement team, you point them to a public page that already holds the proof.
Vendor risk. Instead of someone reading forty pages of a vendor’s SOC 2 report every time the company adopts a tool, an agent reviews documentation, assigns a risk score, and recommends a decision.
Ayoub described that vendor problem well. For “99% of companies,” third-party risk still means sending a questionnaire, checking whether the vendor uses SSO, and approving. He sees the future as connecting to vendors through APIs and monitoring their controls in real time, with alerts when something important stops working.
Notice the word “recommends.” You still make the final call. The agent removes the reading, not the responsibility.
Ask: Does “automation” only mean running tests, or does it also cover the paperwork?
5. What does it say it does not do?
This matters most if you are going to rely on a platform. Software does not replace a compliance team.
Genuinely automatable in a mature setup:
Discovering resources in your cloud accounts
Running control tests continuously
Collecting evidence the moment something passes
Flagging drift the instant a passing control fails
Drafting a first version of a policy
Scoring vendor risk from their own documentation
Not automatable, and probably never should be:
Writing and approving the actual security policies. An AI draft is a starting point, not a final answer.
Real risk assessments. The judgment about what matters to your specific business.
Vendor due diligence conversations, still between humans.
Accepting an exception when a control fails, and defending that decision to an auditor.
Ask: What does it say, out loud, that it does not do? If the answer is “nothing,” be skeptical.
Part 4: The Trap Nobody Talks About
Ayoub raised something that stuck with me. Automation has a hidden cost.
When GRC teams were small, and everything was manual, they had to build relationships with product and engineering. You had to sit with the infrastructure team to understand how encryption actually worked. Connectors & MCPs change that. You can now pull data from Slack, GitHub, and AWS without talking to anyone.
The problem is that connector data gives you a baseline, what Ayoub called the “lowest common denominator” view of security. It tells you whether a setting is on. It doesn't explain why a 15-year-old Oracle database cannot be replaced, or which architectural tradeoff makes a particular vendor dangerous for your company.
Izzy says the same thing from the other direction. Security works as a partnership, not a dictatorship. Understanding what a team is trying to accomplish and applying a security lens to it “is going to be a hundred times more successful” than dictating. Some requirements are firm. Many only say what must be achieved, not how, and that is where GRC earns its seat by finding a path that satisfies the control without getting in engineering’s way.
Automation should buy you time for relationships, not replace them.
Ayoub’s framing is the right one: “winning time on low leverage activity so you can spend time on high leverage where cognitive ability makes sense.” Automation is coming for GRC. The first result should be more interesting work, not fewer people.
Part 5: How to Get Into GRC Engineering
Ayoub and Izzy came from very different places. Ayoub studied economics and linguistics and wrote a master’s thesis on how the YouTube algorithm polarized politics. Izzy studied business management and finance, spent six months in finance, hated it, and ended up doing risk assessments and building automated vulnerability reports at a major bank. Neither followed a straight line. Here is what they would tell you.
Decide whether GRC fits you
Izzy is direct: “Just because you want to do GRC doesn’t mean you’re going to be good at it.” Before committing, ask what you want your days to look like. Do you like meetings? Documentation? Audits? Strategy? Technical investigation?
Be realistic about the early years too. “In your first five years you might not be on that strategy track.” Expect a lot of documents, audit support, and policy work before the interesting strategic problems show up.
Pick your environment carefully. Izzy’s line: “If you do GRC for an old, archaic company, it’s 100% going to be boring.” GRC at a company shipping a new product every six weeks is a completely different job.
Learn frameworks, but think in control objectives
“You can’t be a GRC professional and not know anything about a framework,” Izzy says. “That’s literally our bread and butter.” She recommends starting with SOC 2 and ISO because they are non-prescriptive. They tell you what to achieve, not how, which leaves room to learn.
Ayoub adds the key shift: do not try to memorize every control in ISO or NIST 800-53. Start at a higher level, like the NIST Cybersecurity Framework. Take one control, look up what it means, and understand what problem it is trying to solve.
“Instead of thinking controls, think control objectives.” Ayoub Fandi
Izzy describes the core skill as translating “lawyer speak” into real-world applications. A control that says a system must have a mechanism to determine vulnerabilities really means you need a scanner, a process for finding vulnerabilities in your code, and a way to prove both.
Build technical fundamentals
Izzy’s list: networking fundamentals, how a basic computer works, the OSI model, TLS and data in transit, load balancing, proxies, vulnerability scanning, cloud configuration, and how repositories and scanning pipelines work. “How do you know what you’re securing if you don’t know what the OSI model is?”
Learn to script
Ayoub’s argument for coding is simple. User interfaces lie about what a system can do. With APIs and SDKs, you can do “a hundred times more than what you see in the UI.” Development experience also teaches you how software is actually built: Git, CI/CD pipelines, Markdown documentation, and machine-readable policies. That is the native language of GRC engineering.
The combination of software engineering and GRC is still rare. Ayoub calls it a “unicorn profile.” Many people leading the field come from detection and response, security operations, AppSec, or infrastructure security, not audit. If that sounds like your background, you are closer than you think.
Build something you can show
Both of them push hands-on work. Ayoub points to the Cloud Resume Challenge and its security-focused variant: build a small cloud environment, implement specific controls, and write about how you did it. Even hosting a blog and documenting how you secured it counts. Izzy’s version: “Get you a lab. Actually build a lab.” Start small.
A homelab is the perfect sandbox for GRC engineering. Pick a framework control, implement it, write a policy-as-code check for it, and track when it fails. That is a portfolio piece most applicants will not have.
Make a realistic plan
Izzy has seen too many learning plans that try to cover GRC, SOC work, pentesting, vulnerability scanning, and network engineering in nine months. “This is like seven jobs.” Pick a target role and build toward it over six months, nine months, or longer.
Keep certifications in perspective. The CISSP is not an entry-level cert. You need five years of experience to earn it, regardless of when you pass the exam. And be honest about pay. Izzy warns that entry-level offers can be closer to $45,000 than the six figures some people promise.
You do not need to spend much to learn. Google, YouTube, and Udemy go a long way. But if you skip structured programs, you have to supply the discipline yourself.
Build relationships, not follower counts
Izzy’s advice on mentorship is blunt: “Don’t just follow me on LinkedIn and immediately ask me to be your mentor because the answer is always going to be no. I don’t know you.” Know what you want, why you want it, and what specific help you need before you ask anyone.
Part 6: Growing Into Staff Level
Both guests hold staff-level roles, and they described the same shift.
At staff level, nobody tells you what to work on. Ayoub says you should have enough context, relationships, and experience to find important problems that aren't obvious or assigned. There is always more work than people, so you delegate important but noncritical work and mentor others through it, even when you could do it faster yourself.
Izzy describes her staff work as process improvements that benefit everyone: making security more visible and more effective, and helping engineering teams work more cohesively with security. “You are not responsible for any of the actual work, but you can kind of influence and guide the direction that the work goes.”
That is what GRC engineering looks like at its best. Not a person with a spreadsheet, and not a platform on autopilot. A systems thinker who uses automation to see clearly and relationships to act on what they see.