When I wrote Technology Business Management: The Four Value Conversations CIOs Must Have with Their Businesses, I was trying to solve a problem of standing. CIOs were funded like a cost center, questioned like a cost center, and consulted like a cost center. They were asked what things cost and almost never asked what things were worth. The book came out of my work with the TBM Council, a CIO-led professional association that developed standards and best practices for managing the cost, consumption, and value of IT.

The insight that ran through all of that work was this: the way out of the cost center trap is not better storytelling about IT. It is better economics. When a CIO can show what technology costs, what the business consumes, and what that consumption produces, the conversation shifts from "why is your budget so large" to "what do we want to buy, and what do we want to stop buying." That shift is what turned CIOs into strategic partners, either by delivering services at excellent value for the money or by delivering digital innovation the business could not get anywhere else.

Rebecca Jacoby, then SVP and CIO at Cisco, put it better than I could when she contributed this to the book:

"At Cisco, we recognized that in order to drive business value and innovation, we had to become a competitive provider of IT services. This meant, among other things, that we had to change the very conversations we were having internally and with our business partners. Our conversations and our vocabulary needed to move beyond technologies, SLAs, and projects, to discussions about the tradeoffs needed to balance cost, quality, and value. Only in doing so could we free up resources for business growth and strategic execution. These tradeoffs are at the core of Technology Business Management."

Substitute a few words and that is the CISO's situation today. Move the vocabulary beyond controls, frameworks, and findings. Get to the tradeoffs. Free up resources for growth.

I think about that book constantly in my current role, because CISOs today are standing almost exactly where CIOs stood then.

Every Value Conversation Needs a Value Basis

A value conversation is an interaction, either inside the security function or with business partners, focused on tradeoffs among cost, consumption, capacity, performance, features, and risk in pursuit of better business outcomes. What makes such a conversation possible is a shared basis for comparison. Without one, you get opinion against opinion, and the loudest or most senior opinion wins.

For CIOs, the basis was usually cost transparency tied to consumption, and from there to revenue and profit. Once you know the true cost of a unit of service and who consumes it, you can talk credibly about efficiency, allocation, and return.

Security has the same raw material to work with. Its costs can be measured just as the costs of any other technology service can be measured. And it has units of consumption that business partners recognize immediately: the number of identities protected against account takeover, the volume of business data protected against ransomware, the revenue defended against fraud. Those units make security's cost and coverage legible to people outside the function.

What has been missing is the other half of the equation. A unit of consumption tells you what security is covering and what that coverage costs. It does not tell you what the coverage is worth. For CIOs, connecting the two was rarely automatic. Some services map cleanly to a business or customer facing function, but plenty of technology spending sits well behind the things the business actually recognizes. What closed that gap was the discipline and standards of TBM: a common taxonomy, consistent cost models, and an agreed way of tracing consumption through to business outcomes. The connection had to be built, and TBM is what made it defensible rather than asserted.

For CISOs, value has to be expressed as a reduction in loss exposure, and until recently the profession had no defensible way to put a number on that reduction.

That is what FAIR provides. The value basis for the CISO is risk optimization, and its unit of measure is money.

I want to be precise about the word "optimization," because it is doing real work here. FAIR-CAM states the objective plainly: organizations want to cost-effectively achieve and maintain an acceptable level of risk. Every part of that sentence matters. "Cost-effectively" acknowledges that resources are finite. "Acceptable level" acknowledges that some risk must be accepted in order to pursue any objective worth pursuing, and that too much risk must be avoided. Which means a decision that drives loss exposure unreasonably low is just as misaligned as one that leaves exposure above appetite. Over-control is a real failure mode, not a virtue, and it is one the business feels immediately in cost, friction, and lost speed.

Risk reduction, by itself, is not a value proposition. Risk optimization is. And once loss exposure is quantified, and once acceptable risk thresholds have been defined and approved by the actual risk owners, which is exactly what FAIR-CRMP calls for, the CISO finally has a basis on which the same four conversations can be held.

The Four Conversations, Reframed

As in the book, the first two conversations optimize what you already run. The second two build the capacity to change.

1. Cost for Performance

For CIOs, this conversation was about delivering the right amount of security, availability, redundancy, and responsiveness at the lowest defensible cost. For CISOs it is about delivering the right amount of risk reduction at the lowest defensible cost.

The sources of inefficiency are analogous to the four I described for IT. There are stacked and overlapping controls where a second or third layer buys very little marginal reduction. There are controls aimed at scenarios that carry little loss exposure to begin with. There are controls that look strong on paper but underperform on one of FAIR-CAM's three effectiveness dimensions of capability, coverage, and reliability, which is usually where the surprises live. And there is work driven purely by compliance obligation that moves no risk factor at all, which may still be necessary but should be named and budgeted as compliance rather than sold as risk management.

