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 hosting models do you offer for this product: multi-tenant SaaS, single-tenant SaaS (dedicated tenancy), customer-cloud / BYOC, on-premises, or hybrid? Indicate which are generally available versus in preview.
Why it matters. Buyers with regulated or sensitive workloads may need deployment options beyond shared SaaS. Establishing the menu of supported hosting models up front determines whether the vendor can meet the buyer's substrate constraints at all, before evaluating any features.
- Names each hosting model offered and its GA status
- Distinguishes shared SaaS from dedicated/single-tenant SaaS clearly
- Identifies which model is the default and which are uplift options
- Only multi-tenant SaaS available with no roadmap for higher isolation
- Conflates 'dedicated database' with 'single-tenancy'
- Lists hosting models as available but cannot name a reference customer using them
2. List the regions in which the product is generally available for production use, including the underlying cloud-provider region identifier for each.
Why it matters. Region availability is the first gate for buyers with data-residency, latency, or sovereignty requirements. Tying each region to a cloud-provider region identifier removes ambiguity about where data physically resides.
- Provides a table of each region with its cloud-provider region identifier
- Distinguishes GA regions from preview or roadmap regions
- Identifies any regions reserved for specific tiers or contracts
- Provides only continental groupings ('Europe', 'APAC') without specifics
- Cannot map vendor region names to underlying cloud-provider regions
- Adds new regions only above a minimum contract value it does not disclose
3. Describe your multi-tenancy model. At which layers (compute, storage, database, network, model-serving) is infrastructure shared between tenants versus dedicated per tenant?
Why it matters. 'Single tenant' can mean dedicated database but shared compute, or vice versa. Buyers need a layer-by-layer picture to assess isolation risk and to validate marketing claims against actual architecture.
- Provides a layer-by-layer breakdown of shared vs. dedicated resources
- Identifies tenant-scoped encryption boundaries and key management practices
- Describes how a tenant identifier is propagated and enforced throughout the stack
- Provides only a generic 'logically isolated' claim with no architectural detail
- Cannot identify where the tenant boundary is enforced at each layer
- Uses a shared model-serving layer without per-tenant resource or security isolation
4. Do you support private connectivity (e.g. AWS PrivateLink, Azure Private Link, GCP Private Service Connect) between the buyer's cloud environment and your product? List supported options.
Why it matters. Some enterprise buyers prohibit production traffic to SaaS endpoints over the public internet. Private connectivity availability and pricing significantly affects deployment cost and risk posture.
- Names specific private-connectivity options for each major cloud provider
- Indicates which pricing tiers include private connectivity vs. which charge extra
- Supports private connectivity in all GA regions or clearly lists exceptions
- No private connectivity available
- Private connectivity is available but its price is not disclosed
- Available only in selected regions (e.g., us-east-1 only) without disclosure
5. Which underlying cloud provider(s) host your SaaS offering, and can the buyer choose among them at provisioning time?
Why it matters. Buyers may have cloud-provider preferences driven by existing contracts, data-residency posture, or concentration-risk policies. Knowing the substrate also affects shared-responsibility analysis and sub-processor disclosure.
- Names specific cloud providers (e.g. AWS, Azure, GCP)
- States whether buyer can select the cloud provider at signup
- Discloses any provider-specific feature differences
- Refuses to name the underlying cloud provider
- Single-cloud only with no plan to support others when buyer policy requires it
- Cloud choice exists but its price is not disclosed
6. Can the buyer pin all customer data — including primary storage, backups, logs, caches, and any model invocation traffic — to a chosen region or set of regions?
Why it matters. Region pinning may apply to primary storage only while backups, telemetry, or model-inference traffic go to other regions. Buyers under GDPR, sectoral data-residency, or sovereignty rules need a complete picture.
- Enumerates each data category (storage, backups, logs, inference) and confirms where it resides
- Confirms backups and DR copies remain within chosen region(s) or jurisdiction
- Confirms logs and telemetry can be pinned to a region
- Pins primary data only while backups or logs are sent to other regions
- Model inference routes to a different region than primary storage without buyer control
- Refuses to enumerate data categories and their residency status
7. What controls prevent one tenant's data, prompts, embeddings, or model outputs from being returned to another tenant?
Why it matters. Cross-tenant leakage can occur through shared caches, vector indexes, or prompt-logging pipelines. Buyers need to understand the specific controls and their assurance basis.
- Uses tenant-scoped encryption keys for data at rest
- Employs per-tenant vector indexes or namespaces within a shared index
- Tenant ID is enforced in the storage and database layer, not just the application layer
- Relies solely on application-level filtering to enforce tenancy
- Uses a shared vector store with tenant filtering performed only at query time
- Cannot describe any explicit cross-tenant leakage testing in their SDLC or penetration tests
8. Can buyers restrict inbound access to the product (UI and API) by IP allowlist?
Why it matters. Network-level access restrictions remain a meaningful defense-in-depth control for sensitive workloads. Lack of allowlisting at the vendor's edge can force buyers into more complex and costly compensating controls.
- Native IP allowlist available per tenant, configurable via UI or API
- Allowlisting supports both UI and API endpoints
- Allowlist changes are audited
- No IP restriction capability is available
- Available only via a professional services engagement or manual support ticket
- Allowlisting applies to the UI but not API endpoints, or vice versa
What the audit changed
A language model drafted these questions and a second model critiqued them. Three audit passes followed and made 151 changes. Three examples:
Wrong or outdated citation
Draft: Cites relevant attestations or accreditations (e.g. C5, G-Cloud, FedRAMP, SecNumCloud)
Now: Cites relevant attestations or accreditations (e.g. C5, FedRAMP, SecNumCloud)
G-Cloud is a UK public-sector procurement framework, not an attestation or accreditation. Listing on it says nothing about sovereignty controls. It is run by the Government Commercial Agency (Crown Commercial Service until 1 April 2026). G-Cloud 14 (RM1557.14) runs to 28 October 2026 and is replaced by G-Cloud 15 (RM1557.15). Sources: https://www.gca.gov.uk/agreements/RM1557.14, https://www.gca.gov.uk/agreements/RM1557.15 (Source corrected in pass 2.)
Wrong or outdated citation
Draft: Federal civilian agencies and a growing share of enterprise buyers operate under IPv6-mandate policies.
Now: US federal agencies operate under OMB M-21-07, which sets IPv6-only targets for agency networks (80% of IP-enabled assets by the end of FY2025) and requires new federal systems to be IPv6-enabled at deployment from FY2023.
Named the mandate; 'a growing share of enterprise buyers' had no source. OMB Memorandum M-21-07, 'Completing the Transition to Internet Protocol Version 6 (IPv6)', 19 November 2020: https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf
Wrong or outdated citation
Draft: Supports request signing (e.g., HTTP Signatures) or proof-of-possession tokens
Now: Supports request signing (e.g., HTTP Message Signatures, RFC 9421) or proof-of-possession tokens (e.g., DPoP, RFC 9449)
'HTTP Signatures' was an expired IETF draft (draft-cavage-http-signatures); the published standard is RFC 9421, HTTP Message Signatures (February 2024). DPoP is RFC 9449. Sources: https://www.rfc-editor.org/rfc/rfc9421, https://www.rfc-editor.org/rfc/rfc9449
