Menu
A vendor security questionnaire response should turn each customer question into a scoped claim, connect the claim to current evidence, route exceptions to the right owner, and preserve the approved answer for reuse. The workflow below covers all four jobs without treating an old answer as permanent truth.
Security questionnaires are common in customer due diligence, but SOC 2 does not universally require a questionnaire. The AICPA Trust Services Criteria require organizations to assess and manage risks from vendors and business partners under CC9.2; they do not prescribe one assessment form. Your controls, contracts, customer requirements, and the vendor’s risk determine which records you need.
What is a vendor security questionnaire?
A vendor security questionnaire is a set of questions a customer sends to a supplier to evaluate security, privacy, resilience, and third-party controls. The supplier answers from its actual control environment and supports material claims with reports, policies, test results, or other current evidence.
The same term is used from two viewpoints:
- A buyer uses the questionnaire to assess a prospective or existing vendor.
- A supplier answers the questionnaire during a customer’s security review.
This guide is for the supplier-side response team: security, governance, risk and compliance (GRC), sales engineering, privacy, legal, and the system owners who verify individual answers. For the buyer-side lifecycle — inventory, risk tiers, approval, contracts, monitoring, and offboarding — use the SOC 2 vendor management requirements guide.
How should you answer a vendor security questionnaire?
Answer a vendor security questionnaire in six steps: confirm scope, assign owners, draft from approved material, verify each claim against current evidence, escalate gaps or disclosure restrictions, and retain the approved submission. A named response owner should control the form from intake through archive.
NIST’s October 2024 Cybersecurity Framework 2.0 supply-chain guide emphasizes defined supplier requirements, coordinated roles, risk-based due diligence, recorded decisions, and monitoring. Those same disciplines make an outbound questionnaire response reviewable rather than improvised.
- Confirm the request and scope. Record the customer, deadline, product or service, deployment model, data involved, contractual context, required questionnaire edition, and confidentiality restrictions. Ask whether the customer accepts an existing security package before duplicating work.
- Triage questions by owner. One response owner manages the file. Route identity and access questions to security or IT, architecture and encryption questions to engineering, privacy questions to the privacy owner, contractual promises to legal, and recovery objectives to the business continuity owner.
- Draft from approved answers. Reuse an answer only when its applicability, evidence, review date, and approver still match the request. Copying a similar sentence from an old customer file is not enough.
- Verify the claim and evidence. Check the source record, not just the prose. Confirm dates, system scope, exceptions, report periods, and whether the evidence may be shared. Replace absolute words such as “all,” “always,” and “never” unless the evidence supports them across the stated scope.
- Resolve exceptions before submission. Route partial controls, missing evidence, stale reports, conflicting customer wording, and new contractual commitments to the appropriate owner. Record the decision instead of editing an inconvenient question into a “yes.”
- Approve, submit, and retain. Have security or GRC review the completed form; add legal or privacy approval where the answers create obligations. Save the final version, approval record, evidence references, submission date, and customer-specific deviations.
The retained record matters because the next questionnaire may ask the same control in different words. It also gives your team a dated account of what it represented to a specific customer.
What evidence should support each answer?
Evidence should match the exact claim, system scope, and time period in the answer. Use a policy for stated requirements, configuration or system output for implemented controls, and dated test records for operating effectiveness. Do not attach sensitive evidence merely because a question asks for it.
The examples below are response patterns, not claims to copy. Replace bracketed text only after the named owner verifies the value.
| Question domain | Defensible answer pattern | Evidence to verify internally | Escalate when |
|---|---|---|---|
| Security governance | “Yes. The information security policy applies to [scope], is owned by [role], and was last approved on [date].” | Approved policy, version history, owner, acknowledgment or review record | The policy is draft, overdue for review, or narrower than the answer |
| Identity and access | “Production access uses [identity provider], requires [authentication control], and is reviewed every [approved cadence].” | Identity-provider configuration, access-review record, joiner/mover/leaver tickets | A system sits outside the stated control or the last review missed its cadence |
| Encryption and key management | “Customer data in [named service boundary] is encrypted in transit using [verified protocol] and at rest using [verified control].” | Architecture/data-flow record, cloud or application configuration, key-management procedure | The question says “all data,” but the evidence covers only selected stores or environments |
| Vulnerability and penetration testing | “The last independent penetration test ended on [date]; [summary status] and tracked remediation are available under [disclosure condition].” | Test report, executive summary, findings register, remediation tickets | The test is stale, material findings remain unresolved, or the customer requests the full report |
| Incident response | “The incident response plan was last exercised on [date]. Customer notification follows [approved contractual or policy rule].” | Current plan, tabletop record, incident communications procedure, contract terms | The requested notification deadline is not already approved in policy or contract |
| Availability and recovery | “The approved recovery time objective is [value] and the recovery point objective is [value] for [service]. The last recovery test occurred on [date].” | Business continuity plan, service-level objective, recovery test result | Sales material, policy, and tested results state different values |
| Privacy, subprocessors, and data location | “The service processes [data categories] in [locations] and uses the subprocessors listed at [controlled source].” | Data inventory, data-flow map, DPA, subprocessor register, retention schedule | The request needs a new residency, deletion, or subprocessor commitment |
| Independent assurance | “The current [SOC 2 report or certification] covers [entity/service] for [period or validity date]. Access is available under [condition].” | Issued report or certificate, scope statement, report period, bridge material if applicable | The report period has ended, scope does not cover the product, or an exception affects the answer |
Customer evidence and SOC 2 audit evidence overlap, but they are not interchangeable. A customer may accept a SOC 2 report, policy excerpt, test summary, or trust-center statement. A SOC 2 auditor evaluates whether evidence is sufficient for the control being tested. The SOC 2 evidence collection guide explains that audit-side process in depth. Teams handling recurring customer requests can also compare trust center software by controlled access, questionnaire support, pricing disclosure, and what remains manual.
How should you answer yes, no, partial, and not-applicable questions?
Choose the status that matches the implemented control, then state scope and evidence. “Partial” is more accurate than “yes” when only part of the environment is covered. “Not applicable” needs a reason. A roadmap item does not turn a missing control into an implemented one.
| Status | What the answer should contain | Example structure |
|---|---|---|
| Yes | Implemented control, scope, owner or mechanism, and current evidence | “Yes — [control] applies to [scope]. It is verified by [evidence] dated [date].” |
| Partial | Implemented portion, excluded portion, compensating control, and approved remediation if one exists | “Partially — [covered scope] uses [control]. [Excluded scope] uses [verified alternative]. [Owner] is reviewing the remaining gap.” |
| No | Direct “no,” the actual risk treatment, and an approved target date only if one exists | “No. [Control] is not implemented. Current risk treatment is [accepted/mitigated/transferred] through [approved measure].” |
| Not applicable | The product, data flow, or responsibility boundary that makes the question inapplicable | “Not applicable — the service does not [activity], as shown in [architecture or data-flow source].” |
| Cannot disclose | What can be shared, why access is restricted, and the approved disclosure path | “The full report is restricted. We can provide [summary/report access] under [NDA, portal, or controlled-review condition].” |
Avoid “yes, see policy” when the question asks whether a control operates. A policy describes what should happen. A configuration export, ticket population, review record, or test result shows what did happen.
What do SOC 2 auditors expect from questionnaire records?
SOC 2 auditors expect evidence that your defined vendor-risk control operated as designed. If your control uses questionnaires for certain vendors, an auditor may sample the completed forms, review conclusions, exceptions, approvals, and follow-up. CC9.2 does not make every questionnaire a mandatory artifact.
The direction of the questionnaire matters:
- When your company sends a questionnaire to one of its vendors, the completed assessment can support your CC9.2 vendor-management control. A completed form without review notes or a decision only proves that answers were collected.
- When your company answers a customer’s questionnaire, the submission usually supports customer assurance and sales due diligence. It becomes SOC 2 evidence only when it is relevant to a control, commitment, or sample in your own audit scope.
- In both cases, unsupported or inconsistent claims reveal a governance problem. Keep the underlying control evidence authoritative and treat each customer submission as a dated representation.
This distinction prevents a common mistake: calling every outbound customer questionnaire “audit evidence” while ignoring the buyer-side assessment records an auditor may actually test.
When should you use a custom questionnaire, SIG, or CAIQ?
Use the format the requester accepts and the service context supports. Custom questionnaires capture customer-specific obligations. The Shared Assessments SIG covers broad third-party risk topics. The Cloud Security Alliance CAIQ focuses on cloud-service control transparency. None removes the need to verify answers and scope.
| Format | Best fit | Strength | Limitation |
|---|---|---|---|
| Custom customer questionnaire | A buyer has product-specific, regulatory, privacy, architectural, or contractual questions | Matches the buyer’s exact decision and risk model | Repeats common questions and may introduce unfamiliar wording or new promises |
| Shared Assessments SIG | The buyer and supplier want a standardized, broad third-party assessment | Creates a common structure for reviewing multiple risk domains | It is licensed and versioned; confirm the accepted edition and do not assume it satisfies customer-specific terms |
| Cloud Security Alliance CAIQ v4 | The subject is an IaaS, PaaS, or SaaS service and the buyer wants cloud-control transparency | Uses yes/no questions aligned with the Cloud Controls Matrix and supports CSA STAR Level 1 submission | Cloud-focused scope does not automatically answer every legal, privacy, financial, or resilience question in a custom review |
A SOC 2 report is supporting assurance, not a substitute for every questionnaire. Its report period, system description, criteria, subservice-organization treatment, exceptions, and complementary user entity controls may answer many questions; customer-specific data flows and contract terms still need separate answers.
Standards review note: SIG, CAIQ, and CCM artifacts are versioned. Confirm the requester’s required edition before starting a response.
How should you build a reusable answer library?
A reusable answer library should store more than approved prose. Each record needs a defined scope, evidence pointer, disclosure level, owner, approver, review date, and expiry or update trigger. Those fields let the response owner distinguish reusable facts from customer-specific commitments and stale claims.
| Library field | What to record | Why it prevents errors |
|---|---|---|
| Question concept | Canonical topic, such as privileged access review or encryption in transit | Matches differently worded questions without relying on exact text |
| Approved answer | Plain-language response with bounded scope and defined terms | Gives responders a controlled starting point |
| Applicability | Product, legal entity, environment, region, and data category | Stops an answer for one service from being applied to another |
| Evidence pointer | Controlled link, document ID, report period, or configuration owner | Lets the reviewer verify the claim at its source |
| Disclosure level | Public, NDA, restricted portal, summary only, or internal only | Prevents accidental sharing of sensitive reports or configurations |
| Owner and approver | Person accountable for the control and person who approved the wording | Creates a clear escalation path |
| Review date and trigger | Last verified date plus triggers such as architecture change, policy revision, incident, new report, or contract update | Stops a fixed annual review from missing a material change |
| Customer deviation | Customer-specific wording, commitment, or exception and its legal approval | Keeps one-off promises out of the global answer |
Automation can search the library, suggest matches, flag expired records, and populate a draft. It should not approve scope, invent missing evidence, or turn a conditional answer into an unqualified “yes.” Keep a human control owner responsible for the final claim.
What should happen when evidence is stale, restricted, or missing?
Stop reuse when the answer no longer matches current evidence. Mark the record stale, preserve the last verified date, and route it to the control owner. Submit a bounded partial or “no” answer when appropriate; never update a date or control status just to satisfy the form.
Use these escalation rules:
- Stale report or certificate: State the period or expiry accurately. Ask the assurance owner whether a current report, certificate, or SOC 2 bridge letter exists. Do not describe a bridge letter as extending the audit period.
- Partial coverage: Name the systems or regions covered and excluded. Document a compensating control only when it operates and has evidence.
- Missing control: Answer “no” and record the approved risk treatment. Include a target date only when the responsible owner has approved and funded it.
- Restricted evidence: Offer the approved alternative — an executive summary, controlled trust-center access, NDA review, or auditor-to-auditor discussion. Redact deliberately; keep dates, scope, and conclusions needed to interpret the evidence.
- Conflicting wording: Ask the customer to define ambiguous terms such as “sensitive data,” “real time,” or “critical vulnerability.” Do not silently substitute your definition.
- New commitment: Route notification windows, recovery objectives, residency promises, deletion periods, and audit rights to legal and the control owner before submission.
- Material inconsistency: Pause the response when the answer library, policy, contract, and technical evidence disagree. Resolve the control record first, then update the answer.
The response owner should keep an exception log with the question, risk, assigned owner, decision, approval date, and customer-facing wording. That log makes repeat gaps visible without pretending every gap has been remediated.
What should the final reviewer check before submission?
The final reviewer should confirm that every answer matches the requested product, current evidence, and approved disclosure level. The review should also catch unsupported absolutes, hidden commitments, stale dates, unanswered follow-ups, and customer-specific wording that must not enter the reusable library.
Before sending the file, verify:
- The legal entity, product, environment, regions, and data categories are correct.
- Every “yes” has a current evidence pointer and no known exception contradicts it.
- Every “partial,” “no,” and “not applicable” answer states a reason and has owner approval.
- Report periods, certificate validity dates, test dates, and policy review dates are exact.
- Security, privacy, legal, engineering, and business continuity owners reviewed their assigned claims.
- Restricted artifacts use the approved NDA, portal, summary, or redaction path.
- New contractual promises have legal approval and an operational owner.
- The final submission, approvals, evidence references, and deviations are retained together.
If a customer review exposes weak vendor-management evidence on your side, fix the control record before audit fieldwork. The SOC 2 evidence collection guide shows how to organize the underlying artifacts, while the vendor management requirements guide covers the buyer-side process an auditor is more likely to sample under CC9.2.