A Customer Sent You a Security Questionnaire and You Have Nothing to Fill It In With

Direct answer: Answer it honestly, including the gaps, and attach a dated remediation plan for anything you cannot answer yes to. Buyers reject vendors for inconsistency far more often than for immaturity. An honest "not yet, here is when" survives review. An invented yes fails the moment somebody asks for the evidence behind it.

The first thing to understand

A security questionnaire is not a test you pass or fail on the spot. It is a risk file. Somebody on the buyer side has to write a recommendation, and they need enough to justify it internally. What kills deals at this stage is not a weak control, it is an answer that cannot be backed up, because that turns a technical review into a trust problem.

What to do in the first 48 hours

Read the whole thing before you answer anything. Questionnaires repeat themselves, often asking the same control three ways across different sections, and answering them in order produces contradictions that a reviewer will find. Group the questions by subject first: access, data handling, infrastructure, vendors, incident response, people.

Then sort every question into one of three buckets. Things you do and can evidence. Things you do but have never written down. Things you do not do. That third bucket is where founders panic, and it is usually the smallest of the three.

Most early companies are further along than they think. You almost certainly have access control, because you use SSO. You have encryption, because your cloud provider does it by default. You have backups. What you do not have is any of it written down, which is a documentation problem rather than a security one, and it is much faster to fix.

How to answer the ones you cannot answer yes to

Write what is true now, then what changes and by when. "We do not currently run quarterly access reviews. We have scheduled the first for 30 September and will provide the completed record." A reviewer can work with that. It gives them something to write down and a date to hold you to.

Never answer yes to a control you cannot produce evidence for. The follow-up request is standard, and being unable to answer it is worse than the original no, because now the reviewer has to wonder what else was overstated.

What the questionnaire is really telling you

If a buyer sent a long questionnaire, you have crossed into a segment that will keep asking. The next deal will ask too, and probably for a SOC 2 report rather than a spreadsheet. The questionnaire is early warning that the answer needs to become a standing asset instead of a fire drill every quarter.

That is the actual decision in front of you. Not "how do I get through this document", but "how many more of these am I going to answer by hand before I put a report and a trust page in front of them instead".

What good looks like six months later

Companies that get this right end up answering questionnaires in under an hour, because the underlying answers exist once and get reused. They have a written policy set, an evidence store, and either a SOC 2 report or a clear date for one. The questionnaire stops being an event.

We do this two ways. Security Questionnaire Help gets the document in front of you completed and defensible when a deal is waiting. Trust Center Setup puts the answers on a page you can send instead, which is what stops the next one arriving as a spreadsheet.

Work out which document you have been sent

Before you write a single answer, identify the format, because it tells you how much work is coming and how the answers will be read.

A CAIQ is the Cloud Security Alliance's standard set, mostly yes/no with a notes column, and it maps to a published control framework. It is long but mechanical, and a completed one can be reused almost verbatim for the next buyer who asks.

A SIG comes in a lite version of a couple of hundred questions and a full version that runs to well over a thousand. If you received the full SIG as a company under fifty people, somebody in procurement sent the default template rather than the tier appropriate to your spend. It is entirely reasonable to reply asking whether the lite version is acceptable given the contract value and data scope. That email works more often than founders expect.

A bespoke spreadsheet written by the buyer's own security team is the most informative and the most dangerous. It reflects what they actually worry about, which means the questions are pointed and generic answers stand out. It also means there is a named human who wrote it, and that person can be spoken to.

Who reads it, and what they are trying to produce

The reviewer is usually one of three people, and the right tone differs for each.

A third-party risk analyst works through a queue with a scoring rubric, checking whether each control is present, evidenced and consistent rather than evaluating your architecture. A security engineer pulled in to review a vendor touching sensitive data will read your answers properly and will notice hand-waving instantly, so specificity buys credibility. A procurement coordinator with no security background is checking completeness, and the risk there is that a careful nuanced answer gets scored as a non-answer because it did not begin with a yes or a no.

In all three cases the output is the same artefact: a short internal recommendation with a risk rating and conditions attached. Your job is to make that document easy to write in your favour. Every answer should give the reviewer a sentence they can lift directly.

The questions early companies consistently get wrong

Subprocessors. You will be asked for a list of every third party that stores or processes customer data. Most companies produce four names and miss six, because the analytics tool, the error tracker, the support desk, the AI feature vendor and the email service all touch customer data. An incomplete list discovered later reads as concealment even when it was carelessness. Build the list from your actual billing records and your production environment variables, not from memory.

