Vendor Security Checklist: What to Ask Every SaaS Provider Before Signing

Signing up for a new SaaS tool takes minutes. The due diligence that should precede that decision often takes less time than the sign-up itself. For most small and medium businesses, vendor security assessment means checking the pricing page and reading one review — and nothing more.

This creates real risk. Every SaaS provider you adopt processes business data. For any tool that touches personal data of your customers or employees, you bear legal responsibility for how that vendor handles it. Under GDPR and equivalent frameworks, you are a data controller; the vendor is a processor; and you are responsible for ensuring the processor provides sufficient guarantees.

“They are a well-known company” is not a due diligence process. This checklist is.

Before you evaluate: define what data the tool will touch

The level of scrutiny required depends on what data the vendor will access. Before running the checklist, classify the tool:

Tier 1 — High sensitivity: the tool will process personal data of customers, employees, or other individuals. Examples: CRM, HR software, email marketing, helpdesk, document management, financial software, cloud storage.

Tier 2 — Medium sensitivity: the tool will process business data but not personal data. Examples: project management, internal wikis, business analytics without personal data, development tools.

Tier 3 — Low sensitivity: the tool processes no confidential business or personal data. Examples: design tools working only with non-sensitive content, productivity tools with no data connectivity.

Tier 1 tools require the full checklist. Tier 2 tools require sections 1–3. Tier 3 tools require a minimal review.

Section 1: Legal and contractual requirements

These are non-negotiable for any Tier 1 vendor.

Data Processing Agreement

• Does the vendor offer a Data Processing Agreement (DPA)?
• Does the DPA include the mandatory Article 28 clauses under GDPR (or equivalent under your applicable law)?
• Can you access and sign the DPA before subscribing (not only after purchase)?

If a vendor does not offer a DPA for a tool that processes personal data, do not proceed. There is no legal basis for using that vendor as a processor without one.

Sub-processors

• Does the vendor disclose which sub-processors they use?
• Is there a process for being notified of sub-processor changes?
• Does the DPA require the vendor to impose equivalent obligations on sub-processors?

International transfers

• Where is the vendor headquartered?
• Where is data stored and processed?
• If data is transferred outside your jurisdiction (e.g., EU to US), what transfer mechanism applies?
• Is a Transfer Impact Assessment available or referenced in the DPA?

Jurisdiction and law

• Which law governs the DPA?
• Which courts have jurisdiction over disputes?

Section 2: Security controls

Certifications

• Does the vendor hold ISO 27001 certification?
• Is SOC 2 Type II available? (Request the report, not just a confirmation that it exists)
• For cloud infrastructure: is there CSA STAR certification?

Certifications are not a substitute for evaluation, but their absence from a Tier 1 vendor should be noted and questioned.

Encryption

• Is data encrypted at rest? With what standard? (AES-256 is the minimum acceptable)
• Is data encrypted in transit? (TLS 1.2 or higher)
• Are backups encrypted?
• Who holds the encryption keys? (Vendor-managed keys are standard; customer-managed keys provide additional control)

Access controls

• Does the vendor enforce multi-factor authentication for staff access to customer data?
• Is access to customer data restricted to staff with a need to access it?
• Are privileged access activities logged and monitored?
• Is there a background check process for staff with access to customer data?

Infrastructure

• Which cloud provider(s) host the service? (AWS, Azure, GCP are generally acceptable; unknown providers warrant scrutiny)
• What is the vendor’s uptime SLA and historical uptime?
• Are there documented business continuity and disaster recovery plans?
• What is the Recovery Time Objective and Recovery Point Objective?

Penetration testing

• Does the vendor conduct annual penetration testing?
• Is a summary of the most recent penetration test available to customers?
• Is there a vulnerability disclosure policy?

Section 3: Incident response and breach notification

• What is the vendor’s process for detecting security incidents?
• What is the contractual commitment for notifying you of a breach that affects your data?
• Is the notification timeline in the DPA consistent with your own regulatory obligations (typically 72 hours under GDPR)?
• Does the vendor have cyber liability insurance?
• Can the vendor provide evidence of a past breach response (without compromising confidentiality) to demonstrate their process?

The notification commitment is critical. If a vendor is breached on a Saturday and notifies you the following Wednesday, you may have missed your own 72-hour notification window to your supervisory authority. The DPA should commit to notification within 24–48 hours of the vendor becoming aware.

Section 4: Data management

• What is the vendor’s data retention policy?
• Can you delete your data at any time, including during a contract?
• What happens to your data when the contract ends? Is deletion confirmed in writing?
• Can you export all your data in a portable, machine-readable format?
• How long after contract termination does the vendor retain data before deletion?
• Is there an audit log of access to your data that you can access?

The export and deletion provisions matter more than most businesses recognise at contract inception. A vendor that makes it difficult to leave — by making data export complex or expensive — creates operational lock-in that affects your ability to respond to a breach (if you cannot quickly export and verify your data) and your ability to respond to data subject requests (if you cannot retrieve or delete data efficiently).

Section 5: Contractual protections

• Does the contract limit the vendor’s liability in a way that creates significant uninsured risk for you?
• Are there audit rights that allow you to verify the vendor’s security controls?
• Can you terminate without penalty if the vendor materially changes its privacy or security practices?
• Does the vendor commit to maintaining the certifications and controls described during the sales process?

The questions to ask during the sales process

Asking these questions during a sales call — before the demo, before the trial — gives you useful information about vendor culture:

“Can you send us your current DPA before we schedule a demo?” A vendor who hesitates or says the DPA is only accessible post-purchase is signalling something about their compliance culture.

“Which sub-processors do you use and how will you notify us of changes?” A well-prepared vendor has a clear answer. An unprepared one has a problem.

“When were you last penetration tested and can we see a summary?” A vendor who has never been penetration tested, or who treats the question as unusual, warrants caution.

The answers that should make you walk away

• “We don’t have a DPA” (for any Tier 1 tool)
• “Data is stored in our proprietary data centre” with no detail on security controls
• “We’ve never been breached” as a substitute for security documentation
• “All data is deleted immediately when you cancel” with no written contractual commitment
• “Our terms allow us to use your data to improve our models” for any tool handling client personal data

After signing: ongoing vendor management

Vendor assessment is not a one-time exercise. At minimum annually:

• Review sub-processor lists for changes
• Request updated SOC 2 reports or ISO recertification evidence
• Verify that the DPA still reflects actual processing activities
• Confirm that the vendor’s contact details for breach notification are current
• Review any changes to the vendor’s privacy policy or terms of service

A vendor assessment that happens once at contract inception and never again is a snapshot of risk, not a control.