---
title: "The Security Questionnaire Is Part of the Sale"
url: https://pragmaticleader.io/enterprise-security-questionnaire-sales/
author: "Aaron Wise"
published: 2026-11-04
description: "Enterprise security questionnaires stall deals nobody owns. Run review as a sales stage: answer library, trust page, one owner, SOC 2 when deals need it."
categories: ["Cross Organizational", "security"]
tags: ["security", "regulatory compliance", "cto sales strategy", "engineering and sales alignment", "startup leadership"]
---

# The Security Questionnaire Is Part of the Sale

> “Security is a process, not a product.”  
> — Bruce Schneier, *Crypto-Gram* (May 2000)

Treat the security review as a stage of the sale that engineering owns, not as paperwork that interrupts real work. Keep a maintained library of approved answers, publish a trust page, make one person accountable for turnaround, and start a SOC 2 audit when the pipeline shows deals that need it, not before. A company that does those four things closes in weeks the enterprise deals that would otherwise slip a quarter.

The common view inside engineering is that security questionnaires are compliance theater: hundreds of questions, many irrelevant to how the product works, filled in to satisfy a procurement checklist. There is truth in that. Plenty of the questions are boilerplate, and a completed spreadsheet proves little about how secure a system really is. The conclusion people draw from it, that the questionnaire deserves minimum effort, is still wrong. A buyer with a security team cannot sign until that team is satisfied. Whatever you think of the questions, the answers sit on the critical path to revenue.

Picture a startup's first enterprise deal. Sales has a champion, the demo went well, and pricing is agreed in principle. Then procurement sends a spreadsheet with a few hundred security questions, a request for the SOC 2 report, a pen test summary and a data processing agreement for legal. The account executive forwards it all to engineering with "can you fill this in by Friday?" Three weeks later it is half done, the champion has stopped replying, and the quarter closes without the deal. Nobody decided to lose it. It stalled in a stage nobody owned.

## What enterprise buyers ask for

The requests vary in format and overlap heavily in substance, which is the main reason the work can be made cheap.

The security questionnaire is the most common. Some buyers write their own; many use a standard one such as the Shared Assessments SIG or the Cloud Security Alliance's [Consensus Assessments Initiative Questionnaire (CAIQ)](https://cloudsecurityalliance.org/artifacts/star-level-1-security-questionnaire-caiq-v4). The questions cover access control, encryption, backups, incident response, vendor management, onboarding and offboarding, logging, and where data lives. Most can be answered once and reused.

A [SOC 2 report](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) is an independent auditor's opinion on your controls, under a framework from the AICPA. A Type I report says the controls are designed properly at a point in time. A Type II report says they operated effectively over a period, which is what most enterprise security teams want to see. Outside the US, and in some industries, buyers ask for ISO 27001 instead or as well. Buyers also ask for a recent third-party penetration test, usually summarized in a letter: who did it, when, and confirmation that serious findings were fixed.

A data processing agreement covers how you handle the buyer's personal data and comes with a list of your subprocessors. Legal owns the contract, but engineering supplies the facts: what data you store, where, for how long and which vendors touch it. Companies that built [privacy into the design from the start](https://pragmaticleader.io/privacy-design-building-trust-ground-not-afterthought/) answer these questions from documentation; the rest answer them from archaeology.

