Every strong security leader I know runs on three reflexes: own everything, default to no, and keep the blast radius small. Those reflexes are why we get hired, why we get trusted, and why we get promoted. They are also, almost exactly, the three habits I would have to unlearn to be any good in the chair above mine.
I am a VP of security and DevOps on a track toward the CIO seat, and I spend real time thinking about what that jump actually requires — not the title, the job. The mistake I watch functional leaders make is to assume the CIO role is their current role with a bigger budget and more people. It isn't. It is a change of altitude and a change of scope at the same time. The security VP owns a deep slice of technology and is measured on how well that slice holds. The CIO owns technology end to end — data, delivery, spend, vendors, the platforms the business runs on, the roadmap the company sells against — and is measured on what the business does with all of it.
So this is the agenda I would run, and the instincts I would have to consciously put down to run it. I am writing it from the seat below the one I am describing, on purpose. The view from here is exactly what tells me which of my reflexes travel up and which ones don't.
Own the outcome, not every system
The security instinct is to pull things in. If it touches risk, I want it under my control, my logging, my review. That instinct is correct at my current altitude, where the failure mode is a gap nobody owned. It is wrong at the CIO altitude, where the failure mode is a leader who has centralized so much that the whole organization has to wait for him.
A CIO does not personally control the data warehouse, the ERP, the revenue platform, the field team's tooling, and the AI stack. There are not enough hours, and trying is how you become the bottleneck you were hired to remove. The job is to own the outcome across all of it while federating the control — set the standards, build the paved road, then let capable teams move on it without asking permission for every step.
This is the part of the CIO job I am most prepared for, because platform engineering already taught it to me. When my team built AgentOS, our in-house governed platform for AI agents, the entire point was to stop being the person every request had to route through. Scoped tool authority, a single governed path to the model, an audit trail that records what happened without a human watching the feed — the controls live in the platform, so the answer to "can I use this" is usually yes, safely, without me in the loop. That is the CIO move in miniature. You do not scale by touching everything. You scale by making the safe path the easy path and then getting out of the way.
Default to a conditional yes, not to no
"No" is the safest word a security leader owns. It is also the most expensive word a CIO can say, and those two facts sit right on top of each other.
At my altitude, a no that prevents a bad outcome is a win, and the cost of the no is mostly invisible — it shows up as a project that didn't happen, a tool the team didn't get, a little friction nobody logs. Move up a level and that friction stops being invisible. It becomes the reason a business unit stood up its own shadow stack, the reason a deal cycle ran two weeks long, the reason the best engineer took the offer somewhere less bureaucratic. The CIO carries the cost of no on the same P&L as the cost of yes. The security VP mostly carries only one side of it.
Unlearning default-to-no does not mean becoming a rubber stamp. It means changing the default from "no unless" to "yes with conditions," and doing the work to make the conditions cheap. The answer a good CIO gives is rarely a flat no; it is "yes, on the paved road, with these guardrails, and here is how long that takes." When the guardrails are already built, the conditional yes is nearly free. That is why the platform work and the governance work are the same work — they are what let you say yes without lying about the risk.
Fund the portfolio, not the individual fire
Security budgeting is adversarial and incident-shaped. You argue for a control because a threat justifies it, and the strongest argument is usually the one with the scariest failure attached. I have made that argument many times, and it works. It is also a poor way to run a whole technology estate.
The CIO does not fund threats. The CIO allocates capital across a portfolio — keep-the-lights-on, modernization, growth bets, and the occasional forced march a regulator or a contract requires — and defends that mix against every other claim on the company's money. That is a genuinely different muscle. It asks not "is this risk real" but "is this the best return available for the next dollar of technology spend, across everything we could spend it on." A control worth funding on its own can still lose to a data platform that unlocks three revenue lines, and a mature CIO holds both of those truths at once.
Here is where my current work actually transfers, though. Running FinOps taught me to see the technology estate as a portfolio with a cost curve, not a pile of line items — where the money goes, what return it earns, which commitments are mistuned, and which spend is quietly compounding with no owner. Reporting risk to a board taught me to translate a technical position into a decision the business can vote on. Put those together and you have most of the capital-allocation instinct the CIO seat needs. What I would add is the discipline to argue for the growth bet as hard as I argue for the control — to walk into the room advocating for the thing that makes money, not only the thing that prevents loss.
Treat data as an asset, not only an exposure
A security leader looks at a data store and sees attack surface, retention risk, and regulatory exposure. In the regulated financial services where I work — a fintech whose software reaches more than 1,500 financial institutions — those are not paranoid instincts. GLBA, the examiner, and the third-party risk questionnaire make data a real liability with a real price, and I would not put any of that down. That view is correct. It is just half the picture.
The CIO has to hold the other half at the same time: that same data is the asset the business increasingly runs on, the fuel for the analytics and the AI the company sells against. The security VP's question is "how do we protect this, and how little of it can we keep." The CIO's question includes those and adds "what is this data worth, what could it become, and are we governing it well enough to actually use it, not just well enough to lock it down." Both questions have to be alive in the same head. Governance that only ever subtracts is a tax; governance that makes the data safe enough to build on is an enabler, and the distance between those two postures is most of what separates a CIO who accelerates a company from one who slows it down.
This is the part of the CIO mandate I am best positioned to grow into rather than the part I have mastered, and I want to be honest about that. My concentration sits at the intersection of AI and security, which means I already live where data strategy and data protection collide. Model-risk expectations like SR 11-7, the fair-lending law that binds any model touching credit, the act-or-interpret boundary I use to decide which AI outputs are allowed to act on their own — these are governance disciplines that exist so the data and the models can be used, not shelved. Extending that instinct from "govern the AI" to "govern the whole data strategy" is the shortest bridge I have from where I sit to the seat I am describing.
Report the business the technology enables, not the technology
I report to boards today, and the single most useful thing that experience has taught me is that the board does not want the technology. They want the decision the technology forces, the risk it carries, or the money it makes. A security update that lists controls shipped is a status report; a security update that says "here is the one thing we need you to decide, and here is our recommendation" is a board contribution. That discipline scales straight up into the CIO seat, and it is where a strong functional leader has a real head start.
What changes at the CIO altitude is the surface area. The security VP reports a domain — posture, incidents, compliance, the risk register. The CIO reports the whole relationship between technology and the business: whether the roadmap serves the strategy, whether the spend earns its return, whether the platform can carry the growth the CEO has promised, whether a technology bet paid off or should be cut. That is a broader story, but it is told in the same grammar — decisions and outcomes, not activity. If you have learned to report a security program as a set of business decisions instead of a list of technical accomplishments, you already know the grammar the CIO seat is graded in. You just have to speak it about far more of the map.
What I'd put down first
If I stepped into the seat tomorrow, the reflexes I would work hardest to unlearn are the ones that made me good at the job below it. Concretely:
- Stop pulling systems in; start federating control. Own the outcome across the estate, build the paved road, and measure yourself on how rarely the organization has to wait for you.
- Change the default from no to a conditional yes. Do the platform and governance work that makes the conditions cheap, so "yes, safely" is nearly free.
- Argue for the growth bet as hard as the control. Fund the portfolio for return, not the individual fire for fear, and walk in advocating for the thing that makes money.
- Report decisions and outcomes, about the whole map. Speak the grammar the board already grades you in, just about far more than your own domain.
None of this means the security instincts were wrong. They were right for the altitude that formed them. The CIO job is not the security job scaled up — it is a different job that a security-and-DevOps background prepares you for surprisingly well, as long as you know which of your best habits to set down at the door.
I am writing this from one rung below the seat, which is exactly why I want to hear from the people already in it. If you made this jump — from a functional technology role into owning technology end to end — what was the reflex you had to unlearn first, and what surprised you about what did carry over? Tell me where I have this right, and where the view looks different from the chair I am still reasoning toward.
