AI Vendor Assessment ToolA tier is an internal way to decide how much review and oversight a supplier needs for a particular use. Define criteria locally, connect each tier to an owner and actions, and revisit the tier when the service or context changes. These are governance choices, not official categories, legal classifications, or probabilities of harm.
Define local tier criteria
NIST SP 800-161 Rev. 1 Update 1 provides general supplier cybersecurity risk-management context. It does not prescribe AI vendor tiers or a tiering formula. Choose factors that can change the review decision and record why each factor matters. Useful prompts include data sensitivity, access and action authority, affected people, service dependence, model and subprocessor visibility, reversibility, and decision-relevant evidence gaps.
| Local tier | Example characteristics | Example review response |
|---|---|---|
| Bounded | Limited-purpose use, low-sensitivity data, no write access or consequential action, and a practical fallback | Name a business owner; confirm data use, access, retention, and exit for the approved scope |
| Material dependency | Recurring business-confidential data, important workflow reliance, integrations, or multiple downstream providers | Obtain scoped evidence; document change triggers and assign a monitoring owner |
| Heightened review | Sensitive or regulated data, broad or write access, consequential decisions, material impact on people, or difficult recovery | Use accountable cross-functional review; resolve or explicitly manage material unknowns before production |
These labels do not correspond to a regulator’s taxonomy. A local tier is not a risk probability, compliance score, or safety claim. If evidence is unknown, record the gap and decide whether to limit, defer, or condition the proposed use.
Onboard a vendor consistently
An AI vendor onboarding checklist should capture the provider, product version, intended purpose, business owner, users, affected people, and system boundary. Map inputs, outputs, telemetry, integrations, access, model providers, subprocessors, locations, retention, and training use. Collect evidence references with their scope and date; label evidence missing, partial, expired, or conflicting rather than implying it is complete.
- Apply the organization’s local tier criteria and route the review to business, privacy, security, legal, and technical owners as needed.
- Record the decision, approved scope, conditions, prohibited uses, accountable owner, review trigger, and next review date.
- Before production, confirm that contract terms and settings match the reviewed configuration.
A browser-local scorecard can organize vendor answers and follow-up flags. It does not verify claims, monitor a service continuously, or decide compliance. Keep an owner-controlled vendor register for ongoing work.
Monitor for material changes
AI vendor continuous monitoring means assigning people to watch for signals and act on them; a worksheet alone cannot provide it. Consider event-driven review when a change could invalidate assumptions behind the original decision. Signals may include a new model or subprocessor, different retention or training settings, broader permissions, a new integration, a changed intended purpose, an incident, a material outage, expired evidence, or a change in applicable law.
For each signal, define who receives it, what evidence is requested, who can pause or restrict use, and how the decision is recorded. Set periodic review intervals under local policy and tier criteria, but do not present an internal interval as a universal legal requirement. NIST AI RMF 1.0 describes voluntary lifecycle-oriented risk management. NIST SP 800-161 Rev. 1 Update 1 addresses cybersecurity supply-chain risk management, not AI legal classification.
Plan an annual review if your policy calls for one
An AI vendor annual review checklist can refresh the current use, product and model versions, data flow, access, subprocessors, evidence scope, open actions, incident history, and business dependency. Confirm that the service remains within its approved purpose, and ask owners to explain changes since the last review. An annual cycle is an internal example, not a universal statutory interval.
Track each item as, for example, current evidence reviewed, follow-up open, or unknown, with an owner and due date. Distinguish current evidence from vendor statements and assumptions. Do not turn missing information into a numerical likelihood or use a tier as a substitute for an accountable human decision.
Make vendor exit actionable
An AI vendor exit plan should fit the agreement, actual system configuration, and business continuity needs. Consider how the organization will stop new data flows; disable integrations, API credentials, service accounts, and vendor access; export records it needs to retain; and request return or deletion under the contract. Confirm how the agreement treats logs, support copies, backups, and applicable retention exceptions. Rotate shared credentials where needed, remove vendor-managed agents or workflows, document remaining dependencies, and assign an owner to close each step.
AI vendor offboarding is not complete merely because a subscription has ended. Record evidence of access revocation, data requests and responses, retained records and their owners, unresolved copies or exceptions, and the person accountable for closure. This operational list cannot guarantee that every copy has been deleted; use the agreement’s terms and applicable retention requirements.
Worked hypothetical example
A company approves a support assistant to draft replies from public help articles, with a human agent reviewing each reply. Under its local criteria, it records the use as “Bounded” and assigns an owner to confirm the limited data and access. Months later, the vendor proposes connecting the assistant to customer complaint records and adding a model subprocessor. The owner records retention and data-use details as unknown and reopens the tier decision. Privacy and security reviewers request the new data-flow and contract details; the company pauses the expanded connection while documenting the original limited use separately. Leadership decides whether and under what conditions to expand. This is a hypothetical internal governance workflow, not a compliance score or risk prediction.
Frequently asked questions
Are these tiers official risk categories?
No. They are illustrative local labels. Define and document criteria that fit the organization’s uses and responsibilities.
Does a scorecard provide continuous monitoring?
No. Monitoring requires an owner, signals, evidence requests, escalation and pause authority, and a recorded follow-up process.
Is annual review required for every AI vendor?
This page does not establish a universal interval. Follow applicable requirements and local policy, and add event-driven reviews when important assumptions change.
Can an exit checklist prove deletion?
No. Record the request, vendor response, contractual scope, exceptions, evidence, and unresolved copies; confirm what the agreement and applicable rules require.
For a point-in-time worksheet, see the AI Vendor Risk Scorecard. Pair it with the AI Vendor Assessment Questionnaire and the AI Vendor Risk by Industry guide. The scorecard does not replace ongoing monitoring.
Updated 2026-10-08. Sources are linked on this page.
Use an AI vendor risk tiering template consistently
An AI vendor risk tiering template should record intended use, sensitivity, action authority, dependency scope and the reason for an internal review tier. Describe what evidence would change the tier and who owns that reassessment. A tier is a review convention; it is not a calibrated probability or certification.