By NHI Mgmt Group Editorial TeamDomain: AnnouncementsSource: ExpelPublished February 6, 2026

TL;DR: Security teams often report maturity and operational metrics that finance leaders cannot use to make investment decisions, according to Expel’s webinar and survey of 300 security and finance leaders. The real gap is translation: cybersecurity ROI has to be framed as risk reduction, business enablement, and balance-sheet impact, not technical progress alone.


At a glance

What this is: This is an analysis of why security-finance communication breaks down when teams rely on maturity scores instead of decision-ready cybersecurity ROI metrics.

Why it matters: It matters because IAM, PAM, NHI, and broader security programmes are easier to fund and govern when leaders can tie controls to risk, business outcomes, and accountable decisions.

By the numbers:

👉 Read Expel's analysis of cybersecurity ROI and the CISO-CFO communication gap


Context

Cybersecurity ROI breaks down when security teams present internal maturity scores to leaders who need investment decisions, not programme status. In this case, the core issue is not a lack of reporting, but a mismatch between the language of control operations and the language of finance.

That gap matters across IAM, PAM, NHI, and broader security governance because the controls that reduce risk still have to compete for budget against business priorities. When the audience is finance, the question becomes what risk is being reduced, by how much, and in what business context, rather than whether the programme has moved from one maturity stage to another.

The article’s starting position is typical of many enterprise security programmes: strong internal metrics, weak translation into business terms. That makes it a familiar governance problem, not an outlier.


Key questions

Q: How should security teams measure cybersecurity ROI in a way boards will trust?

A: Use outcome-based measures that connect security controls to reduced loss. The most defensible metrics are containment time, downtime avoided, recovery cost, and expected annual loss reduction. Activity counts are still useful operationally, but they should not be the basis for investment decisions because they do not show whether the organisation is actually safer.

Q: Why do maturity scores often fail to persuade CFOs?

A: Maturity scores describe programme progress, but CFOs need to know what risk is being reduced and what business outcome is being protected. A score can indicate that controls are becoming more disciplined, yet still leave unanswered whether the investment changes loss probability, compliance exposure, or operational resilience. That is why finance often sees maturity as internal housekeeping rather than decision evidence.

Q: How should IAM teams prove business value to executives?

A: Focus on measurable outcomes such as reduced standing privilege, fewer audit exceptions, faster application onboarding, and lower manual review effort. Executives respond to business performance, so identity teams need metrics that connect control improvements to risk reduction, delivery speed, and operational efficiency rather than tool adoption alone.

Q: What should organisations do when security and finance disagree on priorities?

A: Use a shared risk language and test it in planning sessions, not just during budget season. Put finance leaders into incident or tabletop exercises so they see how access, containment, and recovery decisions affect cost and timing. Once they experience the trade-offs, security priorities are easier to justify as business decisions rather than technical preferences.


Technical breakdown

Why maturity scores fail as cybersecurity ROI evidence

Maturity scores are useful for internal programme management because they show whether security operations are becoming more repeatable, measurable, and governed. The problem is that maturity is a proxy for capability, not a direct measure of financial exposure reduced. Finance leaders do not fund controls because a framework moved from ad hoc to managed. They fund them because a control changes downside risk, preserves revenue, or reduces the likelihood of regulatory loss. In IAM and NHI programmes, that distinction is especially important because access controls often work through avoided loss rather than visible gain.

Practical implication: translate maturity reporting into risk and business impact before it reaches the CFO.

How finance evaluates risk versus how security reports it

Finance teams are trained to compare costs, coverage, and downside exposure across the whole business. Security teams often report control activity, incidents blocked, or vulnerability counts, which describe motion but not decision value. That is why the same data can sound impressive to engineers and meaningless to budget owners. For IAM and PAM, the better framing is to show what business risk is reduced by privileged access controls, stronger authentication, or better lifecycle governance, then express that reduction in financial terms where possible.

Practical implication: map each security metric to a business risk statement and a funding decision.

Cybersecurity ROI needs a translation layer, not a new dashboard

A translation layer converts operational metrics into language that supports executive decision-making. That can mean linking IAM or NHI controls to product launches, regulatory exposure, incident containment, or customer trust outcomes. It does not replace telemetry, because control owners still need response times, coverage, and exception rates. But externally reported metrics should answer what changed in business terms, not just what changed in tool output. Without that translation, security stays trapped in a technical reporting loop while finance remains unconvinced of the investment case.

Practical implication: build a dual-layer reporting model with operational metrics underneath and business risk outcomes above.


NHI Mgmt Group analysis

Maturity reporting is a governance signal, not an investment case. Security programmes often confuse internal progress tracking with external decision support. A maturity score can show that a control framework is becoming more consistent, but it does not explain what financial exposure is being reduced or what business initiative is being enabled. That is why CFOs can dismiss technically accurate reporting as irrelevant. Practitioners should treat maturity as an internal control health indicator, not as proof of value.

