The vendors most likely to cause a problem are not the ones you are onboarding. They are the ones you cleared eighteen months ago, filed, and have not looked at since. Onboarding gets scrutiny; the standing vendor base gets a calendar reminder once a year, if that. And in the gap between reviews, the thing you assessed has changed.
The fix is not to review every vendor more often - that does not scale, and most reviews would find nothing. The fix is to reassess on the right triggers: the specific events that mean a vendor is no longer the risk you signed off.
Why the calendar is the wrong schedule
Annual review assumes risk changes at a steady, predictable rate. For a vendor adding AI, it does not: risk does not drift gently between reviews, it jumps on a specific day when something changes - a feature switches on, a model is swapped, the terms are rewritten.
So a yearly cycle is always looking at the wrong time. It re-checks vendors that have not changed and misses the ones that changed the day after their last review. Reassessment should follow the changes, not the calendar - which means knowing which changes count.
The triggers that should re-open a review
A reassessment trigger is an event that could have changed a vendor's risk enough that the assessment on file no longer describes it. Five are worth building into a programme, because each is common and each is the kind of change a yearly cycle routinely misses.
The first is a new AI feature. When a vendor switches on AI in a tool you already use, the tool starts doing something the original assessment never examined - processing your data through a model, generating outputs that affect decisions, possibly training on what flows through it. A new feature is a new risk, even inside an old vendor.
The second is a model change. A vendor that swaps the model behind an existing feature - a new version, a different provider, significant retraining - has changed how your data is handled and where it goes, even though nothing you can see from the outside has moved.
The third is a change of terms. When a vendor revises its data-processing terms, its privacy policy, or its sub-processor list, the contractual basis your original assessment relied on may no longer be the one in force. Terms changes are easy to miss because they arrive as an email nobody reads, not as an event anyone logs.
The fourth is expanded use. Sometimes the vendor has not changed at all - you have. When your organisation starts using an existing tool for something new, or feeds it more sensitive data than before, the risk rises even if the vendor is identical. The assessment was scoped to the old use; the new use is unassessed.
The fifth is an incident. A vendor's security breach, an AI-behaviour failure, or a regulatory action against its product all signal that the original assessment's conclusions may not hold. An incident is the one trigger most programmes do act on - but usually only for the vendor directly involved, not for the assessment assumptions it calls into question.
Not every trigger means a full reassessment
Reacting to all five triggers with a full re-review would recreate the scaling problem the calendar caused. The point of triggers is proportionality: a trigger opens an evaluation, and the evaluation decides how much reassessment the change actually warrants.
The first question on any trigger is whether the change is material - whether it plausibly alters the risk in a way the existing assessment did not cover. A minor version bump that changes nothing about data handling can be logged and closed with a note; a model swap that moves your data to a new sub-processor cannot.
Most triggers resolve to a short, scoped check focused on exactly what changed; only a few warrant reopening the whole assessment. The discipline is having a defined way to make that call, rather than either ignoring the trigger or over-reacting to it.
Prioritise by what you cannot operate without
Triggers tell you when to look; risk tiering tells you where to look hardest. Not every vendor deserves the same vigilance, and pretending they do is how the important ones get lost in the noise.
The vendors that matter most are the ones supporting functions you could not run without, the systems whose failure would stop you serving customers or meeting obligations.
Those deserve continuous attention: their triggers should be watched actively, not waited for. Lower-tier vendors can be handled more lightly, on a longer cycle, because the cost of a missed change is smaller. Tiering is what makes trigger-based reassessment affordable - it concentrates the effort where a missed change would actually hurt.
The part that makes this hard: you have to see the trigger
Here is the catch that decides whether any of this works. Trigger-based reassessment only fires if you know the trigger happened, and most of these triggers arrive silently.
A vendor switching on an AI feature does not send a notice. A model swap behind an existing feature is invisible from your side. A sub-processor added to a list is not announced.
So the reassessment programme depends on something upstream of it: a way to detect that a vendor has changed, rather than waiting to be told. Contract clauses requiring notification of material changes help, and are worth having, but they cover only what the vendor recognises and chooses to report.
The harder half is seeing the changes the vendor does not flag - a discovery problem, and the reason a reassessment process without discovery underneath it ends up reacting only to the changes that happened to be visible.
None of this replaces the annual review entirely; a periodic full check still has its place as a backstop. But it stops being the main mechanism. The main mechanism becomes the triggers - watched most closely on the vendors you cannot do without, and detected rather than waited for.
Frequently asked questions
When should you reassess a third-party vendor?
Montro's position is that you reassess on triggers, not only on a calendar. The main triggers are a new AI feature in an existing tool, a change to the underlying model, a change to the vendor's data terms or sub-processors, an expansion in how your organisation uses the tool, and a vendor security or AI-behaviour incident.
Each signals that the assessment on file may no longer describe the vendor, and each is the kind of change an annual cycle routinely misses.
Does a vendor adding an AI feature require reassessment?
Usually yes, at least a scoped one. When a vendor switches on AI in a tool you already use, it begins processing data through a model in ways the original assessment never examined - new data flows, new outputs, and possibly training on the data passing through. The scope of the reassessment depends on how the feature handles your data, but the feature should trigger an evaluation rather than pass unnoticed until the next scheduled review.
How often should third-party vendors be reviewed?
There is no single interval, because the right answer is "when something material changes," not a fixed frequency. Critical vendors - those supporting functions you could not operate without, warrant continuous attention to their triggers; lower-risk vendors can be handled on a longer cycle. A periodic full review still has value as a backstop, but for vendors adding AI it cannot be the primary mechanism, because material changes do not wait for the review date.
What is a material change for a vendor?
A material change is one that plausibly alters a vendor's risk in a way the existing assessment did not account for - a model swap that moves data to a new sub-processor, a terms change that alters the contractual basis, a new AI feature that processes sensitive data. Not every change is material: a minor update that leaves data handling untouched can be logged and closed. The discipline is having a defined way to judge materiality when a trigger fires, rather than treating every change, or no change, as significant.
