A vendor security questionnaire should connect the proposed service to questions a reviewer can answer with evidence. This template helps draft that questionnaire before onboarding. It produces requests and a review framework; it does not establish that a vendor is secure, compliant, or approved, and it does not contact anyone.
Define the assessment boundary
Begin with the actual service under consideration. Describe what it will do, which data it will receive, and which access it requires. A dashboard receiving daily aggregates presents a different assessment task from a service that can change production records. Keep the questionnaire tied to the proposed integration rather than a vendor's entire product portfolio.
Separate drafting from decision making. The prompt can organize questions, identify evidence to request, and prepare a risk-summary form. A designated reviewer must examine the answers and decide what remains unresolved. Vendor contact details are routing information, not authorization for an assistant to send a message.
Record the immediate stage: an initial conversation, a limited pilot, or a proposed production onboarding. Questions can then refer to the relevant environment. If production access is not proposed, the questionnaire should not imply that it has already been granted. If the scope is uncertain, make scope clarification the first outstanding question.
Complete the seven inputs consistently
Replace VENDOR_NAME, VENDOR_CONTACT, SERVICE_DESCRIPTION, DATA_TYPES_COLLECTED, ACCESS_REQUIRED, COMPLIANCE_REQUIREMENTS, and CONSTRAINTS. Preserve capitalization exactly, including the full uppercase spelling of COMPLIANCE_REQUIREMENTS. Use not supplied when a value is unavailable instead of filling the gap with a plausible vendor detail.
Describe data at a useful level without pasting actual customer records, secrets, or access tokens. State whether the proposal includes identifiers, free text, attachments, or aggregate counts. Identify relevant restrictions supplied by your organization, such as an approved dataset boundary or a prohibition on administrative access. Treat those restrictions as requested conditions to investigate, not proof that the integration enforces them.
Use COMPLIANCE_REQUIREMENTS to record requirements supplied by the responsible organization. The prompt should not decide which laws apply or interpret a certification as permission to proceed. If no external standard has been specified, say so and request clarification from the appropriate owner. The questionnaire can still address the concrete data and access described.
Ask questions that produce usable answers
Cover the nine requested areas: data handling, access controls, authentication, encryption, monitoring and logging, incident response, compliance certifications, subcontractors, and retention or deletion. Tailor each area to the service. For an aggregate reporting endpoint, ask what fields are received and retained rather than assuming raw individual records are uploaded.
Give each question an identifier, a reason for asking, a requested evidence type, and an answer-status field. Ask one substantive question at a time. A single question combining encryption, key access, log retention, and incident notification can receive a vague answer that leaves the reviewer unable to tell which part was addressed.
Request the scope of supporting material. An access-control diagram should identify the proposed integration path. A certification claim should be accompanied by the relevant document and its stated scope. A deletion answer should distinguish the active service from any other copies the vendor says it maintains. These are proposed evidence requests, not assertions about how a particular vendor operates.
Worked fictional example: an aggregate dashboard
Consider a fictional service being evaluated for a warehouse reporting pilot. Its example input is:
VENDOR_NAME: Larch Metrics, a fictional vendor.VENDOR_CONTACT: [email protected], a fictional address.SERVICE_DESCRIPTION: Hosted dashboard displaying daily warehouse order totals.DATA_TYPES_COLLECTED: Warehouse code, calendar date, and order count; individual order records are outside the proposal.ACCESS_REQUIRED: Read-only access to one aggregate API endpoint; no production administrative access.COMPLIANCE_REQUIREMENTS: Internal security checklist; external certifications have not been specified.CONSTRAINTS: Draft only. Do not contact the vendor. Any pilot must use synthetic data. Human review is required before onboarding.
A tailored access question could ask how the connector's permissions are limited to the aggregate endpoint and what evidence demonstrates that it cannot access individual orders. Suggested evidence might include a redacted scope configuration and a documented access test. The answer status remains not supplied until material is actually received and reviewed.
A data-handling question could ask whether warehouse codes or aggregate totals appear in diagnostic logs. Its purpose is to clarify a possible additional copy of the proposed dataset. It should not claim that such logging occurs. An incident-response question could ask who coordinates communications if access credentials are exposed, without assuming an incident has happened.
The example risk summary would record unknown enforcement of the proposed access boundary, evidence requested, an unassigned review owner, and a pending decision. It would not label the fictional vendor as having failed merely because the drafting input contains no answers.
Evaluate evidence separately from vendor statements
Keep an answer and its supporting material in different fields. A vendor statement that access is restricted is a claim to review. A configuration excerpt, policy, report, or demonstration may support that claim, but the reviewer still needs to assess relevance to the proposed service. The prompt should leave that assessment open when the material is absent.
Record a document's supplied title, version or date, scope, and relevant section when available. Do not invent these details to make the evidence register look complete. If a document refers to a different product or environment, note the mismatch and ask what evidence covers the integration being considered.
Use explicit statuses such as not supplied, answer received, evidence pending, reviewer confirmed, and clarification required. Define what your team means by reviewer confirmed before using it. Avoid collapsing an unanswered question, an unsupported assertion, and a verified control gap into one negative label; they call for different follow-up work.
Prioritize without manufacturing a security score
Request a proposed weighting guide that distinguishes decision-critical questions from supporting and informational questions. Tie each proposed critical item to a supplied requirement or an identifiable integration dependency. For the fictional pilot, the prohibition on administrative access makes the connector's permission scope a candidate for explicit review before onboarding.
If the inputs do not establish criticality, label the classification proposed and request confirmation. Do not allow a large number of answered background questions to conceal an unresolved access boundary. Conversely, do not treat a missing answer as evidence of a specific vulnerability. The reviewer needs to know whether the issue is uncertainty, a demonstrated mismatch, or a question outside scope.
If an organization requires numeric scoring, ask it to supply the scale, weights, and decision rules. Keep unanswered items visible alongside the score. The template should not create a universal passing threshold or suggest that an aggregate number establishes compliance, authorization, or suitability for the proposed use.
Prepare a decision handoff with accountable unknowns
The risk-summary template should include the service scope, data involved, requested access, evidence reviewed, unresolved questions, possible consequences, proposed conditions, owner, and next review step. Leave fields blank or marked not supplied when the responsible person has not provided them. A complete-looking form with invented owners is less useful than an honest pending item.
Make follow-up questions answerable. Instead of asking for more security detail, ask which role can change connector permissions or whether the stated deletion process covers the proposed dataset. Identify the answer or artifact needed to close each item. Keep any proposed condition separate from a condition the organization has actually accepted.
Record who may make the final onboarding decision and where that decision belongs. The prompt's output can support a review meeting or an evidence request. It should not automatically update a procurement status, grant credentials, or send the drafted questionnaire. Those actions require their own authorized workflow.
Limitations and next steps
A generated questionnaire is a starting document. It does not validate a certificate, inspect vendor systems, test an integration, or determine legal obligations. The quality of the review depends on the supplied scope, the answers obtained, the evidence examined, and the responsible reviewers' judgment. Keep those dependencies visible in the resulting record.
Start with the fictional example or a sanitized proposal. Remove questions unrelated to the service, confirm the proposed critical items, and assign owners for the remaining unknowns. Then collect answers through your approved process and review the actual evidence before completing the risk summary. Revisit the questionnaire if the data or access proposal changes.
For organizing the human review stages, see Choose a workflow before an autonomous agent. For assessing how a future integration will separate reads from consequential operations, see Plan MCP integration around data and actions. Keep that integration design distinct from the questionnaire's evidence-gathering role.