IAM Business Case and ROI Guide: How to Cost, Quantify and Win Identity Funding

Identity programmes are hard to fund because their costs land in IT while their benefits are spread across HR, audit, the service desk, the business and the risk register. A business case that only counts licences against help desk savings will usually look marginal, and one that only talks about risk will look like fear. This guide sets out how to build an IAM business case that survives a finance review: how to choose the options, build a full cost model, quantify efficiency and risk benefits with defensible data, present return on investment honestly, and keep the case alive across several budget cycles. It is written for identity leads, CISOs and the programme managers who have to write the case, and for finance partners who have to judge it.

Key takeaways

• No single ROI formula exists: the IDPro Body of Knowledge article on the topic says so directly; combine quantitative savings, quantified risk and qualitative strategic value rather than forcing everything into one number.
• Measure your own baseline first: ticket volumes, provisioning hours, audit preparation effort and orphaned accounts from your own systems beat any industry average in front of a finance team.
• Use a multi-year horizon: IGA benefits grow as applications are onboarded, so a one-year view is almost always negative; three to five years is the honest frame.
• Quantify risk in money, with ranges: FAIR-style estimates of loss frequency and magnitude, tied to the risk register, are more credible than headline breach costs.
• Name who benefits: when the funder and the beneficiary differ, show each stakeholder their line, and agree in advance how benefits will be measured after go-live.

Why IAM business cases fail

André Koot's IDPro Body of Knowledge article "The Business Case for IAM" describes the typical deadlock: IAM is treated as an expense to control, the business wants proof of benefit before investing, and IAM stays in a catch-up cycle. Several structural problems sit behind that.

• Funder and beneficiary differ: IT pays for an IGA platform; HR, managers, auditors and the service desk save the time. Without a company-wide view, the article notes, an IGA case can look negative.
• The prevention paradox: a successful identity programme produces breaches that do not happen. The benefit is real but invisible in next year's accounts.
• Hidden labour: manual access requests, approvals, account creation and access reviews are rarely recorded as costs, so automating them looks like it saves nothing.
• Short horizons: licences and integration costs are front-loaded, while benefits grow as each application is connected.
• Sunk costs: past spend on a failing platform is used to argue against replacing it. Past investment should not drive the next decision.

The article's advice is to show return from several angles, because different organisations respond to different arguments: some to money, some to strategy, some to regulation. For programme design itself, see the Identity Security Programme Guide.

Know your trigger and your domain

A business case is easier to write when it starts from the event that created the window for funding. The IDPro article groups triggers into operations (efficiency and data quality in HR and IT), architecture (MFA, zero trust, technical debt) and the C-suite (audit findings, regulatory directives, incidents). Each IAM domain then leans on a different kind of argument.

Build the options, not just the proposal

Finance teams expect a choice. Present at least three options with the same structure so they can be compared.

1. Do nothing (baseline): current costs continue, risks stay on the register, and any known audit findings remain open. This is not free: state its cost.
2. Minimum viable: fix the most pressing finding (for example MFA on all remote access, or automated leavers for the top 20 applications).
3. Recommended: the programme scope you believe is right, phased.
4. Accelerated (optional): the same scope delivered faster with more spend, if timing matters (a regulatory deadline, an insurance renewal).

Phase the recommended option so each phase delivers a measurable benefit and can stand on its own if later funding is cut. An identity roadmap structured this way also makes the case easier to renew each year. See the Identity Programme Roadmap Template.

Cost model: total cost of ownership

Under-costing is the fastest way to lose credibility in year two. Include every line below for each option, across the full horizon.

Quantifying benefits

Efficiency benefits

These are the most defensible because they come from your own data. For each driver, record the baseline, the source and the formula, and agree them with the owning team before the case goes in.

Use the cost per ticket your service desk already reports internally rather than a published industry figure; finance will trust its own number.

Risk benefits

Risk reduction should be expressed as a change in expected loss, with a range. A FAIR-style approach (Factor Analysis of Information Risk, published by The Open Group as the Open FAIR standards O-RT and O-RA) estimates how often a loss event happens and how large it is, then compares the estimate before and after the control.

• Pick scenarios from the risk register: for example "ransomware via compromised remote access account" or "data theft by a leaver with retained SaaS access". Tie each to an existing register entry so the risk owner recognises it. NIST IR 8286 Rev. 1 describes how cybersecurity risk registers feed enterprise risk management.
• Estimate frequency and magnitude as ranges: minimum, most likely and maximum, from your incident history, insurer data and expert judgement. Say which is which.
• Show the change: phishing-resistant MFA lowers the likelihood of credential-based initial access; PAM lowers the magnitude by limiting what a compromised account can reach.
• Add regulatory exposure carefully: the IDPro article suggests estimating penalty exposure as chance of discovery multiplied by maximum fine. Use the realistic fine range, not the statutory maximum, and say so.

