People imagine a security leader as the person who knows the most about hacking. That’s not the job. The job is deciding what to protect, how hard, and convincing the rest of the company to let you do it. The technology is the easy part.
I never held the CISO title. My networking partner and I were both directors, and together we ran security for a national retailer. Now I ghostwrite books for the people who do hold that title. So I’ve seen the real shape of the work, both from doing it and from helping others put it into words.
Our situation was common and rarely talked about. Our boss wasn’t security savvy.
He wasn’t going to define the security strategy, because he couldn’t. So my partner and I did it. We were the de facto CISO, split between two people who divided the work and made the calls together. He owned the networking side, I owned the systems and operations side, and security lived across both, so we ran it jointly.
Plenty of organizations work this way, with a couple of senior people covering security leadership because someone has to. I’d still argue against setting a company up that way on purpose. Executives lump security in with IT, and IT people think about IT problems before they think about people. I think security belongs in its own department, reporting to someone other than the executive who owns IT. IT usually answers to the CFO. Security could answer to the COO, so nobody’s own project outranks the company’s safety.
We defined the rules. We defined how we’d do security, what we’d protect, and in what order. Then we took it to our boss for approval, and we didn’t expect him to understand what we were telling him. The people who sign off on security decisions usually can’t evaluate them on the merits, so part of the job is presenting the work in a way they can say yes to.
That translation problem turned out to be the most important skill in the job. Taking something technical and making it understandable to the person holding the budget. I learned it the hard way, which I describe in the boardroom and the server room speak different languages.
Half the security leader’s job is getting things approved by someone who can’t evaluate them. The technology is the easy part.Share on X
This surprised me most, and I never see it in the job descriptions. What got approved had almost nothing to do with how important it was. It had to do with who it inconvenienced.
The hardest things to get approved were the ones at the edge, close to the users.
Anything that touched what an employee saw or did on their own machine was a fight, because nobody wanted users to be inconvenienced or even to notice the security was there. Lock down an endpoint, restrict what software people can install, force a password change, add a step to a login, and someone complains. The complaint rolls uphill, lands on a manager, and suddenly your security control is a morale problem.
The controls people feel are often the ones stopping real attacks, and they’re the first thing a manager rolls back once the complaints about a login prompt pile up. That’s cowardly. The company trades away real protection for a quieter week, and nobody writes down that the company made the trade.
The easiest things to get approved were the ones in the center, away from users.
The company trades away real protection for a quieter week, and nobody writes down that the company made the trade.
Email servers, domain servers, application servers. We could harden those all day, because nobody saw it and nobody felt it. No employee files a complaint about a server configuration they never interact with. The work was invisible, so it was uncontroversial, so it sailed through.
The security work that’s easiest to approve is the work nobody sees. The work that protects users best is the work they’ll complain about.Share on X
That’s a strange and slightly perverse incentive when you think about it. The visible protections, the ones closest to where people work and often the ones that matter most for stopping real attacks, were the hardest to put in place. The invisible ones sailed through whether they were urgent or not.
A security leader spends a huge amount of energy working the gap between what’s important and what’s acceptable. Learning how to make an important-but-unpopular control palatable enough to survive is half the craft.
So the job is judgment. You have a limited budget, limited political capital, and a surface too large to fully protect, which I get into in most security tools are theater. You decide where the real risk is, you protect that, and you spend your finite influence getting the important and unpopular things approved while letting the invisible easy wins accumulate.
Every one of those is a tradeoff. Spend political capital here and you have less for there. Push too hard on user-facing controls and you burn goodwill you’ll need next quarter. Push too little and you leave real holes open. The security leader is constantly deciding what’s technically right and what’s achievable, and a perfect plan nobody will approve is worth less than a good plan you can get through.
You’re translating constantly. You take a technical reality your boss can’t parse and turn it into a business decision he can. You take a user complaint and weigh it against a real risk. You take a limited budget and decide which battles are worth fighting this year. None of that is in a certification. All of it is the job.
My take
Security leadership is politics with a technical backbone. You’ve got limited budget, limited political capital, and more systems than you can protect, so you pick your fights. Harden the invisible servers freely, since nobody complains about those. Save your influence for the user-facing controls that stop real attacks and draw the most grumbling. A manager who rolls those back for a quieter week is a coward. A good plan that gets approved beats a perfect one that never does.
Who sets security strategy when the boss is not technical?
This is exactly the kind of experience that makes a security leader’s book valuable, and exactly the kind that usually never gets recorded. The technical knowledge is everywhere. The lived reality of defending an organization against both attackers and internal resistance is rare, and it disappears when the person moves on.
When I ghostwrite for a CISO or a security director, the gold is the story of the call they made against the playbook, the unpopular control they fought to get approved, the politics they worked through to keep the company safe. That judgment is what a book preserves, and it’s the part the next generation needs.
Too much of this walks out the door. A security director retires or moves on, and years of knowing which fights to pick leave with them, while the company keeps the policies and loses the judgment that made them work. Most of it could have been written down, and almost none of it ever is.
Frequently Asked Questions
Far less hacking than people imagine. The job is deciding what to protect and how hard, then convincing the rest of the company to allow it. It’s judgment, budget, and politics. The technical knowledge is the easy part. Translating security reality into business decisions the leadership can approve, and getting unpopular controls through, is the hard part.
Yes, and often is. In my case, two directors functioned as a de facto CISO together because our boss wasn’t security savvy. One owned networking, one owned systems, and security lived across both, so we ran it jointly. Plenty of organizations work this way, with senior people quietly carrying security leadership because someone has to.
Because approval tracks who gets inconvenienced. Protections close to users are hardest to approve, since nobody wants users to notice or be slowed down, and complaints roll uphill into morale problems. Work in the center, on servers nobody interacts with, sails through because it’s invisible. Importance and acceptability aren’t the same thing.
Judgment under constraint. Limited budget, limited political capital, and an attack surface too large to fully cover. The good ones decide where the real risk is, protect that, and spend their finite influence wisely, knowing a perfect plan nobody will approve is worth less than a good plan they can get through.
Translation. Taking a technical reality the people holding the budget can’t evaluate and turning it into a business decision they can say yes to. The person who signs off usually can’t judge the security on its merits, so the leader who can make it understandable gets their controls approved, and the one who can’t watches good proposals die.
Yes. I ghostwrite for CISOs, security founders, and technical directors. You can see how I work on the cybersecurity ghostwriting page.
