Why I Left GRC… and Came Back to Fix It

Why I Left GRC… and Came Back to Fix It

When my career started, I left GRC to go into pentesting and validation work. Not because I didn't believe in it, but because I believed it was a natural evolution to learn controls implementation for real: why they exist and what they protect against. Learning there was an equal but opposite compromise for every control and the risk they present is a context most offensive security practitioners never get.

I carried those lessons with me through red and eventually purple teaming where I quickly realized something. Understanding how the controls are delivered, expected, designed, and implemented made me an even more dangerous operator than someone with the standard skillset.

There were two defining moments in my career that genuinely broke my heart.

The first was while I was an internal pentester. I had reached a point in my cadence of operations where the only thing separating one report from the next was the date on the cover. Same findings, same gaps, same risks persisting, different quarter. I wasn't actually moving the needle or helping anyone. That's what prompted the emergence of cross-functional offensive security: purple teaming.

The second came recently, last week in fact. I was speaking on GRC Engineering and Continuous Controls Monitoring (CCM) at ISACA London when someone said to me: "I am compliant before I am secure." And sadly they didn't mean it ironically.

That's when it hit me… somewhere along the way of meeting the regulatory demand we confused driving compliance with proving security assurance.

How We Got Here

GRC didn't fail because it's the wrong approach, it failed because it stopped evolving. While the rest of security operations matured, GRC stayed stuck in a model built for static environments. Point-in-time assessments, annual testing, pass/fail outcomes with no drill down capability, screenshot (or worse) questionnaire-based evidence.

Meanwhile everything it's supposed to govern has changed. Cloud is elastic, identity is fluid, Infrastructure is ephemeral, CI/CD is dynamic and constant, AI is non-deterministic. And yet we're still asking ourselves "Did this control pass?" instead of "Can we trust this control to make the attacker's job harder (see: reduce risk) right now?"

What Offensive Security Figured Out (That GRC Didn’t)

In offsec, maturity doesn't come from more tests, more discoverability, more findings. It comes from clarity. The only factors separating a Tier 0 from a Tier 3 program are more frequency, more context, and specifically applicable intelligence.

GRC never made that leap. It stayed periodic, binary, and detached from the dynamic systems it was supposed to represent.

{{ banner-image }}

The Cost of Getting It Wrong

Here’s the uncomfortable truth (and I'm a red teamer so I'm prepared for the opposition argument): Pass/fail is a basic compliance outcome. Confidence and assurance are security outcomes. Most enterprise GRC programs today have been optimized for the former.

We built entire tools and programs around automating collecting evidence instead of proving effectiveness. We accept static artifacts as truth. GRC is the only area of security where we still do this.

And then we wonder why. Controls silently fail, risks resurface quarter after quarter, security budget spend is at an all time high and yes so are breaches. Security teams are overpowered in alerts and underpowered in assurance.

Why This Breaks At Scale in an AI-Driven World

We're discussing it on all the panels: Agentic AI is increasing speed, scope, scale, and sophistication on both sides of the coin, but only one side is constrained by governance and process. The gap is no longer theoretical. Agentic AI means systems change faster than humans can review them. Decisions are being made without human checkpoints. Attackers operate with the same if not better speed, scale, and automation

You cannot govern a real-time system with a point-in-time model. And more importantly, you cannot build trust without understanding the data-reinforceable narrative behind it.

The Shift: From GRC to GRC Engineering

After leaving ATO application security in the fedgov space, I honestly sat back to see if GRC would go away or be absorbed. Instead, it got a revival. I have always believed in operational truth and data as the only evidence you can trust. So I am not here to "automate better GRC" I am here to push it into what it needs to become.

GRC needs to evolve into an engineering discipline. That means:

• Controls that are data-connected
• Evaluations that are continuous
• Evidence that is observable and traceable
• Systems that are versioned, testable, and owned
• Risk scoring that is rooted in threat and data intelligence

At the end of the day security doesn't begin with policy, it doesn't even begin with regulations. It begins with data, and it ends with intelligence.

Interestingly, some of the strongest signals I’ve seen in this area lately aren’t coming from vendors, they’re coming from practitioners. But that’s also a big part of why I’m at Anecdotes. The Agentic GRC Platform is built for practitioners around the same principles I listed above: a trusted data foundation that pulls evidence directly from the systems controls actually live in (230+ plugins and counting), context-aware AI agents that run continuous evaluation instead of point-in-time checks, and dedicated GRC applications for CCM, dynamic risk scoring, and policy lifecycle management. It’s the closest I have seen anything come to treating GRC as an engineering discipline rather than a documentation exercise.

But what has been most reinforcing isn’t the tech. It’s watching recent internal hires come directly from true GRC practitioners. People who have lived the pain of traditional GRC, found something better on the other side of the platform, and decided they wanted to help build it from the inside.

That doesn’t happen in markets that are working.

We're at an inflection point where the market doesn't need more tooling, it needs a mindset shift. From proving compliance to proving security outcomes. From collecting evidence to understanding systems and critical business functions. From periodic checks to continuous ingest.

I didn't come back to GRC because it's comfortable, I came back because it's unfinished. And if we get this transformation right GRC won't just support security, it will finally be part of how we engineer it.

The next post gets into what GRC engineering looks like when you actually build for it. Until then, if any of this resonates, find me on LinkedIn. If it doesn't, find me anyway. The opposition argument is where the work gets sharper.

‍