Industry figures are context, not the case. IBM's Cost of a Data Breach report page (checked October 2026) gives a global average breach cost of USD 4.99 million, and Verizon's 2026 Data Breach Investigations Report says 48% of breaches involved ransomware and that exploited software vulnerabilities (31%) have overtaken stolen passwords as the top way in. Use such figures to show the scenario is plausible, then quantify with your own numbers. The Change Healthcare intrusion, which began with a remote access login that had no multi-factor check and led to a USD 22 million ransom payment, shows the scale of a single identity control gap. See the Change Healthcare breach analysis.

Strategic and enabling benefits

Some benefits are real but hard to price: faster integration of acquisitions, readiness for zero trust, the ability to govern AI agents and other non-human identities, meeting customer security questionnaires, and lower cyber insurance friction. List them, with the decision or deadline they support, and do not invent numbers for them. See the Identity Controls for Cyber Insurance Questionnaires Guide.

Presenting the return

Present three figures and the assumptions behind them.

• Simple ROI: net return divided by investment, as a percentage. The IDPro article's example: invest 1 million, return 1.1 million, ROI 10%.
• Payback period: the year in which cumulative benefits exceed cumulative costs.
• Net present value: discounted with your organisation's standard rate, which finance will supply.

A hypothetical example, to show the shape rather than typical values: a programme costing 900,000 over three years that removes 6,000 reset tickets a year, automates 70% of 1,200 joiners, halves access review effort and reclaims 300 SaaS licences may break even in year three on efficiency alone; the quantified risk reduction is then the margin. Always show a sensitivity table: what happens if adoption is 50% slower, or integration costs 30% more. A case that still works under pessimistic assumptions is persuasive; one that only works under optimistic ones will be found out.

Stakeholders and the benefits register

Map every benefit to the person who will see it and the measure that will prove it. This turns the business case into a contract.

Implementation: writing and defending the case

1. Collect the baseline (4 to 6 weeks): service desk data, joiner and leaver timings, review effort, audit findings, licence data, incident history.
2. Agree assumptions with owners: each team signs off its own baseline and the expected improvement.
3. Build the options and cost model across a three to five year horizon.
4. Quantify risk scenarios with the risk team, using ranges and register entries.
5. Test the case informally with a finance partner before formal submission.
6. Define benefits tracking: who measures each benefit, how, and when it is reported.
7. Revisit annually: programmes span budget cycles; report realised benefits against the case and refresh it. If a phase is cut, show what risk remains.

Decision guidance: small versus large organisations

Small and mid-sized organisations usually do not need a full FAIR analysis. A one-page case with the baseline, three options, a cost model, and the insurance or customer requirement that is driving the work is often enough. Lean on the requirements that are already non-negotiable, such as MFA demanded by an insurer. Large organisations should expect a formal investment committee: use quantified risk tied to the enterprise risk register, a benefits register with named owners, and a phased plan where each phase is approved separately. In regulated sectors, the IDPro article notes that better access assurance can also be framed in terms of operational risk and capital requirements, which is a language banking and insurance boards already use.

Measuring realised benefits

A case that is never checked will not be believed next time. Track these after go-live and report them to the sponsor quarterly.

• Reset and access tickets: volume per 1,000 users against baseline.
• Joiner time to productive access: median days from start date to full access.
• Leaver deprovisioning time: median and worst case, for connected applications.
• Applications onboarded: connected applications as a share of the in-scope catalogue.
• Audit findings: identity-related findings open and closed.
• Coverage of key controls: phishing-resistant MFA and PAM coverage for privileged users.

For a broader metrics framework, see the Security Metrics and KPIs Programme Guide.

Framework mapping

Common failure patterns

• Vendor ROI figures in the case: a vendor's study is the vendor's number; finance will discount it and the rest of the case with it.
• Counting benefits twice: the same hours saved claimed by both the service desk and IT operations.
• Ignoring integration effort: costing licences and implementation but not the per-application work to connect the long tail.
• All risk, no numbers: breach headlines without a scenario, a frequency or a range.
• No benefits owner: the case is approved, nobody measures the outcome, and the next phase cannot be justified.
• One-year horizon: making a multi-year programme look like a loss.

Practitioner checklist

• State the trigger and the decision the case supports in the first paragraph.
• Collect a 12-month baseline from your own service desk, HR, audit and licence data.
• Present at least three options, including the cost of doing nothing.
• Build a full TCO including per-application integration, run cost and change management.
• Quantify two or three risk scenarios from the risk register as ranges.
• Show ROI, payback and NPV over three to five years, with a sensitivity table.
• Map each benefit to a stakeholder, a measure and an owner.
• Agree how and when realised benefits will be reported.
• Refresh the case each budget cycle with realised results.

Standards and references

• IDPro Body of Knowledge: The Business Case for IAM
• NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• FAIR Institute: What is FAIR
• IBM: Cost of a Data Breach Report
• Verizon: Data Breach Investigations Report

Related NHI Mgmt Group resources: Identity Security Programme Guide · Identity Programme Roadmap Template · Identity Team Operating Model and Workforce Planning Guide · IGA Buyer's Guide · Security Metrics and KPIs Programme Guide