Useful measures here pair cost against effect, deliberately: reduction in annualized loss exposure per dollar spent, coverage and reliability rates for the controls carrying the most weight in your top scenarios, and the cost of the control stack supporting each material risk scenario. The point is not to shrink the security budget. The point is to be able to defend it line by line.

2. Business-Aligned Portfolio

The core move in the book was to treat spending on one asset as coming at the expense of another. That logic applies cleanly to security, and it applies to more than the project portfolio. It applies to tools and platforms, to vendors and managed services, to people and skills, and to the services the security function offers the rest of the business.

The alignment question is whether the distribution of security spending resembles the distribution of loss exposure. Very often it does not, and nobody has been able to see it. When you can express aggregate exposure by business unit, by product, by process, or by crown jewel asset, and then set spending against it, the misalignments become obvious and the rationalization conversation becomes possible. Overlapping tooling gets consolidated. Attention moves toward the scenarios that carry the exposure.

This is also the conversation where business ownership of risk becomes real. Security advises, the business owns. A business leader who can see the loss exposure attached to their own product line, alongside what is being spent to manage it, is in a position to make an actual decision rather than to receive a verdict.

3. Investment in Innovation

This conversation runs in two directions for a CISO, and both matter.

The first is governing security's own investments. A new capability needs a business case expressed in expected reduction of loss exposure, and it needs to account for the operating burden it creates. Security tools have a long tail of tuning, integration, and staffing that rarely appears in the acquisition decision, which is the same project TCO problem I described for IT. The run versus change ratio is as revealing in a security budget as it is in an IT budget. If nearly everything is run, the function has no capacity to get better.

The second direction is where the strategic partnership actually gets made. The business is going to adopt AI, enter new markets, acquire companies, and launch digital products regardless of what security thinks. A CISO who can quantify the exposure those moves create, and price the options for managing it, becomes part of the investment decision rather than an obstacle discovered late in it. That is the security equivalent of delivering digital innovation, and it is worth far more than any efficiency gain.

4. Enterprise Agility

Agility for IT meant responding quickly to changing business needs and helping the business respond to market opportunities and threats. For security, agility is mostly about the speed and quality of risk decisions.

This is where the FAIR Cyber Risk Management Program standard (FAIR-CRMP) does more work than practitioners usually expect. Its first component is Agile Governance, and the pairing of those two words is deliberate. Governance is normally cast as the brake. Designed well, it is the accelerator. Clear policies, defined roles, explicit decision authority, active board and executive oversight, and resources and skills aligned to those roles are precisely what allows an organization to make a fast decision that still holds up afterward. When nobody knows who owns a decision or which threshold applies to it, every question becomes an escalation, and escalation is where speed goes to die.

Several other levers are available. Pre-agreed risk thresholds mean that most decisions can be made against a standing rule rather than escalated and relitigated. Reusable scenario libraries, telemetry, and reference data mean an analysis takes hours rather than weeks, which is the difference between informing a decision and arriving after it. Variablizing fixed security cost structures preserves the option to change direction. Governing emerging technology use rather than prohibiting it keeps the practice visible and manageable, which is the same argument I made about shadow IT. And investing in response and resilience, which act on loss magnitude rather than event frequency, gives the business the ability to absorb events it cannot prevent.

The measures that matter are things like the share of risk decisions made against defined thresholds, the time required to answer "how much risk does this create," the proportion of aggregate exposure under continuous monitoring, and the quality of the data feeding all of it.

Where to Start

The CIOs who made this shift did not run all four conversations at once. They picked the one where the pain was sharpest and the data was most available, and they held that conversation until it became routine. Cost for performance was usually first, because efficiency questions are the ones the business is already asking.

I would give CISOs the same advice. Pick the conversation your business is already trying to have with you, and bring a quantified answer to it.

What makes that possible now, and did not a decade ago, is that the underlying standards exist. The FAIR Model gives you loss exposure in financial terms. The FAIR Controls Analytics Model (FAIR-CAM) explains how controls actually affect that exposure, which is what makes the cost-for-performance discussion honest. The FAIR Materiality Assessment Model (FAIR-MAM) gives you the granularity to talk about loss the way a finance organization does. And FAIR-CRMP provides the program scaffolding, from agile governance through the definition and approval of acceptable risk thresholds and the alignment of strategy and budget to them.

None of this requires a large dedicated team or a multi-year transformation. Risk fluency is a learnable skill, not a program. But it does require a decision to stop reporting activity and start discussing tradeoffs.

The CIOs who made that decision stopped being asked what things cost and started being asked what the company should do. The same thing is available to CISOs now.