A vendor risk assessment helps you decide whether a third party can handle your systems or data safely, what safeguards belong in the contract, and how often the relationship should be reviewed. This reusable workflow gives SMBs and SaaS teams a practical vendor security questionnaire, risk-scoring method, evidence checklist, and escalation process that can be adapted before onboarding or when a supplier’s services change.
Overview
Third-party security is not a one-time procurement task. A vendor may process personal data, connect to production systems, host business-critical workloads, or support an operational process that your team cannot easily replace. The purpose of a vendor risk assessment is to understand that dependency before access is granted and to keep the decision documented.
Start by creating a vendor record with the supplier’s name, service owner, business purpose, data involved, systems accessed, regions used, contract status, and renewal date. Record whether the vendor is a software provider, hosting provider, payment service, consultant, subprocessor, or another type of supplier. This classification determines which questions and documents matter most.
Risk should be based on exposure rather than vendor size or marketing language. A small tool with no sensitive data may require a lightweight review. A familiar cloud platform with privileged production access may require deeper diligence, stronger contract terms, and more frequent monitoring.
Keep evidence with the assessment rather than recording only a pass-or-fail conclusion. Useful evidence can include a completed vendor security questionnaire, relevant certifications or audit reports, penetration-test summaries, policy excerpts, data-flow diagrams, a disaster recovery summary, breach-notification procedures, and the signed agreement. Sensitive reports should be stored with appropriate access restrictions.
For related operational controls, compare this process with the vendor security assessment checklist for SMBs and SaaS buyers, and use the access control policy checklist when a supplier needs accounts or administrative access.
Checklist by scenario
1. Low-risk vendor with limited access
Use a proportionate review for tools that do not process sensitive information, do not connect to production systems, and can be replaced without major disruption.
- Confirm the business owner and intended use.
- Identify the information collected, stored, or transmitted.
- Check whether the service supports MFA, role-based access, account removal, and audit logs.
- Review the vendor’s privacy notice and security documentation.
- Confirm how data is deleted when the account is closed.
- Record the decision, residual risks, and next review date.
2. Vendor processing personal data
When a supplier processes personal data on your behalf, document the relationship and clarify responsibilities before processing begins. The assessment should support—not replace—your privacy compliance work.
- Map the categories of individuals and personal data involved.
- Clarify the purpose, duration, locations, and permitted uses of processing.
- Determine whether the supplier is acting as a processor, subprocessor, or another type of party under the applicable arrangement.
- Review the data processing agreement, including confidentiality, security measures, assistance with rights requests, deletion or return of data, and audit or information rights.
- Request the vendor’s current subprocessor information and escalation process for changes.
- Check transfer, retention, and deletion practices against your documented requirements.
For background on maintaining supplier transparency, see subprocessor list best practices and the website GDPR compliance checklist.
3. Vendor with production or privileged access
Apply a higher level of scrutiny when a supplier can administer infrastructure, access source code, view customer records, alter DNS, or bypass normal application controls.
- Require named accounts rather than shared credentials.
- Require MFA and least-privilege permissions.
- Define approval, logging, session, and emergency-access requirements.
- Set an access expiration or review date.
- Confirm how the vendor handles its own personnel changes and offboarding.
- Establish a process for revoking access promptly when the contract ends or the business need changes.
- Review backup, recovery, monitoring, vulnerability management, and incident response controls.
Domain, hosting, and infrastructure suppliers deserve particular attention because compromise can affect many systems at once. Use the domain transfer security checklist and website security checklist to identify related controls.
4. Business-critical or difficult-to-replace vendor
For a supplier whose outage would interrupt core operations, add resilience and exit planning to the review.
- Identify service dependencies and single points of failure.
- Request relevant uptime, recovery, backup, and continuity information without treating an assurance statement as a guarantee.
- Document recovery objectives that are appropriate for your business.
- Confirm data export formats, migration assistance, and deletion procedures.
- Identify alternative suppliers or manual workarounds.
- Define who makes the escalation decision during a serious outage or security event.
How to score and approve the assessment
A simple scoring model is easier to maintain than a complicated formula that no one uses. Score each vendor against a small set of consistent factors, such as data sensitivity, access level, operational criticality, regulatory or contractual impact, and dependency on subcontractors. Use a scale such as low, medium, or high, and document why each rating was assigned.
For example, a vendor that stores customer information, has privileged access, and supports a critical service may be high risk even if its questionnaire answers appear satisfactory. A vendor with no sensitive data and no system integration may remain low risk with limited evidence. The score should describe your exposure, not certify that the vendor is “secure.”
Set approval rules before reviewing individual suppliers. A low-risk vendor may be approved by the service owner. A medium-risk vendor may require security or privacy review. A high-risk vendor may require leadership approval, compensating controls, a remediation plan, or a decision not to proceed. Record accepted risks with an owner and target date.
What to double-check
- Evidence dates: Confirm that reports, certificates, questionnaires, and test summaries are current enough for the decision. Note their coverage period and scope.
- Scope: Check whether an assurance report covers the exact product, environment, and service location you intend to use.
- Contract alignment: Make sure the agreement reflects the actual data, access, subprocessors, retention period, security obligations, audit rights, and incident-communication process.
- Incident handling: Identify the vendor’s notification channel, required contacts, cooperation expectations, and evidence-preservation process. Coordinate this with your incident response plan.
- Access lifecycle: Verify who approves access, how permissions are reviewed, and how accounts are removed for both your staff and the supplier’s staff.
- Data deletion: Ask what happens to backups, logs, replicas, exports, and data held by subprocessors when the relationship ends.
- Subcontracting: Look beyond the direct supplier. A vendor may rely on cloud hosting, support providers, analytics tools, or other subprocessors.
- Exceptions: Capture unanswered questions and temporary compensating controls instead of silently treating them as complete.
Common mistakes
Sending the same questionnaire to every vendor. A long form can obscure the controls that matter. Use a baseline questionnaire and add modules for personal data, privileged access, hosting, payment information, or business continuity.
Accepting a certification as the entire review. An assurance document can provide useful evidence, but it may not cover your exact service, configuration, contract terms, or use case. Review its scope and supplement it with targeted questions.
Assessing the vendor but not your configuration. Strong supplier controls do not prevent an administrator from enabling excessive permissions, exposing an integration, or retaining data unnecessarily. Include configuration and access reviews in your onboarding process.
Leaving procurement records disconnected from technical records. Security teams need to know renewal dates, service owners, and contract changes. Procurement and IT should use a shared register or linked records with clear ownership.
Failing to plan for termination. Documenting an exit path before a dispute or incident makes it easier to revoke access, retrieve data, update integrations, and confirm deletion.
When to revisit the assessment
Review each vendor on a schedule that matches its risk. A low-risk tool may be reviewed during an annual planning cycle. A high-risk or business-critical supplier may need more frequent review, especially when it handles sensitive data or privileged access. Set the next review date when the vendor is approved rather than relying on memory.
Reopen the assessment whenever the underlying inputs change. Triggers include a new data category, expanded permissions, a new integration, a change in hosting or subprocessors, a material contract amendment, an incident, a prolonged outage, a major product change, a merger, a change in ownership, or a move to a different service tier. Also revisit the assessment before seasonal planning cycles and whenever internal workflows or tools change.
At each review, confirm the owner, risk rating, evidence, open remediation items, contract status, access list, subprocessor information, and exit plan. Then choose one of three outcomes: approve as is, approve with tracked conditions, or escalate for a new decision. This keeps vendor due diligence connected to day-to-day operations instead of turning it into a document that is filed and forgotten.
To put the process into practice, create a vendor register, define your risk tiers, prepare a short baseline questionnaire, assign approval owners, and schedule the first review dates. Pair the workflow with your security policies using the security policy starter set for small businesses. The result is a repeatable third-party risk management checklist that can grow with your organization without requiring every supplier to undergo the same review.
