A vendor security questionnaire is a means to a decision: can we trust this supplier with this data or this function, and on what conditions? Questionnaires fail when they become a ritual, sent identically to every vendor, returned full of yes answers, and filed without anyone reading them. This template gives you a starting structure with scoring. The guidance below covers which domains to ask about, how to weight answers, when to skip the questionnaire, and how to spot answers that deserve a follow-up call.
Question domains and what good answers look like
Add domains when the service warrants it: secure development for software vendors, model training and data use for AI providers, physical security for data center or logistics suppliers, and privacy obligations such as GDPR Article 28 processor terms where personal data is involved.
Scoring that reflects what matters
Flat scoring, where every yes earns one point, rewards vendors for volume rather than for the controls that protect you. A more useful model has three layers:
- Knockout questions. A small set where a wrong answer stops approval pending remediation or exception, such as no MFA on administrative access to customer data, or no commitment to notify you of breaches.
- Weighted domains. Weight domains by relevance to the engagement. Data handling and access control might carry the most weight for a SaaS vendor holding customer data; continuity carries more for a payments processor.
- Answer quality. Score partial or conditional answers between full and zero, and give credit only for evidence-backed answers on high-weight questions.
Illustrative outcome bands
Scale the questionnaire to the vendor tier
Sending the full question set to a vendor that never touches your data wastes both sides' time and trains vendors to answer carelessly. Use your vendor tiering model to decide depth: a short form for low-risk vendors, the core set for moderate risk, and the full set plus evidence review for critical vendors. The vendor risk program guide covers how intake, tiering, and assessment connect.
Reviewing a SOC 2 report or ISO certificate properly
- The service and systems you use are within the report or certificate scope
- The SOC 2 period is recent; request a bridge letter covering the gap to today
- Exceptions noted by the auditor are read and assessed, not skipped
- Subservice organizations that were carved out are identified, since their controls are not tested in the report
- Complementary user entity controls are listed and assigned to owners on your side
- ISO certificates come from an accredited certification body, are in date, and the statement of applicability is available on request
Red flags worth a follow-up
- Every answer is yes, including questions that do not apply to the service.
- Policies are offered as evidence for operational questions, such as a policy document in response to asking for last access review results.
- A certification is claimed but the scope covers a different product or entity.
- Vague incident notification commitments, such as notifying 'promptly' with no contractual backing.
- Refusal to name subprocessors that will hold your data.
Framework requirements for supplier assessment
ISO/IEC 27001:2022 Annex A 5.19 through 5.22 require processes for supplier security, security requirements in supplier agreements, ICT supply chain risk, and monitoring supplier services, with 5.23 covering cloud services. SOC 2 CC9.2 addresses assessing and managing vendor risk. NIST CSF 2.0 covers this under GV.SC, cybersecurity supply chain risk management. PCI DSS 4.0.1 Requirement 12.8 expects due diligence before engaging service providers and monitoring their compliance status at least once every 12 months. HIPAA requires business associate agreements under §164.308(b). The third-party risk glossary entry defines the broader discipline.
Asurvo's Third Party product brings vendor inventory, tiering, questionnaires, risk scoring, and continuous monitoring together, so a questionnaire result becomes part of the vendor's risk record rather than an attachment in someone's inbox.