Vendor questionnaires

How do you answer license questions in security questionnaires?

Answer from a reviewed, product-scoped inventory tied to a named release, not from last year's spreadsheet. Questionnaires want stable, current disclosure. Here is how to respond without overclaiming.

Last updated: July 2, 2026

Vendor security questionnaires, SIG Lite, CAIQ, custom RFP spreadsheets: Most include a section on open-source, third-party software, or license compliance. Wording varies. The reviewer wants to know you control third-party license obligations in the product they are evaluating.

These questions arrive mid-deal, often answered by someone who did not write the code. Engineering may never have centralized inventory. Legal may not have seen the dependency list. This guide maps typical question types to honest answers when your codebase changes every sprint.

This page maps the questionnaire's question types. The reply workflow, step by step, is the guides page "Procurement license request".

Where license questions appear

Questionnaires scatter license duties across sections. You may see them under intellectual property, software development practices, supply chain, legal compliance, or a dedicated open-source annex. Search the PDF for: OSS, open source, third party, license, SBOM, component, attribution, copyleft, GPL.

Do you use open-source software in the product under review?
Provide a list of open-source components and licenses.
Provide license texts / third-party notices.
Do you have a policy for open-source use?
How do you track license compliance?
Provide SBOM or software bill of materials.
Link to open-source / license disclosure page.
Any copyleft (GPL, AGPL, LGPL) components?

What are reviewers really checking in a license questionnaire?

Reviewers are checking for operational control, not philosophy: Whether you can produce a reviewed, product-scoped license list with full text, tied to a named release, that will survive your next deploy. Standardized questionnaires such as the Shared Assessments SIG and the CSA CAIQ build these expectations into named control rows.

Can you produce a reviewed list for this product? Does it include full license text? Is it tied to a release they can name? Will it still be accurate after your next deploy?

A yes without evidence fails on sample audit: They pick five components and ask for text. A policy PDF without inventory fails because policies do not ship with the binary. An SBOM without reviewed licenses fails because identifiers are not disclosure.

Existence of inventory for the specific product, not company-wide hand-waving.
Evidence of review, not raw registry metadata.
Full license text, not summaries.
Process for updates, critical when teams merge dependency changes daily.
Honest scope: SaaS vs installable vs embedded may differ.

Question type	Honest answer	Evidence to attach
Do you use open-source software?	Yes, with a reviewed inventory per product	Link to the published disclosure record
Provide components and licenses	The reviewed list for the product under review	URL, PDF, or JSON export from one approved snapshot
Provide license texts / notices	Full text ships with the record, not SPDX IDs alone	Per-component license text on the record
Any copyleft (GPL, AGPL, LGPL)?	Answered from a searched inventory, never memory	Search results and review status per match
How do you track compliance?	Import, review, and publish on every release	Revision history and drift flags

The most common question types, paired with the honest answer and the evidence that survives sample audits.

Answering when inventory is incomplete

Do not checkbox yes and attach a marketing page footer. If you are building the process, say so: What you have today, what release you can cover, when full disclosure will be ready.

Partial honesty preserves deals. Overclaiming fails in legal review and destroys trust. Many buyers accept a timeline if engineering and compliance names are attached.

State current state plainly: Partial inventory, in-progress review, no publish yet.
Name the product and release you can support today.
Give a date for full disclosure, and meet it.
Do not copy last year's answers if dependencies changed.
Escalate copyleft or GPL questions to counsel. Checkbox answers are risky.

Answering when inventory exists

Send from the same approved publish snapshot: URL, PDF export, or JSON bundle, whichever the form allows. State product name, release tag or date, and one sentence on how you re-publish when dependencies change.

If the questionnaire asks both SBOM and license disclosure, attach both from the same release, but do not treat them as interchangeable. SBOM satisfies security rows; reviewed license text satisfies legal rows.

Match the product under review, not a sibling SKU.
Include release or date the data reflects.
Attach full license text or point to reviewed disclosure.
Describe maintenance: Import, review, publish on each release.
Name an owner: Engineering, compliance, or legal contact.

How should you answer copyleft and high-risk license questions?

Answer copyleft questions from a searched, reviewed inventory, never from memory or assumption, because a false "no" is the most expensive answer you can give. GPL, AGPL, LGPL, and SSPL conditions turn on how you link, distribute, and offer source, so matches usually need legal interpretation before you sign.

Questionnaires often ask specifically about GPL, AGPL, LGPL, or copyleft. These require accurate inventory and often legal interpretation of how you link, distribute, and offer source.

Do not answer no because you have not searched. Import lockfiles, search for copyleft identifiers, escalate matches before you sign the questionnaire. A false negative is worse than a flagged yes with a mitigation plan.

Run inventory search for GPL, AGPL, LGPL, SSPL, and custom licenses.
Document each hit: Version, usage context, review status.
Involve counsel on distribution and source-offer obligations.
Answer the questionnaire with facts from reviewed inventory.
Update answers when copyleft components are added or removed.

Policy questions vs evidence questions

Many forms ask for your open-source policy PDF. Policies matter for SOC 2 and ISO context. They describe intent. Buyers still ask for evidence: The actual list for the product.

Answer policy questions with your policy. Answer inventory questions with your reviewed record, not the policy alone. If policy says "we comply with licenses" but you have no published inventory, the evidence question fails regardless.

Keeping answers true after you submit

Questionnaire answers have a half-life. The week after you submit, someone may merge a major dependency upgrade. Your signed attestation still sits in the buyer's file, now stale.

Operational teams re-import on release, re-review changes, re-publish disclosure, and notify key accounts when material license posture changes. Static answers without a maintenance loop are a liability in renewal and audit cycles.

The fastest honest answer

SourceTrust turns this loop into the default: Import the lockfile, review each license once, publish a product-scoped attestation page with full license text, and republish on every release. The next questionnaire gets a URL instead of a scramble.