When to run an AI security review — the four trigger points

A disposition memo produced at initial deployment is a snapshot. It captures the system as it was at the time of review: the model, the data sources, the tool manifest, the user population, the deployment context. Every one of those can change after go-live. Some changes are cosmetic. Others alter the risk profile substantially enough that the original clearance decision no longer applies to the system as it now exists.

Without defined trigger points, teams default to one of two failure modes. The first is re-reviewing everything on a calendar schedule regardless of what changed — expensive and not risk-proportionate. The second is never re-reviewing unless forced — which means systems accumulate drift against their clearance record until an incident or an auditor forces the issue.

Trigger-based re-assessment is not a workaround for a weaker process. It is the correct process. The question “has anything changed that would alter the clearance decision?” is more useful than “have 12 months elapsed?”

The four triggers below cover the events that materially change the assessed system. They are not exhaustive — your governance framework may add others — but they cover the vast majority of cases where an existing clearance becomes insufficient.

Every AI system entering production for the first time requires a review. This is the baseline trigger and the one most teams already handle, at least informally. What matters here is not just that a review happened, but that it produced a defensible record before the system went live — not after.

“Initial deployment” applies not just to systems built in-house but to any AI capability your organisation begins operating. A SaaS product with an AI feature you have enabled. A third-party agent you have connected to internal systems via an API. A model accessed through a vendor’s API that your product team is now using in a customer-facing workflow. If your organisation is accountable for the outcome of the AI system — if you are the data controller, the service operator, or the entity named in the contract — then you need a clearance decision before it goes live.

The review threshold for initial deployment is the go-live decision. The question is: does this system meet the bar to operate in the stated deployment context, and under what conditions? The answer — proceed, conditional, restricted pilot, hold, or decline — is the clearance decision. It must be written down.

Changing the model that powers an AI system is one of the most frequently underestimated triggers. Teams treat it as a configuration change — update a variable, redeploy, done. From a security standpoint, it is closer to replacing a core component of the system.

What counts as a significant model change that triggers a review?

• Switching model family. Moving from one model provider to another, or from one base model to another within the same provider. Different training data, different capability profile, different alignment properties.
• Moving from base to fine-tuned. A fine-tuned model has been trained on additional data that can shift its output distribution, introduce memorisation of that training data, or alter its compliance with safety instructions.
• Significant version upgrade. Moving from one major version to another of the same model family. Minor point releases may not require a full review, but a version upgrade that is documented by the provider as introducing changed behaviour — including changed refusal patterns, changed tool-call behaviour, or changed instruction-following — does.
• Changing inference configuration materially. Removing a system prompt that contained safety constraints. Substantially raising the temperature or removing sampling restrictions that bounded output variability.

What generally does not trigger a full review: a minor version patch that the provider describes as a performance or stability fix with no behaviour changes; adjusting generation parameters within a previously reviewed range.

Most AI systems start narrower than they end up. A system that was piloted with internal users gets opened to customers. A tool that handled read-only queries is given the ability to write. A workflow scoped to one department expands to the whole organisation. Each of these is a scope expansion that may require a new review — not because the underlying technology changed, but because the risk profile of the deployment context changed.

Scope expansions that typically trigger a review:

• User population expansion. Moving from internal to external users, or from a pilot group to the full user base. The threat surface changes when adversarial users can reach the system.
• Adding write or action capabilities. A system that could only read and report is given the ability to send, create, update, or delete. Blast radius increases qualitatively.
• Adding access to sensitive data classes. The system gains access to a data source it previously did not — personal data, financial records, health information, privileged credentials.
• Integration with additional external systems. An agent that previously operated within a single system is now connected to external services, adding supply-chain risk and new tool-call surfaces.
• Regulatory reclassification. The deployment context changes in a way that triggers a higher-risk classification under the EU AI Act, HIPAA, or another applicable framework.

A clearance decision is specific to the deployment context it was issued for. “Cleared for internal pilot” does not mean “cleared for external customers”. These are different deployments and must be assessed separately.

When an AI system is involved in a security incident — or when an incident reveals that a control assumed to be in place was absent or ineffective — a review is required. The question the review must answer is different from the initial deployment question. It is not “should this system deploy?” but “is the existing clearance decision still valid given what we now know?”

What qualifies as an incident that triggers a review:

• Security incident involving the AI system. Any incident where the AI system was in the attack path, the exfiltration channel, or the affected surface.
• Control gap discovered. A control listed in the disposition as required is found to be absent, misconfigured, or ineffective. The clearance was issued on the assumption that this control existed. That assumption is now false.
• Model provider safety disclosure. The model provider discloses a vulnerability, a jailbreak class, or a safety degradation that applies to the version in use.
• Unexpected output pattern at scale. The system is producing outputs that were not anticipated in the threat model and that have downstream harm potential — even if no security incident has yet occurred.

Not every change is a trigger. The question is whether the change materially alters the risk profile that the original clearance decision was based on. A useful framing: if the reviewer who signed off the original disposition were shown the change, would they consider the system they reviewed and the system that now exists to be the same system for security purposes?

Materiality is context-dependent. A change that is cosmetic for a low-risk internal tool may be significant for a customer-facing system handling sensitive data. The disposition record should include the re-assessment triggers that were agreed at the time of review — specific enough to be unambiguous when they fire. Vague triggers like “any significant change” are not useful because they require interpretation at the moment they matter most.

Examples of specific, unambiguous trigger formulations:

• “Model family changes from the assessed provider.”
• “User population expands beyond the internal HR department.”
• “Any tool that enables write operations is added to the tool manifest.”
• “System is integrated with a data source outside the assessed data classification boundary.”
• “A security incident involves the system as an attack surface or exfiltration channel.”

When a trigger fires, the system enters a pending re-assessment state. It may continue to operate under the existing clearance if the trigger is assessed as not materially changing the risk profile — but that assessment itself must be documented. “We evaluated the trigger and concluded the clearance remains valid because…” is a valid outcome. Silently ignoring the trigger is not.

Every trigger event, and the decision about how to respond to it, should appear in the governance record for the system. This is not a heavyweight requirement. It means that when an auditor, a regulator, or a post-incident investigator asks “when did the model change, and was the clearance reviewed at that point?” there is a written answer.

The governance record for a trigger event should include:

• The trigger that fired, with a date.
• The decision: full review required, or change assessed as non-material (with reasoning).
• If a review was conducted: a link to the updated disposition.
• If the change was assessed as non-material: the name and role of the person who made that assessment.

Drel tracks trigger state and re-assessment history as part of every assessment record. Each disposition includes the triggers that were registered at the time of review, and each trigger event produces an entry in the disposition history. The clearance at any point in time is the most recent disposition that has not been superseded by a trigger.

If your team is establishing this process for the first time, start with the four triggers in this piece and define the specific conditions that fire each one for your systems. Document them in the disposition memo at initial review. That single step substantially closes the governance gap between “we approved it once” and “we have a defensible record of every clearance decision we have made.”