It arrived as a spreadsheet attachment with a two-week deadline and a cheerful covering note. One hundred and eighty questions across nine tabs. It came from the first customer who was actually going to matter, the one whose name would have changed every subsequent conversation, and it arrived four days after they said they wanted to move forward.

We could answer about sixty of the questions honestly. Another forty we could answer with work. The remainder asked for things that take months of elapsed time and cannot be produced by working harder.

That is the lesson, and it is the whole lesson. Some things you can build under pressure. Trust is not one of them, because trust is largely made of time you have already spent.

Trust has a lead time

Take the most commonly requested attestation. A Type I report assesses whether your controls are appropriately designed at a single point in time. Preparation, remediation and the audit itself typically consume two to three months, and it is achievable from a standing start if you commit.

A Type II report assesses whether those controls actually operated over a period, and the period is the point. It requires an observation window, commonly three to twelve months, during which evidence accumulates. There is no version of this you can accelerate with money or urgency. If a buyer requires Type II and you begin the day they ask, you are a minimum of six months from an answer, and their procurement cycle is not going to wait.

This is why the certification belongs on the roadmap during the quarter when you have no customers asking for it. It is the least satisfying work available and it is pure elapsed time, which makes starting early the only lever that exists.

What the hundred and eighty questions are actually asking

Behind the spreadsheet there are about six real questions, and every tab is a restatement of one of them.

• Where does our data physically go, and through whose hands?
• Who inside your company can see it, and how do you know?
• Is it used to improve anything, including anybody’s model?
• What happens, specifically, if you are breached?
• What happens to our data if you cease to exist?
• Who is personally accountable for these answers?

Answer those six well and most of the spreadsheet resolves. The reason founders find the exercise so painful is not the volume. It is that the questions require you to know your own data flows precisely, and a company that has been shipping quickly for a year frequently does not.

One item deserves separate attention because it is new and it catches people. Your model provider is now a subprocessor. That means they appear on a list your customer’s legal team will read, alongside your hosting provider and your error monitoring service. It means when you change providers, or add a second one for routing as described in Lesson 7, you may have a contractual notification obligation. Founders who treat model selection as a purely technical decision discover this at renewal.

The three documents you need before the deal, not during it

A data processing agreement with a current subprocessor list. Templates exist and are fine as a starting point. What is not fine is a subprocessor list assembled from memory in an afternoon. Keep it accurate as you add services, because you will be asked to attest to it.

A one-page security overview. Written by you, honest about what exists and what does not. Encryption in transit and at rest, access control, logging, where data resides, who has production access, what your review process is. One page, dated. This document alone will short-circuit a surprising proportion of the spreadsheet, because a reviewer who can see you have thought about it clearly asks fewer follow-ups.

An incident response commitment with a number in it. Notification within a stated number of hours, to a stated contact, with a stated escalation path. The commitment matters more than the sophistication of the plan behind it.

Underneath all three sits the actual prerequisite: a diagram of where data enters, where it rests, where it is processed, where it leaves, and how long each copy persists. If you cannot draw it, you cannot answer honestly, and answering dishonestly is a much worse day later.

The questions that did not exist three years ago

Modern questionnaires now carry a section that is specific to this category, and it is worth preparing real answers rather than reassuring ones.

• Is our data used to train models? The answer needs to be a contractual commitment that flows through to your provider terms, not a setting somebody toggled. Buyers increasingly ask you to evidence it.
• Where is inference performed? A geographic question with regulatory consequences. Know the answer for every provider and every routing path, including the cheap tier you added last month.
• What is retained at the provider, and for how long? Including any abuse monitoring retention, which is frequently longer than teams assume.
• Does a human ever review the content? Under what circumstances and with what controls.
• How do we learn when the model changes? This connects directly to Lesson 13. A buyer in a regulated function needs to know that the thing they validated is the thing that is running.
• How is the system classified under applicable AI regulation? European obligations in particular now impose documentation and transparency requirements that vary with the risk category of the use case. Treat this as an architecture question rather than a legal one, because the answer determines what you have to log and that is not something to retrofit.

Saying no honestly is a stronger position than founders expect

The instinct when the spreadsheet arrives is to make every answer as green as possible. It is the wrong instinct, and reviewers are extremely good at detecting it.

The position that works is honest maturity. We do not hold a Type II report. Our observation period began in March and completes in September. Here is our current control set, here is our independent penetration test from last quarter, and here is what we are willing to commit to contractually in the interim.

Buyers accept that far more often than founders anticipate, because every security reviewer has dealt with small vendors before and what they are assessing is partly whether you are the kind of company that tells them things. The answer they will not forgive is the one that turns out to have been optimistic, discovered during an incident, when the conversation is no longer about procurement.

We lost that first deal. Not because of the answers, but because the elapsed time we needed did not fit inside their quarter. The work we did to answer the sixty questions properly meant the next one, five months later, took nine days.

Trust has a lead time. Start it before the deal that needs it.

Tomorrow: the job description you wrote and did not post.