AI Control Plane RFP template: the 87-question buyer's checklist for 2026

The "AI Control Plane" category is now mature enough that buyers can run a structured RFP and get apples-to-apples answers - if they know the right questions. This post is the 87-question RFP template Areebi's research team uses with enterprise procurement teams, organised into seven sections (Identity and access; Data protection and residency; Policy enforcement and shadow AI; Audit and evidence; Model and vendor governance; Incident response; Compliance and certifications) and grounded in NIST AI 600-1 (July 2024), ISO/IEC 42001:2023, SOC 2 Trust Services Criteria, EU AI Act, Gartner's Market Guide for AI Trust, Risk, and Security Management (AI TRiSM), and ENISA's AI Threat Landscape. Use it as-is, or as a starting point for your own. Updated 2026-05-20.

An RFP is a forcing function, not a checklist. The goal is not to score vendors against a generic spec; it is to surface the gap between marketing language and operational reality. The template below is intentionally specific and intentionally referenced to standards. Each question carries a citation to the regulatory or framework expectation that justifies asking it - so when a vendor pushes back on the question, you can point to the source and say "we have to ask this because [standard X] requires we know."

Practical guidance:

• Tier the questions. Make some mandatory (a "no" disqualifies), some scored (the answer affects ranking), and some informational (used to inform the implementation plan but not the buy decision). Tiering is a function of your sector and data classes.
• Score on evidence, not assertions. "Yes we support that" is not an answer. Ask for the SOC 2 control reference, the architecture diagram, the screenshot, the policy document, the audit log sample, the customer reference.
• Run a hands-on evaluation in parallel. The RFP is the artefact for the procurement committee; the proof-of-concept is where the truth lives. The Areebi build vs buy guide covers the evaluation pattern.
• Re-score annually. AI control plane vendors are moving fast in 2026; an answer that was good 12 months ago may be out of date. Bake re-evaluation into the renewal cycle.

Use the Areebi AI vendor risk score as the scoring rubric for the answers you receive.

NIST AI 600-1 ties identity to the "Govern" function (GV.OV-2, GV.RR-3) and the Manage function for access control. ISO 42001 control 8.2 addresses access management; SOC 2 CC6 covers logical access. The EU AI Act Article 14 (human oversight) and Article 22 (data governance) presuppose authenticated identity at every AI interaction.

1. SSO and identity providers supported. Does the platform support SAML 2.0, OIDC, and SCIM provisioning from major IdPs (Okta, Microsoft Entra, Ping, Google Workspace)?
2. Federated identity scope. Are identities federated end-to-end, including to the model vendor (so the LLM provider sees the authenticated user identity, not a service account)?
3. MFA requirement. Does the platform enforce MFA on all administrative actions? On user actions? Can MFA be required policy-by-policy?
4. Role-based access control. Are roles defined and configurable? Are they enforced consistently across UI, API, and admin surfaces?
5. Attribute-based access control. Can policies be conditioned on user attributes (department, location, security clearance, data classification)?
6. Just-in-time access. Does the platform support time-bounded elevated access with approval workflow?
7. Service-account governance. Service accounts, API keys, and machine identities - rotation policies, scope limits, audit trail?
8. Identity lifecycle hooks. Provisioning and de-provisioning automated on HR / IdP events; orphaned identities flagged.
9. Session management. Maximum session length configurable; idle timeout; concurrent session limits.
10. Privileged access management integration. Integration with CyberArk, BeyondTrust, Delinea for break-glass access patterns.
11. Per-tenant identity isolation. Multi-tenant deployments - is identity isolation cryptographic, logical, or process-level?
12. Authentication for the audit log. Read access to audit log is itself authenticated, MFA'd, and logged.

NIST AI 600-1 lists data privacy as a top risk class (Risk DP). ISO 42001 control 8.3 addresses information security; SOC 2 P (Privacy) and C (Confidentiality) categories apply. GDPR Articles 5, 25, 32 and EDPB Opinion 28/2024 set the EU floor; HIPAA 45 CFR 164.312, OCR online tracking guidance, and the various US state laws set the US floor.

