The CFO Says the Ranges Are Too Wide

Wide ranges are an honest reflection of uncertainty, not a modelling failure - and narrowing them by inventing precision would be worse. But the objection deserves a substantive answer rather than a defence of the method.

• Show sensitivity: which assumptions drive the spread? If the ransomware range is dominated by one variable (e.g., days of downtime), present it as a decision about downtime tolerance, not about probability.
• Use the range for its actual purpose: decisions get made on direction and order of magnitude, not on the midpoint. Whether the expected loss is $6M or $11M, the conclusion about a $1.2M control package is the same.
• Tighten over time: commit to refining the estimate as incident data and control telemetry accumulate, and say which data would narrow it.

A CISO who promises a single number to satisfy a CFO is borrowing credibility that will be called in at the first incident that lands outside the forecast.

Appetite becomes usable when it is written as thresholds and consequences, not adjectives. A statement the committee can act on:

• For each top scenario, an acceptable annualised loss exposure and the tolerance for a single-event loss above that level.
• Escalation triggers: any scenario where estimated exposure exceeds the threshold must come to the committee with options - transfer, avoid, reduce, or explicitly accept.
• A stated preference ranking: for this firm, likely availability of operations first (ransomware), then regulatory and contractual exposure (vendor breach), then financial fraud (BEC). That ranking is what makes the $1.2M decision tractable.

Then apply it: if the endpoint and identity investment demonstrably reduces the ransomware and vendor scenarios below the tolerance line, it is justified by the appetite statement rather than by a security preference. If it does not, the committee is choosing to accept risk and should record that choice. The test of an appetite statement is whether it changes a funding decision - if every proposal fits under it, it is decoration.

This is a governance problem disguised as a modelling dispute, and dismissing it will cost the CISO every future data point from operations.

• Separate risk quantification from performance management explicitly, with the committee: the analysis estimates loss exposure for prioritisation and funding; it is not an appraisal input and not attributable to an individual leader's record.
• Demonstrate it in the first use - the $1.2M decision should be presented as an enterprise funding choice, with the COO's operational constraints named as an input to the model, not as the cause of the loss range.
• Give the COO authorship: have his unit validate the downtime and business-interruption assumptions. Numbers a business leader helped build are numbers he will defend, and the estimates get better.

The underlying principle: security risk quantification only works if business units volunteer honest data. One punitive use - even perceived - and the data pipeline is permanently poisoned. The CISO should ask the committee to minute that commitment.