Why Being a CISO Is the Most Fascinating Job in the Building

There is no other job in the building like this one. Unique in a precise sense: every direction you turn asks you a different question, in a different language, about the same underlying thing. Most people describe that as a design flaw. I've come to think it's the whole point of the role, and the reason this is the most fascinating job I've ever had.

Let me show you what I mean.

The auditor walks in with NIST CSF 2.0 in hand and asks: did you cover Govern, Identify, Protect, Detect, Respond, Recover? Six functions. Tick the boxes. Show the maturity ratings.

The architect walks in with a vendor Magic Quadrant and asks: did you pick the right IGA, the right PAM, the right CIEM, the right ITDR, the right EDR, the right NDR, the right CSPM, the right DSPM? Eight categories, half of which didn't exist three years ago, each with its own analyst, its own conferences, its own roadmap, its own renewal cycle.

The CFO walks in with a budget request and asks: what's the program? What's the deliverable this year? What's the ROI story? One investment unit. One PM. One quarterly milestone.

The head of the new digital offering walks in with a launch date. Her team has spent a year building the client onboarding journey, two markets are waiting on it, and she needs to know - because she owns the revenue number - whether the security review is going to be the thing that kills the date.

The infrastructure head walks in and says the new EDR agent is hammering CPU across the production fleet - can we exclude these subnets, just temporarily? The application development head walks in and says her senior engineers need persistent admin access because the just-in-time access flow is breaking their sprint velocity. The head of operational risk walks in with the quarterly control assessment and asks why three of your maturity ratings are showing amber. None of them are wrong. Most of them are trying to build or run something the firm genuinely needs. Each one is defending the primary objective of their function. Yours is the only role in the building whose primary objective is security itself, which means every other primary objective in the room is asking you to bend yours so theirs can ship.

The board walks in once a quarter and asks something different from all of the above. They don't want NIST scores. They don't want vendor names. They don't want your program list. They want to know whether the firm will be on the front page next week, in a vocabulary that has nothing to do with how security actually works. That's a different translation entirely: technical to non-technical, security as a domain to security as a business outcome. Most CISOs were trained to talk to engineers, not to directors. The board meeting is the room where you most clearly stop being a security leader and start being something closer to a translator.

And underneath all of this, the threat actors don't follow any of these taxonomies. They aren't organised by NIST function, or vendor category, or budget program, or org chart, or board agenda. They are non-linear. They chain techniques opportunistically. The same ransomware crew can play out a hundred different ways across a hundred different victims: same starting point, same end state, completely different attack paths in between. Many-to-many at every step of the chain: many initial access vectors, many ways to move laterally, many ways to escalate, many ways to exfiltrate, many ways to deliver the payload. You cannot pattern-match your way to a clean defensive posture because there is no single pattern to match. The adversary's organising principle is "anything that works." Yours is "everything that might."

So you tell the auditor about the NIST coverage map, the architect about the technology stack, the CFO about the program. You sit with the product head and work out which controls genuinely have to land before launch and which can follow in the next release. You explain to the infrastructure head why you can't carve out the subnet, to the dev head why the engineers don't get persistent admin, to the risk head why the amber ratings are in the right places. You translate the whole thing again for the board, in business outcomes that the boardroom can actually hold onto. And while all of that is happening, the threat actor is doing none of it. They're just looking for a single misconfiguration to pivot on. A different vocabulary in every doorway. One control surface. And when something pulls on a thread (usually the regulator, sometimes an incident, occasionally a board member who's read about a peer firm breach) you find out the stories don't reconcile cleanly. They never did.

For a while you assume this is a personal problem. Better tools, better frameworks, better budgeting discipline, better dashboards - surely something should bring these views into alignment. Buy a GRC platform. Hire a control-mapping consultant. Adopt CIS Critical Controls as a unifier. Try to write a master taxonomy that maps everything to everything.

None of it works cleanly. You get partial alignment (a mapping that holds for one quarter, one audit, one board cycle) but it always leaks at the seams. The tools aren't bad. The problem just isn't a tooling problem.

