How to answer a security questionnaire before your SOC 2

What a security questionnaire is and why buyers send them

A security questionnaire is a list of questions a prospective customer sends you before they sign, so their security or procurement team can judge the risk of handing you their data. It might be a short web form, a spreadsheet with a few hundred rows, or a document their vendor risk team built years ago. The questions cover the same ground every time: who can access customer data, how you protect it, what happens when something goes wrong, and whether any of it is written down.

Larger companies send them because their own auditors and regulators expect them to assess the vendors they rely on, and a vendor security questionnaire does that at scale. For a startup selling upmarket, the questionnaire is often the first time anyone outside the company looks hard at your security program, and it usually lands before you have a SOC 2 report to point to.

Common security questionnaire formats

Many buyers write their own, but a few industry-standard questionnaires show up often enough to know by name:

• CAIQ (the Consensus Assessments Initiative Questionnaire) from the Cloud Security Alliance. It is built around the CSA's Cloud Controls Matrix and is aimed at cloud service providers. Some vendors fill it in once and share the completed copy with every customer who asks.
• SIG (the Standardized Information Gathering questionnaire) from Shared Assessments. It is long and broad, and it comes in shorter and fuller versions so a buyer can match the depth to the risk.
• Custom questionnaires. A spreadsheet or portal built by the buyer, often borrowing questions from the standard ones and adding their own about data location, subprocessors and contract terms.

The wording differs, but the topics repeat, so one thorough set of answers covers most of the next questionnaire.

How to answer a security questionnaire honestly

The one rule that matters: never claim a control you don't have. A questionnaire answer often ends up referenced in the contract or the buyer's risk file. If it is false and something goes wrong, you have a misrepresentation, not just a security gap. And your SOC 2 auditor will later test what you actually do.

Honest answers rarely cost you the deal. Buyers expect startups to have gaps. What worries them is a vendor who can't tell the difference between what is done and what is planned. Use a small set of answer types and stick to them:

A few habits make the answers stronger:

• Add one sentence of context to every yes. Who does it, how often, and when it last happened. A bare "Yes" invites follow-up questions; a specific one usually closes the topic.
• Prefer "Planned" with a date over a hopeful yes. "Planned for Q2" is a commitment a buyer can track. A yes you can't back up is a liability you carry into every renewal.
• Describe compensating controls. If you don't do something the textbook way, say what you do instead and why it addresses the same risk.

Build a reusable answer library

The second questionnaire should take a fraction of the time of the first, but only if your answers live somewhere better than the last email thread. A simple answer library works well:

1. One entry per topic, not per questionnaire. Group answers by subject: access control, encryption, logging, incident response, vendors, backups, people and training, physical security, data handling and privacy.
2. A short answer and a long answer. One sentence for yes/no fields, a paragraph for free text.
3. A source for each answer. The policy or evidence that backs it, so anyone can check it is still true.
4. An owner and a "last confirmed" date. Answers go stale when a tool changes or a process slips. Review the library on a schedule, for example every quarter, and after any major change.
5. A log of what you sent. Which customer received which questionnaire, on what date, with which answers. When a customer asks at renewal, you can show what changed.

Keep the library next to your policies, so an answer that drifts from its policy is easy to spot.

Documents that shorten the review

Many buyers accept documents alongside, or in place of, parts of a questionnaire. Your buyer decides what they accept, so ask.

• A security overview. A few pages on hosting, encryption, access, monitoring, incident response, backups, vendors and staff practices, written for a security reviewer rather than as marketing.
• A policy summary. A list of your security policies with their owner, approval date and next review date. Many companies share the summary freely and the full policies under NDA.
• Architecture and data flow. Where customer data enters, where it is stored, which subprocessors touch it, and where it leaves. A simple diagram answers a whole section of most questionnaires.
• A penetration test summary. Testers commonly provide a summary or attestation letter you can share, with the full report kept internal. Include when it was done and how findings were addressed.
• Proof of insurance. Some buyers ask for evidence of cyber or professional liability coverage. Your broker can usually provide it.
• A SOC 2 report, if you have one. Usually shared under NDA. If the report period ended some months ago, buyers often ask for a bridge letter: a letter from your management saying whether anything material has changed in your controls since the period ended.
• A readiness status, if you don't. A short, honest statement of where you are: which report type you are pursuing, whether an auditor is engaged, and the expected timeline. If you have engaged a firm, ask what, if anything, they can confirm in writing. Never present a readiness assessment as a report.

