Can we just refuse to fill out the questionnaire and offer a call instead?

You can offer a call, and you should — but as an addition, not a replacement. The questionnaire exists because the security reviewer has to leave a written record that the review happened; a call produces no artifact they can file, so refusing to answer in writing usually stalls the deal rather than speeding it up. The move that works is to answer the questionnaire in writing, mark the handful of items where a written answer genuinely misrepresents your situation, and ask for a call specifically about those. Reviewers accept that readily, because it makes their job easier rather than harder. What does not work is sending back a marketing security page and asking them to map it to their questions themselves.

What if we genuinely don't do something the questionnaire assumes, like formal penetration testing?

Say so, then say what you do instead and what you plan to do about it. A questionnaire is a set of questions, not a set of requirements — the reviewer is building a risk picture, and a clear no with context is far less damaging than a yes they later discover was aspirational. For something like penetration testing, an honest answer names what you do have (dependency scanning, code review on every change, whatever security testing is actually in your pipeline), states plainly that you have not had an independent penetration test, and gives a real intent if you have one. Reviewers see incomplete programs constantly. What they escalate on is an answer that turns out to be untrue.

How long does it typically take to get through one of these?

The writing is not the slow part. A focused team can draft answers to a long questionnaire in a couple of working days, and the review cycle on the buyer's side is often one to two weeks depending on how busy their security team is. What stretches the timeline is everything the questionnaire surfaces that you do not have: a missing incident response plan, no current architecture diagram, no subprocessor list, an access review that has never been run. Those are days of work if the underlying practice exists and only the documentation is missing, and weeks to months if the practice itself has to be built. The honest planning assumption is that the questionnaire itself is fast and the gap remediation sets the date.

Does answering a questionnaire well mean we can skip SOC 2?

For one deal, sometimes. Plenty of enterprise buyers will accept a well-answered questionnaire plus contractual security commitments from a small vendor, particularly where the data involved is not especially sensitive. What it does not do is scale. The second and third questionnaire arrive in different formats asking the same things, and each one consumes your engineering leadership for a week. At that point an audited report is not a compliance purchase so much as a way to stop answering the same questions by hand. The usual pattern is that the first questionnaire is survivable and the third is the one that makes the case for the audit.

Your deal is stuck in a security questionnaire — what to actually do

A verbal yes turns into a 90-question security review and the deal stops moving. How to triage the questionnaire, fix the gaps that are actually fixable in a week, and be honest about the ones that are not.

The situation this page is written for

You had the meeting. The champion was enthusiastic, the pricing conversation went fine, someone said the word "onboarding" in a sentence about next month. Then the email arrives from a name you have not seen before — security, IT risk, third-party vendor management — with a spreadsheet attached and a note asking you to complete it before contracting can proceed.

The spreadsheet has ninety rows. Some of them you can answer in your sleep. Some of them use vocabulary you have never had reason to learn. A few assume a whole function exists at your company that does not — a security officer, a documented risk register, an annual penetration test, a formal change advisory process. And somewhere around row forty it stops feeling like paperwork and starts feeling like the deal is in trouble.

It usually is not in trouble. But it is now on someone else's timeline, and the thing that determines whether it closes this quarter or next is how you spend the next week.

The questionnaire itself is likely one of three shapes. It might be a standardized format used broadly across industries so buyers do not have to write their own, sometimes with a shorter core version and a longer full version. It might be a cloud-specific one built around a control framework for cloud providers. Or — most commonly with larger buyers — it is a custom internal template accreted over years, containing questions that made sense for a data center vendor in 2013 and now sit awkwardly next to questions about your model provider. All three are answerable. The custom ones are the most tedious and the most negotiable.

Why this happens to companies with genuinely decent security

The instinctive reading is that the questionnaire is exposing you as insecure. Occasionally that is true. Far more often it exposes something narrower and much more fixable: your practices exist, they are reasonable, and none of them have ever been written down or mapped to the language the questionnaire uses.

A small engineering team that deploys through pull requests with mandatory review, runs infrastructure as code, uses SSO on every internal system, encrypts everything in transit and at rest by default because that is what the managed services do, and revokes access on the day someone leaves — that team is running a materially better security program than plenty of larger companies. But when the questionnaire asks whether they have a documented change management procedure, the honest answer they reach for is "sort of?" — because the procedure lives in the habits of five people rather than in a document.

