The Audit Chair Asked What the Identity Program Returned: Turning IAM Metrics Into Risk and ROI Numbers That Hold Up

The views expressed are my own and do not represent those of my employer.

Picture a CISO who has just finished a clean quarterly update. Orphaned accounts are down. Access review completion hit its target. Ticket volume is trending the right direction. Then the audit committee chair looks up from the pre read and asks a simple question: "We funded this identity program for a year. What did it return?"

The CISO starts reading the dashboard back. The chair listens politely, then says, "Those are things your team did. I am asking what changed for the company."

That moment is why I am writing this post. In March I published two posts on IAM metrics. They were useful, and they were also incomplete in ways that would have left that CISO exactly where they ended up: holding good activity numbers and no answer. This is version two. It converts identity results into risk reduction and return numbers that a CFO can audit and an audit chair can repeat.

What I Got Wrong in March and What Moved Since

If you have not read them, my March 28 post, IAM Metrics That Actually Matter, and my March 30 follow up, IAM Metrics in Practice, cover the operational foundation. I will not repeat them here. I will tell you where they fell short.

They stopped at indicators. Everything lived at the operational and risk indicator layer. Nothing was converted to dollars or expected loss, which is the only language a finance chair uses to compare your program against every other claim on capital.

Illustrative figures read like results. Several example numbers looked like real outcomes. They were illustrations, and I should have labeled them that way. In this post, every invented number sits inside a section marked hypothetical, and none of it describes any real organization.

The composites were not auditable. The "Identity Attack Surface Score" and the "Program ROI Indicator" were vague. A CFO cannot tie out a score whose inputs and weights are not written down. I fix that below.

Some statistics went stale. The human element figure I used has been superseded, and the help desk cost figures were dated and secondhand. I replaced them, and I tell you below how to replace the rest with your own data.

I skipped non human identities. Service accounts, API keys and AI agents were missing entirely. That is a real gap now.

Here is what has moved since spring, with sources.

Verizon 2026 DBIR. The human element was present in 62 percent of breaches, up slightly from 60 percent the year before. The bigger headline: exploitation of vulnerabilities is now the most common initial access vector at 31 percent, and abuse of user credentials dropped to 13 percent. Do not read that as identity risk shrinking. One analysis of the report notes that credential abuse was 22 percent in the 2025 DBIR and sits at 13 percent now, a change the DBIR links largely to pretexting being tracked as its own vector. Part of that drop is classification. Tell your board the attack path mix changed, not that identity matters less.

IBM Cost of a Data Breach. IBM's 2025 report found the global average cost fell to $4.44 million, down 9 percent from $4.88 million. IBM has since published its 2026 edition, which reports a global average of $4.99 million. Industry and region vary widely, so use these as context for your own loss scenarios, not as your loss number. I also saw a figure for credential initiated breaches that I could not trace to a primary source, so I am leaving it out.

NACD and ISA, April 2026. The fifth edition of the Director's Handbook on Cyber Risk Oversight rests on six oversight principles and fifteen boardroom tools. Its board level metrics tool puts the burden on management to translate technical cybersecurity data into business relevant terms. That is a direct instruction to CISOs. Raw counts do not meet it.

MFA is not one thing. Microsoft's research found MFA reduces the risk of compromise by 99.22 percent across the population and 98.56 percent when credentials had leaked. The same paper shows the spread by attack type: MFA prevented 100 percent of automated attacks, 96 percent of bulk phishing and 76 percent of targeted attacks. Microsoft's own guidance says traditional methods such as SMS codes, email one time passcodes and push notifications are becoming less effective against today's attackers. So "MFA deployed" is a weak claim. "Phishing resistant MFA enforced on the paths that matter" is the claim worth reporting.

Three Layers, Three Audiences

The fix for the "what did it return" problem is not more metrics. It is sorting the metrics you already have by who needs them and who must vouch for them.

Layer 1 is operational. Orphaned accounts, access review completion rates, ticket counts, provisioning queue times. These live in team dashboards and weekly operations reviews. They are how your team runs the program. They do not go to the board, and they are not ROI.

Layer 2 is senior management. This is your CFO, CIO, general counsel and CHRO. The metrics here are the ones that convert activity to money: help desk cost avoided, provisioning time to productivity, audit findings and remediation cost, and license reclamation from cleaning up dormant accounts. Each one needs an owner outside security who validates it. Finance validates the dollar assumptions. IT operations validates ticket volumes. HR validates hire and separation data. Internal audit validates findings.

A dollar figure that the owning function has not signed is an opinion, not a metric.

That validation step is what separates a number that survives a challenge from one that collapses the first time the CFO asks where it came from. It also builds allies, which I come back to near the end.

Six Numbers for the Board and Nothing Else

Layer 3 is the board and audit committee. I limit it to six metrics. More than that and the one red number gets buried.

