How to say no to the business without being overruled

Security leaders who say no a lot get routed around. Security leaders who never say no get blamed later. The way through isn't a better no; it's a better offer.

Reframe the request

Nobody asks for risk. They ask for speed, a feature, a vendor, a shortcut. When I'm asked to approve something I don't like, the first thing I do is find out what they're actually trying to get. Often there's a way to get most of it with much less exposure, and the person asking will take that deal gladly, because they didn't want the risk either. They wanted the outcome.

Put the decision where it belongs

Some risks are mine to accept. Most aren't. If a business unit wants to run something that could cost the company real money, the person accepting that risk should be the one whose budget pays for the consequence. My job is to make the risk legible: what could happen, how likely, what it would cost, what would reduce it. Their job is to decide. Written down, with a date.

That's not passing the buck. It's the only arrangement in which the no sticks, because it isn't mine anymore.

Keep a short list

Some things I won't sign, ever, and I say so in advance: credentials in code, production data in test, unmanaged admin access, and a handful of others that depend on the business. A short list, known in advance, gets respected. A long list gets ignored.

What this looks like in a meeting

"I can't approve that as described. Here's what I can approve this week, here's what it would take to approve the full version, and here's who needs to sign if you want to proceed anyway." Nobody leaves that meeting feeling blocked. They leave with options and an owner.

If you're a leader trying to get this balance right, or a board wondering why security keeps losing these arguments, that's a conversation I'd welcome.

Explore: More on executive leadership · Work with me