This is the point where most writing about the CISO role turns dark. Burnout statistics, average tenure, the impossible job. I want to take it somewhere else, because I think the structure I just described is the best thing about the role - the thing that makes it genuinely unlike any other seat in the building.

What I've come to think is the actual structure underneath the role is this. The questions coming at you are not different phrasings of one question. They are orthogonal taxonomies that share vocabulary but not referents. They look like they should reconcile because they all use the word "security," but each one is asking in a different grammatical mood, about a different object, for a different audience. Five of them matter most.

Frameworks answer: "Did you cover all the things a security program should cover?" That question comes from auditors, internal risk committees, cyber insurers, the CISO's own conscience. The verb is should. The object is controls.

Vendor categories answer: "What product can I buy to solve this technical problem?" That question comes from architects, Gartner and Forrester analysts, security engineers writing RFPs. The verb is can. The object is products.

Obligations answer: "What must you demonstrate - and to whom?" In a bank, the enforcer is the supervisor. In a SaaS company, it's the enterprise customer's procurement questionnaire and the SOC 2 auditor. For everyone, it's increasingly the cyber insurer. The enforcer changes by industry; the verb never does. The verb is must. The object is evidence.

Threat reality answers: "What will an adversary actually do?" That question comes from the red team, the SOC, threat intelligence - and from the adversary themselves, who answers it daily whether you ask or not. The verb is will. The object is behaviors: attack paths chained opportunistically, indifferent to every other taxonomy on this list.

The business answers: "What are we trying to ship, and what is protecting it worth?" That question comes from product heads, the CEO, the people building things for customers. The verb is wants. The object is outcomes: launches, revenue, customer trust.

