The AI security review checklist, by lifecycle gate
A checklist that follows the lifecycle of an AI system — intake, architecture, threat model, control plan, disposition, pilot, production. Each gate has different review questions and different evidence requirements.
The most common failure in AI security reviews is that the review happens at the wrong point in the lifecycle. Either it runs too early — before the architecture is stable enough to threat-model — or too late, after deployment decisions have been locked in and the review becomes a documentation exercise for a decision already made.
Structuring the review against lifecycle gates solves this. Each gate corresponds to a point where the review can still change an outcome. The questions at each gate are different because the available information and the decisions still open are different.
Why lifecycle gates matter
A gate-based checklist does two things a flat checklist cannot. First, it sequences review activities to match when information becomes available. You cannot assess data governance controls before the data flows are specified. Second, it ties review evidence to decisions — at each gate, there is a specific go/no-go question the review must answer.
The gates below follow the standard AI system lifecycle. Not every system passes through every gate — a vendor-provided AI system may skip the architecture gate if the architecture is not disclosed — but any gate that is skipped should be explicitly flagged as an evidence gap in the disposition.
Review checklist by lifecycle gate
| Gate | Review questions | Evidence required |
|---|---|---|
| Intake | Is the system description complete? Who is the system owner? What is the target deployment context? | Completed system description document, named risk acceptor, target deployment date |
| Architecture review | Are data flows fully documented? What tools and integrations are connected? Where are the human-in-the-loop boundaries? | Architecture diagram, tool manifest, data flow map with classifications |
| Threat model | Which OWASP LLM / Agentic Top 10 threats apply? What is the blast radius of the worst case? What are the data-protection risks? | Threat register with likelihood, impact, and risk ratings; methodology reference |
| Control plan | Does each threat above threshold have a specified control? Who owns each control? How will it be verified? | Control plan with owner, lifecycle gate, and verification method per control |
| Disposition | What is the clearance decision? Who accepts the residual risk, and under what condition? What triggers a re-assessment? | Signed disposition record: decision, rationale, residual risk acceptance, re-assessment triggers, sign-off log |
| Pilot | Are all before-pilot controls verified? Has anything changed since the disposition was issued? | Control verification evidence for before-pilot controls; change log since disposition |
| Production | Are all before-production controls verified? Are ongoing controls owned and scheduled? | Full control verification evidence; ongoing control schedule; updated sign-off log |
Gate 1: Intake — what is this system?
The intake gate establishes the minimum information needed to scope the review. It should produce a system description that everyone on the review team can work from.
- What does the system do? What is its stated purpose and its actual use case?
- Who uses it, and in what context?
- What data does it process? What are the data classifications?
- Is it a new system, a model update to an existing system, or a scope expansion?
- What is the target deployment date? (This scopes the time available for the review.)
- Who is the system owner and who will accept the risk disposition?
Gate 2: Architecture review — how is it built?
The architecture review maps the system's components and data flows. This is the foundation of the threat model.
- What model or models does the system use? Base models, fine-tuned models, or both?
- What is the system architecture? How does data flow in and out?
- What tools or integrations are connected? (APIs, MCP servers, databases, external services.)
- What human oversight mechanisms are in place? Where are the human-in-the-loop boundaries?
- What data does the system have access to? What data does it store or retain?
- What authentication and authorisation controls govern access to the system and to the tools it uses?
Gate 3: Threat model — what could go wrong?
The threat model applies the architecture to a structured set of threat categories. For AI systems, the relevant threat catalogues are OWASP LLM Top 10, OWASP Agentic Top 10, and NIST AI RMF.
- Which OWASP LLM Top 10 threats apply to this system?
- If the system is agentic, which OWASP Agentic Top 10 threats apply?
- What are the highest-impact threats given the system's data access and integration scope?
- What is the blast radius if the system behaves unexpectedly?
- What are the data-protection risks specific to the personal data the system processes?
Gate 4: Control plan — what mitigates each threat?
The control plan maps each identified threat to the controls that address it, grouped by lifecycle gate, with an owner and a verification method.
- What control addresses each identified threat?
- Which controls must be in place before pilot? Before production? Which are ongoing?
- Who owns each control? (Role, not person.)
- How will each control be verified? What evidence demonstrates it is in place?
- What residual risk remains after controls are applied?
Gate 5: Disposition — what is the decision?
The disposition is the decision record. It synthesises the threat model and control plan into a formal decision about whether the system may proceed.
- Decision: proceed / conditional / restricted pilot / hold / decline.
- Rationale: why, in two to three sentences naming the headline risk and mitigation.
- Required controls: the control plan, with gates and owners.
- Residual risk acceptance: what is being accepted, by whom, under what condition.
- Evidence gaps: what is not yet known and the plan to close it.
- Re-assessment triggers: the conditions under which this decision must be revisited.
- Sign-off log: role, status, date, and any caveats.
Gate 6: Pilot — are the controls verified?
Before a pilot expands, the before-pilot controls must be verified. The pilot gate is not an additional review — it is a check that the commitments from the disposition have been honoured.
- Are all before-pilot controls in place and verified against their stated verification methods?
- Is the pilot scope consistent with the restricted scope in the disposition?
- Has anything changed since the disposition was issued that triggers a re-review?
Gate 7: Production — are all production controls verified?
- Are all before-production controls in place and verified?
- Is the production deployment consistent with the scope in the disposition?
- Are ongoing controls documented, owned, and scheduled?
- Has the sign-off log been updated to reflect production approval?
Ongoing: Re-assessment
The re-assessment phase is not a scheduled review — it is triggered by the conditions named in the disposition. The ongoing checklist is: has any re-assessment trigger fired?
- Has the underlying model changed?
- Has the system's scope, data access, or tool manifest expanded?
- Has there been an incident involving the system?
- Have the regulatory obligations for this system type changed?
See the Drel AI security review hub for the full framework alignment and the demo dossier for a complete worked example.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Structure your next AI security review
Drel provides the gate-by-gate structure, the threat model, and the disposition record — so every review produces a defensible output, not just a completed checklist.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.