TL;DR — 10 questions, ranked by risk-surface dominance
CISOs running procurement on AI productivity intelligence vendors in 2026 should ask ten questions in roughly this order of risk-surface dominance: (1) data residency and cross-border transfer mechanism, (2) employee notice and DPIA template availability, (3) AI model auditability and bias testing methodology, (4) breach notification SLA and customer-facing escalation, (5) SOC 2 plus ISO 27001 attestation date and scope, (6) data retention configurability and deletion path, (7) integration security including SCIM/SSO and service-account hygiene, (8) explainability per scoring decision combining rule-trace and SHAP attribution and counterfactual reasoning, (9) sub-processor transparency and onward-transfer chain, (10) contractual right to audit and audit-trail JSON export. The ordering matters because the first three questions surface most of the deal-breakers; the remaining seven calibrate the procurement-decision rubric.
Download the full checklist as a 10-page PDF →
Includes scoring rubric (0-3 per question), vendor evaluation worksheet, and pass / hold / walk decision thresholds.
Why the standard SaaS due-diligence playbook misses AI productivity risk
Standard SaaS due diligence — SOC 2 attestation, encryption at rest and in transit, SSO support, contractual data ownership, breach notification clause — was built for the data-storage-and-process category. AI productivity intelligence sits in a different category and adds five risk surfaces the standard playbook does not catch:
- AI model auditability. Does the vendor have a documented bias-testing methodology, model-version history, regression testing before deployment, and post-market monitoring infrastructure? Standard SaaS diligence does not catch this.
- Explainability per decision. Does the platform produce per-decision audit trails satisfying GDPR Article 22 and EU AI Act Annex IV technical documentation? Standard SaaS exports an entry; AI productivity must export a per-decision artefact.
- Training data lineage. What data trained the models? Is the lineage documented? Are customer-tenant data segregated from training data? Standard SaaS does not have a training-data question because standard SaaS does not have models.
- AI Act conformity assessment. Has the vendor produced one for the Annex III high-risk classification? This is a 2026-specific question that did not exist in pre-Act diligence.
- Ongoing AI risk management. What does the platform do when the model drifts, when a new attack surface emerges, when a regulator requests a post-market monitoring report? Model risk management is an ongoing discipline, not a point-in-time attestation.
The ten questions below collectively cover these five extensions plus the standard SaaS diligence floor. Each question includes the expected vendor response (what good looks like), the diligence flag (what's structurally wrong), and the documentary artefact the CISO should request as a procurement deliverable.
Q1 — Data residency + cross-border transfer mechanism
The question. Where is customer-tenant data stored at rest? Where is it processed? What is the cross-border transfer mechanism if processing crosses jurisdictions? Can residency be configured per business unit so the EU subsidiary's data stays in EU storage, the India subsidiary's data stays in Mumbai storage, the US subsidiary's data uses the EU-US Data Privacy Framework?
What good looks like. Per-business-unit residency configuration. EU, UK, US, and India residency tiers with documented storage locations. Standard Contractual Clauses signed for any EU-to-third-country transfer. EU-US Data Privacy Framework certification if relevant. Per-entry residency tag that propagates through every processing hop and is retained in the audit-trail JSON.
Diligence flag. Account-level residency (the entire customer tenant in one region with no per-business-unit configurability). "Data centre redundancy" framing that obscures the actual location. Schrems II uncertainty answered with marketing rather than the SCC + DPF stack. No per-entry residency tag in the audit trail.
Artefact to request. Data-flow diagram showing every storage and processing location. SCCs signed and dated. DPF certification if applicable. Sample per-entry audit-trail JSON showing residency tag.
Q2 — Employee notice + DPIA template availability
The question. Does the vendor ship an employee-facing transparency notice template aligned with EDPB Guidelines 05/2020? Does the vendor ship a DPIA template covering the lawful basis (typically Art. 6(1)(f) legitimate interest with LIA), categories of data captured, retention, data-subject rights surface, security controls, cross-border transfer mechanism, supervisory authority path?
What good looks like. Both templates ship with the platform. The DPIA template is editable and pre-populated with platform-specific information (categories of data, retention defaults, sub-processor list). The employee notice template covers all EDPB Guidelines 05/2020 elements. Templates have been reviewed by named counsel and dated within 12 months.
Diligence flag. Templates are provided as boilerplate that does not reflect the specific platform. Templates predate the EU AI Act (any DPIA template dated before mid-2024). Templates do not cover the EU AI Act Annex III high-risk obligations.
Artefact to request. Both templates as live artefacts (not screenshots). Counsel-review attestation. EDPB-Guidelines-05/2020 mapping if the vendor has one.
Q3 — AI model auditability + bias testing methodology
The question. Is there a documented bias-testing methodology covering protected classes? What fairness metrics are tracked? What happens when a bias regression is detected? Is there a model-version history surfaced to customers? What's the model retraining cadence and trigger? What regression testing happens before deployment?
What good looks like. Bias testing covers at minimum age, gender, role/seniority, and geography. Fairness metrics include statistical parity, equalised odds, and calibration. Model-version history is surfaced per customer tenant in the audit trail. Retraining cadence is documented (typically quarterly with continuous monitoring), trigger conditions are explicit, regression testing is run on a frozen evaluation set with a defined acceptance bar.
Diligence flag. No bias testing or only model-accuracy metrics (which do not catch fairness regressions). No model-version history exposed to customers. No regression testing before deployment. The vendor's response is "we trust our model" rather than "here is our bias-testing methodology."
Artefact to request. Most recent bias-testing report (under NDA). Model-version history sample for one customer tenant. Regression-testing acceptance bar documentation.
Q4 — Breach notification SLA + escalation path
The question. What is the breach notification SLA to the customer? Is it aligned with GDPR Art. 33 (72 hours to supervisory authority)? What is the customer-facing escalation path during an incident? Is there a 24/7 security contact?
What good looks like. Breach notification within 72 hours of vendor awareness, with a named security-contact channel. Aligned with GDPR Art. 33 + 34 (data-subject notification when high-risk). Incident-response runbook surfaced to enterprise customers. Post-incident root-cause-analysis report committed contractually within 30 days.
Diligence flag. Breach notification clause without a defined SLA. "Best efforts" language. No 24/7 security contact. No post-incident RCA commitment.
Artefact to request. Incident-response runbook (under NDA). Sample post-incident RCA from a prior (anonymised) incident if any. Named 24/7 security contact channel.
Q5 — SOC 2 + ISO 27001 attestation date and scope
The question. When was the SOC 2 Type II report last issued? What trust-services criteria are in scope (security, availability, processing integrity, confidentiality, privacy)? When was ISO 27001 last certified? What is the scope statement? Is there ISO 27701 (privacy) or ISO 42001 (AI management) certification?
What good looks like. SOC 2 Type II dated within the last 12 months, covering all five trust-services criteria. ISO 27001 certified with a scope covering the production platform. ISO 27701 increasingly expected. ISO 42001 emerging — vendors should at minimum have a documented roadmap if not yet certified. The actual SOC 2 report available under NDA, not just the certificate.
Diligence flag. SOC 2 Type I only (point-in-time, not the operating-effectiveness test). Older than 12 months. Limited trust-services scope (e.g. security only, no privacy). Vendor will only share the certificate, not the report.
Artefact to request. Most recent SOC 2 Type II report (under NDA). ISO 27001 certificate + Statement of Applicability. ISO 27701 status. ISO 42001 roadmap if applicable.
Q6 — Data retention configurability + deletion path
The question. Is data retention configurable per data category (entries, decisions, audit trails, employee profile)? Can the customer trigger deletion via API? Is there a documented hard-delete path versus soft-delete? Is retention metadata attached per record so the auditor can reconstruct retention compliance on demand?
What good looks like. Per-category retention configuration (timesheet entries 7 years for SOX, audit trails 7 years, employee profile based on local employment law, productivity decisions retention based on the data subject's rights). API-triggered deletion with documented latency. Hard-delete after a defined retention window with audit-trail entry confirming deletion. Per-record retention metadata in the audit trail.
Diligence flag. Single-bucket retention (one retention period for all data categories). No API-triggered deletion. "Soft delete forever" pattern. No per-record retention metadata.
Artefact to request. Retention configuration matrix. Sample API call for deletion. Sample audit-trail entry showing retention metadata.
Q7 — Integration security + SCIM/SSO + service-account hygiene
The question. Is SAML 2.0 / OIDC SSO supported? Is SCIM 2.0 user provisioning supported? How are service accounts (for API integrations) created and rotated? Is there role-based access control? Are there audit logs for administrative actions?
What good looks like. SAML 2.0 + OIDC SSO with major IdPs (Okta, Azure AD, Google Workspace, OneLogin). SCIM 2.0 user provisioning with full lifecycle (create, update, deactivate, delete). Service accounts created via IdP rather than platform-local credentials. RBAC with documented role definitions and least-privilege defaults. Audit logs for all administrative actions including role changes, integration changes, retention changes.
Diligence flag. SSO available only on Enterprise tier with significant uplift. No SCIM provisioning (manual lifecycle management). Service accounts with long-lived credentials. No audit log for administrative actions.
Artefact to request. SSO/SCIM configuration documentation. Service-account rotation policy. Sample audit-log export.
Q8 — Explainability per scoring decision (rule-trace + SHAP + counterfactual)
The question. Walk me through one flagged decision. Show me the per-decision audit-trail JSON. What's the rule version active? What's the model version? What SHAP attribution drove the score? What counterfactual would have flipped the outcome? What reference examples does this resemble?
What good looks like. A per-decision JSON containing decision metadata, input feature values, rule-trace, ML attribution (model ID + version + SHAP values), counterfactual (minimum input change that flips outcome), reference examples (confirmed-similar historical decisions), human-review state, retention class, residency tag, consent reference. Reads naturally to an external auditor without re-deriving analysis.
Diligence flag. Aggregate model metrics ("AUC 0.91") rather than per-decision artefact. SHAP plots as screenshots rather than machine-readable JSON. No rule-trace component. No counterfactual reasoning. No reference-example retrieval.
Artefact to request. Sample per-decision audit-trail JSON in machine-readable form. Schema documentation. We covered the canonical shape in the Article 22 + XAI mapping post and Pillar #5 on AI timesheet scoring.
Q9 — Sub-processor transparency + onward-transfer chain
The question. What is the published sub-processor list? Is each sub-processor's processing activity, data category, geographic location, and transfer mechanism documented? Is the sub-processor-of-sub-processor chain disclosed at least one hop deep? What is the customer notification path for new sub-processors? What is the customer's right to object?
What good looks like. Published sub-processor list at a stable URL (not buried in DPAs). Each entry with entity name, processing activity, data category, geographic location, GDPR transfer mechanism. Onward-transfer chain disclosed one hop deep. Customer notification 30+ days before new sub-processor engagement. Customer right to object with documented escalation path.
Diligence flag. Sub-processor list available only on request (not published). Generic descriptions ("cloud infrastructure provider") rather than named entities. No onward-transfer disclosure. No notification commitment. No right to object.
Artefact to request. Live sub-processor list URL. Sample notification email. Right-to-object procedure.
Q10 — Contractual right to audit + audit-trail JSON export
The question. What contractual right-to-audit clauses are in the base contract? Annual SOC 2 + ISO request? On-demand audit-trail JSON export for any customer-tenant decision? Third-party security audit cadence? Post-incident RCA commitment? Regulator-readiness report supporting customer DPIA refresh?
What good looks like. Annual SOC 2 Type II + ISO 27001 Statement of Applicability request under NDA. Audit-trail JSON export on demand within 5-10 business days. Third-party security audit at customer expense once every 24-36 months. Post-incident RCA within 30 days. Regulator-readiness report on request for DPIA refresh. The right-to-audit clause is non-negotiable for any vendor handling productivity-decision data.
Diligence flag. Right-to-audit clause framed as "may, at vendor's discretion" rather than customer right. No on-demand audit-trail JSON export commitment. No post-incident RCA commitment. No regulator-readiness report path.
Artefact to request. Sample contract right-to-audit clause language. Sample audit-trail JSON export from the platform (live data, not screenshot).
Procurement-decision rubric (pass / hold / walk)
Score each of the 10 questions 0-3 (0 = fail, 1 = partial, 2 = pass, 3 = procurement-floor with documented template). The maximum is 30. The thresholds:
- 26-30: Pass. Sign the contract with standard negotiation on commercial terms only. The platform is procurement-floor on the diligence surface.
- 20-25: Hold. Negotiate amendments to close the 0-1 gaps. Common amendments: customer-controlled per-business-unit residency, contractual breach-notification SLA, customer right to audit, model-version surface in audit trail. If the vendor closes the gaps, sign. If they will not, walk.
- 15-19: Conditional walk. The gaps are structural. Either run a deeper category-frame review (you may be looking at a time tracker, not a productivity intelligence platform — see the 7-criterion decision frame) or look at other vendors. The remediation cost on a 15-19 score is usually 6-12 months of compliance-team work post-signing.
- 0-14: Walk. The diligence floor is unmet. The platform is structurally non-compliant for the EU AI Act Annex III post-August-2026 floor. Procurement remediation is multi-quarter and customer-borne.
Get the downloadable checklist (PDF)
Get the CISO Procurement Checklist — Free 10-question PDF
The structured PDF version of this checklist — with scoring rubric (0-3 per question), vendor evaluation worksheet, and pass / hold / walk decision thresholds. Aligned with EU AI Act Annex III (effective August 2026), GDPR Article 22, SOC 2, ISO 27001, and India's DPDP Act 2023.
Or book a 15-min demoThe diligence companion artefacts are the 7-tool GDPR scoring matrix (for vendor comparison) and the employee monitoring policy template (free policy template PDF).
Free: 5-Signal Productivity Self-Audit Worksheet
30-min audit on your team. Focus depth + commit cadence + meeting load + flow-state + blocker recovery. PDF + Google Sheets calc. For Ops Heads, Founders, Eng Managers.
Frequently asked questions
What should a CISO ask an AI vendor before procurement?
A CISO running diligence on an AI productivity intelligence vendor in 2026 should ask ten questions structured around data residency and cross-border transfer mechanism, employee notice and DPIA template availability, AI model auditability and bias testing methodology, breach notification SLA and escalation path, SOC 2 plus ISO 27001 attestation freshness and scope, data retention configurability and deletion path, integration security including SCIM/SSO and service-account hygiene, explainability per scoring decision (rule-trace plus SHAP attribution plus counterfactual reasoning), sub-processor transparency and onward-transfer chain, and contractual right to audit plus audit-trail JSON export. The structured matrix in this post covers each in depth.
How is AI vendor procurement different from standard SaaS due diligence?
AI vendor procurement adds five risk surfaces that standard SaaS due diligence does not catch. First, AI model auditability — does the vendor have a documented bias-testing methodology, model-version history, and post-market monitoring infrastructure? Second, explainability per decision — does the platform produce per-decision audit trails satisfying GDPR Article 22 and EU AI Act Annex IV technical documentation requirements? Third, training data lineage — what data trained the models, is the lineage documented, are customer-tenant data segregated from training data? Fourth, AI Act conformity assessment — has the vendor produced one for the high-risk classification (Annex III)? Fifth, ongoing AI risk management — what does the platform do when the model drifts, when a new attack surface emerges, when a regulator requests a post-market monitoring report?
What is the EU AI Act Annex III impact on CISO procurement?
AI used to evaluate workers falls within Annex III high-risk classification effective August 2026. The procurement consequence: a vendor selling AI productivity intelligence into the EU after August 2026 must satisfy Annex III obligations including conformity assessment (Art. 43), technical documentation per Annex IV, human oversight architecture (Art. 14), transparency and information to data subjects (Art. 13), accuracy and robustness testing (Art. 15), post-market monitoring (Art. 72), and serious-incident reporting (Art. 73). A CISO running procurement diligence post-August 2026 should ask for the conformity assessment, the Annex IV technical documentation, the post-market monitoring infrastructure description, and the serious-incident response runbook. [needs-legal-review]
What attestation should an AI productivity vendor have?
The 2026 attestation floor for an enterprise-grade AI productivity intelligence vendor is SOC 2 Type II (covering the trust services criteria for security, availability, processing integrity, confidentiality, and privacy as scoped) plus ISO 27001 (information security management). The Type II attestation should be dated within the last 12 months; older attestations are diligence-flagged. Optional but increasingly expected: ISO 27701 (privacy information management), ISO 42001 (AI management system, effective 2024+), HITRUST CSF for healthcare deployments, and FedRAMP Moderate for US government-adjacent. The attestation report itself (not just the certificate) should be available under NDA; if a vendor will not share the report, that is a diligence flag.
How should a CISO test AI model auditability in a demo?
Three demo tests catch most AI auditability gaps. First, ask the vendor to walk through one flagged decision and show the per-decision audit-trail JSON — rule version, model version, feature attribution, counterfactual, reviewer state. Second, ask for the model retraining log — how often the model retrains, what triggers retraining, what regression testing happens before deployment. Third, ask for the bias-testing methodology — what protected classes are tested, what fairness metrics are tracked, what happens when a bias regression is detected. If any of these three degrades the demo, the AI model auditability claim is marketing rather than infrastructure.
What sub-processor transparency should an AI vendor provide?
GDPR Art. 28(2) requires the data processor (the AI vendor) to obtain prior specific or general written authorisation of the controller (the customer) before engaging sub-processors. The 2026 transparency floor: a published sub-processor list with the entity name, the processing activity, the data category, the geographic location, and the GDPR transfer mechanism (SCCs, adequacy, DPF) if the sub-processor is outside the customer's data-residency tier. The vendor should also commit contractually to notification of new sub-processors with a customer right to object. Sub-processors of sub-processors (onward-transfer chain) should be disclosed at least one hop deep. If the vendor will not publish the sub-processor list, that is a diligence flag for any EU + India + UK-spanning deployment.
What contractual right to audit should be in an AI vendor contract?
The 2026 contractual right-to-audit floor includes: a right to request the vendor's most recent SOC 2 Type II report and the ISO 27001 Statement of Applicability annually under NDA, a right to request the audit-trail JSON for any customer-tenant decision on demand (with reasonable response window — 5-10 business days is typical), a right to a third-party security audit at customer expense once every 24-36 months, a right to a post-incident root-cause-analysis report for any security incident affecting the customer's tenant, and a right to a regulator-readiness report supporting customer DPIA refresh on request. The right-to-audit clause should be non-negotiable for any vendor handling productivity-decision data; vendors who push back on it are diligence-flagged.
Further reading
- GDPR-compliant employee monitoring tools — 7-tool scoring matrix
- Explainable AI and GDPR Article 22 — XAI mapping
- EU AI Act time tracking compliance — Annex III obligations
- Pillar #5 — AI timesheet scoring with audit-trail JSON sample
- How to write an employee monitoring policy (with template)
- gStride security posture + SOC 2 / ISO posture
Get the 10-question CISO checklist PDF
Download the 10-question CISO procurement checklist — printable PDF with scoring rubric, response-grading template, and vendor-comparison worksheet. Designed for AI productivity intelligence vendor diligence post-August-2026 EU AI Act enforcement.
Book a 15-min demo Get the playbook