AI security review for systems that can't wait for the next sprint.

An AI security review is a design-time process. It happens before the system reaches production — ideally before the restricted pilot, and certainly before broad deployment. The output is not a penetration test report, not a red team finding, and not a risk awareness document. It is a structured clearance decision backed by a dossier that a committee can sign, a security architect can defend, and an auditor can inspect.

The review covers four things: a risk disposition that characterises what the system does and what could go wrong; a threat model specific to the system's architecture (AI inference, RAG pipeline, agentic tool calls, or some combination); a control plan listing required controls with lifecycle gates; and an evidence pack documenting what has been verified, what remains a gap, and what must be satisfied before a proceed decision can be recorded.

What it is not: runtime scanning, continuous monitoring, live posture management, or a guarantee of any regulatory outcome. A security review is a design-time artifact. It captures the state of the system at the point of review and names the conditions that would require re-assessment. It does not watch production.

This distinction matters practically. When a DPO asks "was this system reviewed before deployment?", the answer should be a document with a date, a scope, a set of identified risks, and a signed clearance decision. A Slack thread saying "yeah, we looked at it" does not satisfy that question. A structured review dossier does.

The review is typically led by a security architect or AI governance officer, with input from the system owner (the team building or procuring the AI system) and oversight from a CISO or head of security. The DPO should be involved wherever personal data enters the system — which, for most enterprise AI deployments, is everywhere.

Each stakeholder reads the output differently, and a well-structured review produces material suited to each:

• The AI Committee — typically the CISO, CTO, and AI governance lead — receives the disposition memo: the clearance decision, the rationale, the residual risks, and the re-assessment triggers. This is what they sign. It should be one to three pages. Not a slide deck.
• The security architect receives the control plan: each required control, its lifecycle gate (design, pilot, production), the owner, and the evidence requirement. This is the operational document they use to track implementation.
• The DPO receives the evidence gaps report: where personal data flows through the system, what controls are in place, what controls are absent, and what must be remediated before the system can be considered appropriate for the data scope. This feeds the DPIA.
• Internal audit receives the full evidence pack: the threat model, risk register, control plan, evidence gaps, and the clearance decision — dated and scoped. This is what sits on file.

The review process itself requires access to design artifacts: system architecture, data flows, model selection, prompt design, tool definitions (for agentic systems), and any existing security controls. It does not require access to production systems, model weights, or live telemetry.

A structured AI security review follows a defined sequence. Each stage produces an artifact that feeds the next. Skipping stages is common and consistently produces the same outcome: a clearance decision made on incomplete information.

1. System intake. Before any threat modelling, the reviewer needs a structured description of what the system is: its purpose, its users, the data it processes, the model(s) it uses, the integrations it depends on, and the deployment environment. System intake is not a checkbox questionnaire — it is the foundation on which the threat model is built. Gaps in intake produce gaps in the threat model.

2. Threat model. Given the system description, the reviewer maps the attack surfaces specific to this system's architecture. For a AI chatbot: prompt injection, output handling, sensitive information disclosure, model inversion. For a RAG pipeline: add the ingestion pipeline, the vector store, and indirect injection via retrieved context. For an agentic system: add the tool surface, the delegation chain, and the blast radius. Threat modelling is not a generic exercise — the threats that matter depend on the architecture.

