SaaS Security Checklist: 20 Questions to Ask Before Buying

Every SaaS tool you adopt becomes an extension of your own security perimeter. Customer data, employee records, financials, source code, internal conversations — all of it now lives on infrastructure you don't control, secured by people you didn't hire. The average mid-size company uses 100+ SaaS apps, which means 100+ potential breach surfaces.

This checklist gives you 20 questions that cover the five areas that matter most: data encryption, compliance certifications, access control, data backups and residency, and incident response. Ask these before you sign — not after a breach teaches you why they matter.

The five security domains

Domain 1: Data encryption (Q1–Q4)

Encryption is the baseline, not the ceiling. Every reputable SaaS vendor encrypts data in transit and at rest — the questions are about how, and who holds the keys.

Q1: Is data encrypted in transit using TLS 1.2 or higher?

This should be an immediate yes. TLS 1.2 minimum is now table stakes; TLS 1.3 is increasingly common. If the vendor hedges or mentions SSL, walk away. Perfect forward secrecy should be standard.

Q2: Is data encrypted at rest, and with what algorithm?

Look for AES-256 encryption at rest, applied to databases, object storage, backups, and logs. Ask whether encryption is applied at the storage layer (volume-level), the application layer (record-level), or both. Application-layer encryption with customer-managed keys is the gold standard — it means even the vendor's own engineers can't read your data without your keys.

Q3: Who manages the encryption keys?

Vendor-managed keys are the default and acceptable for most use cases. For sensitive workloads, look for customer-managed keys (CMK) using AWS KMS, Azure Key Vault, or Google Cloud KMS, where you control key rotation and revocation. Bring-your-own-key (BYOK) is the highest tier and matters for regulated industries.

Q4: Do you support field-level or column-level encryption?

For tools storing PII, PHI, or financial data, field-level encryption means a breach of the database doesn't automatically expose the most sensitive fields. Not every vendor supports this, but it's a strong differentiator for healthcare, fintech, and HR tools.

Domain 2: Compliance & certifications (Q5–Q9)

Certifications don't guarantee security, but they prove a vendor has been independently audited against a recognized standard. A vendor with no certifications is asking you to trust them on faith.

Q5: Are you SOC 2 Type II certified, and can you share the report?

SOC 2 Type II is the most widely recognized SaaS security attestation in North America. Type I assesses design at a point in time; Type II assesses operating effectiveness over 6–12 months. Always ask for Type II, and request the actual report under NDA — a vendor that claims compliance but won't share the report is a yellow flag. Check the report's scope: some vendors certify only a subset of their product or infrastructure.

Q6: Are you ISO 27001 certified?

ISO 27001 is the international standard for information security management systems. It's more common among European and enterprise-focused vendors. ISO 27001 + SOC 2 Type II together is a strong signal. ISO 27017 (cloud security) and ISO 27018 (PII in public clouds) are relevant extensions.

Q7: Are you GDPR compliant, and where is the DPA?

For any vendor processing EU personal data, GDPR compliance is a legal requirement, not optional. Ask for the Data Processing Agreement (DPA) — it should be a standard template you can sign without negotiation. Confirm sub-processor lists are published and updated, and that the vendor supports data subject access requests (DSARs) and the right to erasure.

Q8: Are you HIPAA compliant, and will you sign a BAA?

If you're in healthcare or handle protected health information (PHI) in the US, the vendor must be HIPAA-compliant and willing to sign a Business Associate Agreement (BAA). A vendor that won't sign a BAA cannot legally process PHI on your behalf. Note that "HIPAA-ready" is not the same as "HIPAA-compliant" — only the latter comes with a BAA.

Q9: Do you support PCI DSS for payment data?

If the tool processes, stores, or transmits cardholder data, PCI DSS compliance applies. Most SaaS tools avoid PCI scope by tokenizing through Stripe, Adyen, or Braintree — ask which. If the vendor self-certifies PCI, ask for the Attestation of Compliance (AoC) and confirm the scope.

Domain 3: Access control (Q10–Q13)

Encryption protects data from outsiders. Access control protects it from insiders — including the vendor's own staff. These questions establish who can see your data and under what conditions.

Q10: Do you support SAML SSO and SCIM provisioning?

SAML 2.0 single sign-on (via Okta, Azure AD, Google Workspace, etc.) should be standard on any business plan — though many vendors gate it behind an Enterprise tier. SCIM automated user provisioning means deprovisioning happens instantly when someone leaves your company, eliminating orphan accounts. Confirm both, and check whether SSO is included or a paid add-on.

Q11: Do your employees have access to my data, and under what controls?

The honest answer is usually "yes, under specific circumstances." Ask about: least-privilege access controls, just-in-time access with approval workflows, session recording for production access, and whether access is logged and auditable. A vendor that claims "no employee ever accesses customer data" is either exceptional or evasive — dig in.