That gap is the whole problem, and it is worth naming precisely: the questionnaire is not testing your security, it is testing your evidence of your security. Those are different assets, and startups accumulate the first while producing none of the second. Nothing about writing pull request review into a paragraph makes the code safer. It does make the control legible to someone who cannot look over your shoulder, which is the only thing the reviewer on the other end is able to do.

There is a second reason, less about you. The reviewer is often working from a template that assumes a company shape you do not have. Questions about physical data center access, dedicated security staffing, or segregation of duties across a change board are written for a vendor with a hundred people and a building. They are not traps. They are questions where the correct answer is a short explanation of why the control is satisfied differently in your architecture, or genuinely not applicable — a cloud provider handles physical security, and you should name whose attestation covers it rather than describing a server room you do not have.

Triage before you write a single answer

The failure mode is starting at row one and grinding downward. By row thirty you are exhausted, the hard questions are still ahead of you, and you have no idea yet whether the deal has a two-week problem or a two-month problem. Read the whole thing first and sort every question into three buckets.

Bucket one: we do this and we can prove it. The control exists, and you can produce something on request — a screenshot of the SSO configuration, an export of the access list, a link to the CI pipeline, a policy someone actually wrote. These are volume, not risk. Answer them plainly, keep the evidence in one folder as you go, and move on. Expect this to be the largest bucket if you have been reasonably disciplined.

Bucket two: we do this but nothing is written down. The practice is real and lives in the team's habits or in a tool's configuration, but there is no document, no named owner, and no record that it happens on a schedule. This is where most of your questionnaire lands and it is by far the most important bucket to identify, because almost everything in it is fixable in days, not months. Writing a one-page access control policy that describes what you already do is an afternoon. Running the access review you have never formally run, and saving the output, is a morning. The remediation here is documentation and one deliberate execution of a thing you were already doing informally.

Bucket three: we do not do this at all. No penetration test has ever happened. There is no incident response plan of any kind. Logging does not capture who did what. Backups exist but have never been restored as a test. This bucket is the actual timeline risk, and it is the one to size first and honestly — it determines whether you are telling your champion "next week" or "we need to talk about scope."

Do the sort in a shared spreadsheet with a column for the bucket, a column for the owner, and a column for the evidence artifact. It takes about two hours and converts a wall of anxiety into a work list where most items are already done.

One practical warning while sorting: be strict about the difference between bucket one and bucket two. "We encrypt data at rest" belongs in bucket one only if you can say which services, with which key management, and show it. If the honest answer is "the database is managed and I assume it does," that is bucket two, and it takes twenty minutes to check and become bucket one.

The four things worth fixing first

If you have limited time before the deal needs to move, there is a small set of artifacts that appears on nearly every questionnaire regardless of which framework it came from. Producing them well converts a large number of bucket-two answers at once, and they are the same artifacts an auditor will ask for later, so none of the work is thrown away.

A current architecture and data flow diagram. One page. Where customer data enters, what stores it, which third parties it reaches, where it crosses a trust boundary, and where it is encrypted. This single artifact answers, or makes answerable, a surprising share of the questionnaire — data residency, subprocessors, encryption boundaries, network segmentation, backup locations. It is also the thing that most often does not exist in current form; the diagram in the deck is eighteen months stale and shows two services you deleted. Draw the real one. A reviewer who receives a clear diagram treats the rest of your answers as more credible, which is not a rational scoring rule but is reliably how it works.

A written incident response plan. It does not need to be long, and for a team of eight it should not be. It needs to say: what counts as a security incident, who is notified and how, who makes the call to declare one, the rough phases (detect, contain, eradicate, recover, review), how and within what timeframe you would notify an affected customer, and where you record what happened. Two pages is a respectable plan. Zero pages is a bucket-three answer on almost every questionnaire in existence, and it is the single most common "we do not do this at all" that is genuinely fixable in an afternoon. Note the one caveat: customer notification timelines can be contractually and legally constrained, so pick the language with your counsel rather than inventing a number that sounds reassuring.

