SaaS Vendor Risk Assessment: A Security and Privacy Due Diligence Checklist

Overview

A vendor review should be more than a request for a compliance badge. The useful question is whether the provider's actual services, data access, technical controls, and contract commitments fit your organization's risk tolerance.

Start by defining the service being assessed. Record the product name, business owner, intended users, connected systems, data categories, regions involved, and whether the provider will process personal, confidential, regulated, or security-sensitive information. A low-risk collaboration tool may need a lighter review than a platform that stores customer records or receives production credentials.

Assign a risk tier before sending a long questionnaire. Consider data sensitivity, volume, access privileges, business criticality, internet exposure, integration depth, and the effect of a service outage. The tier should determine how much evidence you request, who must approve the vendor, and how often the review is repeated. For a broader prioritization method, see the third-party risk tiering framework.

Keep evidence with the assessment rather than relying on informal assurances. Useful records may include a completed questionnaire, security documentation, a current assurance report, relevant contract language, subprocessor information, and notes from follow-up discussions. Evidence should support a decision, not become paperwork for its own sake.

Checklist by scenario

Before approving a new SaaS provider

• Scope: What does the service do, and which features will your team actually use?
• Data: What data enters the platform, where is it stored, and what is the provider allowed to do with it?
• Access: Does the product support single sign-on, multi-factor authentication, role-based access, administrative logging, and timely user deprovisioning?
• Encryption: Is data protected in transit and at rest? Clarify key-management responsibilities where relevant.
• Secure development: Ask about vulnerability management, code review, dependency management, penetration testing, and security testing for material changes.
• Resilience: What backup, disaster recovery, availability monitoring, and restoration practices support the service?
• Incident handling: How does the vendor detect, contain, investigate, and communicate security incidents? Confirm that the contract provides a practical notice process.
• Privacy: Identify the processing purpose, roles of the parties, retention rules, data-subject support, deletion process, and international transfer arrangements that may apply.
• Subprocessors: Obtain the current subprocessor list, understand notification and objection processes, and determine whether any subprocessor can access sensitive data.
• Assurance: Review relevant SOC 2, ISO 27001, penetration-testing, or other evidence in context. Check its scope, period, exceptions, and whether it covers the service you will use.
• Exit: Confirm export formats, migration assistance, deletion timelines, account closure procedures, and treatment of backups after termination.

For personal data processing, align the review with your contract process. A DPA guide can help you identify subjects such as instructions, confidentiality, security measures, subprocessors, assistance, audits, and deletion. A DPA does not replace technical due diligence, and technical evidence does not replace appropriate contract terms.

When the vendor handles sensitive or regulated data

Increase scrutiny when the provider stores identity information, financial details, health-related information, authentication secrets, proprietary source code, or data subject to customer or regulatory commitments. Ask for a clear data-flow description rather than a general statement about security. Map collection, processing, support access, analytics, exports, backups, and deletion.

Confirm that the service can enforce the controls your own policies require. Examples include restricted administrator access, audit logs that can be retained, configurable retention, tenant separation, regional hosting options, and approval workflows. If the vendor cannot support a required control, document the gap and obtain a risk acceptance or choose another design.

When the vendor connects to production systems

Review integrations as carefully as the SaaS application. List requested permissions, API scopes, service accounts, network paths, secrets, webhooks, and data exchanged in each direction. Prefer least privilege, separate integration identities, expiring credentials, and monitored administrative actions.

Ask how access is revoked when an employee leaves, a token is exposed, or the contract ends. Test the revocation process where possible. A vendor with strong internal controls can still create unnecessary exposure if your integration grants broad or permanent access.

For an annual or periodic reassessment

Do not simply resend last year's questionnaire. Compare the original assessment with current use. Review changes to data types, user counts, integrations, hosting regions, subprocessors, ownership, product architecture, security incidents, audit evidence, and contract terms. Confirm that previous findings were closed and that compensating controls still operate.

What to double-check

Evidence scope: A certificate or report may cover only a particular entity, product, environment, or period. Match the evidence to the service and processing activity under review.

Shared responsibility: Ask which controls belong to the provider and which remain with your team. Configuration, identity management, user permissions, integration security, and data classification are often customer responsibilities.

Subprocessor language: Check whether the vendor may add subprocessors without meaningful notice, whether objections have a defined process, and whether the vendor remains accountable for them under the agreement.

Retention and deletion: Distinguish between active data, archived data, logs, disaster-recovery copies, and backups. Request a practical description of deletion timing and verification, especially after termination.

Breach communications: Contract language should identify a usable notification channel, required cooperation, contact responsibilities, and information sharing. Coordinate this with your cloud incident response plan; a vendor review is valuable only if your team can act on an alert.

Data residency: Identify where data and support access may occur, not only the provider's headquarters. Treat regional hosting, remote administration, backups, and subprocessors as separate questions.

Risk score: Use a simple, explainable model. Score impact and likelihood separately, record open issues, assign owners and due dates, and state whether the remaining risk is accepted, reduced, transferred through contract, or unresolved. Avoid turning a numerical score into a substitute for judgment.

Common mistakes

• Reviewing the brand instead of the service: A reputable provider may offer products with different architectures, controls, and data-handling terms.
• Accepting “compliant” as evidence: Ask what was assessed, when, and whether the result applies to your use case.
• Ignoring procurement urgency: A rushed approval often creates an unmanaged exception. Use risk tiers and a minimum evidence set to move quickly without skipping the decision record.
• Failing to involve the right owners: Security, privacy, legal, procurement, engineering, and the business owner may each see a different risk.
• Forgetting configuration after approval: Require secure defaults, document the approved configuration, and verify that the deployed setup matches the assessment.
• Leaving unused accounts and integrations active: Include access reviews, license reviews, and integration cleanup in normal service ownership.
• Making the questionnaire impossible to answer: Ask focused questions tied to a decision. Follow up on material gaps instead of demanding irrelevant documentation.

When to revisit

Set a review cadence based on risk rather than applying one schedule to every vendor. A high-impact provider may need a formal review at least annually, while lower-risk services may be reviewed on a longer cycle if monitoring and ownership remain clear. The cadence should be documented and approved.

Trigger an earlier assessment after a security incident, material product change, new integration, major subprocessor change, acquisition, change in hosting region, significant contract amendment, new data category, or change in regulatory or customer requirements. Also revisit vendors before seasonal planning cycles, major migrations, and changes to identity or cloud architecture.

Make reassessment actionable: export the current vendor inventory, filter for the relevant risk tier, verify each owner, request updated evidence, review open findings, and record a new decision. If the provider no longer meets requirements, restrict data or access while remediation is evaluated, or begin a controlled exit using the documented offboarding plan.

For a repeatable workflow, combine this checklist with the SaaS vendor risk assessment workflow and maintain one source of truth for approvals, evidence, renewal dates, findings, and review triggers. The objective is not a perfect score. It is a current, defensible understanding of third-party risk and a clear plan for reducing it.