What an AI security review actually is (and what it is not)

An AI security review is a design-time assessment. It is conducted before or during deployment, against the system's documented architecture, configuration, and stated operational context — not against live telemetry from a running system.

Its output is a structured record: a risk disposition that captures the decision, the rationale, the controls that are required, the residual risk that has been accepted, the evidence gaps that remain, and the conditions under which the decision must be revisited.

An AI security review is not a one-time pass/fail. It is a documented decision that stays valid as long as the system stays within the scope of the assessment — and triggers a re-review when it does not.

The assessment covers the AI system as a whole: the model, the architecture around it, the data flows into and out of it, the tools and integrations connected to it, and the human processes that govern it.

Four things are frequently confused with an AI security review.

A penetration test asks whether the system can be exploited by an active attacker. An AI security review asks whether the system should be deployed at all, and under what conditions. A pentest is valuable and complementary — but it addresses a narrower question.

A compliance audit checks whether controls are in place against a specific framework. A security review is the evidence-generating process that makes a compliance audit possible. Without the review, there is no evidence to audit.

A threat model is one component of a security review, not the review itself. A threat model identifies what could go wrong. The review adds: which of those threats applies to this system in its actual deployment context, what controls address each threat, and whether the residual risk is acceptable.

Runtime monitoring observes a system in production for anomalous behaviour. An AI security review happens before production. The two are complementary: the review defines what should be in place before the system goes live; monitoring detects when something changes after it does.

The primary output of an AI security review is a risk disposition — a structured decision record with seven components:

1. Decision — proceed, conditional, restricted pilot, hold, or decline.
2. Rationale — why, in plain language, with the headline risk and mitigation named.
3. Required controls — what must be in place, by lifecycle gate, with owner and verification method.
4. Residual risk — what is being accepted, by whom, under what condition.
5. Evidence gaps — what is not yet known and how it will be closed.
6. Re-assessment triggers — what changes invalidate this decision.
7. Sign-off log — who approved, in what role, and when.

Supporting the disposition are the intermediate artefacts the review produces: the threat model, the control plan, the framework mapping, and the evidence pack that bundles everything for committee review or audit.

See the Drel demo dossier for a worked example of what this looks like in practice.

An AI security review runs at four points in an AI system's lifecycle:

• Before initial deployment — the primary gate. The review must be complete before the system reaches production users.
• After a significant model change — when the base model is updated, the fine-tuned model is replaced, or the model provider changes. These changes can invalidate the assumptions the original review was based on.
• After a significant scope expansion — when the system is extended to new use cases, new user populations, new data classes, or new integrations.
• After an incident — when the system has behaved in a way that suggests the risk model was wrong or the controls were insufficient.

The re-assessment triggers in the disposition record define which of these events apply to a specific system.

An AI security review involves several roles, each responsible for a different part of the process.

The system owner or AI architect provides the system description: what it does, how it is built, what data it processes, what tools it uses. Without an accurate system description, the threat model is fiction.

The security team runs the threat model and control plan. They identify the threats that apply to this system in its actual context, define the controls that address each threat, and assess the residual risk.

The AI governance lead or committee frames the disposition — the decision, the rationale, the residual risk acceptance. They are accountable for the decision.

The DPO reviews data flows, data retention, and automated decision-making obligations, particularly for systems processing personal data.

The sign-off role — CISO, Head of AI, or the committee collectively — accepts the risk disposition on behalf of the organisation.

An AI security review, when properly executed, produces the evidence that multiple governance frameworks require.

ISO/IEC 42001 requires a documented risk management process with risk treatment records. The review's control plan and disposition record are that process.

EU AI Act Article 9 requires a risk management system with documented risk identification, evaluation, and treatment. The review maps to this directly.

NIST AI RMF Map and Manage functions describe what a security review does — without prescribing a specific format. The disposition record is the primary artefact for both functions.

OWASP LLM / Agentic Top 10 provide the threat taxonomy. A complete AI security review maps each applicable threat to the controls that close it.

A well-constructed review does not need to be repeated for each framework. The evidence is produced once and mapped to each framework's requirements. See the Drel AI security review hub for the full framework mapping.

The purpose of an AI security review is not to produce a document. It is to enable a defensible decision — one that can be explained to a regulator, an auditor, a customer's procurement team, or your own leadership after the fact.

The question a review answers is: should this AI system operate in production, and if so, under what conditions, with what controls, and with what re-assessment commitments? Without a review, that question is answered implicitly — by the teams who deploy the system without a governance record.

The review makes the decision explicit. That is what makes it defensible.