top of page

Speaking Security So the Business Can Actually Decide

  • cletetaylor67
  • Apr 21
  • 6 min read

Or: How I Stopped Saying Smart Things and Started Getting Decisions

Let me start with a confession.Early in my career, I thought if I explained a security issue clearly enough, the business would obviously do the right thing.

Reader, that is adorable.

What actually happened was this: I would explain the risk, sprinkle in some impressive terminology, everyone would nod, someone would say “Good call,” and then absolutely nothing would happen. No funding, no priority, no decision. Just vibes.

It took me years and more than a few awkward follow‑ups to realize the problem wasn’t that leadership didn’t care. It was that I was asking them to make decisions in a language they do not speak fluently.

Security loves mechanisms. Business makes decisions on outcomes.

Once that clicked, life got easier.

Why “Security Speak” Makes Business Brains Short‑Circuit

When we say things like:

  • Zero Trust

  • Least privilege

  • Micro‑segmentation

  • Conditional access

  • EDR, SIEM, IAM, MFA, ABC, 123, please send help

We think we’re being precise. The business hears a foreign language and politely waits for the translation that never comes.

Executives are quietly asking:

  • What is the bad thing we are trying to avoid?

  • How likely is it?

  • How painful will it be?

  • And what changes if we do this versus if we don’t?

If we do not answer those questions directly, we should not be surprised when wheels do not turn.

A Brief Story About a Meeting That Went… Not Great

Let me tell you about a meeting that still makes me laugh and cringe in equal measure.

I once walked into a leadership meeting armed with slides, diagrams, and a truly unreasonable number of acronyms. I was proud of those slides. There were boxes. There were arrows. There were layered controls. It was beautiful.

I confidently explained why we needed to modernize our approach using Zero Trust, least privilege, conditional access, and improved network segmentation. I talked for a solid fifteen minutes without taking a breath or using a single normal human word.

When I finished, the room was silent.

Finally, a senior leader leaned forward and said, completely earnestly,“So… is this something we’re already doing?”

Another executive followed up with,“Are we in danger right now, or is this like a someday thing?”

My personal favorite came last:“Which of these actually stops us from being on the news?”

And there it was. The moment of clarity.

I had explained how security works, not why it mattered. I answered questions no one asked and skipped right over the ones they actually cared about.

That meeting ended with exactly zero decisions made. The only thing that changed was my understanding that being technically correct is not the same thing as being understood.

That story repeated itself a few more times before I finally learned the lesson. If you recognize yourself in it, congratulations. You are normal. Also, welcome to the club.

More Translations From the Field

Here are some of my favorite real‑world translations that actually land.

From “We’re Implementing Zero Trust”

To:

“We’re making access decisions based on real need and current risk instead of assumptions. If someone asks why access was allowed or blocked, we will have an answer that makes sense.”

Translation bonus point: executives love accountability and explainability.

From “We’re Applying Least Privilege”

To:

“People and systems will have only the access they need to do their job, and it will not live forever by default. When roles change, access changes too.”

You will see heads nod because this sounds like basic common sense, which it is.

From “We Need MFA Everywhere”

To:

“Passwords get stolen. All the time. This makes it much harder for someone to turn one stolen password into a real problem.”

No one argues with reality.

From “We Need Better Logging”

To:

“Right now, some problems could be happening for weeks before we notice. Better visibility lets us catch issues early, when they are cheaper and less disruptive to fix.”

This frames logging as saving money and sleep.

From “We Need Endpoint Detection and Response”

To:

“If a device starts behaving suspiciously, we can spot it and respond before it turns into a business‑wide problem.”

You do not need to say EDR. No one misses it.

From “We Need Firewalls to Do Micro‑Segmentation”

To:

“We’re building the ability to isolate compromised systems so one bad day doesn’t automatically turn into a company‑wide outage.”

Now you are talking about blast radius, which leaders absolutely understand.

Explaining Risk Tradeoffs Like a Human

This is where things really change. Decisions live in tradeoffs, not absolutes.

Instead of saying:

“This is a critical risk and we must fix it”

Try something like:

