How to Answer a Security Questionnaire Without SOC 2
A developer at a bigger company loves your API. They want to put it in production. Then a spreadsheet arrives from their security team: 150 rows, a column called "Response," and a first question that reads "Please provide your most recent SOC 2 Type II report."
You don't have one. Most early dev-tool companies don't. That is not the end of the deal. What ends deals is a vague answer, a slow answer, or an answer that turns out to be untrue.
This guide covers how to answer a security questionnaire without SOC 2: honestly, quickly, and in a way a reviewer can sign off on.
This is general know-how, not legal or compliance advice. For contract terms or a regulated buyer, talk to a qualified professional.
What the reviewer is actually doing
The reviewer is not trying to catch you out. Their job is to assess the risk of a new vendor touching their systems or data, then approve, approve with conditions, or escalate.
SOC 2 is a shortcut for them. It is an attestation report from an independent CPA firm covering controls at a service organization, organized around the AICPA's trust services categories: security, availability, processing integrity, confidentiality and privacy. When you can't hand over that report, the reviewer has to do more of the work themselves. Your goal is to make that work easy.
Some questionnaires are standardized, such as the Cloud Security Alliance's CAIQ, so you can answer once and reuse. Others are the buyer's own spreadsheet. The same rules apply to both.
The one rule: never claim a control you don't have
Do not write "Yes" to a control you don't operate. Not "yes, mostly." Not "yes, we're working on it." Your answers often get attached to the contract or referenced in it. A false "Yes" becomes a misrepresentation the day something goes wrong, and security teams compare notes.
A truthful "Not yet" with context is a normal answer. Reviewers see it constantly from small vendors. A "Yes" that falls apart on the first follow-up question costs you the deal and your credibility with that buyer.
The answer pattern: status, what you do instead, when
Every answer that isn't a clean "Yes" should have three parts:
- Status. Yes, No, Partial, or Not applicable. Plain.
- What you do today. The compensating control: the thing you actually do that reduces the same risk.
- What's next. A planned date or trigger, only if it's real.
Bad vs. good rewrites
| Question | Bad answer | Good answer |
|---|---|---|
| Do you have a SOC 2 Type II report? | "In progress." | "No. We have not completed a SOC 2 examination. Our security controls are documented in the attached overview, and we can walk your team through them. We plan to begin a readiness assessment when [trigger, e.g., we reach N enterprise customers]." |
| Do you perform annual penetration tests? | "Yes, we test regularly." | "Not yet by a third party. We run automated dependency and container scanning on every merge and fix critical findings within [N] days. We will share results of our first external test once complete." |
| Is customer data encrypted at rest? | "Industry-standard encryption." | "Yes. Customer data is stored in [managed database service] with encryption at rest enabled ([algorithm], [provider-managed or customer-managed] keys). Backups inherit the same setting." |
Notice the good answers are specific, short, and checkable. "Industry-standard" tells the reviewer nothing. Name the setting.
Compensating controls that small teams can actually show
A compensating control is something real you do that addresses the risk the missing control was meant to address. Here is where small teams usually have more than they think:
Inherited controls from your providers
If you run on a major cloud provider, much of the physical security, hardware disposal and data center access is theirs. Say so, and point the reviewer to the provider's own compliance reports, which they typically make available to customers. Be precise: you inherit their infrastructure controls, not their application security. Don't imply their report covers your code.
Access control
- SSO or enforced MFA on your cloud console, source control, and admin tools.
- Least privilege: who has production access, and how that list is reviewed.
- Offboarding: access removed on the last day, with a checklist.
Change management
- All production changes go through pull requests with review.
- Branch protection on the main branch.
- CI runs tests and dependency scanning before deploy.
This is already how most engineering teams work. Write it down and it becomes evidence.
Monitoring and incident response
- Centralized logging with a retention period you can name.
- Alerting to an on-call rotation.
- A one-page incident response plan: who decides, who communicates, how fast you notify customers.
Vulnerability disclosure
A published way for researchers to report issues (a policy page and a security.txt file) shows the reviewer you have a front door for bad news.
Build an evidence pack once
Reviewers trust artifacts more than prose. Create a small folder you can share under NDA:
- A two-to-four page security overview: architecture, data flow, where data lives, who can access it.
- An architecture diagram showing what talks to what.
- Your access control and offboarding checklist.
- Your incident response plan.
- A list of subprocessors (every third party that touches customer data) and what each one does.
- Screenshots of MFA enforcement and branch protection settings.
- Your data retention and deletion policy.
Each file should carry a "last reviewed" date. A stale document is worse than none.
Workflow: answering the questionnaire in a day, not a month
- Read it all first. Flag questions that don't apply (e.g., physical office questions for a remote team) and questions you can't answer.
- Start from your answer library. Keep a doc of every answer you've given, keyed by topic. Most questionnaires overlap heavily.
- Answer in the pattern. Status, what you do today, what's next.
- Mark N/A with a reason. "N/A: we do not process payment card data. Payments are handled by our payment processor; we never receive card numbers."
- Attach evidence, don't paste essays. "See Security Overview, section 3."
- Get a second reader. Someone who will ask "is that actually true today?"
- Offer a call. A 30-minute walkthrough with the reviewer often resolves more than three rounds of comments.
- Save every final answer to the library. The next questionnaire gets faster.
When "not yet" is not enough
Some buyers require an attestation report with no exceptions. Find out early. Ask your champion: "Is SOC 2 a hard requirement for approval, or one input to the risk review?" If it's hard, you have three honest options: wait, narrow the scope (a pilot with no production or sensitive data), or start the work toward an examination. Don't fill the gap with promises.
Roadmap language that holds up
Only put a date in writing if you would bet on it. Otherwise use a trigger. Weak: "SOC 2 coming soon." Better: "We will begin a SOC 2 readiness assessment once [specific trigger]. Until then, the controls above are in place and we can provide evidence on request."
Checklist
Do this next
If you are staring at a questionnaire right now, the Security Review Kit gives you an answer library structure, compensating-control wording, and an evidence pack outline built for small dev-tool teams. If you are also preparing a launch, the Developer Launch Kit Complete bundle includes it. Get the Security Review Kit: https://shiptodevs.com/#security-review
Sources
- AICPA & CIMA, System and Organization Controls: SOC Suite of Services: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
- Cloud Security Alliance, Consensus Assessments Initiative Questionnaire: https://cloudsecurityalliance.org/artifacts/consensus-assessments-initiative-questionnaire-v1-0
- CISA, Vulnerability Disclosure Policy Template: https://www.cisa.gov/vulnerability-disclosure-policy-template
The Security Review Kit: the full method as templates, a worked example and agent skills.