Build an OWASP LLM Top 10 Risk Register for Your AI App

Tier: Advanced · Workflow area: AI governance, risk & compliance

This playbook turns that list into a concrete, per-application risk register: for each of the ten risks, you assess whether it applies to your system, rate likelihood and impact, record the current controls and the evidence, and log the residual risk with an owner. The result bridges the technical red-team backlog and the executive risk register — the same finding, expressed as both a fix and a governed risk.

When to reach for this

• •
  You need a security-specific risk register for an AI application that maps to a framework auditors and engineers both recognize.
• •
  You want to connect red-team findings (pb-44) to a standing risk artifact, so every confirmed hole has a register entry and an owner.
• •
  You are reviewing a new AI feature and need a structured way to be sure no major risk class was overlooked.
• •
  Skip a full ten-risk register for a trivial, sandboxed prototype; use it for anything touching real data, users, or actions.

The workflow

1. 1.

   Instantiate all ten risks for this specific app. Do not start from a generic list — write what each risk means for your system.

   Copy

   ID     Risk                          Applies  Likelihood  Impact  Control (evidence)                 Residual  Owner
   LLM01  Prompt Injection              Yes      High        High    guardrails + CI eval (pb-43)       Medium    AppSec
   LLM02  Sensitive Info Disclosure     Yes      Medium      High    DLP output scan; redaction         Low       AppSec
   LLM03  Supply Chain                  Yes      Medium      High    model SBOM + dep scan (pb-50)      Medium    Platform
   LLM04  Data & Model Poisoning        Yes      Low         High    RAG provenance filtering           Low       Data
   LLM05  Improper Output Handling      Yes      High        High    output encoding at every sink      Low       AppSec
   LLM06  Excessive Agency              Yes      Medium      High    scoped tool perms; HITL approval   Medium    Platform
   LLM07  System Prompt Leakage         Yes      Medium      Medium  no secrets in prompt; leak tests   Low       AppSec
   LLM08  Vector & Embedding Weakness   Yes      Low         Medium  per-tenant isolation; access ctl   Low       Data
   LLM09  Misinformation                Yes      High        Medium  grounding + citations + eval       Medium    Product
   LLM10  Unbounded Consumption         Yes      Medium      Medium  rate/spend limits at gateway       Low       Platform
   

2. 2.

   Rate likelihood and impact from evidence, not vibes. Feed likelihood from your actual bypass rates (pb-46) and impact from the sink and data at stake. A risk with a measured 68% bypass rate is not "Low likelihood."

3. 3.

   Record the control and its evidence. Each entry names the mitigating control and points to proof it exists and works — a CI config, a scan report, an architecture decision.

4. 4.

   Compute residual risk after controls. Likelihood × impact reduced by control effectiveness. The residual is what leadership actually decides to accept, transfer, or fix further.

5. 5.

   Assign an accountable owner per risk. OWASP risks span AppSec, Platform, Data, and Product. Ownerless risks are the ones that rot.

6. 6.

   Link each register entry to its backlog items and framework mappings. Cross-reference the pb-44 findings, the ATLAS techniques (pb-45), and the NIST RMF risk (pb-47) so the register is one connected system, not a parallel document.

Verify before you trust it

The register is complete when all ten risks are assessed (applicable or explicitly excluded with a reason), every applicable risk has a control with inspectable evidence, and every residual risk has an accountable owner who has accepted it. Run the completeness check: no risk left blank, no "not applicable" without justification — an app that "doesn't have" excessive agency because it has tools it simply hasn't scoped is misclassified. Run the grounding check: for each likelihood rating, confirm it traces to evidence (a bypass rate, an incident, an architecture fact) rather than intuition. Run the ownership check: every non-trivial residual risk names a human who owns it. A register that scores every risk "Low" with no evidence is the classic failure — verify the numbers came from measurement, not optimism.

Pitfalls

• A generic list detached from the app. Copying OWASP's descriptions without instantiating each risk for your system produces a document no one can act on. Write what each risk means here.
• Ratings by intuition. Likelihood pulled from red-team data is defensible; likelihood pulled from optimism is not. Ground it.
• Controls without evidence. A named control with no artifact behind it inflates confidence and fails audit. Attach proof.
• Ownerless residuals. Risk that no one accepts is risk no one manages. Assign every residual.
• A register that never updates. New features add and change risks. Tie the register to change and to the red-team pipeline so it stays current.

Tools

• OWASP LLM Top 10the free, authoritative risk taxonomy and per-risk mitigation guidance that structures every register entry.
• AI risk register / GRC trackerthe living store where entries, ratings, controls, residuals, and owners are recorded and reviewed.
• NIST AI RMFthe broader governance frame the register rolls up into, letting security risks connect to the organization's overall AI risk posture.

Client-safe variant

Build the OWASP register inside the client's risk-management system as their standing record. Ground likelihood ratings in red-team evidence gathered within their boundary, keep the control evidence (scan reports, configs) in their environment, and deliver the register as a living artifact their risk owner maintains and re-rates on change. Present residual risks and their owners plainly so the client's leadership can make accept/transfer/mitigate decisions. Use only the public OWASP materials, avoid embedding verbatim exploit payloads in the register (reference the finding ID instead), and never carry one client's risk ratings or controls into another engagement — each app's register is specific to its architecture and data.