“If we do nothing, we are accepting the chance of several hours or days of downtime for this system. Fixing it reduces that risk but will slow this project by a few weeks. Which risk do we prefer?”

Or:

“This security control adds friction for users, but it lowers fraud risk. Removing it improves speed but increases the odds of a costly incident. Where do we want to sit on that curve?”

Or my personal favorite:

“We can be fast here, or we can limit damage when something goes wrong. Doing both costs more. Which matters more for this system?”

Suddenly, security is not saying no. Security is presenting options.

Another Meeting That Should Have Been an Email (But Still Would Have Gone Wrong)

Because one embarrassing meeting is never enough to really teach the lesson.

In another life, I was presenting a risk assessment to a room full of senior leaders. This time I was determined to do better. Fewer acronyms. Fewer diagrams. I even told myself, “Okay, talk slower. Use normal words. You’ve got this.”

So I walked them through a scenario where a legacy system had weak controls, broad access, and limited monitoring. I thought I’d done a decent job explaining how an attacker could move through the environment if that system was compromised.

When I wrapped up, feeling cautiously optimistic, someone asked,“So is this a hypothetical attack, or did this already happen?”

I said, “Hypothetical.”

Another leader immediately followed up with,“Oh. Then why are we talking about it now?”

I tried to explain probability. And trends. And likelihood. And how attackers don’t usually send calendar invites before showing up.

What they heard was:“This is a thing that has not happened yet.”

The conversation instantly shifted to delivery timelines, quarterly goals, and “keeping things moving.” The risk discussion quietly packed its bag and left the room.

On the way out, one executive actually said, and I quote,“Let’s circle back on this if it becomes real.”

That was the moment it finally sank in. I had described a technical possibility, not a business decision. I never translated what “becomes real” actually looks like in terms they cared about.

What I should have said was something like,“If this failure happens, it looks like several days of downtime, customer complaints, and a very uncomfortable conversation with Legal. This project reduces how likely that future is.”

That meeting taught me a valuable lesson. If you leave room for “we’ll deal with this later,” later will win every time.

Questions That Invite Decisions Instead of Dead Air

Here are a few questions I keep in my mental toolbox:

  • “What would be the most painful failure here?”

  • “How much downtime would be acceptable before this becomes a real problem?”

  • “If this data were exposed, who gets the first angry phone call?”

  • “If this bulk export happened from a valid user that was compromised, how could that impact your business?

  • “Are we optimizing for speed now or resilience later?”

When you ask questions like these, leaders lean in. These feel like business problems because they are.

How to Practice This Without Getting Burned

This skill does not magically appear. You practice it.

A few low‑stress ways to get better:

The No‑Acronym Challenge

Explain your idea without acronyms. If it sounds ridiculous, keep refining it.

Write the Executive Summary First

If the first sentence is technical, start over. Lead with impact, not architecture.

Borrow Business Language Shamelessly

Listen to how leadership talks about risk, cost, customers, and reliability. Use their words. This is not manipulation. It is translation.

Test With a Friendly Non‑Security Person

If they say, “So what?” that is feedback, not failure.

Treat Risk as a Choice, Not a Threat

You are not there to scare people. You are there to help them choose deliberately.

The Quiet Endgame

The real goal is not getting every security control approved.

The real goal is shared ownership of risk.

When something goes wrong and everyone can say, “Yes, we understood this and chose it,” security has done its job.

And honestly, that is when the job gets a lot more interesting.

Thanks for Hanging Out

If you made it this far, thanks for spending a few minutes with me. I genuinely appreciate you reading.

If this topic resonated, you might enjoy some of the other posts over at cletustaylor.com, especially if you like security writing that sounds like it was written by an actual human.

Also, if Zero Trust is your thing, make sure you check out Volume One of the “Zero Trust Trilogy”, which is coming out next month.  It is co‑written with Crystal Coindreau and Quetzacoatl Contreras. That series goes much deeper into these ideas without turning into a standards document disguised as a blog.

Last thing, if you have a subject or challenge you want me to blather on about, drop me a line at hello@cletustaylor.com

More coffee, more stories, more lessons learned the hard way coming soon.

 

Comments


bottom of page