Data residency and cross-border transfer. Canadian companies get asked this constantly and answer it loosely. "Hosted on AWS" is not an answer. The answer names the regions, states whether backups replicate elsewhere, and says which of your subprocessors move data across a border. If you sell to Canadian public sector or health organisations, expect follow-up on where the data can be compelled from.

Penetration testing. A vulnerability scan is not a penetration test and calling it one is the kind of overstatement that costs you the reviewer's trust for the rest of the document. If you have not had a test, say when the first one is booked. If you have, be ready to share an executive summary under NDA rather than the full report with findings in it.

Encryption key management. "We encrypt at rest" invites the follow-up "who holds the keys and how are they rotated". If the answer is that your cloud provider manages them with default rotation, say exactly that. It is a perfectly acceptable answer and vagueness makes it look like a gap.

Business continuity and recovery objectives. Buyers want RTO and RPO figures. Do not invent them. Work out what your backup schedule and restore process actually deliver, state that, and if you have never tested a restore, do one before you answer. Companies discover broken backups during this exercise more often than is comfortable.

Background checks and offboarding. These come up in every questionnaire and are the cheapest gaps to close. Criminal record checks for new hires and a documented offboarding checklist that revokes access within a stated window are a week of work and remove two red rows.

Saying not applicable without it reading as evasion

Plenty of questions genuinely do not apply. A pure SaaS company has no physical data centre to describe. Marking those "N/A" is correct, and it is also the most abused answer in the document, so reviewers are primed to be suspicious of it.

Add one clause of reasoning every time. "Not applicable. We do not operate physical infrastructure; all workloads run in AWS and the relevant controls are inherited from their SOC 2 report." That takes ten seconds and converts a suspicious blank into a demonstration that you understood the question. A document with thirty bare N/A entries and no explanations gets sent back in full.

The exhibit behind the questionnaire is the part that binds you

The questionnaire is a snapshot. The security addendum attached to the contract is a commitment, and it is where early companies do real damage to themselves while relieved that the spreadsheet is finished.

Read it for four things. Breach notification timelines, often drafted at twenty-four hours and worth negotiating to seventy-two unless you genuinely have detection capable of meeting it. Audit rights, which sometimes let the buyer inspect your systems on short notice; a clause accepting a current SOC 2 report in lieu of an on-site audit is the standard substitution. Named control commitments, where the addendum lists controls you must maintain and every one becomes contractually enforceable. And subcontractor approval rights, which can mean you need written consent before adding a new tool that processes customer data.

Never sign an addendum committing to a control you answered honestly about not having. Companies do this because the questionnaire went well and the legal document feels like paperwork. That is how an accurate "not yet, here is the date" turns into a contractual breach four months later.

What happens after you submit

Straight approval is rare on a first enterprise deal. Follow-up evidence requests are the norm, usually three to eight items: a policy document, a recent access review record, the pen test summary, an architecture diagram. Have these ready to send within two days, because response speed at this stage is read as operational maturity.

A review call is common when the buyer's own security engineer is involved. Send the technical person who can answer, not only the account executive. A founder who can explain their own architecture and name their weak spots converts more of these calls than a polished deck ever has.

Conditional approval is a win. It means you are through, subject to specified things being done by specified dates. Track those commitments somewhere formal, because they will be checked at renewal, and a missed remediation date on a conditional approval is a much harder conversation than the original gap. This is the point where keeping the controls, evidence and dates in one place stops being optional; our free Workspace exists for this, and any tracked system will do as long as it is not a founder's inbox.

When to push back, and when not to spend money on this

Not every questionnaire deserves a full response. If the deal is worth a few thousand dollars a year and the buyer sent a thousand-row SIG, the honest calculation is that answering it well costs more than the contract returns. Reply with what you have, offer a call, and accept that you may lose it. Some buyers are not economic for a company your size yet, and chasing them burns the quarter.

Push back where the questions do not fit your service. If you never receive their production data, say so at the top of the document and ask whether the data-handling sections apply. A good analyst will narrow the scope. It also reframes the whole review, because the risk they are assessing is smaller than their template assumed.

And you do not always need help with this. If it is your first questionnaire, it is short, and you have a week, do it yourself. The exercise teaches you your own environment better than any consultant's report and produces the answer library you will reuse. Bring in outside help when the timeline is genuinely tight, when the buyer is large enough that a weak answer loses the account, or when the same work is arriving every month and needs to become a standing compliance position rather than a repeated scramble. If you are unsure which of those you are in, tell us what arrived and when it is due and we will say plainly whether it is worth paying for.