AI Risk Management Training for Executives: Put a Number on It

Ask a security leadership team to rank "prompt injection in the corporate AI assistant" against "ransomware on the file servers" for next year's budget, and most will answer with a color. Amber, probably. Then the CFO asks how much amber costs, and the conversation stalls.

That stall is the gap that AI risk management training for security executives should close. Most courses spend the day on frameworks (NIST AI RMF, ISO/IEC 42001, the EU AI Act) and send leaders home able to classify a risk but unable to price it. Classification decides whether something goes on the register. Price decides whether it gets money. If a course does not teach the second skill, the register entry sits in amber forever.

Why the heat map fails for AI risk

The problem with risk matrices is not new. Louis Anthony Cox Jr. laid it out in "What's Wrong with Risk Matrices?" (Risk Analysis, 2008): coarse likelihood and impact bins can assign identical ratings to risks that differ by orders of magnitude, and in some cases rank a smaller risk above a larger one. Douglas Hubbard and Richard Seiersen made the security-specific version of that argument in How to Measure Anything in Cybersecurity Risk.

AI makes it worse. "Likelihood: medium" for prompt injection hides the one number you can actually measure, which is how often an attack succeeds against your deployment. Throwing that measurement away to pick a bin is a bad trade.

Decompose one scenario with FAIR

The Open Group's Open FAIR standards (O-RT for the taxonomy, O-RA for the analysis) split risk into loss event frequency and loss magnitude. Loss event frequency is threat event frequency times susceptibility: how often an attacker tries, and what fraction of tries succeed.

Take one concrete scenario. An external sender plants instructions in an email or shared document, your assistant retrieves it while answering an unrelated question, and the model leaks internal data through a rendered link. MITRE ATLAS calls the technique AML.T0051.001, indirect prompt injection, and the outcome AML.T0057, LLM Data Leakage. EchoLeak (CVE-2025-32711) in Microsoft 365 Copilot followed this exact path; our AI incident tabletop post walks through it as an exercise.

Three inputs, and they come from three different places:

• Attempt frequency (estimated). How many crafted payloads reach the retrieval index per year. You will not know this. Give a calibrated 90 percent range instead, say 2 to 20, and write down why.
• Susceptibility (measured). The fraction of attempts that succeed. This is where AI risk differs from most FAIR work: your red team can run the attack 60 times against your own tenant with PyRIT or garak and count. Seven successes in 60 trials is evidence. "The vendor says it is mitigated" is not.
• Loss per event (estimated with finance and legal). Response hours, notification, counsel, regulatory exposure. For a sense of the upper end, IBM's Cost of a Data Breach Report 2025 puts the global average breach at US$4.44 million, and GDPR Article 83 allows fines up to 4 percent of worldwide annual turnover. A range of $50,000 to $2 million per leak event is a defensible starting point for most mid-sized firms; yours may differ.

The simulation

About twenty lines of NumPy turn those inputs into a loss distribution. Ranges become lognormals, red team counts become a Beta distribution, and attempts become Poisson draws.

import numpy as np

rng = np.random.default_rng(7)
N = 100_000

def lognormal_from_ci(low, high, size):
    # treat (low, high) as a calibrated 90% interval
    mu = (np.log(low) + np.log(high)) / 2
    sigma = (np.log(high) - np.log(low)) / (2 * 1.645)
    return rng.lognormal(mu, sigma, size)

def simulate(successes, trials):
    attempts = rng.poisson(lognormal_from_ci(2, 20, N))            # payloads reaching retrieval per year
    p_success = rng.beta(1 + successes, 1 + trials - successes, N)  # red team result
    events = rng.binomial(attempts, p_success)                       # loss events per year
    return np.array([lognormal_from_ci(50_000, 2_000_000, k).sum() for k in events])

before = simulate(successes=7, trials=60)   # current config
after = simulate(successes=0, trials=60)    # external mail excluded from retrieval, link allowlist on

for name, ale in [("before", before), ("after", after)]:
    print(f"{name}: mean ${ale.mean():,.0f}  P90 ${np.percentile(ale, 90):,.0f}  "
          f"P(loss > $1M) {np.mean(ale > 1e6):.1%}")

You can sanity-check the means without running anything. The 2 to 20 attempt range has a mean of about 8. The Beta posterior for 7 of 60 has a mean of 8/62, about 13 percent. The $50,000 to $2 million loss range has a mean near $590,000. Multiply them: roughly $620,000 a year in expected loss before the fix. After the fix, the success rate drops to a posterior mean of 1/62, and expected loss falls to about $80,000.

That difference, around $540,000 a year, is the number to put next to the cost of the control. It is also the number that tells you the control does not get you to zero. Zero successes in 60 trials still leaves a 95 percent upper bound of about 5 percent (the rule of three: 3/n), and the simulation carries that uncertainty instead of rounding it away.

The P90 and P(loss > $1M) lines matter more than the mean for a board. "One year in ten, this scenario costs us more than X" is a sentence directors can act on. NIST's AI RMF asks for this work without naming a method: MAP 5.1 covers documenting likelihood and magnitude of impacts, and MEASURE 2.7 covers evaluating security and resilience. A script an auditor can rerun meets both. If you want a packaged version, pyfair implements the FAIR ontology in Python.

What a course should make you do

Judge any AI risk management course by one exercise: does each participant leave having priced a scenario from their own environment, with at least one measured input? Lectures on likelihood scales do not count. Neither does a vendor's risk calculator with the inputs pre-filled.

The measured input is the part executives tend to skip, because it requires asking the red team for trial counts instead of a pass/fail verdict. Our post on counting trials in AI red team work explains what to request. Calibration is the other piece: Hubbard's equivalent-bet test (would you rather bet on your range containing the answer, or on a spin with a 90 percent chance of winning?) takes twenty minutes to teach and fixes most overconfident ranges.

Where quantification breaks

It needs an inventory first. You cannot price a scenario for an assistant nobody knew was connected to the mail server; our CISO post covers finding those through proxy logs. It also decays. A measured success rate describes one model version under one system prompt, and SaaS vendors swap models without notice, so the red team rerun belongs on a schedule (quarterly, and after any vendor model change). And it handles the tail poorly. A regulator deciding to make an example of the first AI leak in your sector is not well described by a lognormal; say that out loud rather than letting the P90 imply more precision than it has.

None of this replaces judgment. It gives judgment something to argue with.

GTK Cyber's A Cyber Executive's Guide for Artificial Intelligence covers AI risk and governance frameworks and ROI evaluation for AI security tools, and we deliver it privately for leadership teams through an executive briefing.