The best vendor question is not the one that produces a confident yes. It identifies an owner, tests a scenario, requests evidence, exposes an exception and connects the answer to a proposal or contract.
Use the questions below after defining your requirements and operating model. Select the ones that can change the decision; do not send a hundred-item questionnaire that rewards polished writing. Ask suppliers to mark what is standard, configured, customised, third-party, planned or excluded.
Use the five-part question pattern
Start with ownership: who performs the work and who approves it? Add your scenario and data. Ask which log, report, test or document proves the answer. Introduce an exception. Finally, ask where the commitment appears in the proposed service, statement of work or contract.
Compare "Do you support data export?" with: "Using a representative account, show a complete export including attachments, relationships, audit history and field definitions; state the format, limits, completion time, assistance and contractual location." The second question can produce evidence and expose cost.
Product fit and boundaries
- Which parts of our three critical scenarios are standard, configured, customised or dependent on another product?
- Show the proposed edition completing the exception path, not only the normal path.
- Which requirements are not supported today? What alternative do existing customers operate?
- Which limits apply to users, records, storage, transactions, APIs, automation or reports, and how are limits measured?
Ask for a demonstration record and written boundary. "Supported" can mean a roadmap, partner extension or manual service. The classification matters to cost, ownership and upgrade risk.
Implementation and operating ownership
- Who is accountable for design, configuration, migration, integration, testing, training and cutover?
- What inputs and decisions must the buyer provide, by when, and what happens when they are late?
- Which roles and skills will we need after launch? Which changes require supplier or partner intervention?
- Show a recent anonymised implementation plan and the acceptance evidence used at each gate.
Request names or role profiles for the proposed delivery team where appropriate. Distinguish the product supplier, reseller, implementation partner and subcontractor. A responsibility matrix without deliverables and acceptance conditions is only a contact list.
Data, integration and portability
- For each important data element, where is it stored, processed, backed up and accessible to support personnel?
- Show import, export and API behavior with our representative volumes, relationships and error cases.
- How are integration failures detected, retried, reconciled and communicated? Who owns an end-to-end incident?
- What data, metadata, configuration and history can we retrieve at exit, in which formats, how quickly and at what cost?
Ask for a sample export early enough to test it. Count records, open attachments, inspect relationships and test encoding and dates. Portability is demonstrated usability, not the existence of an export button.
Security and privacy evidence
- Map security responsibilities between us, you, the hosting provider and subcontractors. Which controls remain ours?
- How do you manage secure development, vulnerability reports, remediation priority and customer notification?
- Show how privileged access is granted, reviewed, logged and revoked, including support access.
- Which independent assessments or test reports cover the proposed service and period? How can we review scope and exceptions?
- How are tenant data, backups and logs deleted or retained after termination?
The NCSC's shared-responsibility model and CISA's Secure by Design guidance are useful prompts: buyers need to understand the boundary, while suppliers should make secure outcomes easier rather than shifting every burden to customers. Evidence must match the actual edition, architecture and delivery chain.
Reliability, support and recovery
- Which service indicators are measured, which targets are contractual and which events are excluded?
- Show the incident communication process, severity rules, escalation route and a redacted post-incident review.
- What recovery time and recovery point apply to the proposed service? When was restoration last tested?
- Which dependencies can degrade the service without breaching your stated availability, and how will we know?
Translate percentages into your workload. Ask what the user experiences, what evidence you receive and what remedy or decision follows. Support response time is not the same as service recovery.
Commercial model and change
- List every price driver and the source used to measure it. Model our baseline, growth and stress scenario.
- Which implementation, environment, integration, support, storage, API, training and exit costs are excluded?
- How can packaging, price, limits or included functions change during the term and at renewal?
- What happens to our configuration and integrations when the product changes? Which notice and test environment do we receive?
Request one consolidated assumptions sheet. If two suppliers calculate "user", "transaction" or "storage" differently, normalise the model before comparing totals.
Product direction and supply chain
- Which proposed capabilities depend on roadmap delivery? Who approved the date, and what remedy applies if it slips?
- Which critical components, hosting services, partners or subcontractors affect delivery and security?
- How are material supplier or architecture changes assessed and communicated?
- Which functions have been retired in the last two years, and how were customers migrated?
NIST's supply-chain risk guidance supports looking beyond the contracting entity. The goal is not to demand a complete component inventory in every sales meeting, but to understand critical dependencies and how risk is governed.
Recognise weak response patterns
| Response | Why it is weak | Useful follow-up |
|---|---|---|
| "Yes, we support that." | no boundary or evidence | show the scenario in the proposed edition |
| "It is on the roadmap." | date and commitment may be unowned | classify as unavailable; request approved commitment and remedy |
| "Our customers usually…" | may hide buyer effort or a partner service | name the responsible role, steps and cost |
| "We are compliant." | scope, period and exception are unknown | identify the applicable requirement and evidence scope |
| "That is unlimited." | technical or fair-use limits may remain | provide measured limits and stress behavior |
Convert the meeting into a decision record
Maintain a ledger with the question, requirement or risk, supplier answer, observed evidence, condition, status, owner, deadline and proposal or contract location. Use verified, conditional, gap and not tested rather than a binary yes/no.
After the meeting, send only unresolved items and the exact acceptable evidence. Update evaluation scores when evidence arrives, not when reassurance is repeated. Before signature, trace every decision-critical promise to a durable document and assign an internal owner to verify it during implementation and operation.
The purpose of vendor questioning is not to catch a supplier out. It is to make responsibilities, limits and evidence clear enough that both parties understand what must be delivered.