Why do security and finance teams disagree on cyber risk?

Why This Matters for Security Teams

Security and finance teams usually disagree because they are optimising for different decisions. Security leaders often translate cyber risk into control gaps, exposure, and likelihood of compromise. Finance leaders usually need the same issue framed as earnings impact, cash flow disruption, regulatory exposure, and capital allocation. That mismatch matters because a technically accurate risk statement can still fail to secure funding if it does not connect to business outcomes.

This is where a shared method is more useful than a shared opinion. The NIST Cybersecurity Framework 2.0 helps because it gives both functions a common structure for identifying, protecting, detecting, responding, and recovering, but it does not by itself solve valuation. Practitioners still need to translate cyber events into operational and financial terms that executives can compare with other investment options.

That translation is especially difficult when the organisation has incomplete loss history, uneven asset criticality data, or weak ownership of business process impact. In practice, many security teams encounter finance resistance only after a major incident or budget cycle has already exposed that risk language was never aligned with funding logic.

How It Works in Practice

In practice, the disagreement is usually not about whether an attack is possible. It is about what the impact means, how likely it is, and who is responsible for assigning a value to each outcome. Security teams often start with threat intelligence, control status, and exposure. Finance teams often start with expected loss, return on investment, and the tradeoff between mitigation cost and residual risk. Both views are valid, but they answer different questions.

A more effective approach is to build a risk narrative that links technical scenarios to business disruption. For example, a ransomware event can be mapped to downtime, recovery labour, contract penalties, legal costs, and delayed revenue recognition. A credential theft event can be tied to fraud, account takeover, and response overhead. If the risk involves AI systems or automated decisioning, the analysis should also consider model misuse, prompt injection, and output integrity, especially where an agent can execute actions or access sensitive data. Current guidance suggests that teams should maintain separate treatment for cyber risk, AI risk, and third-party concentration risk rather than blending them into a single vague score.

• Use a common scenario library with agreed assumptions for frequency, impact, and recovery time.
• Assign business owners to validate process disruption, not just technology impact.
• Distinguish inherent risk from residual risk so the effect of controls is visible.
• Document the cost of inaction in the same currency used for capital planning.

For threat-driven prioritisation, the CISA cyber threat advisories help ground discussion in active adversary behaviour, while incident analysis can be strengthened with attack-pattern mapping. These controls tend to break down when organisations have no agreed asset criticality model and finance treats every cyber scenario as a generic insurance problem because the operational consequences have never been quantified.

Common Variations and Edge Cases

Tighter risk quantification often increases analysis overhead, requiring organisations to balance decision quality against time, data availability, and executive patience. That tradeoff is real, and there is no universal standard for perfect cyber valuation.

Some organisations lean on qualitative heat maps because they are easy to maintain. Others adopt quantitative models such as expected loss distributions or scenario-based analysis. Current guidance suggests that neither approach is wrong if it is used consistently and understood by decision-makers. The problem starts when a colourful score is mistaken for a financial model, or when a financial model is presented without explaining the operational assumptions behind it.

The gap is wider in regulated industries, where finance may care about disclosure, auditability, and board reporting, while security focuses on technical remediation. It also widens in environments with AI systems, autonomous workflows, or supply chain concentration, because the control question becomes harder to separate from dependency risk. Where adversarial AI or automated agent behaviour is relevant, the MITRE ATLAS adversarial AI threat matrix is useful for structuring attack paths, and the Anthropic report on AI-orchestrated cyber espionage shows why executive teams now need to treat AI-enabled attack scale as a planning factor, not a theoretical concern.

Best practice is evolving, but the practical rule is stable: if finance cannot see how the cyber issue affects revenue, cost, resilience, or regulatory consequence, the risk argument will stall even when the technical analysis is sound.

Related resources from NHI Mgmt Group

• How should security teams use GRC to reduce identity-related cyber risk?
• How should security teams manage third-party cyber risk in practice?
• What do security teams get wrong about cyber insurance and identity risk?
• How should security teams include identities in cyber risk assessments?