A Buyer's Guide to Third-party model risk

A vendor assessment covers security controls, certifications, financial stability, and data handling, and comes back clean. What it does not cover is that the vendor reserves the right to change the underlying model, may route your requests to a subprocessor's infrastructure, and can update behaviour without notice under terms you accepted. Six months later your evaluation results describe a model you are no longer using. The assessment was thorough about the company. The thing you depend on is the model, and the contract lets it change.

You assessed a supplier. What you actually depend on is a model they can replace.

Third-party model risk means assessing the vendor's right to change what you consume, the chain of parties involved, and your ability to detect and respond, rather than only their organisational controls.

The Architecture Layer That Decides If Your AI Product Survives Production

Build the architecture layers that make AI products production-ready.

Download Whitepaper

However, most assessments apply a standard supplier questionnaire, which asks about the company and never asks whether the model can be swapped underneath you.

If you are a CISO or VP Security at an enterprise, the intent of this article is:

Define why substitution rights are the central term
Show how subprocessor chains extend the exposure
Lay out what exit and continuity actually require

To do that, let's start with the basics.

What Is Third-Party Model Risk? The Basic Definition

At a high level, third-party model risk is the exposure created by depending on a model you do not control. Standard supplier assessment covers whether the vendor is a competent and secure organisation, which matters and is not the distinguishing risk. What distinguishes this category is that the artefact you depend on is mutable by the supplier, frequently without notice, and its behaviour is what your validation, your evaluation results, and your downstream controls were built around. The assessment therefore has to cover change rights, notification, and your ability to detect and respond.

To compare:

Assessing the vendor and not the substitution right is checking that a supplier runs a good factory while the contract lets them substitute the component. The factory is excellent. The part in your product may not be the one you tested.

Why Does Third-Party Model Risk Matter?

Issues that it addresses or resolves:

Models changing under contracts that permit it
Subprocessor chains extending the exposure invisibly
Evaluation results describing a superseded model

Resolved Issues by Assessment Done Well

Substitution rights understood and negotiated
Change notification obtained where possible
Detection in place where notification is not available

Core Components of Third-Party Model Risk Assessment

Substitution and update rights in the contract
Subprocessor chain with locations and roles
Change notification and deferral terms
Detection capability where notification is absent
Exit path and portability assessment

Modern Vendor Assessment Practice

Contract review focused on model change terms
Version pinning availability assessed
Behavioural monitoring for undeclared change
Subprocessor list with notification requirements
Portability tested rather than assumed

These practices address the real dependency. Behavioural monitoring for undeclared change is what covers the gap when notification is not on offer.

Other Core Issues They Will Solve

Validation remaining meaningful over time
Changes assessed before they affect decisions
Exit possible without a rebuild

In Summary: Third-party model risk is about the vendor's right to change what you consume, which a standard supplier assessment does not examine.

Importance of Third-Party Model Risk in 2026

Hosted models sit inside consequential systems. Four reasons explain why this matters now.

1. The dependency is mutable.

Unlike most software, the thing you consume can change without a version you chose.

2. Standard questionnaires miss it.

Supplier assessment templates ask about the organisation, not about substitution rights.

3. Subprocessor chains are long.

The vendor's own dependencies extend the exposure and can change independently.

4. Validation decays silently.

Evaluation results remain in the file while the model they describe is retired.

Traditional vs. Modern Vendor Assessment

Organisational controls vs. model change rights
Vendor only vs. full subprocessor chain
Notification assumed vs. contracted or detected
Exit theoretical vs. portability tested

In summary: A modern assessment asks what can change, how you find out, and what you do then.

Details About the Core Components of Third-Party Model Risk Assessment: What Are You Designing?

Let's go through each component.

1. Rights Layer

What the contract permits.

Rights decisions:

Substitution and update rights identified
Version pinning availability assessed
Deprecation notice periods captured

2. Chain Layer

Who else is involved.

Chain decisions:

Subprocessors listed with roles
Locations confirmed
Change notification required

3. Notification Layer

How you find out.

Notification decisions:

Contractual notice sought
Deferral rights negotiated where material
Communication channel defined

4. Detection Layer

When notice is absent.

Detection decisions:

Behavioural baselines maintained
Regression suites run continuously
Undeclared change surfaced

5. Exit Layer

Getting out.

Exit decisions:

Portability assessed concretely
Prompt and evaluation reusability tested
Switching cost estimated

Benefits Gained from Assessment Done Well

Model changes detected or notified
Validation that stays meaningful
Exit that is possible rather than nominal

How It All Works Together

The assessment reads the contract for what the vendor may change and on what notice, which is the term that distinguishes this risk from ordinary supplier risk, and establishes whether version pinning is available and for how long. The subprocessor chain is obtained with roles and locations, since the vendor's own dependencies extend the exposure and can change independently of anything you signed. Notification and deferral rights are negotiated where the deployment is consequential enough to justify it. Where notification is not on offer, behavioural baselines and continuously running regression suites provide detection instead, so an undeclared change surfaces rather than being discovered through a drifting metric. And the exit path is assessed concretely, including whether prompts and evaluation sets would transfer, because portability that has never been tested is an assumption.

Common Misconception

The vendor passed our third-party risk assessment, so the dependency is managed.