Should, can, must, will, wants. Five different moods of the same sentence, and no grammar that conjugates them into one. And these are only the loudest five. Behind them sit the rest, each with its own verb: risk registers ask what might happen (likelihood times impact, how the board risk committee keeps score), the architecture asks how the estate actually is built (network, endpoint, cloud, identity, data), the budget asks what pays this year (the CFO's lens, discrete investments to fund), the org chart asks who owns it (who gets paged at 2am). Each one overlaps with the others. None align. Every security decision lives at the intersection of dimensions that were never designed to intersect.

Notice something about the five, though. The first three - should, can, must - are accountability languages. Paper languages. The last two are the forces that actually move: the adversary and the business. A CISO who is fluent only in the paper languages is precise about everything except reality. A CISO fluent only in the last two is exciting right up until the audit. The job demands all five, natively, often in the same meeting.

Take a single discipline: vulnerability management. One sentence to describe what it does: find weaknesses before adversaries do, then fix them. Couldn't be simpler. Now watch it fragment across the axes.

On the framework axis, it touches Identify (asset inventory, discovery), Protect (patching, hardening), Detect (continuous scanning), and Respond (emergency remediation). One discipline. Four NIST functions. The auditor maps your program across all four and asks where the gaps are - a valid question, irrelevant to how the discipline actually operates day-to-day.

On the vendor axis, the market has exploded into seven or eight named categories in the past five years alone: scanners, external attack surface management, software composition analysis, breach and attack simulation, patch management, exposure management platforms, penetration testing as a service. And now Gartner has coined Continuous Threat Exposure Management (CTEM), a category roughly three years old that is already trying to subsume half of the others. Neither the analyst map nor the vendor pitch tells you whether you've actually reduced exposure.

On the obligations axis, it's worse. NIS2 mandates vulnerability handling and disclosure. DORA requires defined remediation windows for critical findings. PCI-DSS v4.0 wants quarterly scans plus annual penetration tests, pass/fail. The SEC has made an unpatched critical vulnerability a potential material disclosure event. And if no regulator covers you, your largest customer's security questionnaire does, with a contract renewal attached. Each enforcer says "manage your vulnerabilities." Each means something different: different definitions of critical, different timelines, different evidence, different reporting chains.

On the threat axis, none of that matters. The only question is whether the vulnerability is actually being exploited, by whom, against estates that look like yours - a handful of CVEs out of the year's tens of thousands. And on the business axis, every remediation window you impose lands somewhere real: in the middle of a launch, a quarter-end freeze, a migration that's already late. "Patch now" is never free; someone's roadmap pays for it.

Five axes, all simultaneously right, none derivable from the others. The same Log4Shell drops on a Friday afternoon and you are simultaneously answering the framework question ("which functions were affected and what's our residual maturity?"), the vendor question ("does our scanner even detect this? do we need an SCA tool we don't have?"), and three regulatory questions with three different disclosure timelines running in parallel - while the threat question answers itself within hours (mass exploitation, everywhere) and the business question lands on your desk personally, because the emergency patching you're about to call collides with the biggest release weekend of the quarter. Same vulnerability. One control surface. Five unaligned response tracks - and the adversary is already inside while you're still translating.

In enterprise architecture, this is called the stakeholder viewpoints problem, formalised in ISO/IEC 42010. Different stakeholders need different views of the same underlying system. No single view is the master view. The architect's job is to maintain the views and translate between them. Security feels it more acutely than most domains because of framework proliferation (NIST plus ISO 27001 plus CIS plus NIS2 plus DORA plus sector-specific overlays) and vendor density. The security market produces more product categories per dollar than nearly any other enterprise tech segment. But the pattern is older than security and bigger than us. Every CIO, every CTO, every infrastructure leader is dealing with a version of this. We just got the loudest version.

There's a Brooks-flavored sharpening worth naming here: this is essential complexity, not accidental complexity. You cannot tool or framework or vendor your way out of it. Better GRC won't reconcile the dimensions. New frameworks won't; they will just add another axis to the pile. Better budget categorisation won't. Good CISOs build working approximations (a risk taxonomy that maps 80% of the landscape, a reporting structure that holds for most quarters) but the approximations are always local and temporary. They buy time. They don't resolve the underlying geometry. The complexity sits in the irreducible fact that multiple audiences need multiple views, the views are mathematically orthogonal, and every real decision cuts across all of them simultaneously. The only viable move is fluency: speaking the vocabularies natively, knowing which one each stakeholder is asking in, and translating in real time.

Here is the move that I think is actually load-bearing for the role.

The impedance mismatch is the reason the CISO role exists.

If all these dimensions spoke the same language, the CISO job would be project management. Execute the catalog. Tick the boxes. Run the runbook. The mismatch is precisely why a senior, judgment-driven role sits in the middle of the structure. You aren't there to solve the mismatch. You are there to be the person who holds all the views simultaneously and produces decisions that are coherent across them. The translation IS the work. The translation IS the deliverable.

You don't have a structural problem. You ARE the solution to a structural problem.

Now sit with what that actually means, because it's the part nobody says out loud. You hold the rarest vantage point in the firm. The auditor sees controls. The architect sees products. The CFO sees programs. The regulator sees evidence. The board sees headlines. You see all of it, at once, every day - and not just the policy machine. The actual machine. The people, the products, the customer promises, the fragile old platforms nobody wants to talk about, the shiny new things everyone wants to launch, the politics, the pressure, and those moments when something breaks and the whole building suddenly remembers why security exists. You are the only person whose job requires that view. There are very few seats in any organisation from which the whole institution is visible. This is one of them.

It also means the job cannot be automated into a runbook, cannot be replaced by a framework, and cannot be commoditised by the next platform pitch - for exactly the reason the geometry is irreducible. The demands are real. So is the pressure from every direction. But that demand is what the function costs, and what it buys is a role with no ceiling on craft: fluency and judgment both compound, and the work stays intellectually alive in a way very few senior roles manage after the first decade.

It's worth being precise about that claim, because every CISO is currently being told some version of "AI will do your job." Look at what AI actually does to the structure. It is genuinely good - already - at working inside a single vocabulary: drafting the evidence pack, mapping controls across frameworks, summarising the threat report, producing first-pass answers to the customer questionnaire. The linguistic layer of translation is getting cheap, and it will keep getting cheaper. What it doesn't touch is the part that was never linguistic: deciding which view wins when they conflict, owning the residual risk after the trade-off, choosing which battle to concede this quarter, lending your personal credibility to a launch. The geometry tells you exactly which half of the job the machines are coming for - the half you wanted to give away anyway. Fluency of the mechanical kind is becoming cheap. Judgment is becoming the whole job. If anything, the seat gets more interesting: less time conjugating, more time deciding.

There's a related thought I'm still working through. The CISO is fundamentally a political role - in the original sense of politeia, the art of holding many interests in productive tension. The technical work is the easy part. The interesting part is reading power, picking which battles to lose this quarter so you can win the one that matters next year, brokering coalitions across people whose incentives don't naturally align with yours. Some people call that art. I think statecraft is closer. And like statecraft, it doesn't get easier with experience; it gets less surprising, and more enjoyable.

Where the role comes alive

Everything I've said so far could leave you with the impression that the job is taxonomies all the way down - that being a CISO means living permanently inside the paper layer of frameworks, categories and evidence. I spent enough years in heavily regulated financial services to know how strong that gravity is. In those environments everything eventually gets translated into controls, risk ratings and assessment language, and nobody outside the function cares about any of it except as a stamp: the thing that lets the firm make money, or stops it losing money.

But the machine the taxonomies describe is not made of paper. It's made of people trying to build things. Sit in the rooms where the real work happens and the job changes texture completely: a team trying to ship a product, serve a customer, enter a new market, modernise a platform everyone is scared to touch - and still move at pace. Security gets interesting exactly there. Not when it generates more control language, but when it helps a good business move fast safely. That's also where the technical depth I love actually pays off: understanding how the architecture really works, where the exposure really is, what a threat actor would actually do, whether the organisation is genuinely resilient or just very good at producing slide decks. You don't get those answers from a maturity rating. You get them from being close to the build.

And the most rewarding part of the job, twenty years in, isn't the geometry at all. It's people. Helping an engineer understand risk without making them feel stupid - watching the moment the threat model stops being a compliance obligation and starts being genuinely interesting to them. Turning analysts into leaders. Helping a product team build, launch and scale something without leaving the front door wide open, and then watching that product come alive in customers' hands: secure because of how it was built, not despite it. The translation work I've spent this whole essay describing is in service of exactly that. The vocabularies are the grammar. The building is the point.

One move, for now

A whole playbook falls out of this geometry - how to budget inside it, how to hire for it, which battles to concede and when. That deserves its own essay, and it will get one. But if you take a single move from this piece, take this one.

Know which vocabulary you're in before you open your mouth. Half the friction in a CISO's week comes from answering in the wrong language: the board asks an obligations question and you answer in framework terms; the architect asks a product question and you answer in risk-register terms. Before every meeting, before every slide, ask yourself which mood this audience is speaking in - should, can, must, will, or wants - and answer in that grammar, not yours.

If this resonates

If you're a CISO reading this: the next time the job feels contradictory, remember what the contradiction means. It means you are sitting in the one seat the structure cannot do without. The taxonomies built for different audiences cannot be reconciled into one. That is a structural property of the work, and it is precisely what makes the role senior, judgment-driven, and impossible to commoditise. The vendors are not going to absorb it. Neither are the frameworks, nor the audit committee, nor whatever platform gets pitched to you next quarter. Translation - patient, opinionated translation between vocabularies - is the actual job. It always was. And it is a genuinely great one: the rarest vantage point in the building, a craft that compounds for decades, and work that never goes stale. The best of it isn't even the geometry. It's the day a team you've backed ships something into the hands of real customers and it holds, because of how it was built. Nobody puts that part in the job description.

If you are not a CISO but you work near one: this is what we are doing when we seem to be saying contradictory things to different audiences. We aren't being inconsistent. We're translating. The control surface is the same. The language has to be different for each room. And if the person in that seat looks like they're enjoying it - now you know why.