Vendor Security Questionnaire

Questionnaires decide deals and supplier choices, so they get both speed and honesty. When answering, every "Yes" is true today and could be shown to an auditor; overclaiming in a questionnaire can become a contractual misrepresentation. When assessing a vendor, the depth matches the risk: a tool that sees customer data gets real scrutiny, a font licence does not.

When to use

• "A prospect sent us a 200-line security questionnaire, due Friday."
• "Fill in this CAIQ / SIG Lite / custom spreadsheet."
• "We want to start using vendor X; is it safe?"
• "Do our annual review of key suppliers."
• Building a reusable answer bank or trust page content.

What you need

• Incoming: the questionnaire file (from a connected Gmail or Google Drive, or uploaded), the deadline, who is asking and which product or service is in scope.
• Your evidence: policies, architecture notes, hosting details, certifications or audit reports, penetration test summaries, insurance certificate, subprocessors list, previous questionnaires. Read from the owner's drive or ask with clarify.
• Outgoing: the vendor's name, what it will do, what data it will see, what access it gets (SSO, API keys, admin), and the contract stage.

Method A: answering an incoming questionnaire

1. Triage. Count questions, note the format and deadline, and spot questions that need the owner or a lawyer: contractual commitments (breach notice times, audit rights, liability), insurance amounts, data location promises, certifications you do not hold. Send that list to the owner on day one.
2. Start from the answer bank. Keep security/answer-bank.md in the workspace: one entry per common question, with the approved answer, the evidence it rests on, the date last confirmed and who approved it. Reuse approved answers; re-check any older than six months.
3. Answer each question with four parts: response (Yes, No, Partial, N/A), a one or two sentence explanation in plain language, the evidence reference, and any compensating control. Answer the question asked; do not paste a policy.
4. Be exactly truthful:
   • Not in place: "No." Then the compensating control, or "planned for " only if the owner has committed to it.
   • Partly in place: "Partial", saying what is and is not covered.
   • Does not apply: "N/A", with the reason (for example, "we do not store card data; payments are handled by our payment provider").
   • Never answer "Yes" because it is close enough. Never invent certifications, audit dates or staff numbers.
5. Check consistency. Long questionnaires ask the same thing several ways. Make sure related answers agree (encryption, MFA, retention periods, incident notice times) and match the company's policies.
6. Owner review. Mark open items, then give the owner the completed file with a short note: questions needing their decision, answers that create commitments, and items to fix to answer "Yes" next time.
7. Send only on the owner's go-ahead. You never send the questionnaire, reports or evidence to the customer yourself. Audit reports and pen test summaries usually go out only under NDA.
8. Update the answer bank with every newly approved answer.

Method B: assessing a vendor

1. Tier the vendor by data and access:

   Tier	Criteria	Depth
   1	Holds customer personal data, sensitive company data, or has production or admin access	Full review
   2	Holds internal non-sensitive data or has limited integration	Light review
   3	No company data, no access	Basic check

2. Gather public evidence first (web_search, web_extract): trust or security page, certifications (verify an ISO certificate with the issuing certification body where possible), SOC 2 availability, privacy policy, data processing agreement, subprocessors list, data locations, status page and uptime history, breach history in the news, security contact or disclosure programme.
3. For Tier 1, request the SOC 2 Type II report or ISO certificate and Statement of Applicability, and read them properly:
   • SOC 2: auditor's opinion (unqualified or qualified), the period covered, whether the service you will use is in scope, exceptions found and management's responses, carved-out subservice organisations, and the complementary user entity controls your company must run
   • ISO: certificate scope covers the service, certificate is current, issued by an accredited body
4. Ask only the questions the evidence does not answer, using the coverage list in references/vendor-review-checklist.md. A short targeted list gets better answers than a 300-line form.
5. Check the contract terms with the owner: DPA in place where personal data is involved, breach notification time, right to audit or receive reports, data return and deletion at exit, subprocessor change notice, liability and insurance. Legal reviews these.
6. Decide and record: approve, approve with conditions (for example "SSO and MFA must be enforced", "no production data until DPA signed"), or reject. Record the tier, evidence, risks, conditions, decision maker and the next review date (yearly for Tier 1).
7. Keep the vendor register current and set a cronjob for reviews.

Example answers in the four-part format

Q: Do you encrypt customer data at rest?
A: Yes. All customer data is stored in managed databases and object storage with
   provider-managed encryption at rest (AES-256). Evidence: cloud console settings,
   screenshot dated 2026-09-01. Compensating control: n/a.

Q: Do you hold an ISO 27001 certification?
A: No. We are not certified. We follow a written security policy set reviewed yearly
   and can share our policy index and latest penetration test summary under NDA.

Q: Do you perform annual penetration tests by an independent third party?
A: Partial. Our last independent test was in March 2025. The next is scheduled
   for Q1 2027 (owner-approved). Internal vulnerability scanning runs monthly.

Q: Will you notify us of a breach within 24 hours?
A: Flagged for owner and legal: this is a contractual commitment. Our current
   policy commits to notification without undue delay and within 72 hours.

Example dates and commitments above are illustrations; use the company's real ones.

Output

• Incoming: the completed questionnaire in its original format, an "owner decisions needed" list, and updated answer bank entries.
• Vendor assessment: a one-page record using references/vendor-review-checklist.md, plus an updated vendor register row. Summarise the decision on a show_card.

Checks before you finish

• Every "Yes" has evidence you could produce today.
• Related answers are consistent with each other and with policies.
• Commitments and legal questions were flagged to the owner, not answered by you.
• Nothing was sent externally without the owner's go-ahead.
• Vendor decisions record tier, evidence, conditions, decision maker and review date.

Pitfalls

• Overclaiming to win the deal. A false "Yes" can become a breach of contract after an incident. Honest "No, but" answers are normal and accepted.
• Copying last year's answers blindly. Practices change; re-check stale answers.
• Accepting "we're SOC 2 compliant" at face value. Ask for the report and read the scope, period and exceptions.
• Treating every vendor the same. Over-reviewing low-risk tools wastes time that Tier 1 vendors need.
• Ignoring your own duties. SOC 2 reports list controls the customer must run; record them and check you do.
• Sign-off. The owner approves every outgoing answer set and every Tier 1 vendor. Contract terms, liability and data processing agreements need legal review.

Checklist: references/vendor-review-checklist.md. Credits: references/CREDITS.md.