The Enterprise Security Questionnaire: 50 Controls B2B SaaS Buyers Actually Verify
Somewhere between the successful demo and the signed contract sits a spreadsheet with 200 rows and a deadline. The B2B SaaS security questionnaire is the least glamorous artifact in enterprise sales, and one of the most decisive. Founders routinely fill it out from memory, guess at answers they cannot verify, and lose deals over inconsistencies a buyer's security team spots in minutes.
The good news: questionnaires vary wildly in length, but not in substance. Whether the buyer sends a 20-question starter sheet, a CAIQ, an SIG Lite, or a 500-row custom monster, the same 50 controls decide the outcome. If you can answer those 50 with evidence, you can answer almost any questionnaire in hours instead of weeks.
This post maps all 50, grouped the way security reviewers group them, with three things for each area: what the buyer is really checking, what minimum acceptable evidence looks like, and where a written policy is enough versus where you need working infrastructure. It complements our earlier 20-control audit checklist, which goes deeper on implementation; this one is about surviving the questionnaire itself.
How to Read a B2B SaaS Security Questionnaire
Every question on a B2B SaaS security questionnaire is a proxy for one underlying question: does adding your product to our environment increase or decrease our risk? Reviewers are not grading you against perfection. They are checking whether your answers are consistent with each other, consistent with your public documentation, and backed by evidence you can produce on request.
That last part matters most. "Yes" answers without evidence are treated as "unknown". A truthful "partially, with a remediation date" scores better than a confident "yes" that falls apart during the follow-up call. Keep that in mind for all 50 controls below.
Access Control and Identity (Controls 1-10)
This is where reviewers start, because access failures have the most direct consequences.
| # | Control | What the buyer is really checking |
|---|---|---|
| 1 | SSO support (SAML/OIDC) | Can they govern your app through their identity provider |
| 2 | MFA enforced for all staff | Whether one phished password compromises their data |
| 3 | Role-based access control in the product | Least privilege for their own users |
| 4 | RBAC for your internal systems | Least privilege for your engineers |
| 5 | Documented joiner/mover/leaver process | Do ex-employees keep access |
| 6 | Quarterly access reviews | Whether permissions drift silently |
| 7 | Privileged access management | Who can touch production and how it is logged |
| 8 | No shared accounts | Attribution of every action to a person |
| 9 | Session management (timeouts, revocation) | Stolen-session blast radius |
| 10 | SCIM or deprovisioning API | Automated offboarding of their users |
Minimum evidence: an access control policy, a screenshot or export of your last access review, and IdP configuration showing MFA enforcement. Controls 1, 2, 5 and 6 must actually be implemented; a policy document alone will not survive follow-up. SCIM (control 10) is frequently negotiable to a roadmap answer for mid-size deals.
Data Handling and Encryption (Controls 11-19)
| # | Control | What the buyer is really checking |
|---|---|---|
| 11 | Encryption in transit (TLS 1.2+) | Table stakes; a "no" ends the review |
| 12 | Encryption at rest | Exposure if storage is compromised |
| 13 | Key management and rotation | Whether encryption is real or decorative |
| 14 | Data classification policy | Do you know what data you hold |
| 15 | Data residency options | GDPR and sector rules, especially in the EU |
| 16 | Tenant isolation model | Can another customer see their data |
| 17 | Data retention and deletion schedule | How long their data outlives the contract |
| 18 | Verified deletion on offboarding | Whether "deleted" includes backups |
| 19 | Production data in non-production environments | Whether staging leaks real records |
Minimum evidence: your TLS configuration is externally verifiable, so expect them to check it before they ask. For the rest: a data handling policy, an architecture note describing tenant isolation, and a deletion runbook. Control 18 is the one most vendors get caught on, because deletion from backups requires engineering work, not a policy. If your deletion story is weak, our writeup on right-to-erasure engineering covers the patterns that hold up.
Secure Development and Change Management (Controls 20-27)
| # | Control | What the buyer is really checking |
|---|---|---|
| 20 | Code review required before merge | Whether one developer can ship unreviewed code |
| 21 | CI pipeline with automated tests | Repeatability of releases |
| 22 | Static analysis / SAST in the pipeline | Systematic bug classes caught before production |
| 23 | Dependency scanning and patch SLAs | Log4j-style exposure |
| 24 | Secrets management (no secrets in code) | The most common real-world breach vector |
| 25 | Separation of dev and prod environments | Blast radius of developer mistakes |
| 26 | Documented change management | Can changes be traced and rolled back |
| 27 | Annual penetration test | Independent validation, report less than 12 months old |
Minimum evidence: branch protection settings, a CI configuration, a dependency scanning report, and the executive summary of your latest pen test. Reviewers accept a redacted pen test summary plus remediation status; they do not need the full report. Controls 20-25 must be real infrastructure. This is also the area where a codebase that grew fast, or was largely AI-generated, quietly fails: the questionnaire says "yes, code review", and the git history says otherwise. An independent code quality audit before the questionnaire arrives is much cheaper than an awkward follow-up call after it.
Incident Response and Logging (Controls 28-34)
| # | Control | What the buyer is really checking |
|---|---|---|
| 28 | Written incident response plan | Do you improvise during a breach |
| 29 | Customer breach notification SLA | Will they hear it from you or from the press |
| 30 | Centralized application and audit logging | Can incidents be reconstructed |
| 31 | Log retention period (typically 12 months) | Forensic depth |
| 32 | Alerting on anomalous access | Detection, not just recording |
| 33 | Annual incident response test or tabletop | Whether the plan has ever been exercised |
| 34 | Status page or availability communication | Operational transparency |
Minimum evidence: the IR plan itself, a notification clause in your DPA (72 hours is the common ask; do not promise less than you can deliver), and a sample of your logging dashboard. Control 33 can be satisfied with a one-page tabletop summary; run one this quarter if you never have. Controls 28, 29 and 34 are acceptable as documents. Controls 30-32 require tooling.
Business Continuity, Backup and Recovery (Controls 35-40)
| # | Control | What the buyer is really checking |
|---|---|---|
| 35 | Automated backups with defined frequency | Data loss window |
| 36 | Backup restore testing | Whether backups actually restore |
| 37 | Documented RTO and RPO | Honest recovery expectations |
| 38 | Disaster recovery plan | Regional outage survival |
| 39 | Uptime SLA and historical availability | Track record versus promise |
| 40 | Single points of failure assessment | Bus factor in infrastructure and people |
Minimum evidence: backup configuration, the date and result of your last restore test, and a one-page DR summary with RTO/RPO numbers. Control 36 is the trap: "we have backups" without a tested restore is scored as no backups by experienced reviewers. Pick realistic RTO/RPO numbers; a small team claiming a 15-minute RTO reads as unserious.
Third-Party and Subprocessor Risk (Controls 41-46)
| # | Control | What the buyer is really checking |
|---|---|---|
| 41 | Published subprocessor list | Where their data actually flows |
| 42 | Vendor security review process | Whether you audit your own vendors |
| 43 | DPAs with all subprocessors | The legal chain of custody for data |
| 44 | Subprocessor change notification | Contractual right to object |
| 45 | Concentration risk awareness | What happens if your cloud provider fails you |
| 46 | Open source license and SBOM hygiene | Legal and supply-chain exposure |
Minimum evidence: the subprocessor page on your website, a simple vendor review checklist, and an SBOM export from your build tooling. This entire section can be handled with documents and a spreadsheet; it is the highest-scoring area per hour of effort invested. EU buyers increasingly ask for SBOMs under supply-chain rules, so generating one from CI now saves a scramble later.
Compliance and Organizational Security (Controls 47-50)
| # | Control | What the buyer is really checking |
|---|---|---|
| 47 | SOC 2 Type II or ISO 27001 | Independent attestation, or a credible path to it |
| 48 | Security awareness training for all staff | The human layer |
| 49 | Background checks where legally permitted | Insider risk basics |
| 50 | Named security owner | Someone is accountable when it matters |
Minimum evidence: certification report or a dated roadmap toward one, training completion records, and an org note naming your security owner. A missing SOC 2 does not automatically kill mid-market deals if the other 49 controls are strong and you can show an audit timeline. "We are in our observation window with an audit scheduled for Q1" is a real answer; "we are looking into it" is not.
Build the Evidence Pack Once, Answer Every Questionnaire Fast
The teams that turn questionnaires around in hours all do the same thing: they maintain a living evidence pack instead of reconstructing answers per deal. The structure is simple:
- One folder per control area (the seven sections above), each containing the current policy, the latest evidence artifact, and its review date.
- A master answer sheet mapping the 50 controls to your canonical answers, with links to evidence. New questionnaires get mapped to this sheet, not answered from scratch.
- A quarterly refresh ritual: rerun the access review, check certificate and pen test dates, update the subprocessor list, re-export the SBOM. One afternoon per quarter.
- A gap register listing every "partially" answer with an owner and a target date. Buyers respond well to honest gaps with dates; they respond badly to discovering gaps themselves.
Version the pack in git alongside your code if you can. Evidence that carries commit history is more convincing than a folder of undated PDFs.
Where to Start If You Are Staring at a Questionnaire Right Now
Triage in this order: answer the externally verifiable controls first (TLS, status page, subprocessor list), because buyers check those independently. Then the access and encryption sections, which carry the most weight. Flag everything you cannot evidence as "partial, remediation planned" rather than stretching a yes.
If the questionnaire has exposed deeper problems, such as no code review culture, secrets in the repository, or a codebase nobody fully understands, that is not a paperwork issue. Wolf-Tech runs code quality and security audits that produce exactly the kind of independent evidence enterprise reviewers want to see, and we help teams close the engineering gaps behind the answers as part of custom software development engagements.
Facing a security review you are not sure you will pass? Write to hello@wolf-tech.io or visit wolf-tech.io and we will help you figure out which of the 50 controls need real work and which just need better evidence.