vendor_security_questionnaire v1.0.0

name: vendor_security_questionnaire description: Answer vendor security questionnaires from a reusable evidence library: build and version the library, map each incoming question (SIG, SIG Lite, CAIQ, HECVAT, VSAQ, or custom) to a canonical approved answer with its evidence, flag gaps and partial scope honestly, check consistency against past responses, and handle auditor follow-ups. Use when a customer or prospect sends a security questionnaire, a due diligence spreadsheet, or a follow-up on an earlier answer, or when building the library before the next one arrives.

Vendor Security Questionnaire

Purpose

Stop rewriting the same security answers from scratch for every customer. This skill runs the respondent side of a security review: one versioned evidence library holds the canonical answer and the proof for each control, each new questionnaire is answered by mapping questions to that library, and gaps are named plainly instead of papered over. A prefilled draft alone is not the system. The library, its review cadence, and the consistency check are the system.

Workflow

1. Triage the request before answering anything

Record: who sent it, format (SIG, SIG Lite, CAIQ, HECVAT, VSAQ, custom spreadsheet, portal), due date, product and deployment scope in question, what data the customer would trust you with, and whether an NDA or a secure sharing channel is required for the evidence you will send. Ask one question early: will a current audit report (for example SOC 2 or ISO 27001, if you hold one) satisfy part or all of the request? Many assessors accept the report in place of the sections it already covers. Get the answer in writing and note which sections remain. Set an owner and a deadline that leaves time for subject matter expert review. Do not promise a date before you know the size: a Lite format is a different job from a full SIG Core.

2. Build or refresh the evidence library

One entry per control, not per question. Fields and rules are in references/evidence-library-schema.md. In short, every entry carries: a stable ID, domain, the canonical answer, a response value (Yes, No, Partial, N/A), scope, evidence pointers, framework tags, an owner, a last reviewed date, and an approval status. Use bin/library_tool.py to hold the library as JSON, validate it, and find stale entries:

• init creates an empty library.
• add adds one entry from a JSON file.
• search finds entries by keyword.
• stale lists entries not reviewed within a set number of days.
• check validates required fields, duplicate IDs, and bad dates. Seed the library from the last two or three completed questionnaires plus current policies, not from memory. Where past answers conflict, the current policy and the control owner decide, and the losing wording is deleted, not kept as an alternative.

3. Map the questionnaire to the library

Split the incoming file by domain or tab and work in batches. For each question:

1. Find the matching library entry. bin/library_tool.py reuse does a first pass: give it one question per line and it returns the best matching entry, a confidence band, and the questions it could not match.
2. If the match is exact in substance, reuse the canonical answer word for word. Consistency across customers is a feature: assessors compare notes, and past answers resurface in renewals.
3. If the question asks for a narrower or wider scope than the entry covers, adjust only the scope wording and flag the answer for the control owner.
4. If nothing matches, route it to the control owner as a new draft. A new answer enters the questionnaire only after the owner approves it, and it goes into the library at the same time so the next questionnaire inherits it.

Details on the common formats and their domains are in references/formats-and-domains.md.

4. Answer honestly, with evidence attached

• Every Yes names its evidence: policy name and section, audit report and page or section, a dated test report, or a configuration record. An answer with no evidence pointer is a draft, not an answer.
• Partial means partial. State what is covered and what is not: "Yes for production. The sandbox environment is not covered." Do not let a blanket Yes stand for a control that only covers part of the scope asked about.
• No means No, with a plan. Give the remediation step, a target date the owner has committed to, and any interim measure in place today. Never describe a planned or in-progress control in present tense as if it were live.
• N/A needs a reason tied to scope, such as a service the product does not offer or data it never processes. "N/A" with no reason reads as evasion and draws a follow-up.
• Answer only what was asked. Extra detail creates extra questions and can contradict the library. Keep the canonical length: enough to show the control and how it runs, no more.

5. Run the consistency and staleness pass

Before sending:

• Run library_tool.py check and library_tool.py stale on the library. Any entry used in this response that is past its review date gets re-confirmed by its owner first.
• Compare every answer that differs from what you told the same customer last time. A changed answer is fine when the control changed; it needs a one line note saying what changed and when. An unexplained change is the single most common trigger for a deep follow-up round.
• Search the finished response for the same control answered two ways in different sections. Large formats ask the same thing in several domains. Fix the outlier to the canonical wording.
• Confirm every evidence attachment is the current version, is approved for external sharing, and matches the sharing terms (NDA, portal only, expiry) agreed at triage.

6. Send, log, and handle follow-ups

Send through the channel agreed at triage, never as a loose email attachment when a portal or expiring link was requested. Log the response in the library record: customer, date, format and version, library version used, and the file sent. That log is what makes the next consistency check possible. For follow-ups:

• Treat each follow-up as a request to clarify the answer already given, not to write a new one. Start from the logged response, quote the original answer, then clarify.
• If a follow-up exposes a wrong answer, correct it in writing, correct the library entry in the same pass, and note the correction in the log. Do not quietly change wording and hope it is not noticed.
• If a follow-up asks for evidence you cannot share (raw penetration test detail, another customer's data, internal incident specifics), say what you can share instead: an attestation, a summary, or a call with the control owner under NDA. Offer the alternative in the same reply.
• Track open follow-ups with an owner and a date. A questionnaire is done when the assessor closes it, not when the first file is sent.

7. Close the loop after each questionnaire

Within a week of closing: add new approved answers to the library, retire wording that drew confusion, refresh entries whose controls changed during the review, and record which questions had no library match. A rising no-match count in one domain is a signal that the library, or the control itself, needs work.

Output Contract

For each questionnaire, deliver:

1. The completed questionnaire in the customer's original format and layout, with answers in place and evidence references in the comment or attachment fields the format provides.
2. A cover summary the sender can route internally: format and version, library version used, counts of questions answered from the library, answered new, answered No or Partial, and marked N/A, plus a list of every answer that changed since the last response to this customer and why.
3. A gap list for internal use only: each No or Partial with its owner, remediation step, and committed date.
4. An updated library: new entries added, changed entries re-dated and re-approved, and the response logged.

Operating Rules

• Never invent a control, a certification, a date, a test result, or a policy. If a fact is not in a policy, report, or record you can point to, the answer is a gap, not a guess.
• The library is the single source of truth for wording. Do not keep private answer copies in slide decks, inboxes, or personal drives; they drift and then contradict the library in front of an assessor.
• Only approved entries get sent. Draft entries may fill a working copy but must be approved by the control owner before the response leaves.
• Review cadence: every entry is re-confirmed at least every 12 months, and immediately when the control, the tooling, or the owner changes. Audit reports and penetration tests are refreshed on their own cycle and the library entry is updated when a new one lands.
• Treat questionnaire answers as commitments. Legal or compliance review is required for answers about incidents, regulatory status, contractual terms, and anything forward looking.
• Protect the evidence itself. Audit reports are shared under the terms they were issued with. Check sharing terms before attaching, and redact anything about other customers.
• If quality and time conflict, send fewer finished answers with an honest interim note and a date for the rest, rather than a complete file of unchecked answers.