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

By Charles Givre · 2026-10-28

> AI risk management training for security executives should teach you to price one AI scenario in dollars, using red team success rates as measured input.

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?"](https://doi.org/10.1111/j.1539-6924.2008.01030.x) (*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](https://www.opengroup.org/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](/atlas/AML.T0051.001), and the outcome [AML.T0057, LLM Data Leakage](/atlas/AML.T0057). EchoLeak ([CVE-2025-32711](https://nvd.nist.gov/vuln/detail/CVE-2025-32711)) in Microsoft 365 Copilot followed this exact path; our [AI incident tabletop post](/blog/executive-ai-risk-training-tabletop) 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](https://github.com/Azure/PyRIT) or [garak](https://github.com/NVIDIA/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](https://www.ibm.com/reports/data-breach) 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](https://numpy.org/doc/stable/reference/random/generator.html) turn those inputs into a loss distribution. Ranges become lognormals, red team counts become a Beta distribution, and attempts become Poisson draws.

```python
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](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) 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](https://github.com/Hive-Systems/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](/blog/ai-red-team-training-security-engineers) 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](/blog/where-cisos-learn-ai-security) 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](/courses/executive-ai-guide) 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](/executive-briefing).

## FAQ

### What should AI risk management training for security executives teach?

How to turn one AI scenario into a loss range a CFO will accept, and how to show what a control does to that range. That means decomposing the scenario into frequency and magnitude, knowing which inputs can be measured (attack success rate) and which must be estimated (attempt frequency, loss per event), and reading the output as a distribution instead of a single forecast. Framework names are the easy part.

### Can you use FAIR for AI and LLM risks?

Yes. Open FAIR does not care whether the asset is a database or a model. Loss event frequency is threat event frequency times susceptibility, and loss magnitude is what an event costs you. AI systems are unusual in one helpful way: susceptibility to prompt injection can be measured directly by running repeated attack trials against your own deployment, which is rarer for traditional assets.

### What does zero successes in a red team run mean for risk?

Not zero risk. With 0 successes in 60 trials, the rule of three puts the 95 percent upper bound on the true success rate at about 3/60, or 5 percent. A Beta(1, 61) distribution captures the same uncertainty in a simulation. If a vendor reports 'no successful attacks,' ask how many trials that was.

### How does this relate to the NIST AI RMF?

The AI RMF asks for this work without prescribing a method. MAP 5.1 asks organizations to identify and document the likelihood and magnitude of each impact, and MEASURE 2.7 asks that AI system security and resilience be evaluated and documented. A FAIR-style model with red team data as an input satisfies both with an artifact an auditor can rerun.


---

Canonical: https://gtkcyber.com/blog/ai-risk-management-training-security-executives/