What SIG-Lite is, and how it differs from full SIG or CAIQ
The Standardized Information Gathering (SIG) questionnaire, maintained by Shared Assessments, is one of the most widely reused third-party risk assessment templates in enterprise procurement. It comes in two common shapes: the full SIG (sometimes called SIG Core), which runs to hundreds of questions across every control domain, and SIG-Lite, a condensed subset built for lower-risk engagements or as a first-pass screen before a deeper review.
SIG-Lite typically asks 100-200 yes/no and short-answer questions spanning the same control domains as the full SIG — but at a summary level. Where a full SIG might ask for the specific configuration of your logging pipeline, SIG-Lite asks whether you have centralized logging and monitoring at all. It's built to be answerable by a security lead in a sitting, not a multi-week control walkthrough.
CAIQ (the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire) overlaps with SIG-Lite in intent — both are standardized, reusable, yes/no-heavy screens — but they come from different bodies, use different question numbering and domain groupings, and a prospect who has adopted one won't necessarily accept the other as a substitute. Vendors who sell into multiple enterprise verticals often end up maintaining answer sets for both, plus a custom Excel questionnaire or two, because different buyers have standardized on different templates.
Common question categories in a SIG-Lite
Exact wording and section numbering vary by SIG version and by which sections a given buyer chose to include, but most SIG-Lite questionnaires cluster around the same handful of domains:
Policy & org structure
Whether you have a documented information security policy, a named security owner or team, a risk assessment process, and a vendor/third-party risk management program of your own.
Access control
Authentication requirements (MFA, password policy), least-privilege and role-based access provisioning, access review cadence, and how offboarding revokes access.
Encryption & handling
Encryption in transit and at rest, data classification, data retention and deletion practices, and where customer data is hosted or replicated (including subprocessors).
Resilience & response
Business continuity and disaster recovery planning, backup practices, incident response procedures, breach notification commitments, and vulnerability/patch management.
A shorter but still recurring set of questions covers compliance posture (do you hold SOC 2, ISO 27001, or similar attestations, and can you produce them), physical security (relevant mainly if you operate your own data centers rather than a cloud provider), and HR security (background checks, security awareness training, confidentiality agreements for staff with data access).
Documentation you'll typically want on hand
Reviewers rarely take a yes/no answer at face value for anything material — most SIG-Lite submissions get followed up with a request for supporting evidence, either immediately or during contract negotiation. Having the following assembled before you start answering saves the second round of back-and-forth:
- Current SOC 2 Type II report (or ISO 27001 certificate) — the single document that answers the largest number of SIG-Lite questions by reference, since most control-level questions can point back to a specific section of the report.
- Information security policy and any subsidiary policies (access control, acceptable use, incident response) that exist as standalone documents.
- Subprocessor list — the names and locations of any third parties that touch customer data, kept current, since this is one of the most commonly stale documents in a vendor's compliance folder.
- Data flow diagram showing where customer data enters, is stored, and exits your systems.
- Incident response plan or a summary of it, including notification timelines you commit to contractually.
- Penetration test summary from the most recent test, or a letter of attestation if the full report is confidential.
- Business continuity / disaster recovery summary, including recovery time and recovery point objectives if you've defined them.
If any of these don't exist yet, that's useful information on its own — a "no" with a stated remediation timeline is generally received better by reviewers than a vague or evasive answer, since reviewers are calibrated to expect gaps in a young vendor's program.
Tips for keeping answers consistent across submissions
The single biggest source of friction in repeat SIG-Lite submissions isn't the questions themselves — it's contradicting a prior answer. A reviewer who cross-references your last submission (or checks it against your public trust center or SOC 2 report) and finds a different answer to the same underlying question will slow the review down to resolve the discrepancy, regardless of which answer was correct.
- Keep one source-of-truth answer set per recurring question, dated to your current control state, rather than re-answering from memory each time a new questionnaire arrives.
- Version your answers alongside your SOC 2 report cycle. When a new report is issued, review and update any answers that reference control changes described in it.
- Watch for wording drift, not just fact drift. Two answers can both be technically true but read as inconsistent — for example, "we encrypt data at rest" versus "all customer data is encrypted using AES-256 at rest" describe the same control with different specificity, and a careful reviewer may flag the gap.
- Log which prospect received which version. If a control changes between submissions, you want to know who has the stale answer in case it surfaces again during contract renewal review.
- Route anything novel through your security team before it goes out. A corpus of prior answers is a strong starting draft, but a new subprocessor, a changed retention window, or a first-time customer in a regulated industry can all change what the accurate answer is — treat drafts as a starting point for review, not a final submission.