Ready-to-send template · 5 sections, 30+ questions
The questions to ask a software vendor before you trust them with your data.
A copy-and-send security questionnaire covering governance, data protection, application security, infrastructure, and incident response — so you can evaluate a vendor on evidence instead of a sales deck, and capture the answers that matter in writing before you sign.
Why send a questionnaire at all
When you buy software, you inherit that vendor's security posture. If they get breached and your customer data was in their system, your customers do not care whose fault it was — they hold you accountable. A vendor security questionnaire is how you do diligence before that risk becomes yours, and how you turn a confident sales pitch into specific, written commitments.
This template is the set of questions we send when evaluating tools that will touch a client's data, and the same set we help clients answer when they are the vendor under review. Scale the depth to the risk: a vendor holding your production database deserves every question; a low-risk widget does not. For a related buyer-side process, see the technical due diligence checklist.
1. Security governance & program
- Do you hold a current SOC 2 Type II, ISO 27001, or equivalent certification? Please share the report or summary and its scope.
- Who owns security at your company, and is there a dedicated security or compliance function?
- Do you maintain documented security policies, and how often are they reviewed and approved?
- How do you screen employees and contractors who can access customer data, and is access removed promptly when they leave?
- Do you require security awareness training for staff, and how frequently?
- Do you carry cyber-liability insurance, and what does it cover?
2. Data protection & privacy
- What customer data do you collect, where is it stored, and in which regions or jurisdictions?
- Is data encrypted in transit and at rest, and which algorithms and key-management approach do you use?
- How do you segregate one customer's data from another in a multi-tenant environment?
- What is your data-retention policy, and how do you handle deletion when a customer offboards?
- Which sub-processors or fourth parties touch our data, and how do you vet them?
- Can we obtain a data-processing agreement, and does it address applicable privacy regulations?
- How would you support a customer data-access or deletion request that we are legally required to fulfill?
3. Application security
- Do you follow a secure development lifecycle, including code review and dependency scanning?
- How often do you commission independent penetration tests, and will you share a summary of the most recent results?
- How do you authenticate users, and do you support single sign-on and multi-factor authentication?
- How is access to customer data controlled internally, and is least-privilege enforced and logged?
- How do you manage and rotate secrets, API keys, and credentials?
- Do you have a responsible-disclosure or bug-bounty program for externally reported vulnerabilities?
4. Infrastructure & operations
- Where is the service hosted, and what physical and logical security controls protect the infrastructure?
- How are systems patched, and what is your target timeline for remediating critical vulnerabilities?
- What is your backup strategy, and have you tested restoring from backups?
- What are your documented availability targets, and where can we see historical uptime?
- How do you monitor for security events, and how long are audit logs retained?
- What is your business-continuity and disaster-recovery plan, and when was it last exercised?
5. Incident response & breach notification
- Do you have a documented incident-response plan, and who is responsible for executing it?
- How quickly will you notify customers of a confirmed security incident affecting their data, and will you commit to that timeline contractually?
- What information will a breach notification include, and through what channel?
- Have you experienced a material security incident in the past 24 months? If so, describe what happened and what changed afterward.
- How do you coordinate with customers during an incident, including a single point of contact?
- Do you conduct post-incident reviews, and are the lessons fed back into your controls?
How to read the answers
The value is not in the questions, it is in how the vendor answers them. A strong vendor responds specifically, attaches documentation, and is comfortable committing to breach-notification timelines in the contract. Watch for the red flags: vague answers on where data lives, no independent penetration testing, no documented incident-response plan, or reluctance to name a notification window. Any of those in a high-risk vendor is a reason to slow down.
If a vendor offers a current SOC 2 Type II report, read it first and confirm its scope actually covers the product you are buying. If you want to understand what that report does and does not prove, the SOC 2 preparation guide is a useful companion, and the penetration testing primer explains why an independent test matters more than a self-assessment.
How this connects to our work
We sit on both sides of this exchange. When a client is buying, we help them evaluate vendor answers and spot the gaps a sales team glosses over. When a client is the vendor — usually a SaaS company facing enterprise security reviews — we run a penetration test and a web application pentest so they can answer the application-security questions with real evidence instead of promises.
The infrastructure and operations questions map directly to how we build, which is why teams that use our SaaS platform development and custom business software services tend to pass vendor reviews faster. To talk through your specific situation, see our pricing overview or reach out directly.
Frequently asked questions
When should I send a vendor security questionnaire?
Send it before you sign a contract with any vendor that will store, process, or access your customer data, source code, credentials, or production systems. The depth should scale with the risk: a marketing widget needs a lighter review than a vendor holding your customer database.
What if the vendor already has a SOC 2 report?
A current SOC 2 Type II report answers many of these questions, so ask for it first. Use the questionnaire to fill the gaps the report does not cover, to confirm the report's scope actually includes the product you are buying, and to capture commitments in writing.
How do I score the answers?
Treat vague, evasive, or 'we are working on it' answers to data-protection and incident-response questions as red flags. A trustworthy vendor answers specifically, points to documentation, and is comfortable putting breach-notification timelines into the contract.
Can I use this as a buyer and as a vendor?
Yes. Buyers send it to evaluate suppliers. Vendors use it to pre-write a security overview so they can answer customer security reviews quickly instead of scrambling on every deal. The same questions work in both directions.
Related resources & reading
Technical Due Diligence Checklist
The broader diligence review for evaluating a software supplier or acquisition.
Web App Pentest Checklist
Scope an independent test to back up the application-security answers.
SOC 2 Pentest Prep Guide
What a SOC 2 report proves, and what it does not.
Penetration Testing
Turn the security section into evidence with an independent test.
On the answering side of a security review?
If enterprise prospects keep sending you questionnaires like this one, an independent penetration test and a tidy security overview will shorten every deal. See how engagements are priced or book a call.