# AI Risk Register
One row per risk, mapped to NIST AI RMF.

_A risk register row template aligned to the NIST AI RMF functions (GOVERN, MAP, MEASURE, MANAGE). Use one row per risk and review on a schedule._

Used in: Lesson expert/07 — https://vetslearn.com/lessons/expert/07
Source: https://vetslearn.com/resources/templates/engineering#t-risk-register

---

# Risk Register: [SYSTEM NAME]

**Owner:** [OWNER]
**Review cadence:** [REVIEW CADENCE — e.g. quarterly]

---

## Columns

| Column | Fill in |
|---|---|
| Risk ID | `RISK-001`, incremented. Never reuse. |
| Description | One sentence. What can go wrong and to whom. |
| NIST AI RMF function | GOVERN / MAP / MEASURE / MANAGE |
| Likelihood | Low / Medium / High |
| Impact | Low / Medium / High |
| Risk score | Likelihood x Impact (1-9) |
| Mitigation | What we are doing. Concrete. Linked to ticket or doc. |
| Owner | Named person. Not a team. |
| Review date | When this row gets re-scored. |

## Example rows

| Risk ID | Description | NIST function | Likelihood | Impact | Score | Mitigation | Owner | Review date |
|---|---|---|---|---|---|---|---|---|
| RISK-001 | Model returns wrong policy answer to customer | MEASURE | Medium | High | 6 | Eval set with 200 policy cases, blocks deploy under 95% pass | Jane Doe | 2026-09-01 |
| RISK-002 | Prompt injection via retrieved doc tricks agent into emailing customer list | MAP | Medium | High | 6 | Tool allowlist, human-in-loop for email send, indirect injection eval | John Smith | 2026-09-01 |
| RISK-003 | Vendor model deprecated with 30 days notice | GOVERN | High | Medium | 6 | Dual-vendor abstraction layer, monthly fallback test | Jane Doe | 2026-09-01 |
| RISK-004 | PII leaks into logs | MANAGE | Low | High | 3 | PII redaction at log writer, quarterly audit | Sec team lead | 2026-09-01 |
| RISK-005 | Cost spike from runaway agent loop | MANAGE | Medium | Medium | 4 | Max steps cap of 10, cost alert at $500/hour | John Smith | 2026-09-01 |

## How to score

- **Likelihood:** Low = could happen once a year. Medium = could happen monthly. High = expected within weeks.
- **Impact:** Low = internal annoyance. Medium = some users affected, recoverable. High = data exposure, regulatory action, or trust loss.
- **Score:** Likelihood (1-3) x Impact (1-3). Anything 6 or above needs an active mitigation, not a planned one.

## Review process

At each review:
1. Re-score every open row.
2. Close rows where the mitigation now holds and the score is 2 or below.
3. Add new rows from postmortems, red-team findings, and audits.
4. The owner column must be a person. "The team" is not an owner.

---

## How to use

Keep this in version control next to the system card and threat model. The three documents reference each other — a threat in the threat model that needs ongoing tracking becomes a row here. Federal reviewers will ask for this. Boards will ask for this. Pretending you do not need one until you are asked is the slowest path to having one.

## Check before you use it

- Every owner is a named person who knows they own the row.
- Every score of 6 or above has an active mitigation, not a planned one.
- No review date is in the past.
- The newest rows trace to the latest postmortems and red-team findings. If none do, the register is stale.