SIG Lite questionnaire help for small SaaS companies

Always work from the exact file your buyer sent. Versions change between years and buyers sometimes edit them.

What SIG Lite is

SIG stands for Standardized Information Gathering. It is a questionnaire published by Shared Assessments, an industry body focused on third-party risk management. The full SIG is a large question set that assessors use to evaluate vendors. SIG Lite is the shorter version, intended for lower-risk vendors or as a first screening step. Buyers, especially in financial services, insurance and other regulated sectors, often send it because it lets them compare many vendors on one common structure.

How many questions it has depends on the year and version. It is commonly a few hundred questions, and it varies by version, so do not rely on a number you read elsewhere. Count the rows in the file you received. The free analyser counts and categorises rows in your browser if you want a quick profile.

Two points are worth knowing up front:

• It is usually delivered as an Excel workbook with multiple tabs: instructions, a business-information tab, the question tabs by domain, and sometimes supporting tabs. Buyers feed this file into their own processes, so keep the structure intact.
• Answers are often constrained. Many questions take Yes, No or N/A, with a free-text comment column. Read the instructions tab for what the comment column is for. Some buyers read the comments closely, others only the Yes/No column.

The domains it covers

The exact domain names and numbering differ by version, but SIG-style questionnaires broadly cover the following areas. This list is a guide to what you should expect, not a replica of the official file.

If you are a cloud-hosted SaaS company, expect many physical-security questions to be answered by reference to your infrastructure provider. Say so explicitly: "Hosted on [provider]; physical controls are provided by the provider and described in their published attestations." Do not describe their controls as yours.

How a small SaaS should approach it

1. Do not try to answer from memory

SIG-style sheets reward consistency across domains. Build a short evidence pack first: policy set with versions, architecture overview, subprocessor list, backup and DR summary, incident response plan, and any attestation or pen-test summary you hold. Give each document a code and version.

2. Decide your scoping statement

Many questions assume a corporate environment. Decide in advance what is in scope: the production SaaS service, your corporate IT, your office (if any). State it once, in the same words every time. A remote-first company with no office should say so plainly rather than answering physical-security questions as if it ran a data centre.

3. Use "N/A" carefully

N/A is legitimate when a control truly does not apply (for example, no on-premises servers). It is not a polite way to say "we do not do this". If a control applies but you do not have it, the honest answer is "No", with a comment about what you do instead. Reviewers notice N/A used to avoid gaps.

4. Use the comment column to be precise

Short, factual comments help: name the control, the tool category, the frequency, and the document. "Yes" with no context is weaker than "Yes; enforced for all staff via our identity provider; see SEC-POL-003 v1.4 §2."

5. Pay attention to frequency and evidence words

Words like "annually", "formally", "independent", "documented", "tested" are the ones where small teams overclaim. If you have a backup process but have not run a restore test, "Yes, we back up" is true and "Yes, we test restores" is not. Answer them separately.

Honest gap examples

Examples only. Replace with your own facts.

Question: Is there a formal, documented information security programme with executive sponsorship?
Answer: Partly. We have a documented security policy set approved by our CEO and reviewed annually. We do not yet have a dedicated security officer; responsibility sits with our CTO. We can share the policy set under NDA.

Question: Are disaster recovery plans tested at least annually?
Answer: No. We have a documented recovery procedure and daily backups. We have not yet run a formal full-recovery exercise. We plan to run and document one and can share the results when complete.

Only say "we plan to" if there is an owner and a real intention. If you are not sure, leave the sentence out.

Common pitfalls

• Contradicting yourself across tabs. The same topic (retention, encryption, MFA) is often asked in several domains. Keep answers identical in substance.
• Reusing last year's file blindly. If the version changed, question wording and numbering may have changed, so do not paste by row number. Match by meaning, and check that old answers still hold.
• Reformatting the workbook. Do not remove sheets, add columns or re-save in another format unless instructed. Buyers often import it as it stands.
• Treating "Lite" as lightweight. It is shorter than the full version, but still a few hundred questions in many editions. Budget a few focused days, not an afternoon.

If the buyer sends more than one framework

Some buyers send SIG Lite plus a cloud-specific sheet. The cloud-focused CAIQ covers overlapping ground in a different layout; see our CAIQ guide. Writing one approved answer per topic and reusing it is far faster than answering each sheet from scratch. For the topics that come up in nearly every file, see what enterprise buyers ask SaaS companies.

Where tooling helps and where it does not

A SIG-style file is exactly the kind of repetitive, structured document where an extractive drafting tool saves time: it matches each question to your documents, cites the source, and leaves unsupported rows blank. It does not remove the need for the work above: scope, evidence and judgement about what you can truthfully claim stay with you.