Usually this arrives the same way. A larger customer wants to buy, procurement sends a spreadsheet with a few hundred rows, and nobody at your end has done one before. It might be a SIG Lite, a CAIQ, or something the customer wrote themselves. The format varies. What they're asking doesn't, much.
What they're actually asking
Strip out the duplication and most questionnaires want six things.
Access control. Who can reach production, how they authenticate, whether MFA is enforced, what happens on the day someone leaves.
Encryption. In transit and at rest. Usually satisfied by TLS everywhere and whatever your cloud provider does with disks, but you need to be able to say so specifically.
Vulnerabilities in your own code. How you find them before shipping. This is the one that catches people out, because the honest answer is often "we don't, really."
Third-party dependencies. How you know a library you use has a known CVE, and how quickly you update it. Dependabot or equivalent covers a lot of this.
Incident response. What happens when something goes wrong. They want to see a documented process, not a heroic story.
Sub-processors. Every third party that touches customer data. Write the list before you're asked, because assembling it under time pressure is miserable.
You probably don't need SOC 2 yet
The instinct when a questionnaire lands is to panic-start a compliance programme. That's usually the wrong order and it's expensive.
A questionnaire is the customer's risk team deciding whether you're safe to buy from. A SOC 2 report is one way of answering it quickly, but it isn't the only way, and if you don't already have one you're months and five figures away. Most questionnaires can be answered honestly without it, provided your answers are specific and you can back them up.
The exception is when the contract names it outright. Then it's a deadline, not a question, and you should find out early rather than at signature.
Where startups actually get stuck
It's almost always the code scanning question.
Access control and encryption tend to be fine, because the cloud provider did most of it. Dependency scanning is fine, because GitHub turned it on. Then there's a question asking how you identify security defects in code your team wrote before it reaches production, and the real answer is that nobody looks.
You have three options. A penetration test gives you a report the customer will accept, but it's a point-in-time snapshot, typically several thousand pounds, and it's out of date the week after. Manual code review is credible if you have someone qualified to do it and impossible to evidence if you don't. Automated scanning in your pipeline is the cheapest of the three to stand up and the easiest to evidence, because it produces a record on every commit rather than a PDF once a year.
Most questionnaires accept the third, as long as you can show it runs on every change and that findings get fixed rather than accumulating.
What to do this week
Answer honestly. Risk teams read a lot of these and inflated answers are noticed. "We don't currently do X, and here's what we're putting in place by Q3" is a much better answer than a claim you can't evidence, and it's less likely to end up as a contractual commitment you can't meet.
Then keep the answers. The same six questions arrive with every enterprise deal, and the second one is far less painful if you've written the first down properly.
If code scanning is your gap, that's the one worth closing before the next questionnaire rather than after. Kolega runs on every commit, produces the evidence trail these reviews ask for, and fixes what it finds rather than handing you a list to work through.
Links to add on publish
Trust Centre
Answer: Does SAST satisfy SOC 2 requirements? (when written)
Up-link:
/use-cases/compliance