SaaS security questionnaire for small teams before buying a tool

TL;DR

Small teams do not need an enterprise procurement program for every SaaS purchase. They do need a repeatable way to ask: can this vendor protect the data and workflow we are about to give them?

Use this questionnaire when a tool will process customer data, employee data, invoices, contracts, support tickets, recordings, credentials, source code, or operational documents. The goal is not to score vendors or demand perfect paperwork. It is to get enough evidence to make a proportionate decision before the contract is signed and data is imported.

Practical sequence:

• Classify the data, users, integrations, and business impact.
• Ask focused questions about privacy, access, resilience, incidents, and supply chain.
• Look for evidence: DPA, subprocessor list, security documentation, audit reports, or clear control descriptions.
• Accept lighter proof for low-risk tools, but slow down for systems touching personal data, finance, identity, production, or customer support.

This guide is not legal advice and includes no vendor ratings or invented test results.

Scenario: the small-team buying problem

A 12-person company needs a new help desk, AI meeting assistant, HR app, project tool, or finance automation platform. The founder wants speed. Operations wants a smooth rollout. Security and privacy are handled by whoever has time. Then a customer asks where their data is hosted, whether a data processing agreement exists, and who can access support tickets.

That is when rushed SaaS buying becomes expensive. Common gaps include shared admin accounts, unclear support access, overbroad calendar or mailbox permissions, unknown subprocessors, no export plan, and contracts reviewed only after data migration.

A good questionnaire should not punish small vendors for lacking big-company polish. It should reveal whether the vendor can support your use case safely, legally, and operationally.

First: classify your own use case

Before asking the vendor, answer four internal questions:

• Data: What will the tool process? Names, emails, invoices, HR records, health data, source code, contracts, recordings, API keys?
• Access: Who can log in? Admins, contractors, guests, service accounts, integrations?
• Impact: What happens if the service is unavailable, breached, or difficult to leave?
• Legal role: Is the vendor processing personal data on your instructions, or acting partly as an independent controller?

If the vendor processes personal data for you, GDPR Article 28 requires processor terms covering documented instructions, confidentiality, security measures, subprocessors, assistance with rights requests, deletion or return of data, and audit information. A privacy policy alone is usually not enough for processor use.

Vendor questions: good answers and warning signs

1. What data will you collect and process for our account?

Good: The vendor distinguishes account data, content data, telemetry, billing data, support access, and integrations. Required and optional data are clear.

Worrying: “Standard data” is the answer, or the vendor cannot explain whether staff can view customer content.

2. Where is data hosted, backed up, and accessed from?

Good: Hosting regions, infrastructure providers, backup locations, support access, and data residency options are described. If EU hosting is offered, exceptions are explained.

Worrying: “Cloud hosted” is the whole answer, or EU hosting is advertised while logs, backups, support, and analytics remain unclear.

3. Do you provide a DPA and subprocessor list?

Good: A data processing agreement is available before purchase, includes Article 28-style commitments where GDPR applies, and links to a current subprocessor list with change notice.

Worrying: The vendor says the privacy policy replaces a DPA, refuses to identify subprocessors, or makes processor terms available only after signing.

4. How is employee and support access controlled?

Good: Role-based access, least privilege, MFA, logging, access reviews, and time-limited or approved support access for sensitive data.

Worrying: Shared admin access, no logs, no reviews, or “only trusted employees” without concrete controls.

5. What controls can customers enforce?

Good: Admin MFA, roles, secure invitations, session controls, audit logs, and ideally SSO/SCIM for higher-risk use.

Worrying: Admin MFA or audit logs are missing, or basic security controls require a plan far beyond your budget.

6. How are integrations and APIs secured?

Good: Least-privilege OAuth scopes or scoped tokens, token revocation, rotation, webhook signing, rate limits, and clear permission documentation.

Worrying: Permanent full-access API keys, no selective revocation, or integrations asking for more access than the workflow needs.

7. What is your vulnerability and incident process?

Good: The vendor can describe vulnerability intake, patching, severity handling, customer notification, incident roles, and post-incident review.

Worrying: No security contact, no notification commitment, or “we have never had an incident” used as a substitute for a process.

8. How do export, deletion, backup, and restore work?

Good: Backup frequency, restore testing, export formats, deletion timelines, and termination handling are explained.

Worrying: No practical export, vague deletion, indefinite backups, or exit terms that make leaving hard.

9. What independent or structured evidence can you share?

Good: SOC 2, ISO 27001, a pen-test summary, security whitepaper, trust center, or a control mapping such as the CSA Cloud Controls Matrix.

Worrying: Expired badges, slogans instead of controls, or refusal to share any meaningful evidence for a high-risk use case.

10. How do you manage your own supply chain?

Good: Critical suppliers are reviewed, dependencies are tracked, production access is restricted, and subprocessor changes are governed. CISA’s ICT supply-chain guidance is useful because SaaS risk includes the vendor’s vendors, infrastructure, code, and operations.

Worrying: Unknown critical suppliers, no dependency tracking, or “our cloud provider handles security” as the entire answer.

Quick evaluation table

Legal nuance: privacy is not just a checkbox

For EU and UK buyers, the question is both security and lawful use. If the SaaS provider processes personal data on your behalf, review the DPA, subprocessors, technical and organizational measures, deletion commitments, and international transfer approach. EU hosting can help, but it does not answer everything: support access, telemetry, backups, and subprocessors may still matter.

For US buyers, the legal hooks may come from customer contracts, sector rules, state privacy laws, insurance requirements, or internal security commitments. For any buyer, regulated data such as health, children’s data, payment data, or sensitive employee records deserves a deeper review.

Methodology and evidence

This draft uses a buyer-risk workflow, not vendor scoring. It is anchored in:

• GDPR Article 28 for processor contract requirements.
• CISA ICT supply-chain security for supplier and dependency risk.
• CSA Cloud Controls Matrix v4 for cloud control categories.
• ENISA cloud security guidance for SMEs for small-business cloud adoption.

No hands-on testing is implied. Combine this questionnaire with contract review, actual product configuration, and your risk appetite.

Trade-offs small teams can accept

Reasonable compromises may include accepting a standard security pack for low-risk data, starting with a limited pilot, using MFA without SSO, restricting integrations until scopes are clear, or accepting manual export for a non-critical tool.

Poor compromises include processing sensitive data without a DPA, granting broad mailbox or finance access without reviewing scopes, ignoring missing admin MFA, or asking security questions only after migration.

FAQ

How many questions should we ask?

For low-risk tools, 10 to 15 focused questions may be enough. For customer data, employee data, payments, identity, finance, or production workflows, ask for deeper evidence.

Are SOC 2 or ISO 27001 required?

Not always. Independent assurance helps, but absence of certification is not automatically disqualifying for low-risk use. Look at data sensitivity, workflow criticality, contract terms, and alternative evidence.

What if the vendor refuses our questionnaire?

Ask for a trust center, standard security pack, DPA, subprocessor list, or existing control responses. If none are available for a high-risk use case, treat that as a procurement risk.

Is EU hosting enough?

No. Check support access, subprocessors, logs, telemetry, backups, deletion, and transfer terms.

Who should own the review?

Assign one accountable owner, usually with input from the business lead, operations, IT/security, and privacy or legal support.

Internal link suggestions

• Vendor due diligence for small businesses.
• GDPR DPA and subprocessor review checklist.
• SaaS access controls: MFA, SSO, roles, and audit logs.
• Software procurement risk assessment template.
• SaaS exit planning: export, deletion, and contract end.