13. Data residency by region. Which regions does the platform operate in? Can data (prompts, completions, audit logs, embeddings, configuration) be pinned to a specific region?
14. Sovereignty controls. Does the platform support EU sovereign cloud requirements, customer-managed encryption keys (BYOK / HYOK), and supply-chain transparency for the underlying infrastructure?
15. Encryption at rest. What algorithms and key management? Customer-managed keys supported?
16. Encryption in transit. TLS 1.2 minimum (1.3 preferred)? Internal service-to-service encryption?
17. Tokenisation and redaction. Does the platform support pre-inference redaction of sensitive fields (PHI, PII, payment data, trade secrets)? Reversible tokenisation for authorised re-identification?
18. Data classification. Per-class policy enforcement (PHI separately from PII separately from trade secret)?
19. Retention policies. Per-class retention; automated purging; verifiable deletion?
20. Right-to-erasure support. GDPR Article 17 implementation - can the platform identify and delete all records relating to a specific data subject across prompts, completions, retrieval stores, and logs?
21. Data minimisation enforcement. Can the platform reject prompts that contain unnecessary data classes for the workload (e.g. block SSNs in a marketing workload)?
22. Outbound data control. DLP-style egress controls on data leaving the platform to external models or downstream tools?
23. Model vendor data flow. What data does the platform send to the model vendor? Is the training-on-customer-data carve-out enforced and verifiable?
24. BAA / DPA support. Will the vendor sign a BAA for healthcare customers? A standard DPA with EU SCCs for EU customers? What are the exclusions?
25. Cross-border transfer mechanisms. SCCs, adequacy decisions, BCR - which mechanisms does the vendor rely on and where?

This is the operational core of an AI control plane. Gartner's Market Guide for AI Trust, Risk, and Security Management (AI TRiSM) identifies policy enforcement and shadow AI discovery as the differentiating capabilities. ENISA's AI Threat Landscape emphasises runtime defence; OWASP's Top 10 for LLM Applications 2025 enumerates the threats the policy engine must counter.

26. Policy expression language. Code? Declarative? Visual builder? Hybrid? How are policies version-controlled?
27. Policy testing. Test harness for policies before deployment; dry-run mode against historical traffic; impact analysis?
28. Pre-built policy library. Off-the-shelf policies for common regulatory regimes (HIPAA, GDPR, PCI DSS, SOC 2) - what is the catalogue?
29. Real-time enforcement latency. P50 / P95 / P99 latency impact of policy enforcement on the inference path?
30. Prompt injection defence. What patterns does the platform detect and block? How is the detection updated as new patterns emerge?
31. Output filtering. Toxicity, PII / PHI leakage, regulated content - which classifiers, which thresholds, how tuned?
32. System prompt protection. Defence against system prompt extraction and leakage attacks?
33. Tool-use / agent governance. When the LLM calls tools (database, email, browser, code execution), what policies gate the call?
34. Shadow AI discovery. Discovery of unauthorised AI tool usage - network traffic analysis, browser extension monitoring, log analysis, expense report analysis? See our 90-minute shadow AI hunt.
35. Vendor allow / deny list. Per-tenant configurable allow-list of approved model vendors and tools; default-deny for unknowns?
36. Rate limits and quotas. Per-user, per-tenant, per-vendor rate limits and spend quotas?
37. Policy override workflow. When a user needs to invoke an action the policy blocks, what is the approval / break-glass workflow, and how is it audited?
38. Policy as code integration. Are policies exportable / importable as code, version-controlled in Git, and CI/CD deployable?

SOC 2 TSP Section 100, ISO 42001 control 9.5, and the NIST AI 600-1 Manage function all expect a reconstructable evidentiary chain. The audit log is what makes ISO 42001 certification and SOC 2 attestation possible at all.

