The Enterprise Security Questionnaire: A Startup's Field Guide

The spreadsheet arrives with the subject line "final step before contract" and it has 214 rows, four tabs, and a column headed Evidence Reference. Somewhere around row 60 it asks whether you conduct annual third-party penetration testing of all production systems, and you do not, and the deal is worth more than the rest of your pipeline combined.

The good news is that this document is not a test you pass or fail. It is a risk file that someone at the other company has to be able to defend if things go wrong. The bad news is that most founders lose the deal not because their security is weak, but because they answer badly — vaguely, inconsistently, or dishonestly.

What these documents actually are

Three things arrive under the same name, and it matters which one you have.

Standardised questionnaires. The SIG (Standardized Information Gathering questionnaire, from Shared Assessments) and the CAIQ (Consensus Assessments Initiative Questionnaire, from the Cloud Security Alliance) are the two you will meet most. SIG comes in a fuller and a lighter form; CAIQ maps to the CSA's Cloud Controls Matrix. Both are largely yes/no with a comment field. Their virtue is that they are reusable: answer once, reuse across prospects with light editing.

Bespoke enterprise questionnaires. A bank, insurer, or large healthcare provider writes its own from internal policy. These are the painful ones. They contain questions inherited from an on-premise era that make no sense for a SaaS product ("describe physical access controls at your data centre" — you use a cloud provider, and the honest answer says so and points at the provider's own attestation).

Framework-derived checklists. Questions lifted directly from ISO/IEC 27001 Annex A control areas, or from a regulator's expectations. These are usually the most rational, because someone thought about the structure before writing them.

Why they send it

Not to evaluate your engineering taste. When an enterprise buys your product, your failures become their incident. Regulators and their own customers hold them accountable for their supply chain, so procurement and third-party risk teams must document that they assessed you before signing. The questionnaire is the artefact of that assessment.

Two consequences follow, and both are useful to you:

1. A "no" is survivable; an unexplained "no" often is not. The reviewer is sorting answers into acceptable risk, compensating control, and blocker. Give them the material to put you in the first two categories.
2. The reviewer is rarely the decision-maker. They are frequently a risk analyst working through a queue. Answers that are clear, consistent, and evidenced move quickly. Answers that require a follow-up call add weeks.

Never lie. The asymmetry is brutal.

Say your access reviews are quarterly when they have never happened, and you have not merely stretched the truth in a spreadsheet. That questionnaire is almost always incorporated into the contract by reference, or backed by a warranty that your representations are accurate.

The consequences of a discovered misrepresentation are not "we look bad":

• Contractual misrepresentation, which can void the agreement and expose you to damages — potentially uncapped, because misrepresentation frequently sits outside the liability cap.
• Discovery at the worst moment. Nobody re-reads your questionnaire during business as usual. They read it during an incident, when the customer's legal team is establishing who was responsible. A single false row reframes an incident as your fault.
• Permanent exclusion. Enterprise risk teams share vendor reputations internally, and a vendor caught misrepresenting controls does not get reassessed next year.

Compare that with the actual cost of an honest "not yet":

Q: Do you perform annual penetration testing by an independent third party?

A: Partially. We have not yet commissioned an independent penetration test. We perform automated vulnerability scanning of production infrastructure weekly and dependency scanning on every build, with findings triaged in our engineering backlog. An independent application penetration test is scheduled for Q4 2026, and we will share the summary report and remediation status with you once complete.

That answer will pass more often than founders expect. It states the gap, shows that the underlying risk is not unmanaged, and gives a date. What fails is "Yes" with no evidence, or a blank cell, or "we take security very seriously".

Where a control genuinely does not apply, say so and say why — "Not applicable: we do not operate physical data centres; production runs on [cloud provider], whose facility controls are covered by their published attestation" is a complete and acceptable answer.

The controls that unblock the most rows

Questionnaires look bespoke and are not. The same underlying controls are asked about repeatedly in different words, which means a small number of investments clear a disproportionate share of the document.

| Control | Rows it typically unblocks | Effort | Cost | | ----------------------------------------------------------- | --------------------------------------------------- | ------------------------- | ----------------------- | | SSO + enforced MFA on every business system | Access control, authentication, joiner/mover/leaver | Low | Low | | Written policy set (infosec, access, incident, BCP, vendor) | Governance, policy, entire tabs | Medium | Low if written in-house | | Centralised logging with defined retention | Monitoring, audit trail, forensics readiness | Medium | Low–medium | | Encryption in transit and at rest | Data protection, cryptography | Low (mostly already true) | Low | | Documented incident response plan | Incident management, breach notification | Low–medium | Low | | Quarterly access reviews, evidenced | Access control, privileged access | Low | Low | | Vendor/sub-processor inventory | Supply chain, data residency | Low | Low | | Background checks and security onboarding | HR security | Low | Low | | Independent penetration test report | Testing, secure development, assurance | Low for you | The main real spend |

Two rows in that table carry more weight than the rest combined, and it is worth being blunt about why.

A written policy set answers questions the reviewer cannot verify any other way. A large fraction of any questionnaire asks whether something is documented, approved, and reviewed annually. If the practice exists in your team's heads but not on paper, the honest answer to all of those is no. The document is the control, for these purposes. They need not be long — a five-page access control policy that reflects what you genuinely do beats a forty-page template you copied and do not follow, and the second kind gets exposed the moment anyone asks for evidence.

A penetration test report does similar work on the technical side. It answers the direct testing questions, but it also substantiates claims about secure development, vulnerability management, and remediation processes, because it is third-party evidence that someone external examined your system and you fixed what they found. Share the executive summary and remediation status rather than the full technical report — that is normal practice and reviewers accept it.

The order to do them in on a startup budget

Sequence matters more than total spend. Roughly:

1. SSO and enforced MFA everywhere, plus removal of shared accounts. Days of work, and it is the single densest cluster of questions.
2. Write the policy set. Infosec, access control, incident response, change management, vendor management, business continuity. Do this before spending on tooling — it is cheap, it forces decisions you need to make anyway, and it unblocks whole tabs.
3. Turn on centralised logging with a stated retention period and write the period down. "90 days in [tool], 1 year archived" is an answer; "we have logs" is not.
4. Start quarterly access reviews and keep the evidence. A dated spreadsheet with reviewer initials is legitimate evidence at your stage. The review only counts if you can prove it happened.
5. Build the vendor and sub-processor list, with what data each one touches and where it is processed. You will need it for privacy questions too.
6. Commission an independent penetration test once the obvious hygiene is fixed — and be clear that this is a different purchase from automated scanning. Testing before you have done steps 1–5 wastes budget confirming things you already know.
7. Only then consider a certification such as ISO 27001, if the market keeps demanding it. It is a significant, ongoing commitment, and it is the right move when certification is repeatedly a gating requirement — not as a first response to one questionnaire.

Handling the process itself

A few habits that consistently shorten the cycle:

• Keep one master answer file. Every question you have ever answered, with the current approved wording. New questionnaires become mostly copy-paste, and more importantly your answers stop contradicting each other across prospects.
• Own it as one person. Divided ownership produces inconsistent answers, which is the fastest way to trigger a follow-up call.
• Answer in the reviewer's structure. If there is an evidence column, cite the document name and version. Do not attach eighty pages and invite them to search.
• Push back on genuinely irrelevant sections. Asking whether the physical data centre questions can be marked not-applicable, given the cloud provider's attestation, is a normal and expected request.
• Track your gaps as a roadmap. By the third questionnaire you will see the same handful of gaps recurring. That list is your security roadmap, written for you by your customers.

Where this lands

Most startups in this position need two things that are far less daunting than the spreadsheet implies: a policy set that honestly documents how they already work, and an independent test of the application that gives a reviewer something external to point at. If you are staring at your first enterprise questionnaire and trying to work out which gaps genuinely block the deal and which can be answered with a date, that is the kind of conversation we have regularly — including with founders who end up needing less than they feared.