An AI security review is not a single checklist. It is a structured argument that a system is safe enough to operate — backed by evidence a reviewer can stand behind and an auditor can verify a year later.
Most reviews fail not because the threat analysis was wrong, but because the result is not a decision. There is a report, a risk register, maybe a score. But no one looked at the assembled evidence and said: this system is cleared — or it is not — and here is why, and here is who decided.
This template fixes that. It structures the review as five phases that accumulate toward a single output: a clearance decision with a named reviewer and a durable record.
- ✓AI model(s) and version(s) in use
- ✓System purpose and user population
- ✓Data flows: inputs, outputs, and where sensitive data travels
- ✓External integrations, APIs, and tool permissions
- ✓Deployment topology (cloud, on-prem, edge, hybrid)
- ✓Agentic capabilities: tools, memory, actions the system can take
- ✓Threat actors: external, internal, and AI-assisted
- ✓Prompt injection and jailbreak surface area
- ✓Data exfiltration paths through model outputs
- ✓Agentic escalation: what can the system do if compromised?
- ✓Supply chain risks: model providers, fine-tuning data, plugins
- ✓OWASP LLM Top 10 relevance mapping
- ✓Input validation and sanitization controls
- ✓Output filtering and content moderation
- ✓Authentication and authorization on AI endpoints
- ✓Rate limiting, abuse detection, and circuit breakers
- ✓Logging, monitoring, and incident response coverage
- ✓Human oversight mechanisms and override controls
- ✓Architecture diagram reviewed by security team
- ✓Penetration test or red-team report (if conducted)
- ✓Vendor certifications (SOC 2, ISO 27001, etc.) with scope notes
- ✓Data processing agreement and privacy impact assessment
- ✓Control implementation evidence (config screenshots, code review)
- ✓Outstanding findings with owners and remediation deadlines
- ✓Disposition: Cleared, Conditional, or Not cleared
- ✓Rationale: what evidence supports the disposition
- ✓Conditions: what must be remediated before or after launch
- ✓Reviewer name, role, and date of sign-off
- ✓Re-assessment trigger: what changes require a new review
- ✓Record retention: where the evidence pack is stored
How to use this template
Work through the five phases in order. Each phase builds on the last: you cannot assess controls you have not mapped, and you cannot collect evidence for gaps you have not found. Skipping ahead produces a review that looks complete but is not grounded.
The template is intentionally format-agnostic. Run it in a document, a spreadsheet, or a purpose-built tool like Drel. What matters is that the five sections are present and that each one points to evidence — not just to assertions.
Flag anything you cannot verify. A review that honestly marks “not assessed — no evidence available” is safer than one that silently skips what it could not check. The gaps are what the reviewer is accepting when they sign off.
Phase 1: System description
Start here before touching the threat model. The system description is the shared ground truth that every subsequent section builds on. If reviewers are working from different mental models of what the system does, the rest of the review will be incoherent.
Focus on what is true at review time, not the eventual design. Document the AI model and version actually deployed, the data the system touches, and the actions it can take. Agentic systems deserve special attention: a system with tool-calling access to production APIs has a fundamentally different attack surface than one that only generates text.
The scope of the review is the scope of the system description. If it is not in the description, it is not in the review.
Phase 2: Threat model
A threat model for an AI system is not the same as a threat model for a conventional application. The threat surface includes the model itself — its training data, its inference behavior, its tendency to follow instructions from inputs it was not supposed to trust.
Prompt injection is the canonical AI-specific threat: an attacker embeds instructions in data the model processes, and the model executes them. In an agentic system with write access to external services, a successful prompt injection is not a data leak — it is a command execution. Map these paths explicitly. The OWASP LLM Top 10 is a useful starting framework, but it should be applied to your specific architecture, not used as a generic checklist.
Prompt injection in an agentic system is not a data leak. It is a command execution.
Phase 3: Control assessment
For each threat identified, assess whether a control exists and whether there is evidence it works. The output is not a list of controls — it is a gap analysis: threats that are covered, threats that are partially covered, and threats where there is no control at all.
Human oversight is a control. For high-risk AI systems, the ability for a human to intervene, override, or shut down the system is itself a control gap if it is not documented and tested. Do not assume it exists because the application has an admin panel.
Be precise about what “in place” means. A policy that says the system validates inputs is not the same as a tested implementation that rejects malicious inputs. The evidence pack (Phase 4) is where you back up that distinction.
Phase 4: Evidence pack
The evidence pack is the audit trail. It is the set of artifacts that a reviewer can hand to a regulator, an insurer, or a board and say: here is what we looked at, here is what we found, and here is what we decided.
Vendor certifications go here — but they belong in the evidence pack with a scope note, not as a substitute for assessing your system. A vendor's SOC 2 covers what they built. The system you built on top of their API is your responsibility. Flag the boundary explicitly.
A vendor certification is evidence about the vendor. It is not evidence about the system you built on their platform.
Outstanding findings belong here too, with named owners and dates. A finding with no owner is not a finding — it is a wish.
A finding with no owner is not a finding. It is a wish.
Phase 5: Clearance decision
The five sections accumulate to this: a named person looks at the evidence, assesses the residual risk, and makes a decision. The decision is not a score. It is a disposition — Cleared, Conditional, or Not cleared — with a rationale that explains what evidence supported it and what risk was accepted.
Conditional clearance is common and appropriate. A system that is safe enough to launch if three specific gaps are remediated by a specific date is better than a system that waits for a perfect review that never comes. The conditions must be specific, owned, and tracked.
The re-assessment trigger is as important as the initial decision. What changes to the system require a new review? A model upgrade? A new tool permission? A new data source? Define it now, while the reviewer still understands the system, not when the change is already in production.
Run this template with Drel
Drel structures the review as these five phases, populated by AI analysis and reviewed by your team. The output is a clearance decision with a durable evidence record — not a report that lives in a folder.