The assessment established that the vendor is a competent, secure, solvent organisation with acceptable data handling, all of which is worth knowing and none of which addresses the specific property that makes this dependency different. The artefact you consume is mutable by them. If the contract permits model updates without notice, then the system you validated can change on a Tuesday, your evaluation results stop describing what is running, and your first indication may be a shift in an operational metric weeks later. That is a contractual and detection question, and the questionnaire did not ask it.

Key Takeaway: The questionnaire assessed the organisation. The risk is that the artefact you consume is theirs to change.

Real-World Vendor Assessment in Action

Let's take a look at how it operates with a real-world example.

We worked with an enterprise whose model changed under a clean assessment, with these constraints:

Review the contract for substitution and update rights
Obtain the subprocessor chain with notification
Build detection where notification is unavailable

Step 1: Read the Change Terms

The distinguishing clause.

Substitution rights identified
Version pinning assessed
Deprecation notice captured

Step 2: Map the Chain

Beyond the vendor.

Subprocessors listed with roles
Locations confirmed
Notification required

Step 3: Negotiate Notice

Where material.

Contractual notice sought
Deferral rights where justified
Channel defined

Step 4: Build Detection

For the gap.

Behavioural baselines maintained
Regression suites running
Undeclared change surfaced

Step 5: Test the Exit

Concretely.

Portability assessed
Prompt and evaluation transfer tested
Switching cost estimated

Where It Works Well

Vendors offering version pinning and notice
Deployments with behavioural baselines available
Contracts open to negotiated terms

Where It Does Not Work Well

Standard supplier questionnaires used unmodified
Subprocessor chains left unexamined
Exit assumed rather than tested

Key Takeaway: Read the change terms, map the chain, negotiate notice, build detection, test the exit.

Common Pitfalls

i) Standard supplier questionnaires

They establish organisational competence and never ask whether the model can be replaced. Add the change rights review.

Clean assessment
Model changed
Evaluation described something retired

ii) Ignoring subprocessors

The vendor's dependencies can change independently and extend both the technical and jurisdictional exposure. Require the list and notification.

iii) Assuming notification

Many terms permit updates without notice. Where notice is not contractual, detection has to substitute for it.

iv) Untested exit

Portability that has never been exercised is an assumption, and switching cost is usually higher than expected. Test the transfer.

Takeaway from these lessons: The dependency is on a mutable artefact, and the assessment has to follow that.

Third-Party Model Risk Best Practices: What High-Performing Teams Do Differently

1. Review substitution and update rights explicitly

Treat the vendor's ability to change the model as the central assessment question.

2. Obtain the subprocessor chain with change notification

Prevent the exposure extending silently through parties you did not assess.

3. Negotiate notice and deferral where the deployment is consequential

Buy the ability to assess a change before it affects decisions.

4. Build behavioural detection for undeclared change

Cover the gap that unnotified updates leave.

5. Test the exit path rather than assuming portability

Establish switching cost concretely, including prompt and evaluation transfer.

Logiciel's value add is helping enterprises assess model vendors on change rights and detection, so validation and controls survive the vendor updating what you consume.

Takeaway for High-Performing Teams: Read change terms, map the chain, negotiate notice, detect undeclared change, test exit.

Signals You Are Doing This Well

How do you know it is working? Not by assessment completion, but by whether a silent model update would be caught. These are the signals that separate model risk from supplier risk.

Change rights are known. You can state what the vendor may alter.

The chain is mapped. Subprocessors and their roles are documented.

Notice exists or detection does. One of the two covers every dependency.

Validation stays current. Results describe what is actually running.

Exit is tested. Switching cost is measured rather than assumed.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Vendor assessment depends on, and feeds into, the surrounding estate. Ignoring the adjacencies is the most common scoping mistake.

Model risk management consumes the change detection. Data residency covers the subprocessor locations. Model routing and fallback provides the exit mechanism. Regulatory reporting needs the vendor inventory. Naming these adjacencies upfront keeps the work scoped and helps leadership see substitution rights as the question.

The common mistake is treating each adjacency as someone else's problem. The contract review is your problem. The detection is your problem. The exit test is your problem. Pretend otherwise and a clean assessment will cover a model you no longer use. Own the adjacencies you depend on, partner with the teams that hold them, and share the terms.

Conclusion

Standard third-party assessment establishes that a supplier is competent, secure, and solvent, which is worth knowing and misses what makes model vendors different. The artefact you depend on is theirs to change, frequently without notice under terms you accepted, and when it changes your validation results, evaluation sets, and downstream controls all describe something that is no longer running. Read the contract for substitution and update rights, obtain the subprocessor chain with change notification, negotiate notice and deferral where the deployment justifies it, build behavioural detection where notice is unavailable, and test the exit path rather than assuming portability.

Key Takeaways:

Supplier questionnaires assess the organisation, not the mutability of the artefact
Where notice is not contractual, detection has to substitute for it
Portability that has never been exercised is an assumption, not a plan

Assessing model vendors well requires following the dependency. When done correctly, it produces:

Model changes notified or detected
Validation that continues to describe what runs

Is Your Engineering Velocity Real, or Just a Reporting Illusion?

Discover whether your engineering velocity reflects real output or hidden inefficiency.