The Communications Game

Here's my story about how I became convinced that communications was the core skill to master when working in GRC. Now, let me preface this with a big caveat: I'm not going to pretend I'm some mastermind here. I'm still figuring this out, learning the hard way. Still, I've come a long way. Might as well share my experiences.

Most security initiatives fail because of inapt communications. Sometimes it’s resistance to change that we fail to address. Other times it’s confusion because you just put a cereal box of acronyms in everybody's plates. Occasionally, it’s straight-up indifference. And each time, someone on the team says, “We explained it clearly. Why don’t they get it?”

But communication isn’t clarity. It’s relevance.

Whether you're talking to an engineer who wants you out of the way, or a business lead with a target to hit, they can tell if you're reciting a playbook. They can tell if you care about their work, or just want them to care about yours.

And yes, it feels like selling... because it is.

Security doesn’t work without trust. It doesn’t scale without buy-in. And it doesn’t stick if people are only complying out of fear. Our job isn’t just to enforce controls. It’s to embed security in the way the organization thinks, builds, and grows.

But communication is also relentless repetition.

I’ve sat through countless “communications plans” that boil down to a policy update and an all-hands email. That’s not strategy, that’s broadcast. Message in a bottle. The average office worker gets 121 emails per day. A good newsletter "open rate" is 25%. Getting people to care about security requires influence, not information. It means stepping out of our expertise and stepping into theirs. And even if you make the message as tailored and relevant as you can: expect to repeat yourself a hundred times.

Culture Isn’t Built with Slogans

I’ve never liked the phrase “security is everyone’s responsibility.” It sounds inclusive, but it isn’t. What it actually does is spread accountability so thin that no one feels it anymore.

If you work in GRC, you know how this plays out. We tell ourselves we’re enabling a “culture of security,” but we end up recycling awareness training slides and wondering why nobody reads them.

Meanwhile, engineers roll their eyes. Salespeople avoid us. IT does their thing.

Then we get frustrated. “They don’t care about security until a breach occurs!”

But they do. They care enough to pay someone to think about it for them! That someone is you. It may not be the right way to think about security, but it is what it is. Management, when they hire you, buy peace of mind for that "security problem". "But they're just putting security in a little box and expecting us to fix everything, that makes no sense!" I know, but this is what they're buying. Expecting developers or product managers to prioritize security risks over deliverables is a fantasy. It’s our job to translate risk into relevance. That means understanding how their incentives work and meeting them there.

When We Pretend, We Lose

One of the worst mistakes I ever made was showing up to a data lake project like I already had the answers.

Data lakes are messy. It's basically your old Android phone's photo archive version of database storage. And in security, that makes us anxious. We want controls. Owners. Retention schedules. But walking in with a checklist and a smirk doesn’t win you credibility. Maybe you'll get a backlog ticket that never gets touched.

That project taught me something I try not to forget: Sometimes the most secure thing you can do is shut up and listen first. Today, when someone pitches a new AI-powered system or a new data-sharing tool, my instinct is still to scan for risk.

But I’ve learned to start with:

“Interesting idea. Let’s see how we can make this work safely.”

I mean, at our heart, we must remain excited by all of technology's possibilities. If we can't get excited, the spark is gone, and this is where we become bitter and old.

I’ve seen GRC teams lose influence simply because they showed up like lecturers. Like the engineers needed a reminder of the rules. That posture doesn’t just fail internally by the way. It poisons vendor relationships, too. Nobody wants to be told what to do by someone who doesn't understand what they do. I've suffered this countless times working for a SaaS vendor.

Your Heatmaps Don’t Speak for Themselves

We like to think our data will do the talking. That if we come armed with the right risk matrix or classification schemes, people will just get it.

They won’t.

Most people don’t think in frameworks. They think in outcomes. If you walk into a planning meeting talking about ISO controls and pseudonymized PII, you’ll lose them in five minutes.

What they want to know is: "How much will this slow us down? And what's in it for me?" Sure, there are plenty of people who want to do things right and will champion your initiatives. But assume they aren't.

If you can answer those things first, then you’ve earned the space to talk about audit logs, access tiers, or backup policies.

Don’t get me wrong. I’m not saying throw away your frameworks. But they’re your "infrastructure". Not your product.

If They Fail, We Get Fired

If people don’t care about security, that’s not their failure, it’s ours. We can’t keep blaming the business for not listening. We need to ask how we’re speaking. Because when the breach comes, no one’s pointing fingers at the ones who missed the webinar.

They’re looking at us.

Shared responsibility doesn’t mean shared consequences. It never has. It's unfair, and stressful. Kaspersky noted that in 31% of breaches, employees get fired; 45% of them are senior security employees.

So if we want security to succeed, we need to stop expecting everyone else to get it, and start making it impossible not to. That means selling security, not yelling about mandatory checkboxes.

Because in the end, nobody remembers the policies you wrote. They remember whether you helped, whether you listened, and whether they could build with you in the room.

And that’s the kind of GRC that actually gets things done.