AI Security Review Template
One workbook per AI system, covering the full review cycle: system intake, threat register, control plan, evidence gaps, and a signable disposition. The structure an AI Committee can sign, a security architect can defend, and a DPO can keep on file. Includes a full worked example for a Copilot Studio procurement agent.
Free spreadsheet
Excel · .xlsx · 6 sheets
Download free
Enter your work email. Opens in Excel, Google Sheets, or any spreadsheet tool. You'll also receive new blog posts when they publish.
Who it's for
Security architects, AI governance leads, CISOs, and AppSec leads running a structured AI security review before pilot or production.
Use it per system — one workbook per AI system under review. The Disposition sheet is the artifact the AI Committee signs. The supporting sheets are the evidence trail.
How to use it
- 1Fill in System Intake completely — incomplete intake is the most common cause of review delay.
- 2Populate the Threat Register from your threat-modelling exercise.
- 3For each threat, add one or more Control Plan rows with lifecycle gate and evidence required.
- 4List evidence gaps with owner and target date.
- 5Record the clearance decision and re-assessment triggers on the Disposition sheet.
- 6The AI Committee signs the Disposition sheet. The other sheets are the evidence trail.
What's in the file
Five working sheets that form the review dossier, plus a how-to guide. Each sheet is populated with the Copilot Studio procurement agent worked example.
| Sheet | Contents |
|---|---|
| 1 — System Intake | 20 fields covering system purpose, model, data, scope, lifecycle stage, and re-assessment triggers |
| 2 — Threat Register | Per-threat: source framework, attack surface, description, likelihood, severity, inherent risk |
| 3 — Control Plan | Per-control: threat link, control description, lifecycle gate, evidence required, owner, status, target date |
| 4 — Evidence Gaps | Per-gap: control link, description, why it matters, owner, target date, status |
| 5 — Disposition | Clearance decision, scope, conditions, residual risks, re-assessment triggers, sign-off fields |
Sample disposition decision
Decision
Conditional clearance — restricted pilot only
Scope
Procurement team (15 users); reversible actions only; no contract modification
Conditions for production
Output filter implemented (C-005); audit log trace ID complete (C-008); 12-month retention configured (C-009)
Re-assessment triggers
Adding any tool · Scope expansion beyond procurement · Vendor model change · Sub-processor change
Next review
2026-07-12 (or earlier on trigger)
From template to clearance workflow
Spreadsheets are the starting point.
This template structures the review manually. Drel automates the same workflow — building the system model, running the threat analysis, mapping controls to evidence gaps, and producing a review-ready dossier your AI Committee can actually approve or reject.
Frequently asked
Frequently asked questions
- Does this template replace a formal security review?
- It provides the structure for the review and the artefact the AI Committee signs. The substance — threat identification, control selection, evidence collection — still requires qualified security work. Think of the template as the form; the review is the substance you put into it.
- Can I use this for any AI system?
- Yes. The system intake fields and threat-framework references are kept general enough to cover AI, RAG, agentic AI, vendor AI, and customer-facing AI. The worked example is an agentic system, but the template structure applies regardless of type.
- What's the five-state clearance decision?
- The disposition sheet asks for one of five outcomes: proceed (unconditional), conditional (proceed with named conditions), restricted pilot only (limited deployment with re-review), hold (more work before any deployment), or decline (do not deploy). Most production-grade AI systems first receive conditional clearance.
- Why per-system rather than one master review?
- Because the scope of clearance is per-system. Each AI system has its own threat surface, its own controls, its own evidence trail, and its own re-assessment triggers. A combined review for multiple systems blurs the disposition and makes the artefact harder to defend in an audit.
- What re-assessment triggers should I name?
- Common categories: model change (foundation model swap, fine-tuning update), data change (new training data, new ingestion source), scope change (new use case, new user population), tool change (new tool added to agent, tool surface modification), supply chain change (sub-processor change, vendor change), and incident triggers (vendor incident disclosure, internal incident affecting this system).
- How does this map to ISO 42001 and the EU AI Act?
- The Threat Register and Control Plan map to ISO 42001 clauses 6.1.2 and 8.2. The Disposition sheet maps to ISO 42001 clause 8.5 (operational control) and the re-assessment triggers map to clause 9.1 (monitoring). For high-risk EU AI Act systems, the same artefacts support Article 9 risk management evidence.