Why AI-specific questionnaires matter
Traditional security questionnaires like SIG, CAIQ, or custom forms focus on IT infrastructure: network security, access controls, encryption, incident response. These remain essential, but AI systems introduce entirely new risk categories that standard assessments don’t cover.
The evidence gap
A vendor answer can describe a policy without showing how a covered workflow behaved. Ask for a bounded evidence set: architecture and contracts for design, scenario results for effectiveness, and signed operational records plus coverage analysis for selected events.
Standard vs. AI-specific assessment
SOC 2 alone does not answer every AI-workflow question. Scope the review to the model, data, tools, actions, people, and controls that make the use case consequential.
Framework alignment
Use frameworks for different jobs: NIST AI RMF to organize risk management, MITRE ATLAS to inform adversarial scenarios, and OWASP’s current LLM list to surface application-security failure paths. None establishes compliance or control effectiveness by itself.
Procurement baseline
Keep the existing security and privacy review, then add questions for models, training and retrieval data, tools, actions, human review, testing, and evidence.
Workflow-specific reviewMITRE ATLAS
Adversarial Threat Landscape for AI Systems. Knowledge base of tactics and techniques from real-world attacks and AI red teams.[5]
MITRE CorporationOWASP LLM Top 10
The August 2026 list covers ten application risks, with Prompt Injection at LLM01 and Excessive Agency at LLM03.[6]
OWASP FoundationNIST AI RMF + 600-1
AI Risk Management Framework with Generative AI Profile. 72 subcategories across GOVERN, MAP, MEASURE, MANAGE functions.[7]
US GovernmentFramework boundary
A framework can organize questions, but the answer still needs evidence matched to its claim: architecture for design, tests for scenario behavior, contracts for allocation, and operational records plus coverage analysis for selected events.
Question categories
The GLACIS AI Security Questionnaire covers eight categories, each mapped to the relevant frameworks:
Model Security
Prompt injection, jailbreaking, output filtering, adversarial robustness
Data Governance
Training data, customer data handling, retention, PII/PHI protection
Compliance & Regulatory
EU AI Act, NIST AI RMF, ISO 42001, industry-specific requirements
Supply Chain
Model provenance, ML-BOM, third-party dependencies, attestations
Bias & Fairness
Bias testing, discrimination audits, fairness metrics, documentation
Transparency
Model cards, system documentation, disclosure requirements
Operational Security
Monitoring, incident response, human oversight, model updates
Red Teaming
Adversarial testing, vulnerability assessment, remediation tracking
Model security questions
These questions assess defenses against attacks targeting the AI model itself, aligned with OWASP LLM Top 10 and MITRE ATLAS.
Model Security
10 questions • OWASP LLM Top 10 • MITRE ATLAS
MS-1: What defenses are in place against prompt injection attacks? Describe both direct and indirect injection protections.
MS-2: How are jailbreaking attempts detected and prevented? What testing has been performed against known jailbreak techniques?
MS-3: What output filtering is applied before responses are returned to users? Are outputs scanned for harmful content, PII, and policy violations?
MS-4: How is the system prompt protected from extraction? What evidence demonstrates its effectiveness?
MS-5: What controls prevent the model from taking unauthorized actions (tools, APIs, system access)? How are capabilities restricted?
MS-6: How is the model protected against adversarial inputs designed to cause incorrect outputs (adversarial examples)?
MS-7: What rate limiting, abuse prevention, and anomaly detection measures are implemented?
MS-8: Has the system undergone AI red teaming? Provide summary findings and remediation status.
MS-9: How are multi-turn attacks and conversation manipulation detected and prevented?
MS-10: What safeguards prevent the model from generating hallucinated or fabricated information?
Data governance questions
These questions assess how data is handled throughout the AI lifecycle, from training to inference.
Data Governance
9 questions • NIST AI RMF • EU AI Act
DG-1: What data is used for training/fine-tuning? Is any customer data used? Provide complete data provenance documentation.
DG-2: How is customer data isolated from other customers (multi-tenancy controls)? What prevents cross-tenant data leakage?
DG-3: What is the data retention policy for user prompts and model outputs? How is deletion enforced?
DG-4: Can customers opt out of data being used for training? How is this enforced and audited?
DG-5: What PII/PHI detection is performed on inputs and outputs? What redaction or masking is applied?
DG-6: How is training data provenance documented? Is the origin of all training data known and verified?
DG-7: What controls prevent training data poisoning attacks?
DG-8: For healthcare: Is there a BAA available? What PHI protections are in place?
DG-9: What controls exist to prevent the model from memorizing and reproducing training data (extraction attacks)?
Supply chain & provenance questions
Supply-chain review should cover model provenance, training and fine-tuning data, libraries, registries, plugins, model-context tools, subprocessors, and update paths. Ask which dependencies can change behavior or reach consequential data and actions.
Supply Chain
7 questions • OWASP LLM Top 10 • MITRE ATLAS
SC-1: What is the provenance of the AI model(s) used? Are they custom-trained, fine-tuned, or third-party?
SC-2: Is an ML-BOM (Machine Learning Bill of Materials) maintained? Does it include datasets, models, and code dependencies?
SC-3: How are third-party AI models validated before use? What security testing is performed?
SC-4: What controls protect against backdoored or trojanized models?
SC-5: Are cryptographic attestations used to verify model and data integrity (SLSA, Sigstore)?
SC-6: How are model updates verified and tested before deployment?
SC-7: What visibility exists into Nth-party dependencies (your vendor’s vendors)?
Bias and fairness questions
NYC Local Law 144 requires an annual bias audit before using a covered automated employment decision tool, along with public-summary and notice requirements. Applicability and enforcement consequences depend on the facts; this questionnaire is not legal advice.[10]
Bias & Fairness
EU AI Act • NYC LL144BF-1: Has the system undergone independent bias testing? Provide audit results for protected characteristics (gender, race, age, disability).
BF-2: What fairness metrics are used (demographic parity, equalized odds, individual fairness)? How are thresholds determined?
BF-3: How is training data evaluated for representativeness and potential bias amplification?
BF-4: What bias mitigation techniques are applied (pre-processing, in-processing, post-processing)?
BF-5: Is bias monitoring continuous? How often are bias metrics recalculated in production?
BF-6: What tools are used for bias detection (IBM AI Fairness 360, Microsoft Fairlearn, Aequitas)?
BF-7: How are bias incidents reported, investigated, and remediated?
Transparency and model cards
Transparency duties vary by role, system, audience, and jurisdiction. EU AI Act Article 50 includes disclosure and labeling duties for specified systems and content; determine applicability for the actual deployment rather than treating every model card or public report as universally required.
Transparency
EU AI Act • NIST AI RMFTR-1: Is a model card available? Does it include intended uses, limitations, training data summary, and evaluation results?
TR-2: Is documentation available in machine-readable format (JSON) for programmatic analysis?
TR-3: Are users notified when they are interacting with an AI system (disclosure requirements)?
TR-4: Is safety evaluation documentation publicly available? What testing methodology is described?
TR-5: How is documentation updated when the model is substantially revised?
TR-6: What information is disclosed about model capabilities, limitations, and known failure modes?
Compliance and regulatory questions
These questions help surface potential regulatory and standards dependencies. Applicability varies by jurisdiction, role, sector, data, and use case; verify the current primary text and obtain legal advice for the deployment.
Compliance & Regulatory
EU AI Act • NISTCR-1: How is the system classified under the EU AI Act? What compliance measures are in place for that risk tier?
CR-2: Is the organization aligned with NIST AI RMF? Describe implementation status across all four functions.
CR-3: Is the organization ISO 42001 certified or pursuing certification?
CR-4: If Colorado SB 26-189 applies, how will the organization support required notices, disclosures, correction, human review, and records from January 1, 2027?
CR-5: What documentation is maintained for regulatory compliance (risk assessments, impact assessments, conformity assessments)?
CR-6: Are there any pending regulatory actions or findings related to AI systems?
CR-7: What industry-specific AI regulations apply (healthcare, financial services, employment)?
CR-8: How are regulatory changes monitored and incorporated into the system?
Operational security questions
These questions assess ongoing security operations and human oversight.
Operational Security
NIST • SIGOS-1: What monitoring is in place for AI system behavior? What metrics are tracked and alerted on?
OS-2: How are AI-related security incidents detected, triaged, and responded to? Is there an AI-specific incident response plan?
OS-3: What human oversight exists for AI decisions? When is human review required?
OS-4: How is model drift monitored? What triggers model review or retraining?
OS-5: What audit logging is maintained? How long are logs retained? Are they tamper-evident?
OS-6: Can customers access logs of AI interactions with their data?
OS-7: What is the process for reporting AI safety concerns (internal and external)?
OS-8: How are AI model updates tested before deployment? What rollback capabilities exist?
Scoring and evaluation
The following rubric is illustrative, not a generally applicable acceptance standard. Buyers should define question relevance, evidence expectations, decision rights, thresholds, and treatment of compensating controls for the specific workflow, risk appetite, contract, and applicable obligations.
| Score | Criteria | Evidence Required | Illustrative interpretation |
|---|---|---|---|
| 4 | Comprehensive controls with continuous monitoring | Documented, tested, audited | Potentially sufficient for the buyer’s defined scope |
| 3 | Controls in place, some evidence gaps | Documented, partially tested | Buyer-defined conditions or monitoring may be appropriate |
| 2 | Some controls, significant gaps | Partial documentation | Assess buyer-specific remediation or compensating controls |
| 1 | Few controls, major gaps | Minimal or no evidence | Escalate under the buyer’s risk process |
| 0 | No controls or evidence | None | Buyer decision required; do not infer automatic rejection |
Category weights
These percentages are examples only, not defaults or prescribed weights. A buyer should set or omit weights based on the workflow, material risks, mandatory requirements, evidence quality, and its own decision process:
Red Flags
Watch for vendors who claim “we use [major provider] so we inherit their security” without demonstrating application-layer controls. LLM security requires layered defenses. Also flag vendors who can’t answer basic questions about prompt injection or training data governance.