Cybersecurity ROI is a translation problem, not a measurement problem. Most organisations already measure enough data to justify action, but they rarely package that data in the way finance uses to allocate capital. In identity-heavy programmes, the better question is whether a control reduces loss likelihood, constrains blast radius, or preserves delivery speed under risk. The discipline now is to convert control telemetry into decision language that stands up in budget planning.

Identity programmes have to prove business enablement as well as risk reduction. IAM, PAM, and NHI governance are often easiest to defend when they are tied to shipping applications, passing audits, or reducing incident cost. That means security leaders should stop presenting identity work as a technical hygiene task and start presenting it as a control that protects revenue-bearing processes. The practitioner conclusion is clear: if identity investment cannot be connected to a business outcome, it will always be vulnerable in budget conversations.

Speaking finance’s language is now part of security governance maturity. The article’s core insight is that communication skill has become a control plane issue. If directors and CFOs cannot understand what a security control changes in business terms, then the organisation cannot reliably prioritise risk. Security teams should not expect finance to learn the framework vocabulary; they should present the consequences in terms finance already uses to make decisions.

From our research:

  • 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
  • For a broader control view: Ultimate Guide to NHIs , Key Challenges and Risks explains why visibility gaps and over-privilege keep undermining governance.

What this signals

Cybersecurity reporting is moving toward decision support, not control description. Security leaders who cannot express impact in financial terms will keep losing budget influence, even when their controls are technically sound. That shift matters for identity programmes because IAM and NHI work often delivers value indirectly, through prevented loss and preserved delivery speed, so the translation layer has become part of the programme architecture.

Identity leaders should treat executive communication as a control dependency. If the board or CFO cannot understand why access governance changes business risk, then the organisation will underinvest in the controls that quietly prevent incidents. For practitioners, the practical move is to pair operational evidence with executive risk narratives and, where relevant, align reporting to standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and Ultimate Guide to NHIs.


For practitioners

  • Recast maturity metrics as financial risk statements Convert internal security scores into statements about expected loss reduction, regulatory exposure, or business continuity impact so finance can compare them with other investments.
  • Tie identity controls to business initiatives Link IAM, PAM, and NHI controls directly to product launches, customer-facing applications, or regulated workflows so budget owners see the operational dependency.
  • Build a two-layer reporting model Keep operational metrics for the security team, but add an executive layer that explains what those metrics mean for cost, coverage, and downside risk.
  • Bring finance into incident exercises Use tabletop exercises to show how security decisions affect financial outcomes, then capture the decisions, trade-offs, and response timing finance leaders need to understand.

Key takeaways

  • Security teams lose executive traction when they report maturity instead of financial impact.
  • The measurable gap is not a lack of telemetry, but a lack of translation into decision language finance can use.
  • IAM and NHI programmes are easier to fund when they are tied to business outcomes, not control housekeeping.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.GV-1Governance and business context are central to the article's reporting gap.
NIST SP 800-53 Rev 5CA-7Continuous monitoring supports the operational metrics discussed in the article.
CIS Controls v8CIS-4 , Secure Configuration of Enterprise Assets and SoftwareThe article contrasts operational control data with business-impact reporting.
NIST AI RMFGOVERNThe article is about governance, accountability, and decision alignment.

Establish governance that defines who translates security evidence into executive risk language.


Key terms

  • Cybersecurity ROI: The return an organisation gets from security spending, measured by reduced loss, faster recovery, or lower operational disruption. In practice, it should be judged by outcomes, not by how many tools were bought or how many tasks were completed.
  • Security maturity assessment: A security maturity assessment measures how well a programme has implemented policies, controls, and governance processes against a defined model. In identity security, its value depends on whether it is tied to evidence from access, lifecycle, and privilege controls rather than relying on questionnaire answers alone.
  • Translation Layer: A translation layer is the intermediate representation a system uses to convert one format into another. In agentic design workflows, it can sit between intent and shipped code, creating opportunities for drift, semantic loss, or layout errors that would not exist if the agent wrote the final artifact directly.
  • Control telemetry: Control telemetry is the operational data produced by security tools and processes, such as alerts, response times, coverage, and exception rates. It is essential for running a programme, but it must be interpreted before it can support board-level investment decisions.

What's in the full article

Expel's full webinar and research write-up covers the operational detail this post intentionally leaves for the source:

  • The survey instrument and response breakdown from 300 security and finance leaders, useful if you need to validate the sample behind the findings.
  • The discussion format and speaker perspective from the Expel and non-Expel panel, which provides more nuance than the summary can capture.
  • The specific phrasing security teams can use when translating controls into CFO-ready risk and ROI language.
  • The next installment in the series, which expands on why strong security is often judged by business impact rather than technical maturity.

👉 The full Expel piece includes the webinar context, panel commentary, and the survey detail behind the metrics.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management in a way that supports real-world programme decisions. It is a practical fit for security and identity practitioners who need to connect controls to broader governance outcomes.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org