GRC Isn’t Broken—But the Way We Talk About It Is

It happened again today. A former coworker reached out after quite some time, and we caught up on the events of the last few years and the key moments in each other’s lives. I noticed he had gotten the promotion he talked about years ago. He noticed I had moved into GRC. But what he said sounded…off.

“Must be nice. I never had time to get the CISA. I guess I’ll have to keep doing the hard stuff.”

There’s a particular kind of advice that circulates around Governance, Risk, and Compliance (GRC). You’ve probably seen it.

“Compliance is recession-proof.”
“It’s a cushy role—mostly meetings and documentation.”
“You don’t need deep technical knowledge. Just learn the frameworks.”
“Get a CISA, maybe a CISSP, and you’re qualified for any GRC role.”

None of these statements are entirely false. That’s what makes them so persistent. And so misleading.

There is a need for compliance, even during a recession. There are a lot of meetings. Understanding frameworks matters. Certifications matter too. But each of these statements becomes incomplete the moment they are treated as the whole truth.

The problem isn’t bad intent. It’s oversimplification. And GRC isn’t unique in this.

My wife is a teacher. She regularly hears two contradictory narratives: that teaching is an easy job with summers off, and that teachers are underpaid heroes deserving of ritualized gratitude. Both narratives miss the reality. One trivializes the work. The other performs respect without engaging with what the work actually demands.

GRC lives in a similar tension.

The Comforting Myth of “Easy” Compliance

A lot of GRC advice is designed to reduce anxiety for people considering the field. That instinct is understandable, especially for career changers, but it often crosses into distortion.

Yes, GRC work is usually less physically demanding than some roles.
Yes, it often allows for remote or flexible work.
Yes, strong communication skills matter.

But none of that makes the work light.

While deep technical expertise is not strictly required, it is absolutely a force multiplier. The stronger a person’s technical background, the deeper the well they can draw from when making decisions. Decision-making is the missing link for many people who want to move into GRC.

Good GRC work requires sustained judgment under uncertainty. It means translating ambiguous requirements into defensible decisions, navigating organizational incentives that don’t always align with security outcomes, and living with the fact that “good enough” is often the best possible answer. Until it isn’t. In GRC, the moment when “good enough” fails can alter both company and career trajectories.

That cognitive load—the constant requirement to make and defend decisions—doesn’t show up well in blog posts promising fast tracks or in videos framed around salary bands. Nor does the communication burden: translating between technical teams, executives, boards, auditors, and sometimes customers, all of whom are listening for different things.

Frameworks Are Not the Job

Another common distortion is the idea that mastering frameworks is the work. Frameworks matter. They provide shared language, structure, and legitimacy. But they are not the deliverable.

The real work happens in the space between what the framework expects, what the organization can realistically sustain, and what risk actually looks like in practice. That space is messy. It is contextual. And it cannot be fully templated.

When advice overemphasizes frameworks without addressing that translation layer, newcomers are set up for confusion or, worse, disillusionment.

Doing Better Means Being More Honest

If we want better outcomes in GRC—stronger programs, healthier careers, fewer burned-out practitioners—we need to be more precise in how we describe the work.

That means being upfront that GRC is not for everyone. It means acknowledging that the hardest part of the job is not learning controls, but exercising judgment. And it means shifting the conversation away from abstract compliance toward the concrete outputs that demonstrate reasoning, intent, and follow-through.

This is where I’m increasingly convinced the conversation needs to go.

Not “How do I break into GRC?”
But “What does competent GRC actually produce?”

Toward Artifact-Driven GRC

Real GRC maturity shows up in artifacts.

Not paperwork for its own sake, but evidence of thinking over time. Decisions that can be explained months later. Risk acceptances that reflect real trade-offs, not convenience. Documentation that tells a story rather than checking a box. I can’t count the number of Issues and Exceptions Management cases that passed my desk without clarity on why decisions were made. If the decision makers had left the organization, their replacements were tasked with making a new decision without the true context of the previous one.

Competent GRC work produces clarity, more than perfection. It leaves behind records that show how a decision was made, what constraints existed at the time, and what conditions would trigger a reassessment. The goal is not to eliminate uncertainty, but to make uncertainty visible and manageable.

Artifacts don’t eliminate judgment. They preserve it. They allow others—future team members, auditors, leadership—to understand not just what was done, but why it made sense at the time.

If we anchor GRC education and advice around those outputs, we set more accurate expectations. And we respect the work by describing it honestly.

Not as cushy.
Not as martyrdom.
But as demanding, thoughtful, and worth doing well.