The customer said yes. Then security sent the spreadsheet.

It is late October. The champion has said yes, the price is agreed, and the deal is meant to close before the customer's year-end. Then an email arrives from someone in their third-party risk team you have never spoken to, with a spreadsheet attached: a couple of hundred rows, one column headed Response and another headed Evidence. Your sales lead asks how long it will take. Someone says a few days.

For most of the rows, that is right. Answering a security questionnaire is mostly a writing job, teams get quicker at it with every deal, and there are now tools that draft answers from your previous ones in minutes. A handful of rows are a different kind of thing. Do you support single sign-on through the customer's own identity provider? Are administrator actions recorded in a log that nobody can edit? Attach a summary of a penetration test carried out by an independent party in the last twelve months. If the honest answer is no, good writing does not change it.

Those rows are engineering tickets that came in through the sales pipeline instead of the backlog, at the time of year when engineers are hardest to free up. This piece is about them: how to find them quickly, how to answer them without lying or losing the deal, and how to fit the work in before the date that matters.

Why the generous yes is the expensive one

The tempting move with a gap is the aspirational answer. Single sign-on (SSO) is planned for next quarter, so tick yes. Multi-factor authentication is on for most administrators, so yes. It feels harmless, because the reviewer is a stranger and the spreadsheet looks like a formality.

Signed questionnaire answers are often attached to the contract or referenced in its security schedule, and from then on each yes reads as a statement that the control exists today. If an incident later traces back to a control you said you had, that answer is the first document anyone reaches for. Long before that, there is a more ordinary cost. Reviewers ask for evidence, and a yes that collapses at the first follow-up question turns a two-week review into a long one, because now the reviewer has to wonder about every other row.

A reviewer almost never meets a flawless vendor, and does not expect to. What they need is a way to describe the remaining risk to the person who signs it off, in terms that person can accept. A plain no, with a mitigation and a date, gives them exactly that. An answer they have caught being generous gives them a reason to escalate.

Sort every no by the work it needs

Start by answering every row that is true and easy. That clears most of the spreadsheet and leaves the rows where the honest answer is no, partly, or we think so. Sort those by what it would take to turn them into a yes. The work behind a row, not its wording, is what decides your date.

• Not applicable. Questions about handling card data when you never touch payments, or about physical data centres when you run entirely on a cloud provider. Answer with one sentence explaining why it does not apply. A blank cell reads as evasion.
• Paperwork. The control exists in practice but is not written down: the incident response plan that lives in two people's heads, the quarterly access review that happens but leaves no record. Days of work for someone senior who knows the system, and no code.
• Engineering. The control does not exist and has to be built: SSO, an audit log of administrator actions, a way for customers to delete their data, encryption on a forgotten backup store. Weeks of work, competing directly with the roadmap.
• Outside evidence. Things only an independent party can provide, such as a recent penetration test or an audit report. This is calendar time, and working harder does not compress it.

Then decide which gaps matter to this buyer. That depends on what they will put into your product and who will log in. A bank loading customer records will read the encryption and access sections line by line; a marketing team storing campaign briefs will skim them. Ask your champion which sections their security team weighs most heavily, and ask for a short call with the reviewer if you can get one. Most will tell you, because a focused answer saves them time too.

The engineering bin is where the date goes

Paperwork rarely moves a signing date. The engineering bin does, for reasons that tend to become obvious only on the second or third deal.

The build is bigger than the question. Do you support SSO sounds like a switch. In practice it means connecting to each customer's identity provider, creating accounts the first time someone signs in, deciding what happens to the password accounts that already exist, an admin screen to configure all of it, and a support procedure for the morning a customer's signing certificate expires and nobody can log in. Audit logging is similar. Writing log lines is easy; deciding which actions count, making the log tamper-evident and giving customers a way to read it is the actual work.

The people who could build it are busy. The engineers who know the code well enough to add audit logging safely are the same people finishing the features that won the deal. Pull them off, and the deal's other promises start slipping instead.

And the evidence has to come in order. An independent penetration test should examine the system the customer will actually use, so it runs after the new features ship. Findings take time to fix, and many reviewers want to see that the serious ones were retested rather than merely promised. None of that can be parallelised by adding effort.

Work backward from the signature

Here is the shape of a typical plan for a deal that needs to sign in mid-December, with two features to build and no recent independent test. It assumes the triage happens this week.

Read it from the right. The customer's reviewer needs a week with the final evidence. The fixes and retest need the week before that, and the test itself the week before that. Four weeks of build remain, starting on 2 November. There is no slack anywhere. If the build starts a week late, the signature lands in the week many companies freeze changes and half the approvers are away, and a December deal quietly becomes a February one.

If the triage turns up no engineering gaps at all, book the penetration test now. There is nothing new to wait for, and the weeks before the holidays fill quickly.

What to send back this week

You do not need to have closed the gaps to reply. You need to show that you know exactly what they are. Return the questionnaire with a short cover note listing each material gap with five things: the control, where it stands today, what protects the customer in the meantime, who owns it, and the date.

A line in that note might read: SSO is not supported today. Until it ships, every account in your tenant requires multi-factor authentication. SSO will be in production by 27 November and inside the scope of an independent penetration test the following week, and once you connect your identity provider we will switch off password sign-in for your users. A reviewer can paste that straight into a risk write-up.

Then offer to put the commitment into the contract as a dated obligation instead of a yes. It can feel like giving ground. In practice it turns a gap into a promise you can keep, and it tells the customer you read contracts the way they do.

The rows that are new this year

More of the spreadsheet is now about AI, and the questions are getting sharper. Reviewers have ready-made material to draw on. The SIG, the widely used questionnaire published by Shared Assessments, is revised every year. In June the Cloud Security Alliance published version 1.1 of its AI Controls Matrix, which ships with a questionnaire of its own, the AI-CAIQ, so a reviewer who wants a list of AI questions no longer has to write one.

In practice the AI rows ask about two different things. Some are about the AI inside your product: does customer data train a model, which model providers handle it, and can a customer opt out. Others are about the AI in how you build: which coding assistants can read your source code, and whose accounts they run on. The second kind catches teams out, particularly when outside engineers are involved, because the answer depends on knowing which tools each person actually uses. If you know, it is paperwork. If customer data reaches a model provider and there is no way to switch that off for a customer who asks, it is engineering, and it belongs in the plan with everything else. The one answer worse than no is we are not sure.

When you can do this without anyone's help

If the triage comes back as paperwork and not-applicable rows, you need a senior engineer who knows the system and a few clear days. If there is one modest build and your team has room, do it in-house. It will cost less, and the knowledge stays with the people who will maintain it.

Outside help earns its cost in a narrower case: the engineering bin is full, the people who could empty it are committed to the roadmap that won the deal, and you also need an independent test on a fixed date. The useful shape then is mixed. A couple of engineers take the build tickets inside your team and under your direction, while the penetration test is booked against what they are building, from the same plan. That combination is what our custom engagements are for. Whoever you use, ask whether they can schedule both halves together, because the week between the build and the test is where these plans usually slip.

The questionnaire you answer this month will come back next year, from this customer and from the next three, with the same rows in a different order. Every gap you close properly is a row you never have to word carefully again.