3. Risk register. Each identified threat is characterised as a risk: likelihood (given the controls in place), impact (given the system's data scope and action surface), and current control status (no control, partial control, control implemented but not evidenced, control implemented and evidenced). The risk register is the document that drives the control plan.

4. Control mapping. Each risk in the register is assigned one or more controls. Controls are mapped to frameworks (OWASP, NIST AI RMF, ISO 42001) and assigned lifecycle gates: must be in place before design sign-off, before pilot, before production. This is the control plan. It is operational — it names owners and evidence requirements, not just control names.

5. Evidence pack. The evidence pack assembles what has been verified (controls in place and evidenced), what is a gap (controls required but not implemented), and what is conditional (controls claimed but not yet evidenced). The clearance decision flows from this: proceed if gaps are minor and can be remediated before production; conditional if gaps are significant but a plan exists; hold if critical controls are absent.

Framework mapping is not naming a framework in a document header. It is assigning each identified control to the specific clause or threat category that requires it, so that when an auditor or committee member asks "how does this map to NIST AI RMF?", the answer is a specific control row, not a general assertion.

OWASP LLM Top 10 covers the core LLM attack surface: prompt injection (LLM01), insecure output handling (LLM02), training data poisoning (LLM03), model denial of service (LLM04), supply chain vulnerabilities (LLM05), sensitive information disclosure (LLM06), insecure plugin design (LLM07), excessive agency (LLM08), overreliance (LLM09), and model theft (LLM10). Drel maps each to the control layer (input validation, output filtering, access control, audit logging) rather than treating the list as a checklist.

OWASP Agentic Top 10 covers the additional surface for tool-using agents: prompt injection in agentic context, excessive agency, privilege escalation, context manipulation, insecure memory, tool injection, unauthorized lateral movement, supply chain risks, audit trail deficiency, and identity spoofing. These threats require controls that LLM-focused frameworks don't address: tool scope limits, delegation policies, blast radius documentation.

MITRE ATLAS provides a tactics-and-techniques taxonomy for adversarial attacks on AI systems. Where OWASP names threat categories, ATLAS names specific adversarial techniques: model inversion, membership inference, evasion attacks, data poisoning. For high-assurance systems — those processing sensitive data or making consequential decisions — ATLAS mapping adds specificity that committee-level documentation benefits from.

MAESTRO is a threat modeling framework for multi-agent systems. It covers orchestrator-agent trust models, lateral movement between agents, supply chain risks in agent dependencies, and audit trail requirements for agent actions. For systems with more than one agent in the pipeline, MAESTRO mapping is required to capture threats that OWASP frameworks don't model.

NIST AI RMF (Govern, Map, Measure, Manage) provides the risk management lifecycle context. GOVERN covers policies and accountability. MAP covers context and risk identification. MEASURE covers analysis and prioritization. MANAGE covers response and monitoring. Drel maps each stage of the review to the corresponding RMF function, so the output is structured as an RMF artifact — useful for US federal and regulated sectors.

ISO 42001 is a management system standard for AI. Clause 6 covers planning and risk. Clause 8 covers operations and AI system lifecycle. Clause 9 covers performance evaluation. Drel maps the evidence pack output to clause 8.2 evidence requirements — what an auditor checking ISO 42001 conformance would expect to see for each assessed AI system.

EU AI Act Article 9 requires a risk management system for high-risk AI systems under Annex III. Article 9 specifies: a process for identifying and analyzing risks, risk mitigation measures, testing before deployment, and ongoing post-market monitoring. Drel maps the assessment output to Article 9 evidence requirements — the clearance decision is structured to satisfy Article 9(6)'s documentation obligation for the deployer.

The AI Committee — whatever form it takes in your organization — needs to make a decision: does this system go to production? The decision has legal weight (the DPO's file), operational weight (the security architect's control backlog), and governance weight (the CISO's sign-off). It should be backed by a document, not a meeting summary.

The clearance decision is one of five dispositions:

• Proceed — identified risks are within accepted thresholds, required controls are in place and evidenced. The system may deploy.
• Conditional proceed — identified risks are within thresholds but specific controls are required before or during production. Conditions are named explicitly and tracked.
• Restricted pilot only — the system may operate in a scoped pilot environment under named conditions (limited user set, no live data, specific tool restrictions) but may not move to production until conditions are met.
• Hold — critical control gaps exist that cannot be conditioned around. The system does not proceed until gaps are remediated and a re-review is conducted.
• Decline — the risk profile is incompatible with the organization's policy or legal constraints. The system does not proceed.

Beyond the disposition, the committee receives a control plan: the list of required controls with owners, timelines, and evidence requirements. This is not the committee's document — it is passed to the security architect — but the committee should see that it exists and that it is owned.

The committee also receives re-assessment triggers: the named conditions that require a new review. Adding a new tool. Changing the model. Expanding the data scope. Deploying to a new environment. These are not general reminders — they are specific, named events that automatically require re-assessment before the next change goes to production.

Finally, the committee receives a sign-off log: who reviewed the system, in what capacity, on what date, with what scope. This is the document the DPO keeps. When an incident occurs or a regulator asks about pre-deployment review, the sign-off log is the answer.

Most teams that conduct AI security reviews do so with good intentions and incomplete execution. The same five failure modes appear repeatedly.

1. Treating it as a one-time event. A security review covers the system as it exists at the point of review. The moment the system changes — new model, new prompt, new tool, new data source — the review is stale. Teams that conduct a single pre-launch review and then consider the system cleared are operating on an assumption that the AI system is frozen. AI systems are not frozen. They change constantly. Re-assessment triggers must be named and enforced.

2. Reviewing the demo, not the production config. The demo uses sample data. The production system uses personal data. The demo has no tools. The production agent has twelve. The demo was reviewed; the production system was not. This is the single most common form of incomplete review: the scope of what was actually assessed does not match the scope of what was deployed.

3. Signing off on slides, not a structured document. A slide deck summarising "key risks" is not a security review dossier. It has no risk register, no control plan, no evidence gaps list, no clearance decision with a scope statement. It cannot be defended in an audit. It cannot be referenced in a DPA. It is a communication artifact, not a governance artifact. The committee should be signing a document with an explicit scope and a dated clearance decision.

4. Not naming re-assessment triggers. A clearance decision without re-assessment triggers is a clearance decision that implicitly lasts forever. "We reviewed it last year" is not an answer to "has this system been reviewed since you added retrieval-augmented generation to it?" Re-assessment triggers must be explicit, enumerated, and owned by someone.

5. Confusing framework mapping with compliance certification. Mapping an AI system to OWASP LLM Top 10 and ISO 42001 does not make the system compliant with those frameworks. It means the system has been assessed against those frameworks' threat and control categories. Certification — in the sense of accreditation-backed attestation — is a separate process conducted by accredited third parties. Drel maps assessments to frameworks. It does not certify systems, attest controls, or guarantee any regulatory outcome. Any tool or team claiming otherwise is misrepresenting what a design-time review produces.