There is a moment that catches almost every young company by surprise. A large customer says yes. Everyone celebrates. And then a spreadsheet arrives from someone you have never spoken to, with two hundred rows and a two-week deadline.
This is the security assessment, and it is not a formality. Deals die here — not because the answers were bad, but because the answers did not exist and nobody had two weeks spare to invent them.
Here is what is actually on it, why each question is there, and what a good answer looks like.
“Where is our data stored?”
Why they ask: Their own regulator, or their own customers, may require data to stay in a particular country. If your answer is a region they cannot accept, the conversation ends here regardless of how good your product is.
A good answer names the country and the region, states whether it can be changed, and does so without needing to check. “Canadian regions by default, other regions available, tell us if you have a requirement” is a good answer. “I’ll find out” is the beginning of a two-week delay.
“Is data encrypted in transit and at rest?”
Why they ask: It is the cheapest possible filter. Anyone who cannot answer this immediately is unlikely to survive the rest of the list.
A good answer is specific: TLS 1.2 or above enforced with HSTS, AES-256 at rest covering the database, object storage and backups. That last clause matters more than people expect — encrypted databases with unencrypted backups is a common and embarrassing gap.
“Who at your company can access our data?”
Why they ask: Insider access is a genuine risk, and the honest shape of the answer tells them a lot about how you operate.
A good answer describes access as scoped, justified and logged. The bad answer is any version of “our engineers have access to production” without qualification, because it means access is ambient — everyone has it because that was easier to set up.
“Do you support single sign-on and MFA?”
Why they ask: They do not want to manage another set of passwords for their staff, and they want to be able to remove access centrally the day someone leaves.
A good answer covers both SSO through their identity provider and MFA enforceable per role, so administrators can be held to a higher standard than ordinary users.
“What is your backup and recovery process?”
Why they ask: They are trying to work out what happens to their data if something goes wrong at your end.
A good answer has three parts, and most people only have two:
- Backups run on a schedule, are stored separately, and are retained for a stated period.
- Recovery is possible to a point in time within that window.
- Restores are tested.
The third is the one that separates real answers from aspirational ones. A backup that has never been restored is a hypothesis. If you can say when the last restore test was and what the result was, you are ahead of most companies many times your size.
“How do you handle vulnerabilities in dependencies?”
Why they ask: Most breaches are not clever. They are a known vulnerability in a library that nobody updated.
A good answer describes continuous scanning against published advisories, a schedule for routine patches, and an out-of-band path for critical ones. The key word is continuously — a quarterly review is not a process, it is a calendar entry.
“What is your incident response process?”
Why they ask: They are not asking whether you will have an incident. They are asking what you will do, and specifically when they will hear about it.
A good answer covers contain, assess, notify, fix, and report — with a defined notification window. Under Quebec’s Law 25 and the GDPR you have obligations with short clocks attached, and “we would tell you as soon as we could” is not a process.
“Are you SOC 2 certified?”
Why they ask: It is a shortcut. Rather than evaluate your practices, they would like an auditor to have done it.
A good answer, if you are not certified, is to say so. Plainly, in the first conversation, without hedging. Then describe the underlying practice and offer the evidence you do have: a written security overview, an architecture description, your access control model, your backup testing record.
Many buyers will accept that, particularly for a pilot. Almost none will forgive discovering at contract stage that the certification they assumed you had does not exist.
The pattern behind all of it
Every question on that spreadsheet is really the same question: does this company do things deliberately, or did it do whatever was easiest and hope?
You cannot fake the answer under deadline. But you also do not have to be a large company to give a good one — you have to have made these decisions on purpose, and written them down before anyone asked.
The document that answers most of a security assessment is about six pages long. Writing it takes a day when you are calm and three weeks when you are not.