Reading a vendor security questionnaire when you're the vendor

The questionnaire arrives as a spreadsheet. Two hundred rows, sometimes four hundred, a column marked Yes/No/Partial, and a comments column the person who built the template clearly expected nobody to use. Somewhere around row thirty the first instinct shows up: find the reading of the question under which the answer is yes. That instinct is the whole problem, and it is worth naming early, because most of what goes wrong later in a procurement process starts there.

Most of these questions have three honest answers rather than two. Yes. No. And "not in the way you are asking" — which is the most common of the three and the one the form has no column for. The comments column is where that answer goes, and using it generously is the practical difference between a questionnaire that helps a deal along and one that quietly kills it three months later.

The certification questions are the easy ones

SOC 2. ISO 27001. A third-party penetration test report. These rows feel like the hardest part of the document and are in fact the simplest, because they are not really questions about your security. They are questions about whether a specific document exists. Either you can attach it or you cannot.

We cannot. We have not completed a SOC 2 audit, we do not hold ISO 27001, and we have no third-party penetration test report to share. All three are published on our own security page as gaps, sitting in the same list as the practices we do have, and we answer the questionnaire the same way we publish it.

The temptation on those rows is the hedge: "we follow SOC 2 principles", "our infrastructure provider is certified", "aligned with ISO 27001". Every experienced reviewer reads those as a no, because they are a no, and having read one they now read the rest of your answers differently — including the true ones. A hedge does not win you the row. It spends credibility on every row after it.

The questions that actually take thought

Past the certifications the document gets more interesting, and the rows that take real work are the ones about specifics rather than posture: where the data sits, who else touches it, how access is granted and removed, what happens when a customer leaves, and how quickly you would tell them about an incident.

Sub-processors is the one good-faith vendors get wrong

A sub-processor is any third party that may handle customer data — the hosting platform, the payment processor, the email provider, the error-tracking service, the support desk. The list has to be complete, and it is invariably longer than the one a company writes from memory, because the obvious names come to mind immediately and the tool somebody added during a sprint two years ago does not.

This is not a formality. Under GDPR a controller has to be told who processes their data, and "we forgot to list our email provider" is a breach of that duty whether or not the provider is perfectly fine. The only reliable way to build the list is to work through the billing statements rather than the memory of the engineering team — an afternoon's work most vendors have never done, which a reviewer cannot verify directly but can absolutely tell the difference in.

Access, and how it ends

Questions about who can reach customer data get answered with the granting half: roles, least privilege, approval steps. The half that matters more is the revoking half — what happens on the day somebody leaves, how long it takes, and whether anybody checks afterwards that it happened. A vendor who can describe their offboarding in concrete steps is telling you something a policy document cannot, and it is a fair question to ask of a company of any size.

Getting your data back

Export and deletion sit near the end of the document, after the reviewer's attention has usually gone, and they are the rows a customer is most likely to actually need one day. Which formats, which fields, attachments included or not, how long it takes, and what confirmation you get when data is deleted. Our answer is that we will export in a portable format or delete and confirm when it is gone, because the underlying position is not complicated: it is the customer's data.

What honesty costs, and what it buys

The cost is real and worth stating plainly. You lose deals. If a signed Business Associate Agreement is a requirement, we say on the first call that we do not sign them today, and the conversation ends there. Some of those would have been good customers.

What it buys is that you lose them at question twelve instead of in month three. A deal that ends during procurement costs a sales conversation. A deal that ends after a scoping exercise, a pilot, and a half-built implementation costs all of that plus the relationship — and the reason it ends is not the missing certification, it is that the missing certification was discovered rather than disclosed. Those are different failures and only one of them is survivable.

There is a second, less obvious return. A questionnaire answered honestly is a specification of what you have not built yet, written by somebody with no stake in your roadmap. The gaps you find yourself writing "no" against repeatedly, across different customers, are an unusually clean signal about what to fix first — cleaner than most internal prioritisation, because the person asking has no interest in flattering you.

If you are on the other side of the table

Most readers of this site buy software rather than sell it, so here is the same argument inverted: specificity is the signal. A vendor who answers "not held today" and then names precisely what they do have is easier to evaluate than one who answers "enterprise-grade security" across forty rows. The second is not necessarily worse at security. They are, however, harder to check, and you are making the decision on what you can check.

The follow-up worth asking any vendor, ourselves included, is what they publish versus what they will tell you on request. A company that has written its gaps down somewhere its customers can read them has already had the uncomfortable internal argument about saying so, which is most of the work.