Vendor questionnaire

Vendor Security Questionnaire

Disclaimer: this skill supports a security assessment of vendors. Contractual and legal review (data-processing agreements, liability clauses, jurisdiction) requires legal. This skill does not replace contract-legal expertise.

When to use

Vendor Security Questionnaires are the standard mechanism organizations use to assess the security posture of their third-party providers. From both sides: you send them (as the buyer) AND receive them (as a provider serving B2B customers). This skill covers both roles.

Triggers on:

• A question like "which questionnaire do we use for this vendor", "fill out this SIG-Lite for customer X", "build CAIQ answers", "what is a reasonable questionnaire for a low-risk SaaS", "evidence reuse across questionnaires".
• A new vendor onboarding (sender side).
• An incoming security questionnaire from a customer (receiver side).
• A handoff from supply-chain (SBOM side), dora (Art 28-30 third-party risk), nis2 (Art 21(4) supply-chain security), policy-drafter (vendor management policy).
• Annual re-review of existing vendors.

When NOT (handoff)

• Contract drafting or legal review → legal team. This skill provides input for contracts, not contracts themselves.
• Policy layer of vendor management → policy-drafter.
• Technical dep/supply-chain evaluation (SBOM, provenance) → supply-chain. Complementary.
• Risk-scoring methodology → risk-register.
• Compliance-specific attestation production → iso27001, soc2, audit-evidence.
• Privacy-specific vendor assessment (sub-processors under AVG Art 28) → gdpr-pia context plus DPA review.
• Fraud / financial due diligence → out of scope, financial-controlling expertise.

Approach

Seven phases. Phase 1 (tiering) decides all subsequent steps; phase 4 (evidence reuse) is where efficiency gains live.

1. Vendor tiering

Not every vendor receives the same attention. Tier sets the depth of due diligence.

Tier criteria (multi-dimensional):

• Data access: which data is processed (PII? Financial? Special categories Art 9 AVG?)?
• System access: does the vendor have access to production systems, admin roles, source code?
• Business criticality: how long do we survive an outage of this vendor?
• Regulatory scope: is this vendor part of a NIS2/DORA-subject chain?

Tier definitions (3-tier example):

• Tier 1 (critical): touches PII or production, essential for core operations, regulatory-subject. Full questionnaire + SOC 2/ISO 27001 evidence required + annual review + on-site/remote audit rights.
• Tier 2 (moderate): limited data exposure or moderate business impact. Mid-size questionnaire (SIG-Lite or CAIQ-Lite), attestation evidence sufficient, biennial review.
• Tier 3 (low): no PII, no production access, replaceable. Lightweight questionnaire (10-20 questions), evidence optional, triennial review.

Document the tiering criteria as part of the Vendor Management Policy (see policy-drafter).

2. Standardized frameworks

Use existing frameworks where possible; building custom is expensive and double work.

• CAIQ (Consensus Assessments Initiative Questionnaire) — Cloud Security Alliance. 261 questions (v4.0.3) aligned with the Cloud Controls Matrix (CCM). Strongest for cloud service providers. Freely available.
• SIG / SIG-Lite / SIG-Core (Standardized Information Gathering) — Shared Assessments. SIG-Lite ~300 questions, SIG-Core ~1500, full SIG ~3000. Broadly applicable, commercial license for the full version.
• VSA (Vendor Security Alliance) — VSAQ (core) + VSAQ-full. Compact alternative aimed at modern SaaS.
• NIST SP 800-171 self-assessment — for vendors handling US-federal/DoD data (CUI).
• CRA assessment — expected role of vendors under the EU Cyber Resilience Act for software-product security.

Selection heuristic: if the vendor offers a framework themselves ("here is our completed CAIQ + SOC 2 report"), accept that first. Custom questionnaire only when existing frameworks really have gaps for your context.

3. Custom-questionnaire authoring (only when needed)

For organization-specific questions outside the standard frameworks. Keep it limited to the truly unique.

• Top-level clustering: governance, identity/access, data protection, ops/monitoring, incident response, supply chain, compliance, continuity.
• Question phrasing: closed questions with an evidence request (e.g. "Do you enforce MFA for admin access? [Y/N]. If yes, provide evidence screenshot/policy reference"), not open essays ("Please describe your security").
• Length: tier-dependent. Tier 1 can be 100+ questions; tier 3 not more than 20. Vendor fatigue is real.
• Language: NL or EN, not both (see policy-drafter phase 4).

Custom questionnaires must be a stable, versioned document, not an ad-hoc variant per vendor.

4. Evidence mapping and reuse

Most of the value in modern-day vendor security is in not answering the same questions over and over.

• Attestation-first: if a vendor has SOC 2 Type II or ISO 27001, ask for those reports first. Mapping table: CAIQ question X maps to SOC 2 CC6.1 control. Answer: "See attached SOC 2 report, section CC6.1, evidence in Appendix".
• Cross-walks:
  • CAIQ ↔ CCM ↔ ISO 27001 Annex A: CSA publishes the mappings.
  • SIG ↔ ISO 27001: Shared Assessments publishes them.
  • NIST CSF ↔ ISO 27001: many cross-walks publicly available.