Two newer sets of questions now appear regularly. AI features prompt questions about whether customer data trains models, which model providers see it and how long they keep it. Software supply chain questions ask how dependencies are approved and scanned, which has become harder to answer honestly now that [coding agents add packages nobody explicitly approved](https://pragmaticleader.io/coding-agents-supply-chain-security/). Have truthful answers to both before the first buyer asks.

## How reviews stall deals

The pattern is predictable. Nobody owns the review, so it goes to whichever engineer sales knows best. That engineer answers from memory, slowly, between other work. The answers differ from the ones a colleague gave a different buyer last month. Some questions expose real gaps, such as no formal access review or a backup restore that has never been tested, and the engineer either guesses optimistically or stalls while deciding what to say. Meanwhile the buyer's security team has its own queue, and a late response sends the deal to the back of it.

None of this is a technical problem, and the cost is measured in delay rather than in effort. A questionnaire that takes three weeks instead of three days does not usually kill a deal outright. It pushes the signature past quarter end, gives a competitor time to finish its own review first, and lets the champion's attention drift to other priorities. Sales teams that qualify with a framework like MEDDIC already track the buyer's decision process; [a CTO who understands MEDDIC](https://pragmaticleader.io/architecting-sales-success-ctos-guide-meddic/) will recognize the security review as a named step in that process, with a date that engineering controls.

## What stops the stalling

### A maintained answer library

Keep one document, or one tool, with approved answers to the questions buyers keep asking, grouped by topic. Each answer has a date and an owner. When a new questionnaire arrives, most of it is copy and adapt; only the genuinely new questions need an engineer's time, and those answers go back into the library. Review it on a schedule, because an answer that was true a year ago and is no longer true is worse than no answer at all.

The obvious objection is that a compliance automation platform does all of this, so why build a process? The tools are useful, and past a certain volume they are worth buying, for the reasons laid out in the [build, buy or wait call](https://pragmaticleader.io/build-vs-buy-decision-by-stage/). But a tool stores answers; it does not keep them true or decide what to say about a gap. A well-kept document beats an unmaintained platform, and the platform only pays off once someone owns the content inside it.

### A trust page

Publish a page that answers the first round of questions before procurement asks them: security practices in plain language, certifications and their dates, the subprocessor list, how to request the SOC 2 report or pen test letter under NDA, and how to report a vulnerability. A [security.txt file](https://www.rfc-editor.org/rfc/rfc9116) pointing researchers to that reporting channel is a small signal that security teams notice. A good trust page shortens reviews because some buyers accept it in place of parts of their questionnaire, and the rest arrive already knowing the basics.

### A named owner

One person is accountable for security reviews: turnaround time, the answer library and the escalation when a question exposes a gap. At an early company that is often the CTO. Later it becomes a security or compliance lead. What matters is that sales knows where to send the spreadsheet, and that the person receiving it knows it is their job rather than a favor. Track turnaround the way sales tracks other stages, and the review stops being an excuse for a slipped deal.

Answer honestly. Security teams read hundreds of these, and they recognize answers that claim every control is in place. "Not yet; planned for next quarter, and here is the compensating control" is a common and acceptable answer. Claiming a control you don't have turns into a contractual misrepresentation, which is a much bigger problem than the gap itself.

## When SOC 2 is worth it

SOC 2 costs real money and real engineering time, both for the first audit and every year after. The auditor’s fee is only part of it: readiness work, tooling and staff time add to it, and a Type II report can’t be issued until your controls have run through an observation period of several months. Get quotes from two or three audit firms before building the business case; published estimates vary too widely to plan on. It is worth it when it stands between you and revenue, and not before. The useful question is how many deals in the pipeline have asked for it and what those deals are worth.

Run that as a business case. Picture a Series A company with eight enterprise opportunities in its pipeline. Three have asked for SOC 2 and will not sign without at least a plan; together they represent more annual revenue than the audit, the tooling and the engineering time cost in the first year. That is a clear yes. Now picture the same company with one opportunity asking, a small one, and a founder who wants SOC 2 because a competitor announced theirs. That is a no for now, and the money is better spent on the controls an audit would check anyway.

The opposing view says start early, because the controls are good practice and the report becomes a sales asset. The first half is right; the second half depends on who you sell to. Most of what an audit checks (SSO and MFA everywhere, least-privilege access, encrypted data, tested backups, logging, managed secrets, an incident response plan, clean offboarding) is worth doing at any stage, and the [practical guide to security, compliance and access](https://pragmaticleader.io/govern-like-pro-practical-guide-security-compliance-access/) covers it. Paying an auditor to attest to those controls is a separate decision, and it should follow demand.

**Seed.** Most companies should not start a SOC 2 audit unless their buyers are enterprises that will not proceed without it. Put the effort into the controls themselves, including [secrets management done properly](https://pragmaticleader.io/high-cost-cutting-corners-secrets-management-done-right/), which is a common gap. Build the answer library and a simple trust page. When an early buyer asks for SOC 2, ask whether a completed questionnaire, a pen test letter and a stated plan to pursue the audit will do. For a pilot, it often will.

**Series A and B.** If the company sells to mid-market or enterprise customers, SOC 2 usually becomes a requirement. Start when the pipeline shows it, and plan for the Type II observation period. A Type I report only says your controls were designed properly on one date; a Type II says they operated over a period of months, which is what the [AICPA notes customers usually need to know](https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy). Many buyers will accept a Type I for a first deal with a committed Type II date, and expect the Type II at renewal. Compliance automation platforms reduce the evidence-gathering work considerably, but someone still has to own the program and fix what it finds. This is also the stage to schedule an annual pen test.

**Later stage.** SOC 2 becomes the baseline and the questions move to other frameworks: ISO 27001 for international buyers, HIPAA for health data, FedRAMP for US federal sales, sector rules in finance. Each one is a market-entry decision with a cost, and should be argued as one. A security or solutions engineer often joins large deals directly, the same way [pre-sales engineers](https://pragmaticleader.io/engineering-perfect-pitch-technical-pros-guide-winning-pre-sales/) do for technical evaluation.

## What good and bad look like

**What good looks like.** A questionnaire comes back within days, consistent with every previous one. Sales knows what the trust page covers and sends it early. Real gaps are on the roadmap with dates, and engineering can say so without embarrassment. The cost of compliance work is visible to the executive team and set against the revenue it protects.

**What bad looks like.** Every questionnaire is a fire drill. Answers depend on who filled them in. SOC 2 is started in a panic after a large deal is lost, or at seed because a competitor has it and no buyer is asking. Engineering resents sales for the interruptions, and sales blames engineering for the lost quarter.

Engineering leaders who understand [how their company sells](https://pragmaticleader.io/deployments-deals-bridging-tech-sales-divide/) see the security review for what it is: a sales stage they own. The instinct behind [disciplined sales qualification](https://pragmaticleader.io/art-saying-no-sales-qualification-saves-time-money-roadmap/) applies here as well. Find out early whether a deal needs a report the company does not have, and decide deliberately whether to chase it.

The question for your next pipeline review: for each enterprise deal in the current quarter, does anyone know whether it needs a security review, who owns it, and how many days it will take?