8 questions from the RFI stage, free
These come from the module as sold. The workbook adds follow-ups, a response format, a weight and a score column to each.
1. Which independent security certifications and attestations do you currently hold (e.g., SOC 2 Type II, ISO/IEC 27001, FedRAMP), and what is the renewal cadence for each?
Why it matters. Third-party attestations are the baseline evidence that a vendor's security program is independently validated rather than self-asserted. Certifications and attestations also require recurring external audit.
- Lists specific, current attestations with auditor and report date.
- Offers SOC 2 Type II report under NDA without sales gating.
- ISO/IEC 27001 certificate with statement of applicability available.
- Holds only self-assessments or 'in progress' certifications with no target date.
- Refusal to share reports until late in the contract negotiation process.
- Lapsed certifications or unclear renewal status.
2. Which cloud or hosting providers operate the production infrastructure for the product, and in which geographic regions can customer data be processed and stored?
Why it matters. Sub-processor and data residency disclosure is a baseline requirement. Buyers must align vendor hosting with their own regulatory commitments (e.g., GDPR Chapter V rules on transfers outside the EEA) and assess sub-processor concentration risk.
- Names specific cloud providers (e.g., AWS, GCP, Azure) and regions.
- Offers customer choice of region at onboarding or on a per-workload basis.
- Provides clear data residency commitments in contracts or documentation.
- Refuses to disclose hosting providers or regions.
- No region selection is available for customers.
- The sub-processor list is missing, out of date, or only available upon request.
3. Specify the encryption algorithms, modes, and minimum key lengths used to protect customer data in transit and at rest across all service components (e.g., application, primary data stores, backups, logs, vector databases, model caches).
Why it matters. Generic 'encrypted in transit and at rest' claims are insufficient. Buyers need cipher and key specifics that match their cryptographic policies, especially for new data tiers introduced by AI products (like vector stores) that are easy to miss.
- Specifies TLS 1.2+ with strong, named cipher suites for data in transit.
- Uses AES-256-GCM or an equivalent modern AEAD cipher for data at rest.
- Confirms encryption coverage explicitly includes backups, logs, and all AI-related data stores.
- Only provides generic claims like 'we use AES encryption' without specifics.
- Backups, logs, or other secondary data stores are not encrypted.
- Vector stores or prompt caches are unencrypted.
4. List the enterprise identity standards you support (e.g., SAML 2.0, OIDC, SCIM) and indicate the product tiers where each is available.
Why it matters. Single Sign-On (SSO) and automated user provisioning (SCIM) are baseline requirements for enterprise deployment. Gating these core identity standards behind premium pricing ('SSO tax') runs against CISA's Secure by Design guidance, which asks vendors to offer standards-based SSO in the baseline product at no extra cost.
- Supports both SAML 2.0 and OpenID Connect (OIDC) for SSO.
- Supports SCIM 2.0 for automated user provisioning and deprovisioning.
- SSO/SCIM is available on all paid tiers without a significant premium upcharge.
- SSO/SCIM is restricted to the most expensive enterprise plan only.
- No SCIM support, requiring manual user provisioning.
- Relies on a custom or proprietary federation protocol instead of standards.
5. Describe your secure software development lifecycle (SDLC), including your approach to threat modeling, code review, static (SAST) and dynamic (DAST) security testing, and management of third-party dependencies (including transitive dependencies and SBOM generation).
Why it matters. A secure SDLC is meant to catch vulnerabilities before they reach production. This also provides insight into software supply chain security.
- References NIST SSDF or a similar framework like BSIMM.
- Names specific SAST, DAST, and Software Composition Analysis (SCA) tooling in use.
- Produces Software Bills of Materials (SBOMs) in a standard format (e.g., CycloneDX, SPDX) for releases.
- Vague references to 'best practices' without naming specific tools or frameworks.
- No SBOM generation capability.
- Threat modeling is performed ad-hoc or not at all.
6. How is tenant isolation implemented in your multi-tenant architecture? Describe the mechanisms preventing cross-tenant data access at the application, data, and infrastructure layers, including for shared resources like vector stores or model caches.
Why it matters. Multi-tenant AI products can expose one tenant's data to another through shared model context, vector stores, or caches. Buyers need a clear picture of where logical, cryptographic, or physical boundaries are enforced.
- Describes logical isolation using tenant-scoped identifiers enforced at the data layer.
- Uses per-tenant encryption keys or namespace separation in storage systems.
- Documents specific controls to prevent cross-tenant leakage in shared AI components (e.g., vector databases).
- Isolation is described only at the application layer without data-layer controls.
- No discussion of isolation for AI-specific components like vector stores or prompt caches.
- Uses shared credentials or databases without logical separation.
7. Do you support customer-managed encryption keys (CMEK / BYOK) via a cloud key management service? If so, for which data tiers does this capability apply?
Why it matters. Some regulated buyers require customer-managed keys. They give the customer control over the data lifecycle (e.g., crypto-shredding on offboarding). Partial coverage can omit backups, logs, or vector stores.
- CMEK is supported via major cloud KMS providers (AWS KMS, GCP KMS, Azure Key Vault).
- Coverage extends to all customer-data tiers, including primary stores, backups, and logs.
- Customers can revoke key access to trigger crypto-shredding of their data.
- CMEK is unavailable or only offered on the highest-priced enterprise tier.
- Coverage is limited to the primary data store, excluding backups or logs.
- Customer key revocation is not supported or does not result in data being made unreadable.
8. Is multi-factor authentication (MFA) enforced for all administrative and privileged operations performed by your personnel on production systems and customer data?
Why it matters. MFA enforcement on privileged access is a primary control against credential compromise. Vendors who only 'support' MFA without enforcing it for their own staff are exposed to phishing and credential reuse attacks that can impact customers.
- MFA is enforced for all personnel using phishing-resistant factors (e.g., FIDO2/WebAuthn).
- Conditional access policies are used to block non-MFA'd access attempts.
- MFA is required for both infrastructure access (e.g., VPN, SSH) and application admin consoles.
- MFA is optional for staff.
- Relies on weak MFA factors like SMS or email.
- No phishing-resistant factors are supported or enforced.
What the audit changed
A language model drafted these questions and a second model critiqued them. Three audit passes followed and made 148 changes. Three examples:
Wrong or outdated citation
Draft: Documents annual renewal cadence and continuous monitoring posture.
Now: Documents the audit cycle for each item (e.g., ISO/IEC 27001 three-year certification cycle with annual surveillance audits; the period each SOC 2 Type II report covers).
An ISO/IEC 27001 certificate is issued for three years with annual surveillance audits (ISO/IEC 17021-1 certification cycle); it is not renewed annually. SOC 2 has no renewal; each report covers a stated period (AICPA).
Wrong or outdated citation
Draft: (e.g., GDPR, CCPA)
Now: (e.g., GDPR Chapter V rules on transfers outside the EEA)
CCPA/CPRA sets no data residency or transfer restriction; GDPR restricts transfers in Chapter V (Arts. 44-49), not hosting location as such.
Wrong or outdated citation
Draft: The Business Continuity Plan (BCP) is independently audited as part of SOC 2 or a similar attestation.
Now: The Business Continuity Plan (BCP) is independently audited, e.g., in a SOC 2 report with the Availability criteria in scope, or a similar attestation.
A SOC 2 report covers business continuity in part even with only the Security category in scope: CC9.1 requires risk mitigation activities for potential business disruptions. Testing of recovery plan procedures is criterion A1.3, which applies only when Availability is in scope (AICPA 2017 Trust Services Criteria, revised points of focus 2022; https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). (Source corrected in pass 3.)
