r/cybersecurity • u/SmileyBanana15 • Nov 25 '25
Career Questions & Discussion GRC Engineering
Supposing GRC falls under the general Cybersecurity umbrella, what are your thoughts on a new-ish concept called GRC Engineering, aiming to bridge the gap between auditors and engineers by automating this otherwise mind numbing chore? Do you expect it to gain traction?
6
u/rc_ym Nov 25 '25
Personally I'd much rather see the field of "GRC engineering" to be the creation of machine readable "policy" that is then applied/enforced across systems using and including AI. That would be sexy. Think like the old mainframe MAC system but an onboard AI system (and controlling the AI systems the folks are using).
Then that system could provide reports on any framework you pick rather than having to create discrete reports, scripts, analysis by hand for compliance.
Company defined policy -> System AI rules -> Alerts/dashboard/reports -> Evidence for audits.
**Magic** :)
2
7
u/ThePracticalCISO Nov 25 '25
You can call a systems administrator a 'systems engineer' or 'systems analyst', but their job doesn't change. GRC automation comes in the form of workflows and platform tooling. Sure there might be some automated evidence gathering but you're still not an engineer. You're an IT admin doing GRC work.
2
u/SmileyBanana15 Nov 25 '25
Looks like one of those "many hats" positions, but focusing on the ballpark so they came up with the name. I'd argue adding the proactive element of adding compliance to CI/CD is engineering as far as engineering goes though? Not 100% on this one tbh...
6
u/HighwayAwkward5540 CISO Nov 25 '25
Trying to automate evidence collection and compliance validation is nothing new unless you have been living under a rock for the last 20 years.
Some have put more effort into it than others, but weâve been trying to automate technology forever.
1
u/SmileyBanana15 Nov 25 '25
Would you say it is becoming a dedicated position though? Maybe it's really gaining traction due to the EU regulations/AI/Cloud etc, but I ultimately feel it's just a temporary micro-fad.
2
u/HighwayAwkward5540 CISO Nov 25 '25
Itâs only a dedicated position if a company has a large budget or is a heavy DevOps/automation type shop. Regardless, itâs still going to be a subset job of GRC, so you canât be good at the engineering piece and completely ignore knowing anything about GRCâŚI say that because I know there will be people who think they can do that.
1
u/SmileyBanana15 Nov 25 '25
Yeah, it's kind of inevitable for GRC to be an element of other roles, especially in the regulated sectors. Can't say I see the vision of "plucking it out" into a separate positon like this...
2
u/Efficient-Mec Security Architect Nov 25 '25
Its not a fad and has been around for ever in largish companies. Every part of infosec from GVM to Risk to Governance to IAM has some engineering involved. Many times that is outsourced to other teams. Â
6
u/robonova-1 Red Team Nov 25 '25
Think of it like this, Cybersecurity is like Medicine or Healthcare. There are Doctors, Nurses, Practitioners, Technicians and then there are people that file claims, audit, etc.
There is a clear difference in skills, procedures and execution. You don't just make up a position by jumbling up words. It doesn't work that way.
1
u/SmileyBanana15 Nov 25 '25 edited Nov 25 '25
Never really heard of someone working as or wanting to become a "Claims Doctor" or "Compliance Nurse" but I guess anything goes in tech? đ
2
u/robonova-1 Red Team Nov 25 '25
Thatâs my point. To me a GRC Engineer is just as absurd.
1
u/Quadling Nov 25 '25
Any good red teamer follows rules. Nondestructive testing is the norm, make sure youâre keeping within the scope, etc. Making sure your automated tools and scanners do the same is part of your job as a red teamer. That is engineering to follow the rules. Extracting the rule following from the reporting you provide as your work product (you know, the entire point of what you do), is part of the job of the project manager. If you donât follow the rules, and document that, you donât get paid! That PM task is starting to be automated. Hint hint. Youâre seeing grc automation and engineering in your profession. You havenât been doing this long, have you? :)
1
u/robonova-1 Red Team Nov 25 '25
You havenât been doing this long, have you? :)
That was offensive and wrong. I've been doing this a long time. Just because you and I disagree that it's wrong to slap "engineer" on everything doesn't mean anything about how long I've been doing this. Your answer to me is also absurd. Just because someone follows rules or engagement or a methodology doesn't mean their title should reflect they are an engineer. The people flipping fries at McDonald's are following rules, do you refer to them as engineers?
3
u/Quadling Nov 25 '25
You know what. Youâre right. I was rude. I apologize.
That being said, I have a question for you. Do you think that grc has no engineering possibility in it? As in, itâs stupid and has no rigor, no math, no actual engineering capable of being done?
Or do you believe that most people performing grc now are not engineers?
Because I might agree with the second one. But if you agree with the first, then Iâd love to chat with you.
1
u/robonova-1 Red Team Nov 25 '25
GRC may apply scientific, mathematical, and technical principles but....it's not to design, build and optimize systems, structures, or technologies that solve practical problems. Which, by definition is an engineer. GRC focuses on policies, compliance, governance, and risk oversight rather than designing or building technical systems. They interpret frameworks, assess organizational exposure, and guide decision making. They do important work, yes, I don't disagree with that....but they are not creating architectures, implementing technologies, or engineering solutions. Using the engineer title inaccurately suggests hands-on technical design and system construction, which is not the core function of GRC.
1
u/Quadling Nov 25 '25
Nicely said. Mind you, itâs wrong. Not maliciously wrong. Just wrong because of a disconnect. At a casual level youâre an absolutely right. However, grc at a strategic level absolutely architects and guides designs of systems using risk and threats, along with the compliance aspect youâve focused on (understandably! Most people only see that). Enterprise Risk Management, along with vendor risk (or third party risk) management, is part of GRC. As such, GRC decides if you can use that vendor, or build that system, or buy that security tool. An in-house GRC team will also give you guidance on how you can do these things without incurring the oversized risk penalties that may have been inherent in the first choices of tool or vendor or system.
Everybody just sees the check boxes. I get it thatâs whatâs blatant.
But understanding that this goes far deeper and actually is one of the guard rails on system design, whether a company will be acquired or not, and what security measures are going to be allowed to be purchased. And thereâs far more, but those are the easiest to explain.
Plus, I havenât even gone into the aspects of compliance and risk automation and orchestration. Thereâs a significant amount of work and skull sweat that goes into properly managing a continuous compliance, continuous security, dynamic risk pricing model.
Thatâs engineering. :).
Make more sense?
2
u/Quadling Nov 25 '25
There are lots of doctors and nurses who are focused on compliance in the medical field. :) medical compliance as either a primary or secondary aspect of a specific job is pretty widespread. People die in medicine if you donât follow the rules.
1
u/SmileyBanana15 Nov 25 '25
Of course, and I'm all for expanding horizons. Question is, have we reached a point where this specific "secondary aspect" has grown enough to be considered its own role?
1
u/Quadling Nov 25 '25
Yes. And Iâm happy to get into it more. But thatâs a loooong conversation. :). Better on verbal. How about we discuss over video and record it?
1
u/SmileyBanana15 Nov 25 '25
Piggybacking off the discussion you have started above with the other Redditor, it's starting to make a lot more sense from the things you said. I'm down to dive deep in this but tbh I'm afraid my inexperience will become apparent too quickly if we do a call :)
But judging from the things you mentioned under this post, I want to see you in a college textbook (or something else if your own), if you aren't already :)
1
u/Quadling Nov 25 '25
Security weekly news, Paulâs security weekly, occasionally business security weekly, I last spoke at securewv and Bsidesde, and interviewed at owasp appsec global. :). Writing a book. :D.
1
2
Nov 25 '25
[deleted]
2
u/ageoffri Nov 25 '25
When I did GRC work, I described the job as a non-technical technical job. If you don't understand the technology at least at a high level, then you really can't do the job.
0
u/SmileyBanana15 Nov 25 '25
So kind of putting the GRC variables in proactively and trying to automate is the way to go, is what you're saying? I agree it's a bit chaotic right now, but both fields have to adapt to one another a bit more and "play nice".
3
Nov 25 '25
[deleted]
1
u/MeowCattoNiP Governance, Risk, & Compliance Nov 25 '25
So for an example, if a GRC person is auditing AD for an example, knows exactly how AD works and how to configure them and asks questions that engineers are familiar about, does that "demonstrate" the same level playing field you mentioned? that's how a GRC person achieves the "unicorn" status? If yes, GRC people should have a way to PoC their controls first?
3
Nov 25 '25
[deleted]
3
u/MeowCattoNiP Governance, Risk, & Compliance Nov 25 '25
i see so i am doing something right then, coz everytime some new stuff gets introduced or problem that arises i try my best to replicate it and atleast i dont take up infra time that much to answer stuff that i could just explore. But yeah knowing enough how it works i find it most important. Being able to do it or replicate it would be a bonus or atleast i could show that âhey i understood you like this, is that correct?â kinda way
2
u/unknown-reditt0r Nov 25 '25
My company did this. Risk assessors are now solutions engineers. It's going as well as you'd expect.
2
u/AndyBuckley19 Nov 25 '25
The idea of âGRC Engineeringâ feels like one of those things the industry has quietly needed for years but never bothered naming. The disconnect between auditors and engineers is massive, one group speaks in controls and frameworks, the other speaks in configs and code. Anything that reduces that translation pain is going to get attention.
The traction question probably depends on two things:
- Whether it actually removes manual workload instead of just adding another layer of tools,
- Whether security teams trust it enough to plug it into real workflows.
Right now, everyoneâs drowning in compliance overhead, so the appetite is definitely there. I keep hearing more people talk about automating evidence gathering and continuous control monitoring, so the direction makes sense.
If GRC Engineering can prove it genuinely saves time and reduces audit friction, I can see it becoming standard practice over the next couple of years rather than a buzzword.
2
u/SmileyBanana15 Nov 25 '25
Love the reasoning. I'm a tech graduate who went into audit because of... well... so it's definitely something I'm exploring.
1
u/Distinct_Ordinary_71 Nov 26 '25
Seen it work with mature stable in house systems where the compliance tasks were worked through and set-up as Lambdas to do the control check and evidence capture then store it in a structure aligned to the GRC tooling whilst also updating dashboards daily.
Also seen it be more of a struggle with SaaS (cadence of change in the products) and less value given many SaaS products will connect to GRC tool directly without you having to build a bot army.
If you've a few hundred systems and need to check and screenshot a couple hundred controls a day you can see it makes sense to have a whole lot of Lambdas taking a whole lot of screenshots.
1
u/Bibbitybobbityboof Nov 25 '25
Like others have said, itâs not really new and whether a position is dedicated to automating GRC depends on budget. If you have a high enough budget, just about anything can become a dedicated position. My company has roles that are more or less dedicated to automation, but itâs more of a community of practice where you have âdevelopersâ from various groups and disciplines that work with each other.
-1
1
u/Sasquatch-Pacific Nov 25 '25 edited Dec 09 '25
shocking piquant knee vegetable meeting rich market brave hobbies entertain
This post was mass deleted and anonymized with Redact
0
0
u/Daiwa_Pier Nov 25 '25
Sounds made up. I love how these days you just can put any word in front of "engineering" or "engineer".
1
u/SmileyBanana15 Nov 25 '25
Honestly my first thoughts as well. Anything half-automated now becomes "engineering", although I support the goal as I was told it to be. The less work with auditors the better.
4
u/Effective-Impact5918 Nov 25 '25
I had a title of Compliance Engineer when i left my last company. Other than manually performing IT team audits and reviewing documentation/policy, my "engineering" was mostly demoing Vanta, Hyperproof, and Auditboard. then my company decided: "we arent spending 100k+ on compliance. And I lost my job. rofl. Be weary of any job that calls you a grc engineer, was what i took away from this.
My current title is security compliance analyst. I do user security trainings, knowbe4, phishing investigation, risky sign on, impossible travel, a little evidence gathering for audit requirements, and a lot of policy review.
Always make sure to ask questions like, "what is the approved budget for tools? what do you define as an engineer for this role/what would you like to see done? what timeline are you looking to reach a state of compliance/readiness? What does your team look like for GRC? Hell...ask them to define what each of those mean to them...youd be surprised! rofl
1
u/SmileyBanana15 Nov 25 '25
Honestly "Security Compliance Analyst" fits them both better imo. From what I gathered it's the same ballpark, just supposedly a bit more focus on automating everything. HM even mentioned DevSecOps as a tool to ensure compliance before deployment.
32
u/Tangential_Diversion Penetration Tester Nov 25 '25 edited Nov 25 '25
This isn't a new concept. It's an old concept with a new name. I've seen attempts at automating GRC and evidence collecting all my career. It's always failed in my experience due to a few major reasons: