A third-party vendor can become a direct path into your systems, data, customers, or operational processes. This reusable vendor security review checklist helps technology, procurement, and risk teams evaluate a software provider before signing, renewing, or expanding a contract. It covers access, authentication, encryption, breach handling, subprocessors, vulnerability management, retention, evidence, and contract terms so the decision is based on documented risk rather than a vendor’s marketing summary.
Overview
A vendor security review is a structured assessment of what could happen if a supplier is compromised, misconfigured, unavailable, or unable to meet its security commitments. The review should match the vendor’s actual exposure. A tool that only receives public information does not require the same scrutiny as a platform that stores employee records, processes payments, connects to production systems, or handles credentials.
Start by recording the proposed use case, the data involved, the integrations required, the users who will access the product, and the business process that would be affected by an outage. Separate confirmed evidence from vendor statements, assumptions, and open questions. A completed questionnaire is useful, but it is not proof by itself.
Quick vendor comparison table
| Review area | Lower-risk indicators | Follow-up questions |
|---|---|---|
| Data access | Minimal data, narrow permissions, clear tenant separation | What data is collected, copied, derived, or accessible by support staff? |
| Authentication | Single sign-on, multifactor authentication, role-based access, audit logs | Are these controls available to all users, administrators, and support personnel? |
| Encryption | Encryption in transit and at rest with documented key-management practices | Which systems and backups are covered, and who can access keys? |
| Resilience | Documented backups, recovery procedures, and tested continuity plans | What recovery objectives apply to the contracted service? |
| Incident response | Defined escalation process and contractual notification language | When does the notification clock begin, and what information will be provided? |
| Subprocessors | Published list, change notices, and flow-down security obligations | Can the vendor identify where data is processed and by whom? |
| Vulnerability management | Secure development practices, testing, remediation tracking | How are critical findings prioritized, verified, and communicated? |
Checklist by scenario
1. Before approving a new SaaS vendor
- Map the data: List personal information, confidential business data, credentials, tokens, source code, logs, and metadata the product will handle.
- Classify the exposure: Mark whether the vendor stores, processes, transmits, or merely views each data category.
- Document integrations: Identify APIs, browser extensions, identity-provider connections, webhooks, network paths, and administrative privileges.
- Review access controls: Confirm support for single sign-on, multifactor authentication, role-based permissions, session controls, administrator approval, and access reviews.
- Check logging: Ask whether authentication events, administrative actions, data exports, configuration changes, and API activity are recorded and retained long enough for investigation.
- Request security evidence: Depending on the risk, ask for an applicable independent assurance report, a penetration-test summary, security policies, vulnerability-management information, and a description of incident-response testing. Review scope, dates, exceptions, and management responses rather than relying only on the report title.
- Assess deletion: Establish how data is returned or deleted at contract termination, including backups, caches, logs, and data held by subprocessors.
2. When the vendor connects to production or identity systems
- Require a documented integration design before granting access.
- Use dedicated service accounts, narrowly scoped tokens, expiration dates, and separate administrative roles where supported.
- Prefer read-only access when write access is not necessary.
- Confirm how secrets are stored, rotated, revoked, and audited.
- Define an owner for each integration and a process for removing access when a user, system, or contract changes.
- Test whether the vendor can support emergency account suspension and rapid credential revocation.
For high-impact integrations, have an internal security or infrastructure reviewer examine the permissions directly. A vendor’s general statement that it follows least privilege does not replace an inspection of the permissions your organization will actually grant.
3. Before a contract renewal
- Compare the current product, data flows, subprocessors, and integrations with the original assessment.
- Ask about material security incidents, unresolved findings, significant control changes, and changes in ownership or hosting arrangements during the review period.
- Revalidate administrator accounts, unused integrations, API keys, exports, and user licenses.
- Confirm that the vendor still provides the required security features under the current plan and contract.
- Review the vendor’s updated assurance materials and check whether the scope still covers the services you use.
- Record any accepted exceptions with an owner, rationale, expiry date, and compensating control.
4. If the vendor reports a breach or security incident
- Open an internal incident record and preserve the vendor’s notice, timeline, indicators, affected service names, and contact details.
- Determine whether your organization’s data, credentials, tokens, users, or integrations were involved.
- Rotate exposed secrets and review authentication, administrative, API, and data-export logs.
- Ask what containment, remediation, and validation steps have been completed, and which questions remain unanswered.
- Coordinate legal, privacy, communications, and business owners before making external notifications.
- Reassess whether the vendor remains appropriate and record the decision.
For a broader response workflow, see the incident response checklist for teams and the security alert triage guide.
5. A practical risk-scoring worksheet
Use a simple, documented score rather than pretending to achieve mathematical precision. Rate each category from 0 to 3: 0 means low concern or strong evidence, 1 means minor gap, 2 means material uncertainty or weakness, and 3 means high concern or unacceptable exposure.
| Category | Score | Notes or evidence |
|---|---|---|
| Data sensitivity and volume | 0–3 | |
| Privilege and integration access | 0–3 | |
| Authentication and access management | 0–3 | |
| Encryption and key management | 0–3 | |
| Vulnerability and secure development practices | 0–3 | |
| Incident response and notification terms | 0–3 | |
| Subprocessors and data location | 0–3 | |
| Availability, recovery, and exit plan | 0–3 |
Set decision thresholds before reviewing the result. For example, a high total score may require remediation or senior approval, while a critical issue involving privileged access, unclear data deletion, or inadequate incident notification may require a pause regardless of the total. The threshold is an organizational decision; document it and apply it consistently.
What to double-check
Evidence is current, scoped, and relevant
Check the period covered by every report, the services and locations included, the control exceptions listed, and whether the evidence applies to the product your team will use. A security document for one hosting environment may not cover a separate product, region, or acquired platform.
Contract language matches the questionnaire
Security answers are often informal, while the contract controls what happens when a promise is disputed. Review definitions of a security incident, notification timing, cooperation duties, audit or evidence rights, subprocessor changes, data return and deletion, confidentiality, access termination, and liability allocation with the appropriate legal and security owners. Do not assume that a vendor’s standard policy automatically creates a contractual commitment.
Operational controls can be used by your team
Confirm that the features your review depends on are enabled, configurable, and available to the administrators who will operate them. Ask for implementation documentation or a product demonstration where necessary. An available control that is difficult to configure, excludes service accounts, or produces unusable logs may not reduce practical risk.
Exit is possible
Document how to export data, revoke access, replace integrations, preserve records, and validate deletion. Consider what happens if the vendor is unavailable during an incident or if the service is discontinued. A technically secure vendor can still create operational risk if your organization cannot transition away from it.
If the review involves a suspicious vendor domain, login page, or impersonation concern, use the suspicious-domain investigation checklist before sharing credentials or sensitive documents.
Common mistakes
- Treating a questionnaire as a pass: A complete answer can still describe weak controls, broad access, or missing evidence.
- Reviewing the product but not the integration: Risk often comes from permissions, tokens, exports, and identity connections created during deployment.
- Accepting vague incident terms: “Promptly” or “without undue delay” may not provide the operational clarity your response team needs. Seek defined responsibilities and escalation contacts.
- Ignoring subprocessors: A vendor may rely on other providers for hosting, support, analytics, communications, or data processing. Track those dependencies.
- Overlooking support access: Ask how support personnel are authenticated, approved, monitored, and restricted when they can view customer environments.
- Failing to assign an owner: A review without an accountable service owner becomes outdated when users, integrations, or data change.
- Scoring without recording assumptions: A number without evidence, confidence, and an expiration date is difficult to defend or revisit.
For adjacent privacy exposure work, use the quarterly personal privacy audit. For phishing or impersonation concerns involving a vendor contact, preserve evidence and follow the phishing reporting template.
When to revisit
Review the vendor before the initial purchase, at each contract renewal, and whenever the workflow or tool changes. Trigger an earlier review when the vendor adds a new integration, requests broader permissions, changes subprocessors or hosting arrangements, introduces a materially different product, reports a security incident, or changes ownership or operating controls.
Maintain a short review record containing the current data flow, risk score, evidence links, open actions, accepted exceptions, contract owner, technical owner, and next review date. Recheck high-risk vendors more frequently than low-risk tools, but avoid a calendar-only process: a material change should trigger review immediately.
Before the next seasonal planning or procurement cycle, refresh your vendor questionnaire, evidence requirements, scoring thresholds, incident contacts, and approved compensating controls. When workflows or tools change, compare the new design with the original assessment rather than simply copying the old approval. This makes the checklist useful for every new vendor, renewal, expansion, and vendor breach review.
