Why 30 questions and not 50 or 100?

The 30 questions cover the four framework registers (EU AI Act Annex IV, DORA Article 28, SOC 2 CC9.2, ISO 42001) without overlap. A 100-question assessment carries redundant rows that map to the same underlying control. The reviewer gets fatigued. The vendor's responses degrade quality after the first 40 rows. The 30 questions are the dense set that produces the four-framework coverage in a 90-minute meeting. The vendor file then carries one row per question with a documented answer and a freshness date.

What does the deployer audit-log access question really mean?

Question 11 asks whether the provider exposes per-decision logs to the deployer in a schema the deployer can ingest. Many providers offer aggregate usage logs but not per-decision logs with the policy version and the decision rationale. The deployer needs the per-decision log to satisfy EU AI Act Article 12, DORA Article 19, and Fannie Mae LL-2026-04 disclosure on demand. The fallback is the inspection-layer substrate the deployer runs in front of the provider, which writes the record independently.

How does this assessment integrate with the existing third-party risk program?

The 30 questions slot into the existing vendor management system as a custom assessment template tagged "AI provider." The TPRM platform stores the responses. The DORA Article 28 register pulls from the responses through a mapping file. The SOC 2 CC9.2 walkthrough pulls the population from the same store. The reviewer does not maintain three copies. The annual refresh runs the same template against the vendor.

What is the contract clause sequence the assessment drives?

The assessment outputs feed three contract clauses. The DPA addendum carries the GDPR Article 28 fields, the sub-processor list, and the data transfer mechanisms. The audit rights clause names the deployer-pull endpoint or the equivalent record path. The exit-strategy schedule names the artifacts the deployer keeps post-termination. The clauses then become the basis for the DORA Article 30 contractual content review.

How often does the assessment refresh?

The full assessment refreshes annually. Three triggers force an interim refresh: a sub-processor change (question 7 notification), a security incident the provider reports (question 24), and a substantial modification to the model under EU AI Act Article 43. The interim refresh runs the affected control objective only, not all 30 questions. The vendor file carries the refresh history with the trigger reference.

AI vendor risk assessment: the questions a Head of Security should ask any LLM provider in 2026

The vendor onboarding meeting for an LLM provider in 2026 covers four registers at once. EU AI Act Annex IV lists the technical documentation a general-purpose AI model provider must produce. DORA Article 28 requires the financial entity to maintain a register of contractual arrangements with ICT third-party providers, with specific fields per arrangement. SOC 2 trust services criteria CC9.2 covers vendor management. ISO 42001 clauses 7 and 8 cover supplier and operational control. Four frameworks, one vendor file, 30 questions. The Head of Security signs off when every question carries a documented answer.

I want to walk through the four framework asks, the 30 questions grouped by control objective, the Fannie Mae LL-2026-04 vendor accountability standard that pushed the bar higher in 2026, and how the deployer audit-log access requirement reshapes the conversation.

EU AI Act Annex IV documentation requirements

Annex IV defines the technical documentation a high-risk AI system provider must deliver. The documentation includes the general description (intended purpose, name and version, hardware, software and firmware components), the detailed description of elements (data requirements, methods of training, validation and testing, system architecture), the monitoring and control system, and the cybersecurity measures. Article 26 then extends the obligation to the deployer: the deployer must use the system in accordance with the instructions and keep the logs the system produces.

The vendor risk assessment pulls Annex IV directly. The provider must supply the technical documentation. The deployer's question is whether the documentation arrived, whether it covers the intended use, and whether the cybersecurity measures align with the deployer's environment. The vendor file stores the Annex IV pack with a version reference.

DORA Article 28 third-party register

DORA Article 28 requires the financial entity to maintain and update a register of information on all contractual arrangements with ICT third-party service providers. Article 28 paragraph 6 names the register as the entity's responsibility. Article 30 then defines the contractual content: the function supported, the data processed, the locations, the audit rights, the exit strategies, the service-level descriptions, and the incident reporting obligations.

The 30-question assessment carries the DORA Article 28 fields as a subset. The register entry pulls the location of the ICT services and the data processed straight from the assessment responses. The audit rights field maps to the deployer audit-log access question. The exit strategy field maps to the exit-strategy artifacts question. The financial entity files the entry within 15 days of the arrangement's signature.

SOC 2 CC9.2 vendor management

The SOC 2 trust services criteria CC9.2 covers the entity's assessment and management of risks associated with vendors and business partners. The criterion expects an inventory of vendors, a risk assessment per vendor, a contractual requirement that the vendor meet defined controls, and ongoing monitoring. The Type II audit looks at the operating effectiveness over the period.

The 30-question assessment is the input artifact for CC9.2. The risk assessment per vendor pulls the responses. The contractual requirement names the controls the vendor agreed to. The ongoing monitoring schedule pulls from the incident notification SLA and the SOC 2 report refresh cadence. The control owner files the assessment in the vendor management system. The auditor pulls the population from the system in the walkthrough.