(a) Identity driven expected annual loss, before and after, as a range. Use the standard formula: annualized loss expectancy equals single loss expectancy times annual rate of occurrence. State the scenario in plain words (for example, a compromised privileged credential used to reach core financial systems), state your assumptions, and show a range rather than a point. This is the number that answers the translation duty in the NACD toolkit.

(b) Privileged access coverage, and the split between standing and just in time. Report what share of privileged accounts sit under your controls, and what share of privileged access is permanent versus granted only when needed. Standing privilege is the exposure. Just in time is the reduction.

(c) Phishing resistant MFA enforced, not just deployed, on privileged, remote and cloud console paths. Given the Microsoft findings above, count a path only when the policy blocks weaker methods. A user who is enrolled in a security key but can still fall back to a texted code is not protected against a determined attacker.

(d) Time to revoke access on separation, and percent within SLA. Auditors test this by sampling. Practitioner guides on SOX testing describe a sample of leavers with termination dates and access removal dates side by side. Report the same comparison before they do.

(e) Identity related audit findings by severity and open remediation age. Tie this to your SOX ITGC user access controls. One practitioner source makes a point worth remembering: Section 404 does not mention identity at all, but the ITGC framework auditors walk through places identity controls at the center, covering provisioning, deprovisioning, periodic review, privileged access and segregation of duties. For a public company audit committee, this is the metric that connects identity to the financial statements.

(f) Non human identity ownership coverage. What percent of service accounts, API keys and AI agents have a named human owner and a review date? I wrote about why this matters in IAM for AI Agents. A machine identity with no owner cannot be reviewed, revoked or explained to an auditor. This number is simple, auditable and uncomfortable, which is why it belongs on the page.

What happens to the composite score. I am retiring the Identity Attack Surface Score at the board level. A single blended number hides the one metric that is red, and nobody on an audit committee can reproduce it. If your team wants a composite for internal tracking, publish the inputs, the weights and the formula in the appendix, and let finance or internal audit recompute it. If they cannot, do not use it.

The ROI Math, With the Arithmetic Showing

Here is the version of ROI I now use. It borrows from the return on security investment approach:

ROI equals (expected loss reduction, plus hard cost savings, plus soft benefits at a discount, minus program cost) divided by program cost. Payback in months equals program cost divided by (annual benefit divided by 12).

Hard cost savings are things finance can find in a ledger. Soft benefits, like productivity, get discounted because nobody writes a check for them. Expected loss reduction is the softest of all, because it is a probability times a cost, and I count it as an estimate.

HYPOTHETICAL worked example. Every input below is invented for illustration. It does not describe any real organization.

Start with an annual program cost of $1,500,000.

Help desk tickets. Password and access tickets run 5,000 per month, or 60,000 per year. A 60 percent cut avoids 36,000 tickets per year. At $25 per ticket, a conservative fully loaded figure, that is $900,000. At $70 per ticket, a figure often quoted for password resets, it is $2,520,000. I have not tied that $70 to a primary source, so replace it with your own help desk's fully loaded number, validated by IT operations and finance.

Audit remediation avoided. 1,200 hours at $85 per hour is $102,000.

Dormant license reclamation. 600 licenses at $240 per license is $144,000.

Provisioning productivity. 800 hires times 16 hours saved times $55 per hour is $704,000 gross. Because this is a soft benefit, count only 50 percent in the expected case: $352,000.

Expected loss reduction. Use a single loss expectancy of $4.67 million, an invented figure in the neighborhood of published breach cost averages, for one stated scenario. Annual probability falls from 9 percent to 4 percent. Expected annual loss drops from about $420,000 to about $187,000, a reduction of about $233,500.

Conservative case. Count tickets at $25, audit remediation and license reclamation only. Benefit is $900,000 plus $102,000 plus $144,000, or $1,146,000. ROI is ($1,146,000 minus $1,500,000) divided by $1,500,000, about negative 24 percent in year one.

Expected case. Add provisioning at 50 percent ($352,000) and the expected loss reduction ($233,500). Benefit is $1,731,500. ROI is about positive 15 percent. Payback is about 10 months, since $1,731,500 divided by 12 is roughly $144,300 per month.

High case. Tickets at $70, full gross provisioning productivity of $704,000, plus audit, licenses and expected loss reduction. Benefit is $3,703,500. ROI is about 147 percent.

The conservative case can be negative in year one, and saying so out loud is what makes your expected case believable.

Read the Result Like an Auditor Would

Three honest observations come out of that example, and you should say all three to your audience before someone else does.

Most early dollar value is operational efficiency. In the expected case, tickets, audit hours and licenses make up most of the benefit. The security story, the loss reduction, is the smaller number. That surprises people who assume a security program should justify itself on risk alone.