Documented access control practices. Who can reach production, how they authenticate, whether MFA is enforced, how access is granted and by whom, what happens on the day someone leaves, and how often you review the list. Then actually run the review once and keep the output. If you already use SSO with enforced MFA and role-based permissions, this document is mostly transcription — see RBAC and SSO for SOC 2 for what reviewers are looking for underneath the question. If you do not, this is the highest-value security improvement on the list independent of any deal.

A vendor and subprocessor list. Every third party that stores, processes, or can access customer data, with what data they see, what their security posture is (usually: which reports they publish), and where they are located. Reviewers ask for this constantly because your vendors are now their vendors. Building the list is a couple of hours of going through your billing statements and your environment variables. Most teams discover two or three services on it they had forgotten were in the path.

Underneath all four sits a fifth item that is more work but comes up nearly as often: whether you can reconstruct who did what in your system. If the questionnaire asks about audit trails and the honest answer is that you have application logs, that is a bucket-two-heading-toward-three item worth reading about separately in SOC 2 audit logging for developers.

Being straight about what you do not have

The hardest question on the questionnaire is usually not on the questionnaire. It is what to say when your champion asks whether you are SOC 2 compliant and you are not.

The instinct is to buy time with a timeline — "we are in the process, the report should be ready in a few months." Sometimes that is true. Often it is a number invented under pressure by someone who has not yet talked to an auditor, and it has two bad properties: it is very likely wrong, and it converts a factual gap into a broken promise the day it slips. Security reviewers talk to each other and they have long memories for vendors whose compliance date moved three times.

The better posture is unglamorous and works far more often than founders expect. State plainly where you stand. Say what you actually do have. Say what you have decided to do next and by when only if you have real basis for the date. Then — and this is the part teams miss — ask the reviewer what their process allows for a vendor in your position.

Enterprise buyers usually have exception paths, because they buy from small vendors all the time and the alternative is not being able to. Depending on the buyer, that might look like a security addendum to the contract where you commit to specific practices and to obtaining a report by a certain date; a shorter interim review scoped to the data you would actually touch; a limited pilot with restricted data while the full review proceeds; or acceptance with a compensating control on their side. None of these are things you can demand. All of them are things a reviewer may offer if they believe you are describing your situation accurately, and none of them are on offer to a vendor whose answers turned out to be optimistic.

The asymmetry is worth stating directly. An honest "no, and here is what we do instead" costs you a few points in the reviewer's risk assessment. A "yes" that unravels during evidence collection costs you the deal and the relationship, and it converts a routine review into an escalation.

The questionnaire is the beginning of the real thing

Almost nobody starts a compliance program because they decided to. They start because a deal stopped moving, which is exactly the situation this page describes. That is a perfectly good reason, and the questionnaire in front of you is unusually useful input — it is a specific, external, prioritized list of what your buyers actually care about, which is far better guidance than a generic control framework read cold.

So when the immediate deal is handled, the question becomes whether to keep answering these by hand or to get the underlying work done once. That decision usually turns on how many enterprise deals are in your pipeline. One is an inconvenience. Three or four a quarter is a recurring tax on the two or three people at your company least able to spare a week, and at that point the audited report starts paying for itself in sales cycle time rather than in security.

If you get there, the first branching decision is which examination to pursue, and the difference matters more than it appears — one attests to how your controls are designed at a point in time, the other to how they operated across a window of months, and the second cannot be backdated. That distinction is laid out in SOC 2 Type 1 vs Type 2, and it is worth understanding before you promise a date to anyone.

The useful reframe for the whole exercise: the questionnaire did not find a problem with your security. It found that your security was invisible to anyone outside your team. Every artifact you produce this week — the diagram, the incident response plan, the access documentation, the vendor list — is a permanent asset that makes the next questionnaire shorter, the audit cheaper, and your own operations more legible to the engineer who joins in six months.

If the gaps you found are in the system itself rather than in the paperwork — logging that cannot answer who did what, access control that was never designed to be reviewed, an architecture where the sensitive data is everywhere — that is engineering work, and it is what compliance-ready software is about: building the thing so the evidence falls out of it, rather than reconstructing evidence for a system that was never built to produce any.