How to Write an AI Risk Register for a Small Team

The OWASP Top 10 for Large Language Model Applications is the sensible starting set of categories. The project has grown beyond a single list into the broader OWASP GenAI Security Project, which covers LLMs, agentic systems and AI-driven applications per the project page. The list itself is maintained at the GenAI project site, which also publishes versions and translations on the LLM Top 10 page.

One caution before you paste categories into rows. The numbering has changed between editions, so record which edition you are mapping against and check it when you review. Numbering and ranking shift, and practitioners report that both the 2025 and 2026 editions circulate at once as Superwise notes. A register entry that says "LLM08" without an edition is ambiguous a year later.

The practical move is a two-step seed:

1. Create one row per OWASP category, with the description copied verbatim as your placeholder.
2. Rewrite each description into a sentence about your system, or delete the row if it genuinely cannot happen to you.

That second step is where the register becomes useful. Here is what it looks like for a customer support assistant that can look up orders and issue refunds up to a limit.

• Prompt injection, rewritten: a customer pastes a shipping label or email that contains instructions, and the assistant treats them as its own instructions. Prompt injection is direct or indirect manipulation of the model's behavior through the content it reads, including files and web pages as Cloudflare explains.
• Excessive agency, rewritten: the refund tool accepts any amount, because it was built with the same database credentials as the admin console. OWASP names three root causes for excessive agency: excessive functionality, excessive permissions and excessive autonomy per the LLM06 page, and notes that a read-only extension connecting with UPDATE and DELETE rights is a textbook case.
• Sensitive information disclosure, rewritten: a logged-in customer asks about "my last order" and the retrieval step returns another customer's order record. OWASP's entry on this risk covers PII, credentials and business data leaking through output, and warns that system-prompt restrictions may not be honored in its description.
• Vector and embedding weaknesses, rewritten: a document uploaded to the knowledge base contains hidden text that steers answers. OWASP covers cross-context leakage in shared vector stores and hidden-content poisoning under LLM08, and a vendor summary gives the white-text-on-white-background example at A10 Networks.
• Unbounded consumption, rewritten: someone loops the public chat endpoint overnight and the bill spikes. OWASP lists variable-length input floods, denial of wallet and model extraction via API as members of this class on the LLM10 page.

If your system has no retrieval, delete the vector row. If it has no tools, excessive agency reduces to a planning note. An empty register with ten theoretical rows teaches nobody anything.

A 5 by 5 matrix is the common choice, and the main practical decision is whether to use a simpler grid. A 3 by 3 is faster and coarser; a 5 by 5 gives more resolution at the cost of more arguments about whether something is a 3 or a 4 as this matrix guide sets out. For a small team, 5 by 5 with written anchors is better, because the anchors do most of the work.

Write the anchors down once, in a second tab, and never renegotiate them casually.

Likelihood anchors

Impact anchors

Then apply a threshold rule, which is the decision the first search result usually leaves out.

Worked example. The open refund tool scores likelihood 4 (an easy test triggers it, because a crafted message got it to refund a test order during a red team session) and impact 4 (multi-customer money loss plus a notification question). That is 16, so it is scheduled with a date and reviewed monthly. After the tool is limited to a per-transaction cap and human approval above it, likelihood falls to 2 because the easy test no longer works, and impact falls to 3 because the worst case is now one capped refund. The new score is 6. Move it to quarterly review and write the two scores and the date in the row history. That narrative is the audit trail, and it takes one line.

Two rules keep the numbers honest. First, the owner sets the score, not the person who found the risk, because the owner carries the consequence. Second, never re-score silently. Add a dated note so the trend is visible and you can tell whether mitigations are working or you are just getting more pessimistic.

A register with 80 rows is a graveyard. Aim for 15 to 25 live rows at a small company, and treat growth beyond that as a signal to consolidate. Three habits hold the ceiling:

• One risk, one row. Do not split "refund fraud" into four rows for four attack variants. Put the variants in the mitigation text.
• Close aggressively. When a mitigation is shipped, keep the row for one review cycle, then mark it closed and move it to a closed tab. Closed risks are evidence; they are not workload.
• Delete duplicates without ceremony. If two rows describe the same failure mode viewed from different angles, merge them and note both IDs.

If you need a formal project register alongside this one, Rocketlane's comparison is a useful reminder of the difference: a log records existence, a register adds scoring, owner, mitigation and resolution status, and a RAID log widens scope at the cost of depth in its template guide. Do not try to be a RAID log. Pick one artifact, name it clearly, and put the link in the team wiki.

The best rows come from evidence. Build four intake channels and put a standing item in the sprint to process each one.

1. Incidents and near misses. Every time someone screenshots a bad answer in the team channel, that is an intake. Log the customer-visible effect, then ask which register row it belongs to. If none fits, you have found a new risk. Keep the customer impact separate from the technical cause, because the same cause maps to different rows depending on what the user saw.

2. Model and prompt changes. Any change to the model behind the assistant, the system prompt, the tool list, or the retrieval corpus is a trigger to re-score. Model swaps are the highest-risk change a small team makes, because behavior shifts without code changing. Record the change in a column or a linked changelog and re-read the agency, misinformation and disclosure rows specifically.

3. Red team exercises. Even a one-hour session with the prompts the OWASP project uses as examples will surface candidates. The Cloudflare write-up on insecure output handling gives a workable test: feed the model something that produces a script and see whether the application executes it in the OWASP risks explainer. Insecure output handling is when output reaches another system without validation or encoding, so the test is concrete and the result is a likelihood score.

4. The list itself. Re-read the current OWASP edition once a quarter and check your mapping. Cross-references shift between editions; the 2026 release maps risks to NIST, MITRE ATLAS, CWE and the OWASP Top 10 for Agentic Applications per its resource page, which also gives you vocabulary for describing agent-specific rows.

Whatever comes in, write the description as an event, not a category. "The assistant issued a refund greater than the cap" is a risk. "Excessive agency" is a filing cabinet.

The register only stays current if it is wired into the team's existing rhythm. Three touchpoints are enough.

The incident loop. When an incident happens, do not only fix it. Add or update a row, re-score it with the new evidence, and set the next review date. If the incident was severe enough that the register missed it, add a row for "the register missed this class of failure" and fix the intake. That meta-row is uncomfortable and it is the most useful one you will ever write.

The change loop. Make a register review a required step in the release checklist for anything touching prompts, tools or retrieval. It can be a two-minute check: open the register, filter by "affected component", re-score what changed. The person doing the release owns it.

The recurring review. One 30-minute meeting per month, with a single agenda: read every row scoring 12 or above, confirm the owner, confirm the mitigation is still true, set the next date. Anything scored below that gets read asynchronously. Twice a year, take the full list to whoever signs off on risk and ask them to accept or reject the rows scored 1 to 5, in writing.

Assign the whole thing to one person, not to the engineering team in general. The register needs a keeper who is allowed to nag. If the keeper is the most senior engineer, that person needs explicit permission to spend the time.

Two limits worth knowing before you rely on it.

First, qualitative matrices compress information. A 5 by 5 grid has 25 cells and the ranking inside a diagonal is often arbitrary; the guide cited earlier flags the limitations of qualitative matrices directly at Optro. Do not defend the difference between a 9 and a 10. Defend the threshold rule and the owner.

Second, a spreadsheet does not enforce anything. If the register says refunds require human approval and the code does not, the register is a fiction. Pick the three highest-scoring rows and write a test for each mitigation that fails when the control is removed. That converts a document into a control.

For teams running several AI systems, the maintenance burden lives in the plumbing rather than the risk thinking: which key is used where, who can change a prompt, how spend is capped. Centralizing that is the natural next step, and Quanta for Teams puts a shared credit pool, a private skill library, admin controls and an API key per person in one place (https://quantaintelligence.ai/for-teams). If your register is starting to look like a program of work and you want a second opinion on which rows to fix first, a free discovery call is a reasonable use of 30 minutes (https://quantaintelligence.ai/calendar).