The spreadsheet arrives on a Tuesday with 180 rows, four tabs and a column headed Yes / No / Partial. Your first real enterprise customer wants it back by Friday, their legal team is copied, and your company is twelve people, three of whom write code and none of whom have the words security or compliance in their job title. Somewhere around row forty, the temptation arrives: the questions have an obvious right answer, the boxes are dropdowns, and nobody is going to check.
That temptation is the only genuine risk in the whole exercise. Everything else about a questionnaire is survivable.
What the reviewer is actually doing
It helps to understand the job on the other side of the sheet. The reviewer is not trying to establish that you are as secure as a bank; the company size is on the first tab. They are doing two things.
The first is sizing the blast radius. What of ours would be exposed if this vendor were breached, and could we tell? A tool holding national identifiers and salary data gets a harder read than one holding meeting notes, correctly so.
The second is calibration, and this is the part small companies miss. The reviewer is reading your answers to work out how much your answers are worth. They have read hundreds of these. They know which claims are usually hollow, and a sheet of 180 confident yeses from a twelve-person company reads as a sheet nobody thought about. One honest no in a plausible place does more for your credibility than forty yeses, because it establishes that the yeses were considered.
Answer what you have, name what you do not
The working rule is simple to state and hard to hold at four in the afternoon on the Thursday: never claim a control you cannot evidence.
Evidence does not mean an auditor’s report. It means that if the reviewer said show me, you could, within a day, without inventing anything. A screenshot of the access list. The offboarding checklist with last month’s leaver ticked off and dated. The restore test with the date it ran and who ran it. If the answer to show me is a story about how you would probably do it, the honest box is not Yes.
Where a control is partial, describe the partial version rather than rounding it up. “MFA is enforced on the identity provider and on the two systems that support it; three older tools do not support it and are listed in our register” is a strong answer. “Yes” in the same box, when a reviewer later finds one of those three tools, costs you the deal and every other answer on the page with it.
Where a control does not exist, say so and say what stands in its place. “We do not have single sign-on. Access is granted from one identity provider with unique credentials in a shared manager, and the offboarding checklist names every system a leaver is removed from, run by a named person within four hours of their last day.” That is a real answer to the underlying question, which was never about SAML. It was about whether a leaver keeps reaching the data.
Five controls that carry most of the sheet
A small company can put a genuine floor under itself for close to nothing. Five things, none of which need a hire.
Least privilege, actually applied. Everyone holds the access their job requires and nothing else, admin rights sit with the smallest set of people who can still work, and shared logins are eliminated rather than documented. Most questionnaires ask this four different ways.
A written offboarding checklist. One list, naming every system a departing person must be removed from, with an owner and a target time. This is the single control that most improves your real security posture and the one most often missing, because it is nobody’s project. It also answers the SSO questions honestly, since SSO is the automation of exactly this list.
Encrypted backups with a tested restore. The backup is the easy half. The restore is the answer: a dated record of a restore you performed, what came back, and how long it took. A vendor who has restored is in a different category from one who has configured.
A written incident process. Half a page. How something is detected, who is called, who decides, when and how affected customers are told, and which regulators have a clock attached. Then run it once as a drill and keep the record. A runbook that has been executed answers this category far better than a policy that has been written. If you hold employee records for people in India, work out which of your DPDP obligations attach to an incident while you are writing the half page, not on the day you need it.
An access review on the calendar. Quarterly, every system, every account, with a record of what was removed. Half a day per quarter, and it turns the least-privilege claim from an intention into a fact with a date on it.
None of that requires a certificate, all of it is evidenceable by four people with a shared document, and between them these five cover a large share of a standard questionnaire. The guide to the HR security questionnaire walks the categories in the order reviewers usually ask them, and works equally as a checklist for when you are the one asking.
Why “we are working towards SOC 2” is the weakest line on the page
It appears on almost every small vendor’s sheet. Here is what a reviewer hears.
They hear nothing has started, and usually they are right: “working towards” is what people write when there is no firm, no scope and no date. It is an intention in the clothes of a plan, and reviewers discount it entirely. Worse, it spends the credibility you built elsewhere on the sheet, because it is the one answer they can tell is padded.
The alternative is not a better promise, it is a precise description of a control. “There is no SOC 2 report today and no audit is currently commissioned. What exists instead: production access requires a named approval and is time-boxed, backups are encrypted and a restore was tested on a date we can name, and every change ships through automated dependency and secret scanning that fails the build.” A reviewer can act on that. It tells them what protects their data this quarter, and it can be verified, which is the property a certification is a proxy for in the first place.
The useful discipline is to sort every compliance claim into three buckets and never let them blur. Held, with a report and a date. Commissioned, with a named firm and a window. Intended, which means nothing has started and should be written as such, or not written at all.
A stated limit also does something a vague assurance cannot: it tells the reviewer where the edges of your knowledge are, which is what lets them trust the middle. Vendors who mark their own boundaries get read as vendors who know their system. Vendors who are confident everywhere get read as vendors who have not looked.
Where we stand
Capstan answers these sheets too, and publishes the answers rather than sending them, which is this post’s recommendation applied to ourselves. The security page is written for the person who has to sign off the risk, control by control, with what proves each one and what each proof does not cover.
Since this post was first published, one of those buckets has moved, which is the honest reason to update a post rather than leave it standing. The entity behind Capstan holds an ISO/IEC 27001:2022 certificate for its information security management system. It is published the way this post asks any vendor to publish one: the certificate number, the certification body and its accreditation, the issue and expiry dates, the completed surveillance audit, and the scope, which covers information security applied to software development, business consulting and digital transformation services and is therefore a certification of how the company works rather than a test of the product. That distinction is printed beside the badge, because a reviewer would otherwise have to ask.
The gaps are still on the page, in the same type as everything else. There is no SOC 2 report, and no target date is published for one, because a date nobody has committed to is exactly the padding this post is about. There is no published recovery time objective, because we do not quote numbers we have not measured. Single sign-on does not exist, so no plan withholds it.
What is described instead is specific: support staff hold no standing access to customer data and need a consent you grant, scoped, time-boxed and revocable, with every read logged on both sides; sensitive fields carry per-tenant envelope encryption with the keys held outside the database; and the manifesto carries the reasoning that makes the rest of it worth reading, which is that a company willing to tell you what it has not built is the one you can believe about what it has.