The probabilistic number is soft. A drop from 9 percent to 4 percent is a judgment, not a measurement. Label it an estimate and show a range. In the hypothetical, holding the probability change at five points and varying the single loss between $3 million and $6 million gives a reduction of $150,000 to $300,000. That range is more honest than one figure to the nearest thousand.

Year one can be negative. Benefits ramp. A 60 percent ticket reduction does not arrive on day one, and build costs are often front loaded. Show a multiyear view with the ramp stated. An audit committee trusts a CISO who shows a negative conservative case and explains the path to positive far more than one who shows only the best case.

Never present precision you do not have. If your inputs are rough, your output should look rough.

One Page, Three Minutes, Every Quarter

The one page. The board page carries the six metrics, each with a current value, a trend, a target and one line of plain language. The expected loss range sits at the top with its scenario and assumptions. NACD's example board reporting tool suggests a two page executive memo plus dashboard as a standing agenda item at every board meeting, so your page is the core of that memo.

The three minute talk track. Minute one: the expected loss range and what moved it, in a sentence or two. Minute two: the six metrics, with attention on the one that is red and why. Minute three: the decision or ask. Then stop talking and let them question you.

What to leave off the slide. Ticket counts, tool names, raw orphaned account totals, any composite score, any benefit figure the owning function has not validated, and decimals you cannot defend. Those belong in the layer 1 and layer 2 material.

The quarterly cadence. NACD's Principle 5 guidance calls for structured, standardized cyber risk reports at least quarterly, plus ad hoc updates around material incidents. Build a repeatable cycle. Three weeks before the meeting, refresh the data. Two weeks before, get sign off: finance on dollars, internal audit on findings, IT operations on tickets and revocation times. One week before, pre brief the CFO and the audit chair so nothing in the room is a surprise.

The disclosure angle. For a public company, SEC rules require annual disclosure of the board's oversight of cybersecurity risk and management's role in assessing and managing it. The rule requires a description of the processes by which the board or committee is informed about such risks. A tight quarterly cadence gives your general counsel something real to describe. The rule does not prescribe specific metrics or safeguards, and separate timelines apply to material incidents, so work with counsel on what goes into any filing.

Getting Organizational Support

None of this works if the CFO has never seen your assumptions, so start with relationships. I wrote about the broader skill in Winning the Room, and it applies directly here.

Find one finance partner first. Pick someone in FP&A or controllership and ask them to challenge your cost per ticket and your loss scenario. Their fingerprints on the model are worth more than any slide.

Make internal audit a collaborator, not a surprise. Share your definitions for findings by severity and open remediation age. Auditors will not let you grade your own work, and you do not want them to.

Give IT operations and HR credit. The help desk lead owns the ticket data. HR owns separation and hire timing. If their names are on the numbers, they defend them with you.

Agree on the ask in advance. For each owner, ask one question: "Will you put your name on this number?" If the answer is no, you learned something before the board did.

Key Points

• Operational metrics stay in team dashboards. Dollars and risk go to senior management and the board, validated by the function that owns each input.
• Give the board six identity metrics only, led by expected annual loss as a range with stated scenarios.
• Report phishing resistant MFA as enforced on privileged, remote and cloud console paths, not as deployed.
• Include non human identity ownership coverage: named owner and review date for service accounts, API keys and AI agents.
• Use a transparent ROI formula, label invented inputs as hypothetical, and show conservative, expected and high cases.
• Expect early value from efficiency, treat loss reduction as an estimate, and show a multiyear view.

Pro Tips

Replace every borrowed number with your own. Published averages are useful for context. Your help desk cost, your hire volume and your loss scenario will be the ones a CFO accepts.

Show the conservative case first. Opening with the number that is least flattering builds credibility for everything after it.

Write the scenario in one sentence. If the audit chair cannot repeat the loss scenario back to you, it is too complicated for the board page.

Keep a methods appendix. Put formulas, inputs, owners and validation dates in one place. When someone challenges a number, you hand them the page instead of improvising.

Pitfalls to Avoid

Do not present the expected loss reduction as the headline proof of return. It is the softest number in the set, and leading with it invites the hardest question.

Do not show a composite score you cannot decompose on the spot. If the formula and weights are not on the page, retire it.

Do not claim a statistic you have not verified at its source, and do not leave an illustration unlabeled. One unmarked invented number can undermine every real one.

Do not count a control as protection because it is deployed. Count it when it is enforced and the weaker fallback is blocked.

Do not skip machine identities because they feel like an engineering problem. If nobody owns the service account, the finding lands on you.

Final Thought

The audit chair in that opening scene was not being difficult, she was asking the question every investment has to answer, and the CISOs who earn lasting trust are the ones who answer it with honest ranges, validated inputs and the willingness to say the number is negative in year one.

If you have built an IAM metrics model, or you are about to, I want to hear how it went when you put it in front of finance or the audit committee. What held up, what got challenged, and what would you change? Leave a comment below. I read every one.