| name | vendor-questionnaire |
| description | Vendor security questionnaire workflow — vendor tiering, standardized questionnaires (CAIQ, SIG-Lite/Core, VSA), custom authoring, evidence reuse against existing attestations (SOC 2, ISO 27001), and ongoing vendor-risk monitoring. |
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
Categories
