Answering a vendor security questionnaire from your own documents

If you sell to larger companies, schools or public bodies, it arrives sooner or later: a security questionnaire. Sometimes it's a standard one, such as the SIG, the CAIQ or, in higher education, the HECVAT. Sometimes it's the customer's own spreadsheet. It can run to hundreds of questions, much of it written in language that assumes you have a security team.

Without a system, it's easy to answer each one from scratch, under deadline, and the answers drift from one customer to the next. Here is a way to answer from what you already have, and to make the next one faster.

1. Gather what you already have

You probably have more than you think: an information security policy, a privacy policy, an incident response plan, a backup or business continuity note, your hosting provider's security documentation, an earlier questionnaire you already answered, maybe a penetration test summary. Put them in one folder.

Many of these exist only as PDFs or scans. Getting their text out makes them searchable, so you can find "encryption at rest" across all of them in seconds. Presentr Analyze's text extractor turns a PDF or image into plain text, Word and JSON. If you use Claude, Presentr Analyze is also in the Claude connector directory, so you can ask Claude to pull the text out of a policy PDF or image from a direct HTTPS link.

2. Build an answer bank, not a single answer

Questionnaires ask many of the same things in different words: who can access production data, whether data is encrypted in transit and at rest, how you handle an incident, how often you back up and test restores, how staff are onboarded and offboarded, which subprocessors you use.

Write one short, honest answer for each of those themes, with a pointer to the document that backs it up ("Information security policy, section 4"). Store it in a spreadsheet with three columns: theme, answer, evidence. Every new questionnaire then becomes matching questions to themes, not writing.

3. Answer what is true, and say what isn't in place yet

The temptation under deadline is to write "yes" to everything. Don't. A reviewer would rather see "Not yet: planned for Q2, compensating control: …" than discover later that a "yes" wasn't true. An honest "partially" with a plan reads as a mature answer, and it is the one you can defend.

4. Keep it consistent

The risk with answering by hand is that two customers get two different answers to the same question. An answer bank fixes most of that. When an answer changes because you adopted a new control or changed hosting provider, change it once in the bank, and note the date.

5. Send evidence, not essays

Where a question asks for proof, attach the relevant document or excerpt instead of describing it. Keep a small evidence folder: current policies, certificates, the latest test summary. Each one should be dated, so you know what's out of date. Before anything leaves the company, get it approved, remove anything the customer doesn't need to see, and send it through a secure channel, under the NDA if there is one, rather than as a public link.

What we're testing

Getting the text out of your documents is what Presentr Analyze does today. The slow part people describe is the rest: matching each question to an answer and its evidence, and assembling the completed questionnaire. We're testing a way to do that: you upload the questionnaire and your documents, and get back a draft with each answer linked to the document it came from, ready for you to check. It is a draft for you to review, not answers you send unchecked.

It isn't built yet. If you'd use it, tell us what you'd submit and how you handle questionnaires today.