Suppliers can introduce risk through the data they handle, the access they receive, the services the business depends on, and the software or infrastructure they provide. A proportionate vendor risk assessment helps a lean team focus effort where a supplier could materially affect confidentiality, integrity, availability, resilience, or customer trust.
Direct answer
Perform a vendor risk assessment by classifying the supplier and service, understanding the data and access involved, checking security and resilience practices, reviewing contracts and incident obligations, recording gaps and decisions, approving the risk, and monitoring the supplier throughout the relationship.
Not every vendor needs the same depth of review. A low-risk office supplier should not receive the same process as a provider with privileged production access or sensitive customer data.
This checklist is general educational material. Contractual, privacy, regulatory, and sector-specific requirements should be confirmed for the organisation’s circumstances.
Source and scope: NIST SP 800-161 Rev. 1 covers identifying, assessing, and mitigating supply-chain cybersecurity risk. The tiering and questionnaire below are Aneo’s practical checklist; the exact diligence and contract terms depend on the supplier’s role and applicable obligations.
Step 1: Classify the vendor and service
Start with basic context:
- What service does the vendor provide?
- Is it critical to a customer-facing or internal business process?
- What data will it receive, store, or generate?
- Does it receive privileged, production, administrative, or physical access?
- Does it use subcontractors or subprocessors?
- What happens to the business if the service is unavailable?
- Is the vendor subject to customer, insurance, or framework requirements?
Use a simple tier such as low, medium, or high risk. Document why the tier was assigned so the assessment can be understood later.
Step 2: Review data and access
Confirm the information flow and access model before reviewing certificates or policy documents. Record:
- Data categories and sensitivity
- Data locations and processing regions
- Retention and deletion approach
- Encryption expectations
- Identity and authentication methods
- Privileged access controls
- Support and remote access pathways
- Logging and monitoring relevant to the service
- Tenant separation or customer isolation where applicable
Ask for the minimum access and data needed for the service. Reducing unnecessary access is often more useful than adding another questionnaire.
Step 3: Review security practices proportionately
Use questions that match the risk tier. Topics may include:
- Security governance and ownership
- Vulnerability management and patching
- Secure development and change management
- Identity and access review
- Incident response and customer notification
- Backup, recovery, and resilience testing
- Employee awareness and access lifecycle
- Physical and environmental safeguards
- Subprocessor management
- Business continuity and exit planning
Evidence may include a security overview, independent assessment, penetration test summary, relevant policy excerpts, access review description, recovery test summary, or customer assurance report.
Do not collect evidence merely to fill a folder. Record what each artifact proves and what it does not prove.
Step 4: Review contract protections
Security expectations should be reflected in the relationship, not left only in a questionnaire. Depending on the service, review whether the agreement addresses:
- Permitted data use and confidentiality
- Security responsibilities of each party
- Incident notification and cooperation
- Access and support controls
- Subprocessor or subcontractor changes
- Data return and deletion at exit
- Availability and recovery commitments
- Audit, assurance, or information rights
- Location or transfer requirements
- Assistance with customer or regulatory requests
The exact terms depend on the service and parties. A security assessment does not replace legal review.
Step 5: Record findings and decisions
Use a vendor record that keeps the decision explainable:
| Field | What to record |
|---|---|
| Vendor and service | The supplier and business use |
| Risk tier | Low, medium, or high with rationale |
| Business owner | The person accountable for the relationship |
| Data and access | Information handled and access granted |
| Evidence reviewed | Documents, reports, answers, or tests |
| Findings | Strengths, gaps, and open questions |
| Risk decision | Accept, mitigate, defer, or do not onboard |
| Actions | Owner, priority, and target date for each gap |
| Contract status | Relevant security, privacy, and exit terms |
| Review date | Next scheduled or event-driven review |
If a gap is accepted, record who accepted it, why, what safeguards exist, and when the decision will be reviewed.
Step 6: Approve onboarding and access
Before the vendor is onboarded, confirm that the right business and security owners have reviewed the result. High-risk vendors may need leadership, security, privacy, procurement, or legal approval.
Access should be granted through the normal identity and change process. Record who approved it, what access was granted, when it should be reviewed, and how it will be removed.
Do not let a completed questionnaire become an automatic approval. The decision should reflect risk, business need, evidence quality, contract position, and available safeguards.
Step 7: Monitor the relationship
Vendor risk changes after onboarding. Set a review cadence based on the risk tier and monitor events such as:
- Security incidents or service outages
- Material product or architecture changes
- New subprocessors or processing locations
- Ownership or financial changes
- Expired assurance reports or certifications
- Repeated support or access issues
- Changes to business criticality
- Contract renewal or termination
Review access and data use as well as the vendor’s documents. A current report does not automatically prove that the service is configured correctly for your organisation.
A proportionate tiering model
Low risk
Limited business impact, no sensitive data, and no privileged access. Use a short intake, basic terms, and periodic confirmation.
Medium risk
Meaningful business dependency, internal or personal data, or moderate access. Add security questions, evidence review, defined incident contacts, and scheduled reassessment.
High risk
Critical service dependency, sensitive customer data, privileged production access, or material resilience impact. Use deeper assessment, contract review, leadership approval, access controls, recovery and incident validation, and more frequent monitoring.
Adjust these tiers to fit the business. The labels are less important than the reasoning and consistent application.
Common vendor risk mistakes
Treating every vendor the same
Equal effort is not the same as proportionate risk management.
Accepting a certificate without understanding scope
Check what service, location, period, and controls the assurance actually covers.
Ignoring subprocessors
The supplier’s dependencies can affect data handling, resilience, and incident response.
Forgetting the exit plan
Know how data, access, records, and business processes will be handled when the relationship ends.
Never revisiting the assessment
Vendor risk changes with service usage, architecture, incidents, and business criticality.
Where Framework-Pro fits
Framework-Pro helps teams turn supplier security expectations into relevant controls, policy language, evidence placeholders, and implementation tasks. Vendor decisions still require business, security, privacy, procurement, and legal review appropriate to the relationship.
For related guidance, see how to choose the right evidence for each security control and NIS2 supply-chain security.
Frequently asked questions
What is a vendor risk assessment?
A vendor risk assessment reviews the security, privacy, resilience, access, data handling, and operational risks a supplier may introduce to the business.
What should a vendor security checklist include?
It should cover the service and data, access, security practices, incident response, resilience, subprocessors, contracts, evidence, risk decisions, ownership, and ongoing monitoring.
How often should vendors be reassessed?
Use a cadence based on risk and reassess after material changes, incidents, new subprocessors, scope changes, or contract renewal. High-risk vendors generally need more frequent review.
Does a vendor certificate remove the need for assessment?
No. A certificate or assurance report can be useful evidence, but the organisation still needs to check scope, relevance, configuration, contractual needs, and its own risk decision.