Q12: Do you support role-based access control (RBAC) and audit logs?

Within your own account, you need granular roles (admin, editor, viewer, custom) and a tamper-evident audit log showing who did what, when. Audit logs should be exportable and retained for at least 12 months — longer for regulated industries. Check whether audit logs are included or an Enterprise feature.

Q13: What is your password and authentication policy?

The vendor should enforce strong passwords and support (or require) MFA for all accounts. Ask whether MFA is enforced for their own employees accessing your data. If the vendor's own staff can access production without MFA, your data is one phished credential away from exposure.

Domain 4: Backups & data residency (Q14–Q16)

Encryption and access controls protect against unauthorized access. Backups protect against the authorized kind — accidental deletion, corruption, or a vendor-side outage that takes your data with it.

Q14: How often is my data backed up, and what's the retention policy?

Look for at least daily backups with 30-day retention, and confirm backups are stored in a separate availability zone or region from production. Ask about point-in-time recovery (PITR) — can you restore to a specific moment, not just "last night's backup"? Confirm whether backups are included or a paid add-on; some vendors charge extra for anything beyond 7 days.

Q15: What is your RTO and RPO?

Recovery Time Objective (RTO) is how long until service is restored after an incident. Recovery Point Objective (RPO) is how much data you could lose (the window between the last backup and the incident). Enterprise-grade vendors should commit to RTO under 4 hours and RPO under 1 hour. Get these in the SLA, not in marketing copy.

Q16: Where is my data physically stored, and can I choose the region?

Data residency matters for GDPR (EU data must stay in the EU or adequacy-decision countries), for certain regulated industries, and for customers in jurisdictions with data localization laws. Confirm the vendor's hosting regions (AWS us-east-1, eu-west-1, etc.) and whether you can pin your data to a specific region. For EU customers, confirm the vendor doesn't replicate data to the US without a valid transfer mechanism (SCCs, EU-US Data Privacy Framework).

Domain 5: Incident response (Q17–Q20)

Every vendor will eventually have an incident — a breach, an outage, a misconfiguration. What separates a trustworthy vendor from a risky one is how they prepare for and handle it.

Q17: What is your breach notification policy and timeline?

Many contracts default to "notify within 30 days" or even "as soon as commercially reasonable." That's not good enough. Push for notification within 72 hours of confirmed detection (aligned with GDPR), and specify what they notify you about — not just confirmed breaches but material security incidents. Get the notification commitment in the contract, not the marketing page.

Q18: Do you have a documented incident response plan and a trained team?

Ask whether the vendor has a dedicated security team (not just "the engineering team handles it"), a published security incident response process, and regular tabletop exercises or red-team tests. Vendors mature in security will talk about this openly; immature ones will deflect.

Q19: Do you run regular penetration tests, and can I see a summary?

Annual third-party penetration tests should be standard. Ask who performs them (reputable firms include Bishop Fox, Trail of Bits, NCC Group), how often, and whether you can see a sanitized summary or the SOC 2 report that covers them. Bug bounty programs (HackerOne, Bugcrowd) are a positive signal of ongoing testing.

Q20: What is your vulnerability disclosure and patch management policy?

Ask how the vendor handles CVEs in their dependencies, what their patch SLA is for critical vulnerabilities (look for 7 days or less), and whether they have a public security advisory page. A vendor with no visible security advisories either has perfect security (unlikely) or doesn't disclose (likely).

The 20-question quick checklist

Print this, send it to every vendor you're evaluating, and require written answers before signing. A vendor that takes security seriously will answer in detail; one that doesn't will send you a marketing PDF.

How to actually use this checklist

Don't send all 20 questions cold to every vendor. Tier your approach based on risk:

• Low-risk tools (no sensitive data, productivity tools, internal wikis with non-confidential content): Require a SOC 2 Type II report and SSO. Spot-check the rest.
• Medium-risk tools (CRM, help desk, marketing automation, analytics with customer data): Send all 20 questions. Require written answers and certifications.
• High-risk tools (HR, payroll, finance, anything with PII/PHI/source code/large customer datasets): Send all 20 questions, require a security review call with their team, and have your legal team review the DPA and breach notification terms.

Red flags that should end the conversation

• No SOC 2 Type II and no timeline to get one — for a business-grade SaaS, this is disqualifying.
• Refusal to share certifications under NDA — "trust us" is not a security control.
• SSO and audit logs gated behind a 3x-price Enterprise tier — the vendor is monetizing basic security.
• No documented breach notification commitment in the contract.
• No public vulnerability disclosure policy or security advisory page.
• Customer support staff with standing production database access without JIT controls.

Security is a continuum, not a binary. No vendor will ace every question, and that's fine — the goal is to understand the gaps and decide whether they're acceptable for your risk tolerance and the sensitivity of the data involved. What's never acceptable is a vendor that won't answer the questions at all.