If you are still deciding which report to aim for, SOC 2 Type 1 vs Type 2 covers what each one tells a buyer.

Who should own the answers

Questionnaires often arrive through sales, with a deadline attached. Sales should manage the process, but should not write the answers. A workable split for a small company:

• One coordinator, usually whoever owns the compliance program. They receive the questionnaire, fill what the library already covers and route the rest.
• Subject owners for anything new: the engineering lead for infrastructure and change management, whoever runs IT for access and devices, HR or operations for hiring and training.
• A final reviewer, often a founder, who signs off before anything leaves the building.

Ideally the subject owners also own the matching policies, so the answer, the policy and the practice stay in step.

Keep answers consistent with your actual policies

A common failure: the answer says access reviews are quarterly, the policy says semi-annual, and the last review was eight months ago. Any reviewer comparing them will notice.

• Quote cadences, retention periods and timelines directly from the approved policy, not from memory.
• When you change a policy, update the matching library answers in the same sitting.
• If a questionnaire pushes you to promise something stricter than your policy, decide whether to change the policy first. Don't let a customer answer quietly become a second, different policy.

Answering a security questionnaire without SOC 2

You can win deals with larger companies before you have a report. What helps most is showing that your program is real and moving: approved policies with owners, evidence that recurring controls actually run, and a credible timeline. "We don't have a SOC 2 report yet; our audit window opens in March, and here are our approved policies and last quarter's access review summary" is a much stronger answer than a long list of unexplained yeses.

Some buyers will require a report before signing, or write one into the contract with a date. If you agree to a date, make sure you can meet it.

Use questionnaires as your SOC 2 roadmap

Every "No" and "Planned" in a questionnaire is a gap a real customer cared about. Collect them across questionnaires and you have a prioritized backlog for SOC 2 readiness:

• Missing policies point to documents you need to write. Compare them with our list of which SOC 2 policies you need.
• Controls you can't evidence point to recurring activities you need to start running and recording: access reviews, vulnerability scan reviews, vendor reviews, training.
• Questions you couldn't answer at all usually point to an owner nobody has named yet.

Work the backlog in the order of the SOC 2 readiness checklist, and each questionnaire you answer will have fewer gaps than the last.

Answering with evidence from Confluence

The answers that hold up are the ones backed by records you keep anyway. If your team works in Confluence, Compliance in a Box keeps those records in one compliance space, so the facts a questionnaire asks for are already written down:

• Approved, current policies. Each policy is a Confluence page with an owner and approvers. The Policies tab lists each policy's status, the exact approved version with its approval date, and the next review date, which is what a policy summary for a customer needs. Every approval is bound to an exact page version, so the version history shows what was approved and when.
• Acknowledgement completion. Employees acknowledge policies with one click, and the Dashboard shows the share of required acknowledgements that are done. When a questionnaire asks whether staff have read and accepted your security policies, you can give a real percentage.
• Recurring activity records. Activities such as the User Access Review, Vulnerability Scan Review, Vendor Risk Review, Penetration Test and Security Awareness Training open a dated evidence page for each period, with submission and approval. "When was your last access review?" has a dated, approved answer.
• Generated reports. The app writes a Policy Approval Log, a Policy Acknowledgement Report, an Activity Completion Report, Audit Log pages and a Controls Matrix as Confluence pages, refreshed daily. They are restricted to Compliance Admins and an optional Auditors group, so you summarize them for customers rather than share them. See what each report contains.

The Controls Matrix marks each criterion as Covered, Attention or Gap, which is also a quick way to see which questionnaire answers you can give with confidence and which still need work.

FAQ

What is a security questionnaire?

A set of questions a customer sends a vendor to assess how it protects data, covering access, encryption, incident response, vendors, backups, staff and policies. Answers are usually reviewed by the customer's security or procurement team before a contract is signed.

Can I answer a vendor security questionnaire without a SOC 2 report?

Yes. Answer honestly, mark planned controls with a date, and share supporting documents such as a security overview and a summary of your approved policies. Some buyers will still require a report, so ask early.

Does a SOC 2 report replace security questionnaires?

Often it shortens them rather than replacing them. Many buyers accept a SOC 2 report in place of most questions but still ask a short set of their own, for example about data location or subprocessors.

← All articles