How to answer a customer security questionnaire without a security team
A practical guide for SaaS and fintech startups facing their first big-customer security review, from asset inventory to evidence.
It always lands the same week the big deal is about to close. A spreadsheet with a few hundred rows: encryption, access control, change management, vulnerability management, incident response. Your CTO is the security team, and the buyer wants evidence, not promises.
Here is how to get through it honestly, and be in better shape for the next one.
Step 1: Know what you actually run
Most questionnaires start with some version of "describe your environment". You cannot answer well without an inventory:
- Code repositories.
- Public domains and URLs, including old ones.
- Cloud accounts and the services inside them.
- Where sensitive data lives: card data, identity documents, personal information.
Write it down once and keep it current. It is the base for every answer that follows.
Step 2: Scan what is in front of you
You will be asked how you find vulnerabilities. Have real answers for each surface:
- Code: static analysis for risky patterns.
- Secrets: scanning repos for keys and tokens, and checking whether found keys still work.
- Dependencies: checking packages against known advisories.
- Infrastructure as code and containers: misconfiguration checks.
- Live URLs: probing from outside, the way an attacker would.
There are good open-source tools for each of these. The hard part is running them on a schedule and reading the results.
Step 3: Rank by what each finding can reach
A scan can return hundreds of findings. Do not work through them by the severity the tool printed. Ask a better question: how close is this to customer data?
A medium-severity debug route that leaks a working cloud key that can read the payments database is more urgent than a high-severity issue on a service that touches nothing sensitive. Think in paths: internet, then exposed service, then credential, then data. Fix the step that breaks the path.
Step 4: Fix, then confirm
Closing a finding means re-scanning and confirming it is gone. Keep that evidence. "We fixed it" is weaker than "here is the scan from the next morning".
Step 5: Map your answers to controls
Many questionnaires follow, or borrow from, SOC 2 and ISO 27001. Map your work to the relevant controls, such as logical access, change management, cryptography and secure coding. Then a question about access control points to evidence, not a paragraph written at midnight.
Be clear about what this is and is not. Mapping your findings to controls helps you prepare and answer reviews. A SOC 2 report is still issued by an independent auditor.
Step 6: Watch for new advisories
Buyers increasingly ask what you do when a new vulnerability is announced. Keep a bill of materials for each repo, so when an advisory drops you can say the same day which services are affected and what the upgrade is.
Step 7: Be honest in the answers
If you do not have a control yet, say so, and say what you are doing about it. Reviewers deal with startups every day. Confident, specific, honest answers with evidence go further than polished claims you cannot back up.
A questionnaire-ready checklist
- An asset inventory you trust.
- Scheduled scans across code, secrets, dependencies, cloud and live URLs.
- Findings ranked by distance to sensitive data.
- Fixes confirmed by re-scan.
- Evidence mapped to SOC 2 and ISO 27001 controls.
- A same-day answer for new advisories.
Common mistakes
- Answering from memory. If you cannot point to evidence, the reviewer will ask for it later.
- Treating the scanner dump as the answer. Hundreds of unranked findings tell the buyer you have not triaged them.
- Forgetting old domains. A forgotten staging site is often the easiest way in.
- Scanning once before the review. Watching on a schedule is what keeps the next questionnaire easy.