TL;DR: A vendor security questionnaire is a standardized set of questions buyers send to check a supplier’s security and risk before they sign. To answer one well, pull your evidence into one place and keep each answer short and tied to it, then save what you approve so the next one goes faster. If your app runs on a platform, the platform answers for its infrastructure and you answer for your app.
A spreadsheet lands from your prospect’s security team just as the deal is about to close: 100 rows of questions, due in two weeks. Or you’re the buyer, and your own security review can’t move until a vendor sends its answers. Either way, you need to get through the review without stalling the deal.
Security reviews are just part of buying software now. A breach at one supplier can expose every customer it works with, so buyers check vendors before they sign. Some have no choice, because rules like GDPR, HIPAA, and DORA make them show how their suppliers protect regulated data.
Below, you’ll find the four topics most questionnaires cover, the evidence that answers each one, a step-by-step process for drafting and reviewing responses, how buyers score your answers, and how to get answers when the vendor you’re evaluating is a no-code platform.
What is a vendor security questionnaire?
A vendor security questionnaire is a standardized list of questions a buyer sends to check a supplier’s cybersecurity controls before onboarding it. It also digs into your data protection practices, so the buyer can decide whether you’re worth the risk. It’s the buyer’s way of getting you on the record about how you’ll keep their data safe and what you’ll do if something goes wrong.
It usually comes from the buyer’s security or procurement team, and your security, engineering, and legal teams answer it. Take it seriously. Your answers often end up in the contract, so a quick “yes” can turn into a promise you’re held to.
Most questionnaires use one of these formats:
- SIG (Standardized Information Gathering): A detailed questionnaire from Shared Assessments covering security, privacy, and business resilience. Its questions are matched to many of the standards and regulations in the table below, so one set of answers can show a buyer how you measure up against several at once.
- CAIQ (Consensus Assessments Initiative Questionnaire): The Cloud Security Alliance’s questionnaire for cloud and SaaS vendors. Providers fill it out for a CSA STAR (Security, Trust, Assurance and Risk) Level 1 self-assessment, and some buyers will take a completed one as part of due diligence.
- VSA questionnaires: Free questionnaires (VSA-Core and VSA-Full) from the Vendor Security Alliance. Smaller buyers without their own template often start here.
- Custom questionnaires: Spreadsheets or portal forms a buyer builds around its own risk tolerance. Expect these to take longer, since the wording often doesn’t line up with answers you’ve already written.
A questionnaire often shows up alongside a request for proposal (RFP), but they’re asking different things. The RFP wants to know what you’ll deliver and what it costs. The questionnaire wants to know how you’ll protect the buyer’s data.
A questionnaire’s length depends on how much risk you bring. If you’ll store sensitive records, expect a much longer form than a vendor that never touches customer data gets.
What questions does a vendor security questionnaire include?
The wording changes from buyer to buyer, but most questionnaires dig into the same four parts of your security posture (how well you protect your systems and data overall). For each one below, you’ll see what reviewers ask and the evidence that answers it. Think of it as your evidence map.
Compliance and certification questions
Buyers want proof that someone independent has checked your security, so expect questions about the standards and regulations they care about. Here’s what each one is and when it applies.
| Type | What it covers | Who it applies to | |
|---|---|---|---|
| SOC 2 Type II | Independent report from a CPA firm | How well your security controls worked over several months | Common for SaaS and service companies, especially selling to US businesses |
| ISO 27001 | Voluntary international standard, with certification | How you run your information security program | Any company, and often expected by international buyers |
| NIST (National Institute of Standards and Technology) frameworks |
US government frameworks, voluntary for most companies | Security practices and controls | Any company, and required for US federal agencies and some government contractors, like defense contractors handling sensitive government data |
| PCI DSS (Payment Card Industry Data Security Standard) |
Payment card industry standard | Protecting payment card data | Any company that stores, processes, or sends card data |
| HIPAA (Health Insurance Portability and Accountability Act) |
US law | Protecting health information | US healthcare providers, health plans, and claims clearinghouses, plus vendors that handle health data for them, who must sign a business associate agreement (BAA) |
| GDPR (General Data Protection Regulation) |
EU law | Personal data privacy | Companies based in the EU, and companies elsewhere that offer goods or services to people in the EU or track their behavior there |
| DORA (Digital Operational Resilience Act) |
EU law | How financial firms manage tech risk, including their tech suppliers | EU financial firms, which must build DORA requirements into contracts with their tech suppliers, plus tech suppliers that regulators designate as critical |
A SOC 2 report covers a set stretch of time, so there’s often a gap between when that period ended and when the buyer reviews you. Buyers often ask for a bridge letter to cover it. That’s a short note from your management (not your auditor) confirming nothing important has changed since the report period ended.
Evidence to bring:
- Your SOC 2 report (often shared only under a nondisclosure agreement, or NDA) or ISO 27001 certificate
- A bridge letter, if your last SOC 2 period ended a while ago
- Policies that show how you meet laws like GDPR and HIPAA
- Signed agreements, like a data processing agreement (DPA) or BAA
Access control and data protection questions
Buyers want to know who can get into your systems and how. Expect questions about multi-factor authentication (MFA), which adds a second check at login, like a code sent to your phone. You’ll also get asked about single sign-on (SSO), which lets employees use one company login through a standard like SAML or OIDC.
Reviewers will ask who on your team can see customer data and whether people get only the access their job needs (known as least privilege). Most teams handle that with role-based access.
Then come the encryption questions: data in transit and at rest, how you manage keys, and how long you hold on to data.
Evidence to bring:
- Excerpts from your access control and encryption policies
- A screenshot of your SSO or identity provider (IdP) setup
- Your data retention and deletion policy
Incident response and business continuity questions
Every company has a bad day eventually, and this part of the questionnaire is about yours. Reviewers want to see a formal incident response plan, how fast you’ll tell customers about a breach, and how often you test your backups and disaster recovery plan.
Expect questions about penetration tests (authorized, simulated attacks that find weak spots before attackers do) and how you log and monitor activity.
Evidence to bring:
- Your incident response summary
- A recent pen test or vulnerability scan summary
- Backup restore test records
- Your disaster recovery plan
Third-party and subprocessor questions
Buyers also want to know who else touches their data, starting with your subprocessors (third parties you bring in to process your customers’ personal data, like a cloud host or email provider). Reviewers will ask which ones you use, where they’re located, and how you vet them.
They’ll usually ask for your DPA, which sets the rules for how you handle personal data, and sometimes for the right to audit your controls.
Evidence to bring:
- A current subprocessor list
- Your DPA
How do you answer a vendor security questionnaire step by step?
Work through these in order. The evidence map above tells you which documents go with which answers.
Confirm the scope, owners, and deadline
Read the whole thing before you answer a single question, and check which products and data are actually in scope. A buyer using one of your products doesn’t need answers about the others. Note the format and due date, too.
Then split it up: Engineering takes encryption, IT takes access, legal takes the DPA, and so on. Send clarifying questions early, like whether “employees” includes your contractors. Guessing now usually means rewriting later.
Gather your evidence in one place
Put everything in one shared folder with version history: your SOC 2 report or ISO 27001 certificate, policies, test summaries, your subprocessor list, and system diagrams. Give every file a clear title and date so reviewers can tell how current it is. The more each answer points to a specific file, the fewer follow-up emails you’ll get.
Draft precise, honest answers
Start every answer with a plain yes or no, add a sentence of context, then point to the evidence. And describe each security control (like MFA or encryption) the same way on every questionnaire, because few things slow a review down like two answers that don’t match.
If a question doesn’t apply, say “Not applicable” and give a quick reason. If you don’t meet a requirement, explain your compensating control instead (a different safeguard that covers the same risk).
| Weak answer | Strong answer | |
|---|---|---|
| Do you encrypt data at rest? | Yes, we use industry-standard encryption. | Yes. Customer data is encrypted at rest, as described in section 4 of our encryption policy (attached). |
| Do you require MFA for employees? | Mostly. | Yes. MFA is required for every employee account through our SSO provider. A settings screenshot is attached. |
| Do you have a disaster recovery plan? | We have backups. | Yes. Our disaster recovery plan and last restore test record are in the evidence folder. |
AI tools can pull first drafts from your past approved answers, which helps with repeat questions. Just make sure someone who knows the system reviews every answer before it goes out.
Review, submit, and save to your response library
Before you hit submit, read your answers, policies, and diagrams side by side and make sure they tell the same story. Attach clearly labeled files, and log any follow-up questions with an owner for each.
Then save it all to a response library (a shared collection of approved answers and evidence). Next time a questionnaire shows up, you’ll start from answers you’ve already approved instead of a blank spreadsheet.
How do buyers evaluate vendor questionnaire answers?
For the buyer, your questionnaire is one piece of third-party risk management (keeping track of the risks that come from suppliers). Reviewers check each answer against your evidence and against how much risk they’re willing to accept.
Counting “yes” answers is just the first pass. Here’s what they look at next, so you can see the follow-up questions coming:
- Risk tiering: Buyers start with inherent risk (the data and access you’ll have), then look at what’s left once your controls are in place. A payroll vendor starts out riskier than a design tool.
- Evidence over descriptions: A dated audit report, like your SOC 2 report, beats a paragraph about your security culture. Attach proof wherever you can.
- Must-haves and nice-to-haves: For many buyers, a missing control like MFA is a deal breaker, while other gaps just get logged as lower-risk findings, depending on their policy and how much data you’ll touch. If you’re not sure which ones are must-haves, ask the buyer.
- Scenario questions: Buyers may ask you to talk through a situation, like a support rep who needs temporary access to customer data. They want to see that your policy holds up outside the document.
Reviewers also watch for red flags, like vague answers, documents that contradict each other, or no proof to back up your claims. Because most companies share SOC 2 reports only under an NDA, a public summary (called a SOC 3 report) or your trust center documentation can cover you until the paperwork is signed.
The review doesn’t end with the contract, either. Many buyers track vendors in third-party risk management platforms like Secureframe or OneTrust, and you’ll likely be reassessed at renewal or when you add a new subprocessor.
Can you get a vendor security questionnaire answered for a no-code platform?
Usually, yes. Established no-code platforms typically share security documentation, compliance reports such as a SOC 2 Type II report, and answers to standard questionnaires through a trust center, a security page, or their sales team, sometimes under an NDA.
And if your own app runs on a platform, you won’t answer your customers’ questionnaires alone.
What the platform answers and what you answer
This works through what’s called the shared responsibility model. The platform answers for the infrastructure and controls it owns, and you answer for how you’ve set up and run your app.
- The platform answers: Hosting, encryption, data center security, its own staff’s access, and its own subprocessors. For those questions, point to its SOC 2 report.
- You answer: Who can see which data in your app, who has admin access, and your own policies and incident process. These depend on how you’ve set up the app.
Say one of your enterprise customers sends you a questionnaire. Your answers to infrastructure questions point to your platform’s SOC 2 report, and your answers about data access describe the permissions you set up.
How to request answers from a no-code platform
- Find the platform’s security or trust page.
- Request its SOC 2 Type II report, and sign an NDA if it asks.
- Send over your questionnaire, and ask what the platform already has on hand, like SOC 2 reports, security documentation, or a completed CAIQ.
- Request the subprocessor list and DPA.
- Check which security features depend on your plan, like SSO, security checks, and backup retention.
If a platform can’t share its SOC 2 report or something equivalent, or gets vague when you ask about data access, take a closer look.
How Bubble answers common questionnaire sections
On Bubble, you can see and change every workflow, data type, and privacy rule in your app. In the shared responsibility split, we take care of the infrastructure and platform-level security, and you handle your app’s setup. Because the logic is right there on screen, anyone on your team can explain to a reviewer exactly who can see what.
| How Bubble addresses it | |
|---|---|
| Compliance | We’re compliant with the SOC 2 Type II standard for security. You can reach out to our Sales team for proper documentation. That covers our platform, so your own app isn’t automatically SOC 2 compliant. |
| Platform access | On the Enterprise plan, your organization logs in to Bubble with SSO, and admins control who’s a member. For SSO in your own app, add the WorkOS plugin or set it up with the API Connector. |
| Data access in your app | You decide who can see or change data, down to each field, with visual privacy rules. When the Bubble AI Agent creates data types, it sets up privacy rules for them automatically, and you can review and tweak them to fit your requirements. |
| Encryption | Your data is encrypted with TLS in transit and AES-256 at rest. |
| Vulnerability management | Before you deploy, the security dashboard flags issues like missing privacy rules, unsafe API call configuration, and exposed sensitive credentials or parameters. It comes with every paid plan: Starter gets basic checks, and Growth, Team, and Enterprise add advanced ones like compromised API tokens and database exposure risks. |
| Change management | Your team can look over changes visually before they go live and roll back to an earlier savepoint if something breaks. Version control comes with paid plans (basic on Starter, premium on Growth, Team, and Enterprise). |
| Business continuity | Your app runs on auto-scaling infrastructure with automatic database backups, and you can restore to any point in your plan’s retention window (two days on Starter, customizable on Enterprise). |
If you’ve built your app on Bubble and a customer sends you a questionnaire, be clear about which parts are yours. The security dashboard flags common issues, but someone on your team should still review your app’s security before launch. And because you set your app’s privacy rules, questions about data access are yours to answer.
Bubble apps run on our hosted infrastructure and can’t be self-hosted, so if a questionnaire asks, just say so. If you need more control over hosting, a dedicated instance on the Enterprise plan lets you pick your hosting region, get a static IP, and set up custom Cloudflare configurations.
Organizations have been taking Bubble apps through security reviews for years:
- Seagate: A Bubble app built at Seagate passed the company’s security review.
- Hive Health: The regulated health insurer runs its health plan app for businesses in the Philippines on a dedicated Enterprise server with a static IP and custom Cloudflare policies.
Answer your next vendor security questionnaire with confidence
A vendor security questionnaire can look like a wall of questions, but it comes down to four topics: compliance, access control, incident response, and third parties. Gather your evidence for each one before you start writing, answer only what you can back up, and your review should move a lot faster.
If you’re the buyer, ask for evidence over descriptions. And when the vendor is a platform, use the shared responsibility split to see which answers the platform owns and which the builder owns.
Whichever side you’re on, start a response library this week. Your next questionnaire will start from approved answers instead of a blank page.
If your own customers will review the app you’re building, the platform you build on matters. Bubble is the fully visual app builder where anyone can build software, understand every part of it, and control every detail without code. That includes your privacy rules, so when a customer asks how their data is protected, you can show them exactly who can access it.
You also build on a platform that’s SOC 2 Type II compliant, with a security dashboard that flags common issues before you launch.
Frequently asked questions
What is the difference between a vendor security questionnaire and a vendor risk assessment?
A vendor security questionnaire is one tool inside a vendor risk assessment, which is the bigger process of scoring and keeping tabs on a supplier’s risk. The assessment weighs your answers against your evidence and the buyer’s risk tolerance.
Is SOC 2 Type II the same as a SOC 2 certification?
No. SOC 2 results in an independent attestation report rather than a certificate, so the accurate phrasing is that a vendor has a SOC 2 Type II report or is SOC 2 Type II compliant.
Can a startup answer a vendor security questionnaire without its own SOC 2 report?
Sometimes. Some buyers will accept your hosting platform’s SOC 2 report for infrastructure questions, as long as you pair it with clear policies, honest answers about what’s still in progress, and the compensating controls you already have.
How often should a vendor security questionnaire be reviewed or updated?
Update your saved answers whenever a policy, subprocessor, or security control changes, and review them at least once a year. Buyers typically ask you to confirm your answers again at contract renewal.
Build for as long as you want on the Free plan. Only upgrade when you're ready to launch.
Join Bubble
