How to answer a vendor security questionnaire (SIG Lite, CAIQ, and custom)

what these questionnaires are

A vendor security questionnaire, often shortened to VSQ, is a structured set of questions a customer sends to assess the security of a supplier before signing or renewing a contract. The questions ask how you protect data, manage access, respond to incidents, and develop software. The reviewer uses your answers to decide whether you meet their bar, what risks to flag, and what to put in the contract.

There are three formats. SIG and SIG Lite: the Standardized Information Gathering questionnaire is maintained by Shared Assessments, an industry body for third-party risk; the full SIG is large and covers many control areas in depth, and SIG Lite is the shorter subset for a lighter-touch assessment or a first pass. CAIQ: the Consensus Assessments Initiative Questionnaire comes from the Cloud Security Alliance, maps to the CSA Cloud Controls Matrix, and is built for cloud and SaaS providers, with answers typically yes, no, or not applicable plus a notes column; many SaaS vendors complete one and publish it through the CSA STAR registry. Custom questionnaires: plenty of buyers send their own spreadsheet, often assembled from their internal policy plus pieces of SIG and CAIQ and whatever their last incident taught them. Across all three, the underlying questions repeat. Once you have answered the access control section of a SIG Lite well, you have most of what a CAIQ or a custom form will ask about access, and that overlap is what makes an answer library worth building.

why you received one

You received a questionnaire because a customer's security or procurement process requires one before they can bring you in as a vendor. This is third-party risk management: larger organizations are accountable for the security of the suppliers who touch their data, and the questionnaire is how they document that they checked. It usually triggers when you are about to handle their data, connect to their systems, or sit in a workflow that matters to them; when their own auditors under SOC 2, ISO 27001, DORA, or NIS2 expect them to assess vendors; or when the deal has crossed a size or sensitivity threshold. None of this is a judgment on you. It means the deal is real enough that their risk function got involved. A clear, honest, well-evidenced response moves the deal; a vague or evasive one slows it down.

the answer-from-evidence principle

The single most useful habit is to answer from evidence rather than from memory or estimate. For every answer, you should be able to point to the thing that makes it true: a configuration setting, a log, a policy document, an export, a screenshot. If you cannot point to anything, you do not yet know the answer. This matters because the reviewer may ask for that evidence, and an answer you can back up survives the follow-up while an answer you made up does not. Getting caught with one fabricated answer turns the whole response into something the reviewer no longer trusts.

It also reframes "we do not know" correctly. When nobody on the team can answer from evidence, the honest read is not "we are insecure," it is "we cannot currently see this." Those are different problems: the first needs a control, the second needs visibility, and visibility is usually faster to get. A question like "what percentage of accounts have MFA enforced" is answerable the moment you can see the real state across your identity provider and your applications. Many teams have never pulled that view, so they estimate, and the estimate is wrong. The fix is to look, not to guess better.

the question domains and how to approach each

Strip away the formatting differences and most questionnaires cover the same handful of domains. Access control and identity is the highest-frequency domain and the one covered in most depth, with questions on MFA coverage, offboarding speed, least privilege, periodic access reviews, and how you manage admin and privileged accounts; answer from the real state across your identity provider and connected applications, not from the policy, because policy says MFA is required while evidence says how many accounts actually have it, including those outside single sign-on. Data protection covers encryption at rest and in transit, retention and deletion, and sub-processors; encryption answers are usually concrete configuration, retention requires a written schedule that matches what systems actually do, and sub-processors require a real current list. Incident response covers whether you have a documented plan, how you detect incidents, and your notification timelines; the honest answers are binary and testable. Business continuity and backups covers backup frequency, location, tested restores, and recovery objectives, and the question that catches teams out is whether a restore has actually been tested. Secure development covers code review, dependency and vulnerability management, and secrets handling, answered from your actual pipeline rather than from good-practice aspiration. Compliance posture covers SOC 2 and ISO 27001 status and GDPR alignment, where precision matters: a SOC 2 Type II report is a different thing from "working toward SOC 2," which is different again from "we follow SOC 2 principles." The pattern across all six is the same: find the real state, write the answer it supports, and keep the evidence where you can produce it.

worked examples: ten questions and model answers

The point of these is the shape of a good answer, not words to copy. Adapt them to your own real state.

Is MFA enforced for all users? "MFA is enforced through our identity provider for all accounts that authenticate through single sign-on, which covers the majority of staff and applications. A defined set of applications outside SSO is tracked separately, and we are extending enforced MFA to those on a documented schedule. Current coverage and the remaining list are available on request." This answers from the real state and names the gap rather than claiming a blanket yes the application list would contradict.

How quickly is access removed when an employee leaves? "Departures trigger our offboarding process the same business day. Access to core systems managed through our identity provider is revoked within that window. For applications not yet integrated with the directory, revocation follows a checklist and is completed within [your committed window]. We review offboarding completeness as part of our periodic access reviews." It distinguishes the integrated path from the manual one, where access usually lingers.

