LLM Risk Assessment Template: 6,639 Incidents Edition

The OWASP GenAI Security Project has transformed how you should evaluate AI risks. Their 2026 Top 10 for LLM Applications uses data from 6,639 real incidents, not just expert opinion. If you're still using consensus-driven risk matrices for your AI systems, you're working from outdated assumptions.

Here's a template that translates their data-driven approach into something you can use this week.

Purpose of This Template

This risk assessment template helps you identify and prioritize LLM-specific vulnerabilities in your applications before they become incidents. Unlike generic AI risk frameworks, it's structured around actual failure modes documented in production systems.

Use this when:

• Evaluating a new LLM integration
• Conducting quarterly security reviews of existing AI features
• Preparing evidence for SOC 2 Type II audits that now include AI controls
• Justifying security budget allocation to leadership

Prerequisites

Before you fill this out, gather:

• Your application architecture diagram showing where the LLM sits
• A list of all data sources the model can access
• Current authentication and authorization controls
• Incident response procedures (you'll reference these)
• Names of engineers who understand the prompt engineering and system prompts

You don't need AI expertise to complete this. You need security engineering discipline.

The Template

# LLM Risk Assessment
Application: [Name]
Assessment Date: [YYYY-MM-DD]
Owner: [Team/Individual]
Review Frequency: Quarterly

## 1. Prompt Injection Risk
**Status**: [ ] Critical [ ] High [ ] Medium [ ] Low [ ] N/A

Despite low incident counts, Prompt Injection remains the top documented risk. The "defense effect" is real; you won't see incidents if you've hardened correctly, but that doesn't mean the risk disappeared.

**Questions to answer**:
- Can users submit free-form text that reaches the LLM? YES/NO
- Do you have system prompts that contain privileged instructions? YES/NO
- Can the model access internal APIs or data stores? YES/NO
- Have you tested delimiter injection? (e.g., "Ignore above, now do X") YES/NO

**Current controls**:
[List what you've implemented: input validation, output filtering, privilege separation]

**Defense effect check**: If you answered YES to any question but have NO incidents, that's the defense effect working. Don't deprioritize this.

## 2. Sensitive Information Disclosure
**Status**: [ ] Critical [ ] High [ ] Medium [ ] Low [ ] N/A

**Questions to answer**:
- Does your training data contain PII, credentials, or proprietary code? YES/NO
- Can users craft prompts to extract training data? YES/NO
- Do you log full conversations including user inputs? YES/NO
- Have you tested prompt-based data extraction? YES/NO

**Data exposure inventory**:
[List what sensitive data the model was trained on or can access]

**Mitigation**:
[Redaction rules, access controls, logging sanitization]

## 3. System-Level Failure Planning
The model will be fooled. Plan for it.

**Failure scenarios documented**:
1. [Describe what happens when the model hallucinates in your context]
2. [Describe what happens if misinformation causes operational decisions]
3. [Describe downstream system impact]

**Containment controls**:
- Human review required for: [List critical actions]
- Automated validation: [Describe checks before model output is trusted]
- Rollback procedure: [How you revert automated decisions]
- Alert thresholds: [What triggers human intervention]

## 4. Incident Data Integration
The 2026 OWASP list used 6,639 real incidents. Your assessment should too.

**Your incident history** (last 12 months):
- Prompt injection attempts detected: [Count]
- Data leakage incidents: [Count]
- Model hallucinations that reached production: [Count]
- Security control bypasses: [Count]

If all counts are zero, you either have excellent defenses or insufficient monitoring. Document which.

**Monitoring coverage**:
[List what you're actually measuring]

## 5. Resource Allocation Justification
**Highest risk** (based on YOUR data + OWASP baseline):
[Name the risk]

**Budget requested**:
[Dollar amount or headcount]

**Justification**:
[Tie to incident data, compliance requirement, or business impact]

**If leadership asks "Why spend on a risk with no incidents?"**:
[Your answer: Explain the defense effect and cite the OWASP data showing 6,639 incidents industry-wide]

Customizing the Template

For customer-facing chatbots: Expand Section 2 (Sensitive Information Disclosure). Add questions about whether the model can access customer account data, payment information, or support ticket history.

For internal code assistants: Focus on Section 2 and add a subsection for proprietary code leakage. Document what happens if the model suggests code that exposes internal architecture.

For compliance-heavy environments: Add a section mapping each OWASP risk to your framework. For SOC 2 Type II, tie Prompt Injection to CC6.1 (logical access controls) and Sensitive Information Disclosure to CC6.7 (data classification).

For multi-model deployments: Clone the template for each model. Different LLMs have different risk profiles. Your GPT-4 integration isn't the same risk as your fine-tuned classifier.

Terminology note: When you document incidents, use the OWASP category names. This makes your assessment comparable to industry data and easier to explain to auditors who've read the same list.

Validation Steps

1. Cross-check with architecture: Every YES answer in the template should map to a component in your architecture diagram. If you can't point to where the risk lives, you don't understand it well enough.

2. Test your failure scenarios: Pick one from Section 3 and actually trigger it in a staging environment. Does your containment control work? If you've never tested the rollback procedure, you don't have a rollback procedure.

3. Review with engineering: The people who built the LLM integration should read this and say "Yes, that's accurate." If they're surprised by anything in your risk assessment, you missed something in discovery.

4. Quarterly re-assessment: Set a calendar reminder. The OWASP list shifted based on new incident data. Your risk profile will shift too. Check your incident counts, update your controls, and adjust priorities.

5. Audit trail: Save each version of this assessment. When your auditor asks "How did you identify and respond to AI-specific risks?", you hand them a dated series of these documents showing evolving understanding and improving controls.

The shift to incident-based risk assessment isn't just about following OWASP. It's about making decisions based on what actually happens, not what we think might happen. Fill this out, test your assumptions, and adjust when the data proves you wrong.