Who should own quantified cyber risk when finance, security, and compliance all use it?

Why This Matters for Security Teams

Quantified cyber risk only helps when it supports a decision, and that means the ownership model has to be explicit. Security can estimate threat likelihood and control effectiveness, finance can test whether the loss model is credible, and compliance can verify that the record meets governance and audit expectations. Without a clear owner, the same score can be interpreted as budget justification, board reporting, or a compliance artefact, which creates confusion and weakens accountability.

The right operating model is usually a risk function that owns the method and the final risk record, with structured input from the other functions. That aligns well with the governance intent of the NIST Cybersecurity Framework 2.0, which treats risk management as an ongoing, enterprise activity rather than a security-only task. Current guidance suggests that quantified cyber risk should be traceable to business impact, not just technical findings.

Practitioners often get this wrong by letting each function keep its own version of the truth, then trying to reconcile three different narratives at reporting time. In practice, many security teams encounter ownership disputes only after a material loss event has already exposed the lack of decision accountability, rather than through intentional governance design.

How It Works in Practice

In practice, the owner should be the team that can be held accountable for the risk register, the model assumptions, and the escalation path. That is often an enterprise risk, GRC, or resilience function, not the security team alone. Security supplies control strength, detection coverage, and threat intelligence. Finance validates exposure, loss magnitude, and scenario realism. Compliance checks that the method, evidence, and retention support regulatory and audit needs.

A workable model usually separates governance from contribution:

• Risk function owns the methodology, thresholds, approvals, and reporting cadence.
• Security owns control evidence, threat scenarios, and remediation status.
• Finance owns valuation assumptions, materiality inputs, and loss bands.
• Compliance owns assurance requirements, recordkeeping, and policy alignment.

That structure is stronger when the scenarios are anchored to real threat patterns, incident history, and asset criticality. For example, the NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams map control coverage, while incident intelligence from CISA cyber threat advisories can improve the realism of loss scenarios and likelihood estimates.

For organisations using AI-assisted risk analysis, the model itself becomes part of the control surface. Human judgment still has to own the final risk call, especially where AI is used to summarize evidence, cluster scenarios, or project loss ranges. The recent Anthropic AI-orchestrated cyber espionage campaign report is a reminder that automation can accelerate both analysis and abuse, so model outputs need validation rather than blind acceptance. These controls tend to break down when risk scoring is embedded in disconnected spreadsheets and no single function owns assumptions, approvals, or challenge.

Common Variations and Edge Cases

Tighter ownership often increases governance overhead, requiring organisations to balance speed against auditability. That tradeoff is especially visible in regulated sectors, where compliance teams may want stronger evidence trails while security wants fast iteration on scenarios and finance wants conservative valuation methods.

There is no universal standard for this yet. Some organisations keep ownership in finance because quantified risk feeds capital allocation. Others keep it in security because the scenarios depend on operational controls and threat intelligence. Best practice is evolving toward a hybrid model where one function owns the record and decision process, while the others are mandatory contributors.

Edge cases matter. If the question is tied to third-party cyber exposure, the risk owner may need procurement and vendor management input as well. If the organisation is evaluating AI-enabled attack paths, the scenario library should reflect adversarial machine learning and agent misuse, which is where the MITRE ATLAS adversarial AI threat matrix becomes useful. Where financial crime, identity fraud, or customer onboarding are in scope, teams may also need to align quantified risk with FATF Recommendations so that loss modelling reflects KYC and AML obligations. The model fails when ownership is assigned to the loudest stakeholder instead of the function that can enforce decisions across all three disciplines.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create compliance risk even when policies exist?
• When does NHI compliance become an operational security issue?