• Evidence library (as receiver): maintain a structured repository with evidence per control type. New incoming questionnaire: 80% of answers come from the library, 20% are query-specific.
• Trust centers / SafeBase / Whistic / VendorSPT: publicly accessible portals where you host your attestations, SBOMs, and policy overviews for customers. Lowers incoming-questionnaire load. Standard for mature B2B SaaS.
• CAIQ-based STAR (CSA): public registry of CAIQ-completed vendors. Check before sending a custom questionnaire.

Missing evidence for a specific question is itself a finding: the vendor claims "yes" but cannot back it up.

5. Review + risk acceptance

After answers come in:

• Red-flag pass: auto-disqualifiers. No MFA on admin, no encryption-at-rest for PII, no incident-response plan, no breach-notification clause. Vendors that fail here are not negotiable unless the business case is huge and the risk is explicitly accepted.
• Scoring: tier-adjusted scoring. Tier 1 with gaps = go back to the vendor with a remediation request. Tier 3 with minor gaps = acceptable with compensating controls.
• Risk acceptance: if gaps remain, document in risk-register with an explicit accept decision, owner, deadline for re-review.
• Contract clauses that follow from the questionnaire: breach-notification timeline, right to audit, data-residency guarantee, sub-processor-approval chain, exit procedure with data return/destruction. Specifically required for DORA Art 30 for financial entities.
• Complementary User Entity Controls (CUECs): which controls does the vendor count on you for? Document and communicate internally (see soc2 phase 5).

6. Ongoing monitoring

A one-shot vendor assessment is not enough. Vendors change; risk exposure with them.

• Re-assessment cadence per tier (annual tier 1, biennial tier 2, triennial tier 3).
• Event triggers: incident at the vendor (public breach), significant organizational change, contract renewal, change in data scope.
• Continuous monitoring tools: BitSight, SecurityScorecard, Panorays, UpGuard. They produce outside-in risk ratings (DNS config, cert hygiene, leaked credentials, patch cadence). Not a replacement for the questionnaire but a red-flag detector between formal reviews.
• Register: aligned with DORA Art 28(3) register of information for financial entities (filed with DNB/AFM), or equivalent for non-financial.

7. Verification-loop

Layer 1: scope (all tier-1 vendors assessed, no shadow-IT vendors via P-card forgotten?), assumptions (vendor attestations still valid, not expired?), gaps (sub-processors mapped, not just the top-level vendor?). Layer 2: framework version numbers (CAIQ v4.0.x, SIG year) correct, cross-walk claims supported by CSA/Shared-Assessments publications, no invented SOC 2 mapping codes, contract-clause terminology technical and not legally over-reaching.

Output

Two modes: sender (send a questionnaire + review answers) or receiver (answer an incoming questionnaire).

Sender mode:

Vendor security assessment — <vendor>
Tier: <1 | 2 | 3> | Onboarding date: <...> | Last review: <...>

Questionnaire:
  Framework:          <CAIQ v4 | SIG-Lite | custom>
  Sent:               <date>
  Received:           <date, N answers>

Attestations:
  SOC 2 Type II:      <present, period, issuer>
  ISO 27001:          <present, scope, expiry>
  Other:              <DORA CTPP, FedRAMP, ...>

Findings:
  Red flags:          <list, blocker for onboarding?>
  Gaps (non-blocker): <list with compensating controls or acceptance>
  Evidence gaps:      <claims without evidence>

Contract clauses (aligned with findings):
  Breach notification:<timing>
  Right to audit:     <scope>
  Data residency:     <region lock>
  Sub-processor:      <approval chain>
  Exit:               <return/destruction procedure>

Decision:
  Onboard:            <yes | with conditions | no>
  Risk accepted:      <register-ID in risk-register>

Verification-loop: ...

Receiver mode: a structured answer package with references to evidence-library items, cross-walked to the requested framework codes.

References

• CSA CAIQ — https://cloudsecurityalliance.org/research/cloud-controls-matrix. CAIQ + CCM, freely downloadable, cross-walks to other frameworks.
• CSA STAR Registry — https://cloudsecurityalliance.org/star/registry. Public registry of CAIQ-completed providers.
• Shared Assessments SIG — https://sharedassessments.org/sig/. SIG family questionnaires, commercial.
• Vendor Security Alliance — https://www.vendorsecurityalliance.org/. VSAQ-core and VSAQ-full.
• NIST SP 800-171 — https://csrc.nist.gov/pubs/sp/800/171/r3/final. For CUI-handling assessment.
• EU Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. Relevant for vendor assessment of software products once it enters into force.
• NIST SP 800-161 Rev. 1 — https://csrc.nist.gov/pubs/sp/800/161/r1/final. Cybersecurity Supply Chain Risk Management practices.

Categories

• grc