Don't worry. I'm not about to spend the next 1,000 words of your time telling you about how great I am. I'm still figuring this out. Think of it like an ideal to reach.

What I do know, as someone with some experience, is that there’s a moment in every GRC career when you realize: this job isn’t really about controls or policies. It's about understanding the people making decisions, often without us, most of the time with good intentions, but with poor incentives. And it’s easy to feel like the work is being done without us, or worse, that it’s happening in spite of us. This is how most of the frustration in GRC builds up. Worse, you expect change, but the changes accelerate, just not on the parameters you need them to change!

I had this realization pretty early in my career. I was part of a team that thought it had a duty to be the "conscience" of the company and to "mature" it. The idea was to build such compelling risk stories that some careless projects would slow down. But the reality was that no one listened. The more I pushed, the more isolated we became. Team meetings were basically just ruminations on how these guys were driving the company into a wall.

This brings me to another hot topic: security is not cool. We will never push a feature that makes people lives measurably better. We will never single-handedly enthrall an audience with our demo skills. So, imagine: a bunch of specialists worried about being right while the "others" were getting featured internally. After a bunch of burnout and resignations, the lesson was clear: being right doesn’t matter if no one listens.

That's why I insist on relevance. Making security work isn't about authority (we don't have any) or following the frameworks (they're vague and full of holes). It's about being curious about systems, asking questions that no one else thinks of (because we do have a different, adversarial, perspective), and listening more than telling. There's a saying: "greatness is in the agency of others". So, what makes a GRC specialist "great"? How about ensuring others are allowed to build great things?

GRC Is Not a Role. It’s a Practice.

What makes GRC impactful isn’t just ticking off items from a compliance checklist. GRC is a practice that requires understanding the full scope of a business. I'd argue, this is even the most interesting aspect of security, the one I always use when people ask me why I love this practice! It’s not enough to know the framework or the policy; you need to understand how things really work in the business, from all layers: products, sales, infrastructure, applications, databases, networks, processes, legal, hiring, firing... you touch everything, might as well be curious about everything!

I can’t tell you how many times I’ve been in a meeting where I could connect two people or two systems to help with an issue that had no relation with security. There's this inside joke in networking: "The problem is always DNS!" Funny thing: most software developers don't know that meme, so when you debug them by finding that DNS flaw: that's "street cred"! This amount of cred is your capital. With this sympathy, you earn trust. By virtue of you being connected to every "system" (human of software or business, think systems-thinking), you see patterns that specialists won't see.

This is how you become uniquely positioned in your practice: your constant drive to learn about everything helps people learn more themselves, making everyone richer. As my philosophy teacher said in college: "Knowledge is the only thing you can give someone without having less for yourself". This is why "practice" is so deliberate: a practice has a predisposition on learning, because it evolves.

Relevance, Built Slowly

When you’re doing this work right, most of what you influence will be invisible. Back to my "you're not cool" point: You won’t be recognized for the risks that didn’t materialize, the issues you avoided, or the changes you made quietly behind the scenes. It's impossible to prove the absence of something, and we have no control group to validate what would happen if we did nothing. Ironically, the most praise I've seen a security team get is when we finally remove security measures that had terrible UX. That VPN product that took forever to connect. That inefficient password rotation...

Anyway, the real impact of GRC isn’t in the loud moments. It’s in the invisible work. The subtle nudges you make to help a team shift their thinking. The quiet check-ins to make sure people are aware of your services. The decision to gently remind a product team that there’s a better, safer way to approach a problem without slowing them down.

We tweak permissions. We notice weird contractual clauses that we get deleted. We convince VPs to pay the SSO tax. We see an alert in our configuration management systems and get a user removed. We screen consultants. Yes, sometimes we need to bust out the “policy says” approach. But most of the time, going in humble and curious, you can ask the right questions to get to the why your perspective matters. "You want to use this database? Ok, I'm wondering how will you manage the data residency?". I've asked that, knowing that the database in question didn't support that. I could have said "forget it, data residency won't work". But that feels like your parent telling you what to do. It was invisible work, but that’s the job. And it was only possible because I’d built the trust to have those quiet, important conversations.

In GRC, trust is earned slowly by being present and consistently showing up without needing to be recognized.

The Hardest Part: Sitting with Ambiguity

The real growth in GRC comes from sitting with the ambiguity. This job is not about certainty or easy answers. There are moments when you don’t know if a decision is going to be the right one, and you have to be comfortable with that. In fact, that can become your superpower. Executives, in my experience, dislike when we throw ambiguity back at them.

We can never know when an attack will happen and on which entry point. All we do is relying on educated guesses, intuition, and hopefully some data to steer our decisions. Yet, we must never walk into a meeting with a blank slate. As GRC specialists, our value lies in how well we articulate the problems, solutions, tradeoffs. When someone brings up a vendor, we can’t afford to give soft, evasive opinions. “We’ll have to do a risk assessment” isn’t enough. We need to have a take. We need to know when a vendor is a ticking time bomb and when a risk is just noise.

No, we can’t predict exactly when a third party will get breached. But we can absolutely call out when a vendor sucks at security. And we can design guardrails that limit the blast radius when things go wrong. That’s our job. That’s what earns us a seat at the table. Clear, assertive guidance in the face of limited data, while not going into full bullshitter mode, is the line we thread.

If we own the ambiguity, we abstract the complexity. That’s how things actually move forward. That’s the difference between being a GRC advisor who shapes decisions, and being a “meeting facilitator” who just nods along and documents action items no one reads.

You don’t win influence with risk methodologies. You don’t win it with strategic alignment decks or quoting frameworks. Most of that is corporate filler. You win it by being useful, direct, and present. By understanding what’s at stake, what matters to the business, and how to move toward safer decisions without slowing people down.

That’s what I look for in great GRC work.