AEGIS · AEGIS Shield
Artifact 2.2
Vendor & Tool Risk Assessment
The six-domain assessment every AI vendor passes before it goes on the approved list — and is re-assessed at every contract renewal. Questions with the specific evidence we accept, and the red flags that stop the conversation.
- Client
- [CLIENT NAME]
- Engagement
- [ENGAGEMENT ID]
- Version
- v1.0
- Issued
- 2026-05-18
Delivered by TechFides under the AEGIS Governance Operating Services engagement. This document is proprietary to the client named above. Redistribution beyond the engagement steering committee requires written consent.
Purpose
Intent — Move vendor review from checkbox to diligence. This assessment is the tool that turns a procurement conversation into a governance decision.
This assessment is required for every AI vendor before it is added to the approved tools list in the AUP (§1.1), and again at every contract renewal. Its questions are framed to elicit evidence — not reassurance — and are tagged with the specific red flags that, when observed, should stop the engagement or escalate it to the Council.
When This Assessment Runs
Intent — Stating triggers explicitly is how you prevent the assessment from becoming a one-time gate.
- Before adoption. Any new AI tool proposed for the approved list. Procurement cannot issue a PO without a completed VRA signed by the AI Governance Lead and CISO.
- At renewal. Every existing approved vendor at contract renewal, with a lightweight delta review for materially unchanged vendors.
- On material change. When a vendor notifies of a subprocessor change, a model swap, a change in data residency, or a material security event. Material-change VRAs are completed within 15 business days.
- Ad hoc. When an incident, regulatory inquiry, or client audit surfaces a concern about a specific vendor.
Six Assessment Domains
Intent — The full questionnaire. Every domain has a primary intent; every question has the evidence we expect and the red flags that should trigger escalation.
Model & Training Data
Intent — Understand what the model is, what it was trained on, and how changes are communicated.
Identify every model that will be used to serve our account, including provider, base model, version, and any fine-tuning or retrieval layers.
What we look for — A concrete list — not marketing names. If the answer is 'we use the best model available', you have no contract.
Red flags
- Vague 'proprietary model' language without a base provider named.
- Model selection advertised as automatic, with no change notification.
What was the model trained on, and can you attest in writing that our prompts and outputs are not used to train current or future models?
What we look for — A written attestation with scope (applies to our tenant, all tiers) and duration (binding for the contract term).
Red flags
- Training exclusion is opt-in rather than default.
- Attestation silent on fine-tuning, evaluation, or support review workflows.
How do you notify customers of model version changes, and what is the minimum notice?
What we look for — Notice in days, with an ability to pin to a version for regulated use. Best-in-class: 30+ days for material changes, with changelog detail.
Red flags
- Changes communicated via blog post only.
- No version-pinning option.
Data Handling & Retention
Intent — Verify what happens to our data end to end. This is the domain that most often hides risk.
Describe the full data lifecycle: ingestion, processing, storage, logging, deletion. Where does data rest, and for how long?
What we look for — A diagram or table with specific retention windows per artifact. Zero-retention options documented per tier.
Red flags
- Retention stated as 'industry standard' without a number.
- Support agents have unrestricted access to prompts and outputs.
Can data be processed within specified geographic regions, and do you bind the region to our tenant contractually?
What we look for — Named data residency with a contractual commitment, not best-effort.
Red flags
- Residency determined by performance routing and can change.
- Support and logs fall outside the residency commitment.
List every subprocessor — including downstream inference providers and observability vendors — and your notification process for subprocessor changes.
What we look for — A current subprocessor list, and a 15+ day notification window with our right to object.
Red flags
- No subprocessor list provided.
- Subprocessor changes are one-sided; we have no objection right.
On termination, what is your data deletion commitment, within what timeline, and how is deletion evidenced?
What we look for — Written commitment with a specific timeline (e.g., 30 days) and a deletion certificate on request.
Red flags
- Deletion stated as 'per our standard practice' without a certificate.
Security & Access
Intent — Standard security hygiene plus AI-specific controls.
Provide your most recent SOC 2 Type II report, ISO 27001 certificate, and any other relevant attestations (HIPAA, PCI, FedRAMP, ISO 42001).
What we look for — Current (within 12 months) reports under NDA, with scope matching the services we will consume.
Red flags
- Reports are over 18 months old.
- Scope of the report excludes the services we plan to use.
Describe the tenant isolation model. Can users from another tenant — through a prompt injection, shared embedding, or system prompt leak — observe our content?
What we look for — Logical tenant isolation with named controls; best-in-class: dedicated inference or region-partitioned embeddings for regulated customers.
Red flags
- Shared vector stores across customers without documented partitioning.
- System prompts visible across tenants.
How are administrative and support personnel identified, authenticated, and logged when accessing tenant data — including prompts and outputs?
What we look for — SSO, MFA, just-in-time access with approvals, full audit logs exportable to our SIEM on request.
Red flags
- Standing support access with no customer-visible log.
- Shared support credentials.
Legal & Regulatory
Intent — Contractual commitments and the vendor's regulatory posture relative to ours.
Provide your Data Processing Agreement, Business Associate Agreement (if applicable), and AI-specific addendum.
What we look for — Executable templates matched to our regulatory profile. For HIPAA, a signed BAA before any PHI flows.
Red flags
- No AI addendum offered.
- BAA exists but carves out AI-related processing.
For customers with EU AI Act obligations, do you provide the documentation needed for our compliance — and under what commercial model?
What we look for — Documentation provided at no extra cost for covered obligations; clear statement of responsibility split.
Red flags
- Compliance documentation behind a premium tier.
- Vendor disclaims all regulatory responsibility.
Describe your IP indemnification for model output, including any carve-outs for fine-tuning, RAG, or customer-provided prompts.
What we look for — Meaningful indemnification with caps disclosed; clear rules for staying within the indemnified path.
Red flags
- No indemnification offered.
- Indemnification so narrow it effectively never applies.
Operational Reliability
Intent — What happens when the vendor has an outage, a bug, or a silent model change.
Provide your uptime commitment, credit structure, and historical uptime for the past 12 months with incident summaries.
What we look for — Specific SLA with credit model; historical data with root-cause narratives.
Red flags
- No SLA.
- Historical data presented as percentages only, with no incident list.
How will our team be notified of outages, degraded performance, and model behavior regressions? Through what channel, within what time?
What we look for — Status page, API-queryable, plus proactive email within 15 minutes of incident detection.
Red flags
- Notifications are best-effort Twitter posts.
- No API-queryable status.
Describe the kill switch or override we have if a model version change degrades our production workflow.
What we look for — Ability to pin to a prior version for at least 30 days, or revert via API.
Red flags
- No customer-side rollback option.
Exit & Portability
Intent — Plan the departure at onboarding, not at renewal.
Describe the export format for all tenant data — prompts, outputs, embeddings, fine-tunes, telemetry — and the timeline to produce a full export on request.
What we look for — Standard formats (JSON, CSV, documented schema) with a 10–15 business day turnaround.
Red flags
- No export option for fine-tuned models.
- Export costs are priced per GB at punitive rates.
What must we do to migrate to an alternative provider, and what commitments will you make to prevent lock-in?
What we look for — A named migration path or an articulate acknowledgment of the trade-offs.
Red flags
- Vendor refuses to discuss exit; 'that is not a conversation we have with customers.'
Scoring & Overall Signal
Intent — Every domain receives a score; the rollup produces the single signal that drives the decision.
Per-domain scoring (0–4)
- 4 · Exemplary. Evidence exceeds expectations; written commitments in place; recent independent validation.
- 3 · Sufficient. All expectations met with documented evidence. No red flags.
- 2 · Conditional. Core expectations met, with specific gaps to be closed by contract language or compensating controls.
- 1 · Deficient. Material gaps with no clear remediation path inside the engagement.
- 0 · Absent. Evidence not provided or refused.
Overall signal
Green · Proceed
No red flags. All P0/P1 controls verified. Proceed to contract with standard AEGIS redlines.
Yellow · Conditional
Gaps that can be closed with contract language, compensating controls, or scoped usage. Council ratifies conditions; VRA re-reviewed at renewal.
Red · Escalate
Material gaps. Escalate to Executive Sponsor. Proceed only with a documented risk acceptance and a targeted mitigation plan.
Black · Reject
Fundamental misalignment. The vendor does not meet baseline obligations and cannot be brought into compliance through contract. Do not proceed.
Cover Sheet
Intent — Each completed VRA begins with this cover sheet. It is the artifact that travels with the contract, not the raw responses.
Vendor
[VENDOR NAME]
Tool / Service
[TOOL + VERSION]
Proposed Use Case
[SUMMARY]
Max Data Classification
[P0 / P1 / P2 / P3]
D1
[0-4]
D2
[0-4]
D3
[0-4]
D4
[0-4]
D5
[0-4]
D6
[0-4]
Overall Signal
[GREEN / YELLOW / RED / BLACK]
Prepared by
[AI GOV. LEAD]
CISO sign-off
[SIGNATURE + DATE]
Next review
[DATE]
Conditions & Redlines
Intent — When the signal is Yellow, the conditions that close the gap go in contract language. The standard redlines below should be in every AEGIS-governed AI contract.
- Zero-retention clause. Vendor commits in writing that prompts, outputs, and derived data from our tenant are not used to train current or future models.
- Subprocessor change notification.Minimum 15 business days' notice, with our right to object and terminate without penalty if the change materially changes data residency or security posture.
- Version pinning. Ability to pin to a specific model version for at least 30 days after a vendor version change, to allow us to test and certify the new version.
- Data deletion certificate. On termination or request, a signed deletion certificate provided within 30 days.
- Audit rights. Annual audit right (or acceptance of an equivalent SOC 2 / ISO 27001 report) for regulated engagements.
- Regulatory pass-through. Vendor cooperates with our regulator audits within a stated window and at no additional cost.