Security Review Questions: What Buyers Ask and How to Answer
The security review questions B2B buyers send before they sign, the evidence that answers them, and the questions you should ask your own vendors.
Published: October 25, 2026 · Updated: November 3, 2026
Author: OffBook Editorial Team
A security review is the step where a buyer’s IT or security team decides whether your product can touch their data. The questions are mostly predictable: certifications, encryption, access control, sub-processors, incident response and data deletion. If you sell software, you will answer them. If you buy software, you should ask them. This guide covers both sides, with the evidence that turns a yes into proof.
TL;DR
- Most reviews cover the same ten topics: certifications, encryption, incident response, vulnerability testing, access control, sub-processors, data retention, endpoint security, past incidents and staff training.
- A yes or no is weak. Reviewers want artifacts: a SOC 2 report, a penetration test summary from the last 12 months, proof of MFA on admin portals.
- Breach notification is where deals stall. Know your contractual clock in hours before the buyer asks.
- Founders who answer the first five questions live, with documents ready, usually shorten the review instead of waiting weeks for a questionnaire loop.
- Buyers can reverse the process: ask your own vendors the same questions, especially about sub-processors.
Table of Contents
- What a security review actually is
- The ten topics nearly every review covers
- How to answer the questions that decide deals
- Give evidence, not attestations
- If you are the buyer: questions for your own vendors
- Run the review without losing the deal
- Our perspective
- Prepare for the call where the questions land
- FAQ
- Sources
What a security review actually is
There are two versions of this exercise, and they share a question bank.
In the first, you are the vendor. A prospect’s security team sends a spreadsheet or portal link, and you answer. The review sits between a verbal yes from the champion and a signature. Our guide to how enterprise B2B buying works explains why it appears late: the people who run it are rarely the people you have been talking to.
In the second, you are the buyer. You are about to give a SaaS tool customer data, and you want to know what happens to it.
The length of the questionnaire matters. One published NIST-mapped vendor questionnaire argues that 40 questions is a deliberate number: below 30 you miss whole control families, and past 60 vendors hand it to a proposal team that answers from a library. If a buyer sends you 200 questions, expect that dynamic.
The ten topics nearly every review covers
The Cloud Security Alliance recommends a ten-point baseline for vendor questionnaires. Use it as your checklist, whichever side of the table you sit on.
| Topic | What the reviewer asks | Evidence that answers it |
|---|---|---|
| Certifications | Do you hold SOC 2 or ISO 27001? | The report or certificate, with its audit period |
| Encryption | Is data encrypted in transit and at rest? | Protocol and cipher details, key management description |
| Incident response | Is there a plan, and how fast do you notify us? | Written plan, notification hours, recent tabletop exercise |
| Vulnerability assessment | How often do you test? | Penetration test summary, scan cadence, patch SLAs |
| Access control | Who can see customer data? | Role definitions, MFA and SSO details, access review logs |
| Sub-processors | Who else touches our data? | Current sub-processor list |
| Data retention and deletion | How long do you keep it, and can we delete it? | Retention schedule, deletion process |
| Endpoint security | How are employee devices protected? | Device management policy |
| Past incidents | Have you had a breach? | Honest summary and what changed |
| Staff training | Do employees get security training? | Training schedule and completion records |
How to answer the questions that decide deals
Certifications: “Do you have a SOC 2?”
This is the first question at almost every company, and early-stage startups often cannot say yes. Do not bluff. Say where you are: audit scheduled, observation window underway, or controls documented but not yet audited. Then offer what you do have: policies, a pen test summary and a clear description of your controls.
A reviewer at a larger company is not always looking for a perfect answer. They are looking for a vendor whose answer matches reality. A candid “in progress, here is the timeline” beats a vague claim that collapses under a follow-up.
Encryption and data location
Be specific. Name the protocol for data in transit, the method for data at rest, where data is hosted and who holds the keys. One precise paragraph saves three rounds of email. Reviewers also ask what data you collect in the first place. Security guidance in the supply chain context stresses the gap between what a vendor needs and what it actually receives, so be ready to justify every data field you take.
Access control and SSO
Expect questions about role-based access, tenant isolation, SSO and user provisioning. Two points trip up small teams. First, an answer about your customers’ access is not an answer about your employees’ access to production. Answer both. Second, buyers increasingly ask whether SSO and logging are part of the base product. CISA’s Secure by Demand guide tells customers to push for security features like these in the baseline price rather than as enterprise-tier upsells. If your SSO sits behind a premium plan, expect to be asked why.
Incident response and breach notification
A plan on paper is not enough. Reviewers want the notification timeline in hours and proof you have practiced. Enterprise security addendums commonly use 48 to 72 hours for notifying customers of suspected incidents involving their data. Decide what you can honestly commit to before the legal team asks, because this number ends up in the contract.
Also be ready for the follow-up: when did you last run a tabletop exercise, and what did you change afterward?
Sub-processors
Your vendors are part of your answer. CISA’s fact sheet on procuring safe and secure ICT products points out that protecting data means understanding your vendors’ supply chain practices too. Keep a current sub-processor list, know what each one receives, and be able to say how security requirements flow down to them. Buyers also tend to want contract language that keeps you accountable for a sub-processor’s failure.
Data retention and deletion
What do you store, for how long, and what happens when a customer leaves? The FTC has long treated reasonable security as a proportional, ongoing duty, and its Safeguards Rule lists timely disposal of customer information among the expected controls. That rule applies to financial institutions, so it matters most if you sell into that sector, but reviewers in every industry borrow its logic. We go deeper on retention policy in our piece on data retention for sales calls.
Give evidence, not attestations
A questionnaire full of “yes” answers tells a reviewer almost nothing. Analysts describe this as attestation bias: vendors claim compliance without operational proof. The better reviewers know it, so they ask for artifacts.
Build a small evidence folder before the first request arrives:
- Your SOC 2 report or a dated statement of audit status.
- A penetration test summary from the last 12 months. The same source treats artifacts older than 12 months as stale for risk assessment.
- Proof that MFA is enforced on every administrative portal.
- A current sub-processor list.
- A software bill of materials, if your buyer’s sector asks for it.
- Your incident response plan and the date of your last exercise.
- A one-page data flow description: what you collect, where it lives, who can reach it.
With that folder, most questionnaires become copy and paste. Teams that lack in-house security staff sometimes bring in outside help to run a baseline assessment before the first big review, such as managed security assessments for small and mid-sized organizations. Doing it before a deal is on the line means findings get fixed instead of explained.
If you are the buyer: questions for your own vendors
The same list works in reverse. When you evaluate a tool that will see customer data, five questions do most of the work:
- Which of my data fields do you actually need, and which do you receive but never use?
- Can I see your current sub-processor list, and will you notify me before it changes?
- What is your contractual notification window for a suspected incident?
- Are SSO, audit logs and MFA included in the plan I am buying?
- What happens to my data, and how quickly, if I cancel?
If the tool uses AI, add governance questions: what the model sees, what it retains, and who approves changes. A framework such as governance gates for AI deployment gives you a way to check the operational controls around it.
A useful test of any answer: could the vendor attach a document to it? If not, ask again.
Run the review without losing the deal
Security reviews kill momentum when they run in the background. A few habits keep them moving.
Ask who the reviewer is early. On a discovery call, ask whether the buyer has a security or procurement process, who runs it and how long it usually takes. Our procurement questions mapped to MEDDPICC give you wording for this, and our discovery call questions cover where it fits in the conversation.
Send the evidence folder first. Do not wait for the spreadsheet. Offering your documents proactively shows maturity and often replaces half the questionnaire.
Offer a call with the reviewer. A 30-minute conversation with a security lead can replace a week of email. Prepare using a sales call preparation checklist, and know the answers to the ten topics above cold.
Watch for stall signals. A review with no named owner, no timeline and no urgency is a warning. Our B2B sales red flags checklist covers how to spot a deal that is drifting.
Our perspective
We build software that listens to sales calls, so we sit on both sides of this conversation. We answer security reviews, and our customers have to explain us to their own security teams.
What we have learned shapes how OffBook works. Founders at seed and Series A stage lose time when security comes up unprepared, and the answer is rarely a longer document. It is knowing, in the moment, which question just got asked and what evidence belongs with it. That is the same principle we apply to live coaching: help in the moment, when it changes the outcome.
It is also why we chose to coach without a bot joining the meeting, to ask for explicit consent per session, and to default to privacy-protective settings. A tool that records conversations will be questioned about where that data goes, and we would rather the answer be simple. Our stance is that the less your vendor collects, the shorter your review.
My advice to founders: treat the first security questionnaire as a free audit of your own habits. Write the answers once, back them with artifacts, and keep them current.
Neil
Prepare for the call where the questions land
Security questions rarely arrive in writing first. They come up live, from a technical stakeholder who joins the last call of the cycle. OffBook surfaces on-screen cues during video calls, so a rep sees qualification gaps and objections as they appear, and gets a pre-call brief on the people they are about to meet. Plans start with Power at $59 per month or $590 per year, and Team is $1,000 per year per seat. See the pricing page or how AI call coaching for sales works.
FAQ
What are the most common security review questions?
Expect questions about certifications such as SOC 2 or ISO 27001, encryption in transit and at rest, access control, incident response, sub-processors and data deletion. Reviewers also ask about vulnerability testing, endpoint security, past incidents and staff training. The CSA ten-point baseline covers all of them.
How do you answer if you do not have a SOC 2 yet?
Say so plainly and describe where you are in the process. Then supply substitutes: written policies, a recent penetration test summary, MFA evidence and a sub-processor list. Reviewers generally respond better to an accurate status than to an evasive yes.
How long should breach notification be?
Enterprise addendums commonly specify 48 to 72 hours for an initial notice, per one standard template. Choose a number you can meet in practice, since it becomes a contractual commitment. Have your legal counsel review the wording before you sign.
How do you do a security review of a vendor?
Start with the ten core topics, then request artifacts instead of accepting yes or no answers. Check that penetration tests and similar evidence are under 12 months old, ask for the sub-processor list, and confirm the notification timeline in hours. Record what you accepted and why, so the next review starts from your notes.
Sources
- 10 Important Questions to Add to Your Security Questionnaire, Cloud Security Alliance
- NIST Vendor Risk Assessment Questionnaire: 40 Mapped Questions
- Secure by Demand Guide, CISA
- Procuring Safe and Secure ICT Products and Services Fact Sheet, CISA
- Security Addendum, Enterprise template
- Cybersecurity in the supply chain: managing fourth-party risks, CSO Online
- 16 CFR Part 314, Standards for Safeguarding Customer Information