Stages / Stage guide

A customer sent us a security questionnaire. Where do we start?

Matt Turley, Continuum. Updated November 5, 2026.

For founders of a young product whose first business customer, pilot or enterprise prospect has sent a spreadsheet of security questions.

The short answer

A customer sent us a security questionnaire. Where do we start?

Start by answering truthfully from facts you can check, not from what sounds good. List what data you hold and where, who has access, which vendors touch it, how it is protected and what you do on an incident. Mark gaps as planned with a date. Never claim a certification you do not have.

What is really going on

A security questionnaire is a buyer trying to decide whether giving you their data is a risk they can defend internally. It is rarely a test you pass or fail on a single answer. The reviewer looks for honesty, awareness and a plan, and is quick to distrust answers that are all perfect.

Questionnaires usually ask about the same areas: access control, data protection, infrastructure, vendor management, logging and incident response, backups and business continuity, software development practices and compliance. A small product can answer most of them truthfully with a short list of basic controls.

The danger is answering from aspiration. Marking "yes" to multi-factor authentication on all systems, encryption, logging and penetration testing when you have not checked is both a trust problem and, if it goes wrong later, a contractual one.

The areas a questionnaire covers, and what to have ready

  1. Access control

    How to tell They ask who can access production, how access is granted and removed, and whether multi-factor authentication is required. Many early teams share logins or have a departed contractor still in a dashboard.

    The fix List everyone with access to hosting, database, source code and payments. Remove what is not needed, turn on two-factor authentication everywhere and keep admin to a minimum.

  2. Data: what you hold, where, and how it is protected

    How to tell They ask what personal data you store, where it is hosted, whether it is encrypted in transit and at rest and how long you keep it.

    The fix Write a one-page data inventory. Confirm HTTPS everywhere and what your database and storage providers do by default for encryption at rest, and state it accurately.

  3. Application security

    How to tell They ask how you prevent and find vulnerabilities, whether you test and how you manage dependencies. AI-generated code is rarely reviewed by anyone.

    The fix Get the code read by someone who knows what to look for, fix what matters, turn on dependency vulnerability alerts and keep the evidence.

  4. Vendors and sub-processors

    How to tell They ask which third parties handle their data. An AI-built app often sends data to several without anyone listing them: hosting, database, email, analytics, error tracking and AI model providers.

    The fix List every vendor that touches customer data and what it touches. Check that each one's terms fit what you promise, including whether prompts sent to an AI provider are retained or used for training.

  5. Logging, incident response and recovery

    How to tell They ask how you would detect a breach, who is responsible and whether backups are tested. A one-person team usually has no written process.

    The fix Keep access and error logs, write a half-page incident plan (who decides, who is told, in what order), and take and test a backup restore once.

  6. Compliance claims

    How to tell They ask whether you have SOC 2, ISO 27001 or similar. Early products almost never do, and some questions assume you do.

    The fix Say what you have, honestly. "Not yet; here are the controls we operate, and our plan" is an acceptable answer. Do not imply a certification, and do not describe a vendor's certification as your own.

How we diagnose it

  1. Read the whole questionnaire first. Group the questions by area, and mark which you can answer from known facts, which need checking and which describe a control you do not have.
  2. Check before you answer. For each claim, find the evidence: a setting screenshot, a vendor document, a log. If you cannot find it, the answer is not yes.
  3. Test the application, not just the policy. We read the code and test the live app for the things questionnaires ask about: authorization, exposed secrets, input handling and what is public.
  4. Close the cheap gaps. Two-factor authentication, access cleanup, backups and a written incident plan cost little and change many answers from no to yes.
  5. Answer with dates for the rest. For each real gap, state the control, the owner and the date. A credible plan is usually better received than silence or an inflated yes.

What fixing it changes

  • A data inventory and vendor list that you can show.
  • Two-factor authentication and trimmed access across hosting, database, code and payments.
  • Tested backups and a short written incident plan.
  • The application code read and tested, with fixes made for what matters.
  • A truthful completed questionnaire, with the gaps and the dates stated.

When you do not need us

If the questionnaire is short and your honest answers are mostly "yes, and here is how", fill it in yourself. An independent read becomes valuable when the questions go into application security and you have never had the code reviewed. A Ship Check is not a compliance audit, penetration test or certification, and will not replace one if your customer requires it.

Your next step

A Ship Check is an independent, written read of the codebase with a security and data section. It gives you evidence to answer from and a list of fixes. It is not a compliance audit or a formal penetration test, and we will tell you if your customer needs one.

Ship Check, $299: A senior engineer reads your codebase and sends a written verdict (fine, fixable or rewrite), what will break first, a security and data read, and a costed plan, within 48 hours of repo access or it is free. It has a 7-day money-back and is credited against a Ship Fix. Or: Book a call.

Get a Ship Check, $299 →See all services and prices →
FAQ

Straight answers

Do we need SOC 2 to answer a questionnaire?
No. Many early customers accept honest answers and a roadmap. Some larger buyers require SOC 2 as a condition of contract, and you will need to decide whether the deal justifies that effort. Ask the customer which they actually need.
Can I answer yes if my cloud provider is certified?
Only for what the provider does. A hosting provider's certification covers its own infrastructure, not your application code or how you configure access. Say that precisely rather than presenting the certification as yours.
Can I use AI to fill it in?
It can draft wording, but it cannot know your configuration. Every answer must come from what you verified. An AI-written answer that claims a control you do not run is worse than no answer.
Keep reading
What breaks in an AI-built app after Demo Day?By stage. After demo day or investor attention: a signup spike, technical questions and an app built to be demoed. What breaks first and what to do this week.What should I check before launching my AI-built app?By stage. A launch-week checklist for apps built with AI tools: who can see whose data, secrets, the real payment path, email, backups, monitoring and a rollback plan.How do I know if Supabase RLS is off, and what do I do?By symptom. Row level security off means anyone with your public key can read or change that table. How to check in a minute, the six ways RLS fails, and the fix.What breaks in an AI-built B2B SaaS app before launch?By vertical. For B2B SaaS built with AI tools: tenant isolation, roles, invites, billing and the enterprise asks that arrive first. What breaks and how to check.What breaks in an AI-built health app before launch?By vertical. Health apps built with AI tools: whether HIPAA applies, vendors that need a BAA, patient data in logs and AI prompts, and access control. Not legal advice.Is my AI-built app ready for an investor demo?By stage. The week before an investor demo: what fails live, how to rehearse on the production URL, and what to fix first. A checklist for AI-built apps.
Sources
  1. 1. NIST: Cybersecurity Framework, NIST: The identify, protect, detect, respond and recover structure that most questionnaires follow.
  2. 2. OWASP: Application Security Verification Standard, OWASP: A detailed list of application controls that questionnaire questions are drawn from.
A customer sent us a security questionnaire. Where do we start?