Traditional questionnaires are usually designed to capture policy existence, not runtime behaviour. That leaves gaps around how a model makes decisions, how data was used to train it, what changes after deployment, and whether the supplier can evidence human oversight. AI governance needs operational proof, not just assurances on paper.
Why This Matters for Security Teams
Traditional vendor questionnaires are still useful for baseline assurance, but they are a weak fit for ai governance because they mostly capture intent, not evidence. A supplier can answer “yes” to policy questions while still lacking model lineage, training data controls, prompt safety testing, or post-deployment monitoring. That mismatch is exactly why AI risk assessments need operational artefacts, not just attestation.
For security and risk teams, the issue is not whether the vendor has a policy document. It is whether the vendor can show how the model behaves under stress, how updates are approved, and how human oversight is applied when outputs are wrong or unsafe. The NIST AI Risk Management Framework is helpful here because it pushes organisations toward measurable governance, not checkbox compliance.
Questionnaires also tend to miss the supply chain angle. AI systems are assembled from foundation models, adapters, retrieval layers, third-party APIs, and orchestration logic, so a single “vendor” answer often hides multiple control owners. In practice, many security teams discover AI governance gaps only after an incident review or procurement dispute, rather than through intentional due diligence.
How It Works in Practice
Effective AI due diligence should map the questionnaire to concrete evidence requests. Instead of asking only whether a policy exists, security teams should ask for the operating evidence behind model development, deployment, and change control. That includes model cards, evaluation reports, human review workflows, incident logs, data retention rules, and records showing who can approve model updates.
This is where the limits of generic third-party questionnaires become obvious. They are usually built for SaaS security, privacy, or basic compliance, while AI governance needs to test behaviour at runtime and during change. The NIST AI 600-1 Generative AI Profile is especially relevant when the system uses large language models, because it highlights risks such as prompt injection, harmful output, and weak output validation. The NIST Cyber AI Profile (IR 8596) also helps security teams think about how AI changes established cyber controls.
A practical review usually covers:
- training and fine-tuning data provenance, including whether data was screened for licensing, privacy, and contamination risk
- model provenance and versioning, so a team can tell what changed between releases
- pre-deployment and post-deployment testing for bias, hallucination, jailbreaks, and unsafe tool use
- human oversight, including who reviews edge-case outputs and who can halt the system
- logging and monitoring, so abnormal behaviour can be investigated after go-live
For broader governance alignment, the NIST Cybersecurity Framework 2.0 remains useful for anchoring AI systems to identify, protect, detect, respond, and recover activities, while the ISO/IEC 42001:2023 AI Management System Standard is relevant where organisations want a formal management-system approach. These controls tend to break down when AI capability is embedded through rapid DevOps releases and multiple subcontractors, because no single team owns the full evidence chain.
Common Variations and Edge Cases
Tighter AI assurance often increases procurement friction and evidence collection overhead, requiring organisations to balance speed of adoption against governance depth. That tradeoff is real, especially when the supplier is a fast-moving startup that cannot produce the same artefact set as a regulated enterprise.
Current guidance suggests that not every AI use case needs the same level of scrutiny. A low-risk internal drafting tool is not equivalent to a model making decisions that affect customers, employees, or regulated processes. Where the use case is high impact, the EU AI Act is a strong signal that documentation, traceability, and oversight expectations increase sharply.
There is no universal standard yet for how to questionnaire every AI control, so mature organisations are moving toward evidence packs and scenario-based reviews rather than yes/no forms. That is particularly important when the supplier uses an external model provider, retrieval-augmented generation, or autonomous agents, because governance responsibility can fragment across several entities. In those cases, a questionnaire should be treated as a starting point, not a control test.
For NHIMG, the key insight is that AI governance gaps often overlap with identity and access risk when agents, service accounts, or delegated tools can change behaviour without clear ownership. The supplier may answer the security questions correctly while still failing to prove who can alter prompts, release versions, or override safeguards in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0, NIST AI 600-1 and ISO/IEC 42001:2023 AI Management System Standard set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | Vendor assurance gaps are governance gaps, so evidence and accountability matter. |
| NIST CSF 2.0 | GV.SC | AI suppliers are part of the security supply chain and need third-party control checks. |
| NIST AI 600-1 | GenAI systems need testing for prompt abuse, unsafe output, and validation failures. | |
| EU AI Act | Higher-risk AI use cases require traceability, documentation, and human oversight. | |
| ISO/IEC 42001:2023 AI Management System Standard | AI management systems formalise governance, evidence, and continual improvement. |
Test generative systems for misuse scenarios and require monitoring, guardrails, and output review.
