# Answering a customer's security questionnaire by email

> A customer sent a 90-question security spreadsheet. Here is how a small team answers honestly: what to say, what to attach, and what never to claim.

- Published: 2026-10-17
- Author: Koltrix Team
- Category: Startups
- Source: https://koltrix.com/blog/answering-a-customer-security-questionnaire-by-email-what-a-small-team-can-say

A customer you want writes back with a spreadsheet: ninety questions about encryption, access control, incident response and subprocessors, and a request to return it by Friday. If you are a team of three, the first reaction is usually panic, and the second is the temptation to answer "yes" to everything so the deal can move.

Do not do the second. A small team can pass most questionnaires by being specific and truthful, because the person reading it is not looking for a perfect score. They are looking for someone who knows what they run and will tell them the truth.

## Understand what the reader wants

A security questionnaire is rarely read by a security expert with time to spare. It is usually a procurement or IT person ticking boxes for a file. Their real questions are simple:

- Do you know where our data goes?
- Do you have a basic set of controls, and can you describe them?
- If something goes wrong, will you tell us and fix it?

A short, plain answer that shows you understand the question beats a long one copied from a template. If a question does not apply to you, say so and say why.

## Reply by email first, before you open the spreadsheet

Many deals stall because nobody answers the cover email. Send a short reply the same day:

1. Confirm you received it and name a date you will return it. Pick a date you can keep.
2. Ask who the questions are for, and whether a different format (a short call, or answers in the body of an email) would be acceptable.
3. Ask what would block the deal. Often two or three questions matter and the rest are routine.

Keep the thread in one place. If a shared inbox is where sales and support mail lands, assign the thread to one person so two teammates do not send two different answers. Our post on [collaborative replies without double sends](/blog/collaborative-replies-shared-inbox-no-double-sends) covers the habit.

## Write your honest baseline once

Before answering a single row, write one page for yourself that states what is actually true today. For each area, write what you do, who does it, and what you do not do yet.

| Area | Questions to answer for yourself |
|---|---|
| Accounts | Is two-step sign-in required for everyone, on every system that holds customer data? |
| Access | Who can see customer data? Is that list written down, and does it change when people leave? |
| Data | Where is customer data stored, in which country, and with which providers? |
| Backups | How often, where, and when did you last restore one to prove it works? |
| Incidents | Who decides something is an incident, and how fast do you tell customers? |
| Changes | How does code reach production, and does anyone review it? |
| People | How do you handle laptops, passwords and offboarding? |

Writing this takes an afternoon and every later questionnaire gets faster. It also exposes the gaps you would rather find yourself than have a customer find. Our [one-page email policy](/blog/a-one-page-email-policy-for-a-company-of-five) is a good model for how short such a document can be.

## Use a three-way answer

Most questionnaires offer yes or no. Real life has a third answer, and using it is what keeps you honest.

- **Yes** means it is true today, for everyone, and you could show it.
- **Partly** means it is true for some systems or some people. Say which.
- **Not yet** means you do not do it. Say whether it is planned and when.

A "not yet" with a date reads far better than a "yes" the customer later discovers is false. If you answer yes and a later audit or incident shows otherwise, you have turned a small gap into a trust problem, and in some contracts a legal one.

## Rules for the answers themselves

**Answer the question that was asked.** If asked whether data is encrypted at rest, say what is encrypted and where, not a paragraph about your philosophy.

**Name your providers.** The list of companies that touch customer data is one of the most common questions. Keep it current, with what each one does. The [vendor questions](/blog/email-vendor-security-questions) a buyer should ask you are the same ones you should be able to answer about your own suppliers.

**Do not claim certifications you do not hold.** "SOC 2 compliant" and "SOC 2 audited" are different statements, and so is "hosted on infrastructure that is certified." If your hosting provider holds a certification, say that the provider holds it, not that you do.

**Do not invent policies.** If you do not have a written incident plan, do not say you have one. Write a one-page plan this week, then say so truthfully.

**Keep numbers out unless you can show them.** Recovery times, uptime figures and retention periods should come from something you have measured or configured.

## Handle the privacy questions carefully

Questionnaires often ask about personal data: what you collect, how long you keep it, and how you handle requests to see or delete it. Have a clear answer for each, and know where the customer's own data sits. The basics are in our posts on [email and GDPR for a small company](/blog/email-and-gdpr-for-a-small-company-the-practical-basics) and [personal data in email](/blog/personal-data-in-email-plain-rules-for-small-teams).

If the customer asks for a data processing agreement, say yes to receiving theirs or offering yours, and ask a lawyer to read it. Do not accept legal terms by email on a questionnaire thread.

## What to attach

Short, real documents help more than adjectives:

- A one-page security overview in plain language.
- Your privacy policy and the list of subprocessors.
- A diagram or a paragraph that shows where data flows.
- Screenshots of settings only when asked, with customer names and secrets removed.

Never attach anything that contains secrets, keys, customer data or internal addresses. Check the file properties as well as the page, since spreadsheets can carry comments and hidden sheets.

## Send it so it can be found again

When you return the spreadsheet, reply in the original thread with a short summary in the body: what is attached, the three or four points you most want them to read, and an offer of a 20-minute call. Save the final version and your baseline page in one folder. Next time a customer sends a different questionnaire, you will be copying from your own honest answers instead of starting from zero.

Keep a short log of questions you could not answer. If three customers ask about the same missing control, that is a roadmap item with a reason attached.

## When to ask for help

If a customer demands an independent audit, penetration test results or contractual liability you cannot accept, say so early and plainly. Some deals are not for you yet, and finding that out in week one is cheaper than in week six. A good customer will often accept a smaller commitment, such as a call, a written plan, or a review after the first quarter.

## Key takeaways

- Reply the same day with a date you can keep, and ask what actually blocks the deal.
- Write an honest one-page baseline first; every later questionnaire reuses it.
- Use yes, partly and not yet, and never claim a certification or policy you do not have.
- Attach short, real documents, and keep secrets and customer data out of them.
- Keep a log of questions you could not answer: it shows what to build next.