ISO 42001 AIMS controls

ISO 42001 clause 7 covers support, including resources, competence, awareness, communication, documented information, and AI policy. Clause 8 covers operational planning and control, AI system impact assessment, and AI lifecycle. The supplier control reference in clause 8 ties to the procurement process and the supplier's AI management system maturity.

The 30-question assessment carries the ISO 42001 supplier control fields. The provider's AIMS certification status, the AI policy of the provider, the AI impact assessment the provider performed on the system, and the lifecycle stage the system occupies all enter the vendor file. The deployer's own AIMS audit then references the supplier control with the assessment as evidence.

The 30-question vendor assessment

The 30 questions group into 10 control objectives. Each question carries a documented answer in the vendor file. The Head of Security signs the file when every row is complete.

| # | Control objective | Question | |---|---|---| | 1 | Training-data lineage | What sources contributed to the training data? Disclose datasets, scrape windows, and licensing. | | 2 | Training-data lineage | What is the cutoff date of the training data per model version? | | 3 | Training-data lineage | Does the provider remove the deployer's data from training, and what is the contractual carve-out? | | 4 | Model card disclosures | Is the model card published per version, and what are the documented limitations? | | 5 | Model card disclosures | What evaluation benchmarks does the provider report and at what release? | | 6 | Sub-processor list | List every sub-processor by name, function, and country of processing. | | 7 | Sub-processor list | What is the notification window before a sub-processor changes? | | 8 | Retention policy | How long does the provider retain prompts, completions, and metadata by default? | | 9 | Retention policy | What deployer-side controls override the default retention? | | 10 | Retention policy | Are zero-retention API tiers available, and what is the contractual SLA? | | 11 | Deployer audit-log access | Does the provider expose per-decision logs to the deployer, and in what schema? | | 12 | Deployer audit-log access | Are the logs cryptographically signed, and how does the deployer verify the signature? | | 13 | Deployer audit-log access | What is the maximum log latency from request to availability? | | 14 | Fine-tuning isolation | Is fine-tuning data isolated from the base model and from other tenants? | | 15 | Fine-tuning isolation | What evidence does the provider supply that the isolation holds? | | 16 | Fine-tuning isolation | Are evaluation runs against fine-tuned weights logged separately? | | 17 | Prompt logging consent | Under what contract clause does the provider log prompts at all? | | 18 | Prompt logging consent | Is there a deployer toggle to disable prompt logging, and what is the SLA? | | 19 | Prompt logging consent | How are end-user notices handled when the deployer enables provider-side logging? | | 20 | DPA and DPIA support | Is a DPA in place under GDPR Article 28, and what is the version? | | 21 | DPA and DPIA support | Will the provider supply DPIA inputs the deployer needs under GDPR Article 35? | | 22 | DPA and DPIA support | What are the data transfer mechanisms for non-EU sub-processors? | | 23 | Incident notification SLA | What is the maximum hours to notify the deployer of a security incident? | | 24 | Incident notification SLA | What incident categories trigger the notification? | | 25 | Incident notification SLA | Does the SLA align with DORA Article 19 major ICT incident timelines? | | 26 | Exit-strategy artifacts | What deployer-controlled artifacts survive the contract end? | | 27 | Exit-strategy artifacts | Is the audit-log export available post-termination, and for how long? | | 28 | Exit-strategy artifacts | Are fine-tuned weights portable to another provider? | | 29 | Ongoing assurance | What is the SOC 2 Type II report refresh cadence? | | 30 | Ongoing assurance | Is the provider ISO 42001 certified, and what is the certification scope? |

Fannie Mae LL-2026-04 vendor accountability

The Fannie Mae lender letter LL-2026-04 raised the vendor accountability bar for lenders deploying AI in underwriting and servicing. The letter requires the lender to maintain disclosure on demand: when Fannie Mae asks which model produced which decision on a loan file, the lender must respond with a contemporaneous record. The record must include the model, the version, the inputs, the policy version, and the decision rationale.

The vendor assessment carries the LL-2026-04 disclosure-on-demand row. Question 11 (deployer audit-log access schema) and question 12 (signature verification) are the gating questions. A provider that does not expose per-decision logs to the deployer fails the LL-2026-04 test by construction. The lender then deploys an inspection-layer substrate that records the decision independently of the provider, which closes the gap.

DeepInspect

This is the inspection-layer substrate the assessment questions 11, 12, and 13 depend on when the provider itself does not expose per-decision logs in the schema the deployer needs. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM endpoint. Every HTTP request produces a per-decision audit record committed before the model response returns. The record carries the verified identity, the role and agent context, the data classification applied to the prompt, the model and version called, the policy version, the decision outcome, and a cryptographic signature.

The substrate is the deployer-side record. The deployer controls the schema. The deployer controls the retention. The deployer verifies the signature against the deployer's own key. The provider's log gap stops being the deployer's compliance gap.

Let's talk today.