They need explicit material-change criteria tied to data handling, access scope, model behaviour, and control effectiveness. If a new AI feature changes any of those elements, it should trigger reassessment. Without those thresholds, teams either miss meaningful risk changes or waste time re-reviewing harmless updates.
When does a vendor change require re-review?
Teams should treat re-review as a change-control decision, not a calendar exercise. The real test is whether the vendor update changes the risk profile that was originally approved. Material changes usually show up in how data is handled, what access the vendor now has, how the system behaves, or whether existing controls still work as expected.
That means the trigger is not “new version” by itself. A harmless UI tweak does not deserve the same treatment as a feature that starts retaining prompts, expands API access, introduces a new subcontractor, or changes where sensitive data is processed. The goal is to re-open review only when the update changes the security assumptions the team relied on.
What counts as a material change in practice?
Material change criteria should be explicit and easy to apply. The most useful ones are:
- data scope changes, such as new data types, new retention, new training use, or new cross-border processing
- access scope changes, such as broader permissions, new integrations, new delegated access, or new admin paths
- behaviour changes, such as a new AI feature, new automation, or altered decision logic that affects outputs or actions
- control changes, such as weakened logging, reduced auditability, changed encryption, or less effective isolation
- dependency changes, such as a new subprocess, subprocessor, model provider, or critical upstream service
For vendor management, the key question is whether the change affects confidentiality, integrity, availability, accountability, or compliance obligations. If it does, the change is material even if the vendor describes it as an enhancement. If it does not, teams can usually record the update and move on without reopening the full review.
For AI-enabled vendors, model behaviour deserves particular attention. A feature that changes what the system can infer, decide, generate, or act on can alter business risk even when the underlying UI or contract looks unchanged. That is why security review should focus on effect, not just product category.
How teams decide whether to reopen the review
A practical decision rule is to ask whether the update changes either the exposure or the control assumptions behind the approval. If the answer is yes, re-review. If the answer is no, the change can often be logged as non-material and monitored.
Security teams usually get better results when they use a short triage sequence: first screen the vendor notice, then compare it with the original approved scope, then confirm whether any new data path, access path, or processing path has been introduced. That prevents both extremes, missing a meaningful change and over-reviewing routine releases.
The strongest programs also define ownership. Procurement, legal, security, and the business owner should know who decides that a vendor update crosses the threshold. Without that assignment, teams tend to delay action until an incident, audit, or customer complaint forces the question.
Risk and Threat Considerations
Vendor change can quietly widen attack surface or invalidate earlier risk decisions. The most common failure mode is assuming that a vendor is “the same product” when its data flows, access paths, or automation have materially changed, which can leave the organisation exposed to privacy, privilege, or supply-chain risk.
Failure mechanism: A new feature, integration, or policy change expands what the vendor can access, store, infer, or delegate, while existing approvals still reflect the old operating model.
Impact: Security teams may miss a new high-risk condition, such as broader data exposure, privilege creep, weaker control effectiveness, or a compliance gap that should have been re-assessed before rollout.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Vendor change review depends on explicit risk thresholds and reassessment triggers. |
| Recommendation — Define material-change thresholds and re-review when vendor updates alter approved risk assumptions. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Vendor updates can change service terms, dependencies, and control expectations for external services. |
| CM-3 — Configuration Change Control | The question is about deciding when changes require formal review before acceptance. | |
| RA-3 — Risk Assessment | Material vendor updates require renewed assessment of changed exposure and impact. | |
| Recommendation — Reassess external service risk when a vendor changes data handling, access, or control terms. Use formal change criteria to route material vendor updates back through security review. Re-run risk assessment whenever a vendor change affects data, access, or control effectiveness. | ||
| ISO/IEC 27001:2022 | A.5.21 — Managing information security in the ICT supply chain | Vendor change review is a supply-chain governance control over security-impacting updates. |
| Recommendation — Treat vendor changes as supply-chain events and re-evaluate security impact before acceptance. | ||
| SOC 2 (AICPA) | CC8.1 — Change Management | Vendor changes should be controlled and assessed when they affect the service environment. |
| Recommendation — Require documented change review for vendor updates that alter service behaviour or control coverage. | ||
Practitioner Guidance
What to verify: Require vendors to describe changes in data categories, access permissions, subprocessors, model behaviour, logging, retention, and control ownership in plain language. If they cannot state what changed, treat that as a review signal in itself.
Decision rule: If the change alters what the vendor can see, store, infer, or do, re-review immediately. If it only changes presentation or workflow convenience without changing the underlying security assumptions, record it and monitor for drift.
What good looks like: Teams maintain a short material-change checklist tied to the original approval record, with clear thresholds for security, privacy, and AI behaviour changes. The result is fewer unnecessary reviews and faster escalation when the risk genuinely moves.
Practitioner takeaway: The best threshold is not “did the vendor change?” but “did the change alter the assumptions that justified trusting the vendor last time?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org