TL;DR
I was never a CISO by title. My networking partner and I were both directors, and since our boss was not security savvy, the two of us functioned as a de facto CISO together. We defined the rules and the approach, then went to him for approval knowing he would not understand the details. The real job of a security leader is not the technology. It is judgment, politics, and getting the unglamorous things approved by people who would rather not think about them.
People imagine a security leader as the person who knows the most about hacking. That is 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 have seen the real shape of the work, both from doing it and from helping others put it into words.
Two directors doing one job
Our situation was common and rarely talked about. Our boss was not security savvy. He was not going to define the security strategy, because he could not. 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, where the security leadership is not one person with a title but a couple of senior people who quietly carry it because someone has to.
We defined the rules. We defined how we would do security, what we would protect, and in what order. Then we took it to our boss for approval, and we did not expect him to understand what we were telling him. That was not a complaint. It was just the reality. The people who sign off on security decisions usually cannot 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, taking something technical and making it understandable to the person holding the budget, turned out to be the most important skill in the whole job, and 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
The politics of what gets approved
Here is the part that surprised me most, and that I never see 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 better the control, often, the more it is felt, and the more it is felt, the harder it is to keep.
The easiest things to get approved were the ones in the center, away from users. 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 is a strange and slightly perverse incentive when you think about it. The visible protections, the ones closest to where people actually 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 navigating that gap between what is important and what is acceptable, and learning how to make an important-but-unpopular control palatable enough to survive is half the craft.
Judgment under constraint
So the real job is judgment. You have 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 will need next quarter. Push too little and you leave real holes open. The security leader is constantly deciding not just what is technically right but what is achievable, and a perfect plan nobody will approve is worth less than a good plan you can actually get through.
You are translating constantly. You take a technical reality your boss cannot 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.
Why this is worth writing down
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 never the framework. It is the story of the call they made against the playbook, the unpopular control they fought to get approved, the politics they navigated to keep the company safe. That judgment is what a book preserves, and it is the part the next generation actually needs.
I ghostwrite books for CISOs, security founders, and technical executives who want their hard-won judgment on the record, accurately and in their own voice. If that is you, here is how I work with cybersecurity leaders.
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 is 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 was not 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, not how important the work is. 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 is invisible. Importance and acceptability are not 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 actually get through.
Translation. Taking a technical reality the people holding the budget cannot evaluate and turning it into a business decision they can say yes to. The person who signs off usually cannot judge the security on its merits, so the leader who can make it understandable gets their controls approved, and the one who cannot watches good proposals die.
Yes. I ghostwrite for CISOs, security founders, and technical directors. The valuable material is never the framework, it is the lived judgment, the unpopular call, the politics navigated to keep a company safe. That is what a book preserves. You can see how I work on the cybersecurity ghostwriting page.
Related Reading
- Good Security Policy Names Names
- The Human Layer Is Where Security Actually Breaks
- What Eight PCI Audits Taught Me About Real Security
Are you a security leader sitting on a book that would build your authority?