39. Audit log content. What is captured per inference - prompt, system prompt, completion, retrieved context, policy decisions, identity, model and version, latency, cost?
40. Audit log integrity. Tamper-evidence - signed log entries, hash chains, immutable storage?
41. Audit log retention. Configurable retention; legal-hold support; per-record retention policies?
42. Audit log search and export. Searchable by user, identity, time range, policy decision, data class? Exportable in JSON / CSV / SIEM-friendly formats?
43. SIEM integration. Native integration with Splunk, Sentinel, Chronicle, Sumo, Elastic? Real-time streaming?
44. Evidence packs for auditors. Pre-built evidence packs for ISO 42001, SOC 2, HIPAA, GDPR? How are they generated and how are they validated?
45. Reproducibility. Can an inference be re-played from the audit log with the same model version and the same prompt? This is the SOC 2 reproducibility expectation.
46. Model decision lineage. For a given output, can the auditor trace which model version, which prompt, which retrieved context, which policy decisions, and (if fine-tuned) which training corpus?
47. Reporting and dashboards. Out-of-the-box dashboards for usage, policy violations, top users, top use cases, top costs, top data classes?
48. Anomaly detection. Built-in anomaly detection on usage patterns, policy violations, and cost?
49. Read access governance. Read access to the audit log itself is authenticated, MFA'd, time-bounded where appropriate, and logged?
50. Audit log of admin actions. Configuration changes, policy changes, identity changes - all in the audit log with the actor and the diff?

NIST AI 600-1 risk class "Value Chain and Component Integration" (VC) and ISO 42001 control 8.4 (third-party AI services) require explicit governance of the model and vendor layer. EU AI Act Article 16 (provider obligations) and Article 25 (supplier responsibilities) make the vendor relationship a regulator-relevant artefact.

51. Model registry. Inventory of every model in use - provider, version, modality, training cut-off, intended use, classification?
52. Multi-model routing. Can the platform route different workloads to different models based on policy (data class, sensitivity, cost, capability)?
53. Model version pinning. Workloads pinned to specific model versions for reproducibility; controlled migration to new versions?
54. Vendor registry. Per-vendor record of DPA, BAA, SCC, AUP status, certifications, breach history?
55. AIBOM (AI Bill of Materials). Does the platform produce or integrate with an AIBOM showing models, embeddings, datasets, libraries, and dependencies? See our AIBOM playbook.
56. Model card management. Storage and presentation of model cards (Mitchell et al format) and system cards from vendors?
57. Fine-tuning governance. If fine-tuning is supported, the data lineage, the training run metadata, and the evaluation evidence are captured?
58. RAG governance. If RAG is supported, the retrieval source registry, the embedding model version, and the chunking strategy are captured?
59. Vendor incident integration. When a model vendor publishes a security advisory, how does the platform surface that to your team?
60. Vendor deprecation handling. When a vendor deprecates a model version, the platform's notice-to-action workflow?
61. Self-hosted model support. Can the platform front a self-hosted open-weight model (Llama, Mistral) with the same policy and audit controls as a hosted vendor?
62. Multi-region failover. If a vendor region is unavailable, fallback to another region or another vendor?
63. Cost governance. Per-vendor and per-model cost attribution; budget alerts; chargeback support?

NIST SP 800-61r2 and AI 600-1 set the expectations; ISO 42001 control 10.1 (response to AI system incidents) and SOC 2 CC7.4 / CC7.5 make incident response a control-effectiveness criterion. See our AI incident response runbook for the operational pattern.

64. Kill switch. A tested mechanism to disable a use case, a model integration, or all AI access for an identity, group, or tenant - immediately?
65. Policy hot-deploy. Policy patches deployable to production without service restart and without re-authentication of all sessions?
66. Incident detection rules. Out-of-the-box detection rules for the OWASP LLM Top 10 risks and the NIST AI 600-1 risk classes?
67. Evidence preservation. When an incident is opened, the relevant audit log records are preserved and locked against retention purges?
68. Scope queries. Search across the audit log to identify the affected sessions, users, and downstream actions in a single workflow?
69. Tool-use reversal. If an injected prompt caused an agent to take an action (sent email, modified record), is there a reversal / quarantine workflow?
70. Notification workflows. Configurable notifications to security, privacy, legal, and executive stakeholders by severity?
71. Regulator notification support. Pre-built timelines and content templates for GDPR 72-hour, HIPAA 60-day, SEC 8-K 4-business-day, EU AI Act Article 73, and DORA major-ICT-incident reporting?
72. Tabletop and drill support. Can the platform produce a simulated incident for tabletop exercises?
73. Post-incident artefacts. Timeline, root cause, containment, lessons - exportable for the post-mortem and the audit committee report?
74. Vendor incident coordination. Per-vendor contact records and disclosure-obligation tracking for upstream incidents?
75. MTTR metrics. The platform's own MTTD / MTTR / MTTC metrics on AI-specific incidents (anonymised across the customer base)?

