Early in my career I thought a good security leader was someone who closed things. Open ports, weak passwords, unpatched servers, risky vendors, find them, shut them, move to the next. The scoreboard was the list of things I had eliminated.
It took me a while to notice that the list never got shorter. Close ten risks, the business opens twelve. A new product, a new market, a new partner, a new piece of software someone in finance already signed up for. The work wasn’t reducing the risk to zero. The work was deciding which risks the company would carry on purpose, and making sure someone owned that decision.
That sounds like a small reframe. In practice it changes almost everything about how you do the job.
It became concrete for me in a conversation with a founder I reported to. I came in expecting us to talk about a specific exposure I wanted closed. That wasn’t the conversation he wanted. What he was actually asking for was a plan and a measurable before-and-after, evidence that we were moving in a direction, not a single fire put out. He wasn’t asking for a technical explanation, and he wasn’t asking me to make a particular risk disappear. He was asking me to show him progress he could see. I’d been about to hand him a closed ticket. What he needed was a trajectory.
Here is the distinction I keep coming back to. Fixing a vulnerability can be a technical act. You can do it alone, with tools, on a Friday afternoon. Deciding what the company does about the business risk underneath it is a governance act. It needs someone with the authority to say “yes, we accept this,” and a record that they said it. The first feels productive. The second is the one that holds up when something goes wrong and people ask who decided.
The trap for security people is that we are usually better at the first than the second. We came up through systems. Saying no to a firewall change is easy; the firewall doesn’t have a budget meeting. Saying to a board, in writing, with your name on it, “I recommend we accept this risk for the next two quarters, here’s why, and here’s what would make me change my mind” is a different muscle. Most of us build it late.
My own sharpest lesson here didn’t come from saying no. It came from not insisting. Early in a role I’d joined as the new security lead, I started where I always do: assessing how mature the processes and controls actually were. One of those checks was simple, what traffic was really going in and out of the network. The person who had effectively hired me, the CTO, pushed back: why do you need that, everything here is fine. I was new, I deferred, I moved the check down the list. A few weeks later it turned out that how he was using the infrastructure was exactly the kind of thing that check existed to catch. I would have found it earlier if I had trusted my own assessment instead of the person who hired me. So when I talk about a security leader’s right to say no, I mean something narrower and harder than vetoing changes: the duty to keep asking your own questions even when the most senior person in the room tells you not to. Sometimes “no” is just “I’m still going to look.”
A few things I try to hold onto, for whatever they’re worth:
A risk you accept deliberately is safer than one you’re carrying without knowing it. A documented, owned, time-bounded acceptance can be reviewed. A fix you marked done without recording what was left over has no owner and no review date, and those are the ones that come back.
“It’s handled” is not a risk position. It’s a feeling. A position has an owner, a rationale, and a date it gets looked at again.
The goal isn’t a smaller risk list. It’s a list the management body can actually see. A leader who hands the board ten risks they understand has done more than one who quietly carried fifty.
None of this means I stopped closing things. Patches still matter; weak controls are still weak. And I want to be careful here, because “manage the risk, don’t just remove it” is easy to twist into “so I can leave things open and call it accepted.” That is not the failure I actually see. What I see is closer to the opposite: teams that don’t document at all, close only what is on fire, and leave the quieter risks both unfixed and unrecorded, no owner, no review date, nothing. In most of the teams I’ve seen up close, it isn’t deliberate neglect. They’re buried in operational routine because the process, the planning and the communication underneath were never built, so from the outside it looks like neglect. They miss the business risks not because they don’t care, but because they aren’t speaking the same language as the business, or they’ve been pushed so far from it that “doing the technology” starts to look like the whole job. In that world, managing risk isn’t permission to do less. It’s the thing that drags the quiet risks into the open where someone can finally own them. And an acceptance isn’t a waiver: signing one doesn’t move what the law, the regulator, or the contract already requires of you.
What changed is what I think the job is. I used to measure myself by what I had eliminated. Now I think a security leader’s real output is a smaller, stranger thing: a set of decisions the company made with its eyes open, that someone owns, that someone can defend. Most of the value isn’t in the risks you removed. It’s in the ones you chose to keep, and the fact that choosing was deliberate.
You don’t get a clean scoreboard for that. The risks are still there, and they still belong to the company, not to me. What changed is that each one has a name against it and a date it gets looked at again. Chosen, not inherited. That’s the difference between running security and just reacting to it.