I’ve spent most of my career in GRC trying to find ways to make security relevant. And somewhere along the way, I realized the difference isn’t in the frameworks. It’s not in the policies. It’s not even in how mature your risk register is.

It’s in whether people want you in the room before the decision is made.
That has everything to do with how you show up.

For a long time, I thought influence came from structure and efficiency. If we build the right model, the right RACI, the right ticketing flow, the right automation, things would click. But structure doesn’t build trust. Presence does.

Presence is being there when the vendor is picked (not after the contract is signed).
Presence is being looped into a design document of the first draft of a new system.
Presence is saying, “Let me help you do this right,” before anyone even asks.

And I know how idealistic that sounds. GRC teams are stretched thin. We’re not always invited. We’re often chasing after projects already underway. I'm pretty sure I'm being overlooked in many projects despite everything that I do. But that’s the work. That’s the price to stop being the team of “no” and become the team that helps everyone move forward without stumbling.

Frameworks Are Not Strategy

I’ve written before about how we inherited too much of the checkbox mindset. We were taught that policies equal security. That evidence equals assurance. That frameworks are the work. But they’re not.

They’re sheet music.

They’re useful only if they help us understand the melody of the business. You can read sheet music but that's pretty boring unless you can play an instrument. The real work (a.k.a. playing that violin) is understanding how this company actually builds, ships, sells, and survives and helping it do that more securely.

That’s the difference between GRC as audit prep and GRC as business enablement. One is reactive. The other is embedded. I don't have a sheet music analogy to punctuate that.

When you stop leading with frameworks and start asking what people are trying to achieve, you start seeing the gaps differently. You’re not looking for non-compliance, your mind becomes solution-oriented (solution as in: software solution). This doesn’t mean you throw out compliance. It means you stop confusing it with action.

Relevance Is Built, Not Granted

I think a lot about how trust is built in hallway conversations or in the Slack thread where you helped someone unblock a process instead of quoting policy. Or in the architecture meeting where you asked a thoughtful question and didn’t talk over anyone. That kind of credibility compounds. Quietly. Then suddenly.

And it changes everything.

You stop being the person who files JIRA tickets after the fact. You become the person who gets pulled in before the build.

If you’re in GRC right now and you feel invisible, I see you (get it?). Sometimes, I still do, despite all my speeches about relevant GRC.

But I’ll say this: relevance is the ability to help people find the right ideas or information at the right time for the right need. Can you provide that, or are you simply shifting them your framework?

Try this: map the system down. On a whiteboard or piece of paper. Get a layer where you understand the business intent (this is how we sell this thing), the use case (this is how a human will use the software and get an experience out of it), THEN the tech. Gives you a multi-dimensional mind map of the whole forces at play. That's how I define relevance. If you see these patterns, you can act swiftly.

That’s how you become the advisor, not the afterthought.