The vendor's own compliance posture is a property procurement is buying. The relevant references: SOC 2 Type II report (current, with the Trust Services Criteria mapped to AI risks per our SOC 2 + AI workloads mapping), ISO/IEC 42001:2023 certification, ISO/IEC 27001 + ISO 27701, HIPAA, GDPR posture, EU AI Act readiness.

76. SOC 2 Type II. Current report available under NDA? Trust Services Criteria covered (Security mandatory; Availability, Confidentiality, Processing Integrity, Privacy as applicable)?
77. ISO/IEC 42001:2023. Certified? In progress? Roadmap? Internal-audit evidence available?
78. ISO/IEC 27001. Current certification, scope, certificate available?
79. HIPAA. BAA available; OCR examination history; Security Rule mapping documented?
80. GDPR / EU posture. DPA available; EU SCC where applicable; UK addendum; data residency in EU; DPO contact?
81. EU AI Act. Provider / deployer position documented; high-risk system support if relevant; GPAI Code of Practice signatory status?
82. NIST AI RMF. Self-assessment or third-party attestation against the AI RMF 1.0 and the AI 600-1 GAI Profile?
83. FedRAMP. Authorisation status (FedRAMP Moderate / High); FedRAMP 20x readiness if relevant for US public sector?
84. Penetration testing. Frequency, scope, third-party tester, report available?
85. AI red teaming. Frequency, methodology, findings remediation cadence? See the AI red team guide.
86. Bug bounty. Active programme, scope, third-party platform, response SLAs?
87. Trust Center. Public-facing trust documentation with current status of certifications, sub-processors, incident history?

The 87 questions above are the minimum. Sectoral overlays - DORA for financial services, OCR online tracking guidance for healthcare, OMB M-24-18 for US federal contractors, Australian Privacy Act for AU, Singapore AI Verify for SG - add 20-40 more for those sectors. The Areebi compliance hub indexes the sectoral mappings.

A vendor RFP is only as good as the scoring discipline behind it. Areebi's recommended rubric:

• Score each answer 0-3. 0 = not supported. 1 = roadmap. 2 = supported with evidence. 3 = supported with evidence and customer reference.
• Weight by sector. Healthcare buyers weight Section 2 (data) and Section 7 (compliance, especially HIPAA / SOC 2) heavily. Financial services weight Section 4 (audit) and Section 6 (incident) heavily. EU public sector weights Section 2 (residency) and Section 7 (EU AI Act) heavily.
• Disqualify on any mandatory zero. Identify the mandatory questions for your sector (BAA for healthcare, DPA for EU, SOC 2 for any enterprise) - a zero on those is a disqualification.
• Triangulate with proof-of-concept. The RFP measures stated capability; the proof-of-concept measures actual capability. A vendor scoring 92% on the RFP but scoring poorly in the proof-of-concept is the worse choice.
• Run the same RFP twice, six months apart. The category is moving fast. A vendor that scored 75% in November 2025 should be able to score 85%+ in May 2026 if the product team is keeping up. Vendors that have flatlined are a signal.

Use the AI vendor risk score tool to capture and compare scores across vendors.

An RFP that asks only the marketing-friendly questions ("do you have policy enforcement?") gets back marketing-friendly answers. An RFP that asks the operationally specific, framework-referenced questions ("what is the P95 latency impact of your output filter on a 4k-token completion?", "show me the audit log entry for a HIPAA-scope inference") gets back signals you can buy on. Areebi's research team's view: the AI control plane category will consolidate over the next 18 months, and the buyers running disciplined RFPs in 2026 will be the ones with the leverage to negotiate good contracts with the winners. The 87 questions above are the floor; build on them.