Re-assessment triggers — the field most dispositions skip

AI systems do not stay static. Models are updated. Scope expands. Incidents occur. Data handling terms change. Each of these changes can alter the risk profile in ways the original assessment did not anticipate. Without re-assessment triggers, there is no mechanism to detect when a change makes the original disposition stale.

The triggers serve a second function: they define the governance organisation's commitment to keeping assessments current. A disposition with no triggers implies that the review was a one-time exercise with indefinite validity. A disposition with specific triggers implies that the review is valid under defined conditions — and that the organisation will re-evaluate when those conditions change.

Four standard triggers apply to every AI system disposition, regardless of the system's specific risk profile:

Model change. Any change to the AI model that powers the system — base model update, major version upgrade, model provider change, or significant fine-tuning change. Model changes alter capability boundaries, failure modes, and alignment properties. The assessment must be evaluated against the new model.

Scope expansion.Any expansion of the system's operational scope beyond what was assessed — new user populations, new data classes, new use cases, new system integrations. The original assessment applies only to the assessed scope; expansions require their own evaluation.

Incident. Any security or AI incident involving the system that may reflect control failures, model misalignment, or unanticipated failure modes. An incident may reveal that the threat model was incomplete or that controls that were assessed as adequate are not functioning as designed.

Control gap discovery. Discovery that a control listed as in place in the control plan was not actually in place, or has ceased to be in place. Control gap discovery invalidates the portion of the disposition that depended on that control being present.

In addition to the four standard triggers, each AI system should have system-specific triggers that reflect the particular risk profile identified in the threat model. System-specific triggers are derived from the threat model during the assessment — they are the changes that would materially alter the residual risk for this specific system.

Examples of system-specific triggers by system type:

• Customer-facing AI assistant:Any expansion of the model's tool manifest (capabilities granted to the model); any change to the data sources the model retrieves from; any change to the human review process for model outputs.
• Internal HR AI tool: Any expansion to new data classes (medical, disciplinary, or financial data) beyond the assessed scope; any change to the user population with access; any integration with performance management systems.
• Code generation AI: Any expansion to production code deployment pipelines; any change to the human code review requirement; any expansion to security-critical code domains.
• Vendor AI product:Vendor notification of a material model change; changes to the vendor's data processing terms; vendor security incidents affecting the product.

Triggers must be specific enough to be actionable — a person reviewing the system's status must be able to determine unambiguously whether a trigger has fired.

“Any significant change to the system” is not a trigger. It is a description of the category of events that should be triggers. Every instance of a “significant change” trigger requires a human judgment call about whether the change is significant. Specific triggers make that judgment call at assessment time, when the risk profile is freshest, not at event time.

How to write a specific trigger: identify the specific event, state, or condition that fires the trigger. Not “significant changes to data handling” — but “any change to inference data retention period by the model provider” or “any addition of customer PII to the prompt template.” The trigger should be binary: either the event occurred or it did not.

When a trigger fires, it initiates an evaluation — not automatically a full re-assessment. The evaluation determines whether the fired trigger is material: whether it changes the risk profile in ways the existing disposition does not address.

The evaluation has four outcomes:

1. Non-material: The trigger fired but the change does not alter the risk profile. The governance record is updated with the trigger event, the evaluation, and the conclusion.
2. Scoped review required: The change materially alters one area of the risk profile but not others. A scoped review is conducted focused on the affected area.
3. Full re-assessment required: The change materially alters the overall risk profile. The disposition is suspended pending full re-assessment.
4. Urgent disposition hold: The trigger reflects a situation where continued operation presents immediate risk. The system is placed on hold pending emergency committee review.

The trigger evaluation should be conducted by the assessment owner — typically the CISO or security architect who conducted the original assessment. The evaluation must be documented, not just decided.

Every trigger event — fired or evaluated as non-material — must be recorded in the governance record. The record for each trigger event should contain:

• The trigger that fired (by reference to the trigger defined in the disposition).
• The date the trigger fired and how it was detected.
• The evaluation: what was assessed, who conducted the assessment, what the finding was.
• The outcome: non-material, scoped review, full re-assessment, or disposition hold.
• If a review was conducted: the scope, findings, and updated disposition.

This record creates a traceable history of the system's governance lifecycle — not just the initial approval but all the changes and evaluations that occurred during the system's operational life.

The most common re-assessment trigger failures in practice:

• No triggers at all. The most common failure: the disposition has no re-assessment triggers. The review is treated as permanently valid.
• Only standard triggers. Standard triggers are listed but no system-specific triggers are defined. This misses the changes that are specifically material for this system.
• Triggers but no evaluation process. Triggers are listed in the disposition but there is no defined process for evaluating whether a fired trigger is material. Triggers fire but no evaluation happens.
• Trigger events not recorded. Changes that would fire a trigger occur but are not evaluated because no one is monitoring for trigger events. The monitoring responsibility must be assigned.

For the broader structure of the governance record in which triggers are documented, see What makes an AI decision record defensible.