Do you enforce least privilege? "Access is granted based on role, and we limit standing administrative access to a defined set of accounts. We run periodic access reviews where resource owners confirm or revoke each account's access. We do not yet have continuous automated enforcement of least privilege, so review cadence is our primary control. Review records are available on request." It states the control honestly and names what it is not.

How often do you conduct access reviews? "We review privileged and high-risk access quarterly and standard user access half-yearly. Reviews are conducted by resource owners, decisions are recorded, and revocations are executed within a defined window. Our most recent review record can be shared under NDA." It gives a cadence, an owner, and evidence.

Is customer data encrypted at rest and in transit? "Data in transit is encrypted using TLS 1.2 or higher across all external connections. Data at rest is encrypted using our cloud provider's managed encryption with [the standard your provider uses]. Encryption configuration details and our provider's documentation are available on request." Encryption answers should be specific; vague ones read as uncertainty.

Do you maintain a current list of sub-processors? "Yes. We maintain a sub-processor list covering each third party that processes customer data on our behalf, the purpose, and the processing location. The current list is available on request, and we notify customers of material changes as set out in our data processing agreement." If you do not have this list, the honest answer is that you are assembling it, with a date.

Do you have a documented incident response plan? "Yes. We maintain a documented incident response plan covering detection, classification, containment, customer notification, and post-incident review. The plan defines roles and escalation paths. We can describe the plan in a call and share a redacted version under NDA." If the plan does not exist yet, do not claim it.

What is your customer notification timeline after a confirmed incident? "For an incident affecting customer data, we notify affected customers without undue delay and within [your committed window] of confirmation. The specific commitment is set out in our contractual terms. Our incident response plan defines the steps that lead to notification." State the window you can actually meet under pressure.

How do you manage secrets and credentials in development? "Secrets are stored in a dedicated secrets manager and are not committed to source control. Access to secrets is restricted by role, and we scan repositories for accidentally committed credentials. Rotation follows a defined process for [the cases you actually rotate]. We can walk through the configuration on request." This comes from the pipeline, not from policy aspiration.

What is your current SOC 2 or ISO 27001 status? "We do not currently hold a SOC 2 Type II report. We have completed [your real stage, for example a readiness assessment] and are targeting [report type] by [date]. In the meantime we can share our security policies and answer specific control questions directly." Precise status beats a hedge; reviewers read "we follow SOC 2 principles" as "we have no report."

how to handle a question you cannot answer yes to

You will hit questions where the honest answer today is no, or not yet. The wrong move is to write yes and hope nobody checks. The right move states the current state, the plan, and the timeline. A strong gap answer has three parts: what is true now, what you are doing about it, and when it will be done. For example: "We do not currently enforce MFA on the set of applications outside single sign-on. We have inventoried those applications and are enforcing MFA across them on a schedule that completes by [date]." Buyers accept honest gaps with a roadmap far more often than people expect, because their reviewers see real environments every day and know no mid-market vendor is perfect on every control. What they are screening for is whether you know your own state and are managing it. A confident yes that later proves false signals the opposite, and once one answer is exposed as untrue the reviewer rereads the entire response with suspicion. There is also a contractual reason to be accurate: questionnaire answers can end up referenced in the agreement, and an answer that overstates your controls is a representation you may not be able to stand behind later.

building a reusable answer library

The first questionnaire is slow because you are discovering your own answers while you write them. The work you do once should not have to be redone. An answer library is a structured store of your standard questions and approved answers, each tied to the evidence that backs it; when a new questionnaire arrives, most of it maps to answers you already hold, so you reuse those, write only the genuinely new questions, and the response that took weeks takes hours. A few things make a library work: one owner and one source, so canonical answers do not drift apart and contradict each other; evidence linked to each answer, so you can produce proof without a scramble; a freshness date on each answer, reviewed on a cycle, because an MFA answer true two quarters ago may not be now; and a map across formats, organizing answers by domain rather than by one questionnaire's layout so the same access control answer serves a SIG Lite, a CAIQ, and a custom form. The library is also where answering from evidence pays off most, because refreshing it is a matter of rechecking the evidence, and the gaps you logged become a running roadmap that moves answers from "not yet, here is the plan" to "yes, here is the evidence" over a few cycles.

why access and identity answers are the hardest

Of all the domains, access and identity is the one most companies answer worst, and rarely because they care less about it. The reason is that they cannot see the real state of access across their systems, so they answer from policy and hope. Encryption is configuration, so it is knowable; a backup either ran or it did not. But access is spread across an identity provider, dozens of SaaS applications each with its own user list and role model, cloud consoles, service accounts that belong to no person, and integrations granted at setup and never reviewed. The true answer to "what percentage of accounts have MFA enforced" or "how many former employees still have access somewhere" requires pulling and reconciling state from all of those, and most teams have never done it, so they answer from the policy and the policy and reality have drifted apart. This is why access questions are where bluffing is most tempting and most dangerous: "MFA is enforced for all users" is easy to write and often wrong, because the accounts outside single sign-on are exactly the ones the writer forgot. The honest path is the same as everywhere else, just harder to walk here: see the real state before you answer.