Guide
Vendor risk assessment: process and checklist
A vendor risk assessment is the structured review you run before (and after) letting a third-party tool touch your data, users, or systems. This guide covers the process end to end and gives you a domain-by-domain checklist you can reuse for every vendor.
The assessment process
1. Scope the engagement
Write down what the vendor will actually do: which data it touches, which users get access, whether it integrates with production systems, and what happens to the business if it goes down. Scope decides how deep the rest of the assessment needs to go.
2. Tier the vendor by risk
A tool holding customer PII or production credentials deserves more scrutiny than a design plugin. Tier vendors (for example critical / moderate / low) so the depth of review and re-review cadence match the exposure.
3. Collect evidence
Gather the vendor's trust center, security overview, sub-processor list, DPA, and any audit reports (SOC 2, ISO 27001) or authorizations (FedRAMP, CMMC). Public marketing pages are the weakest evidence; contracts and audit summaries are the strongest.
4. Assess against a fixed checklist
Run the same questions for every vendor so results are comparable. Record a verdict per question — met, needs attention, not met, or unknown — with the source text that justifies it.
5. Decide and document
Approve, approve with conditions, or deny. Capture the residual risk you accepted, who accepted it, and the date. This record is what an auditor or customer questionnaire will ask for later.
6. Re-review on a schedule
Certifications lapse, sub-processors change, and products get re-architected. Re-run the assessment periodically and treat anything older than a few months as stale.
The vendor risk assessment checklist
Six domains, each with the evidence to ask for. Record a verdict and a source for every line — that pairing is what makes the assessment defensible.
Security
- Encryption in transit and at rest, with stated algorithms or standards
- Independent testing: penetration tests, bug bounty, vulnerability management SLAs
- Secure development practices and dependency/patch management
- Documented incident response process and breach notification timelines
Privacy & data handling
- What personal data is processed, and for what purpose
- Data residency and cross-border transfer mechanism
- Sub-processor list and change-notification commitments
- Retention and deletion on termination, including backups
- A signable DPA covering the applicable privacy regimes
Compliance & certifications
- SOC 2 Type II or ISO 27001 with a current report or certificate
- FedRAMP authorization status, if you sell to or operate with federal agencies
- CMMC level, if the relationship touches controlled unclassified information
- Sector requirements such as HIPAA, PCI DSS, or GDPR representations
Access control
- SSO (SAML/OIDC) and SCIM provisioning availability, and on which plan
- Enforceable MFA for all users, including vendor-side administrators
- Granular roles and least-privilege administration
- Audit logs that you can export into your own SIEM
Availability & resilience
- Published uptime commitments and a live status page with history
- Backup frequency, recovery point and recovery time objectives
- Business continuity and disaster recovery testing
- Hosting model and the underlying infrastructure providers
Contractual & business risk
- Liability caps and indemnities relative to the data at stake
- Right to audit, security addendum, and change-of-control terms
- Data export format and offboarding assistance
- Vendor viability: funding, customer base, and support commitments
Common mistakes
Accepting the marketing page as evidence
"Bank-level encryption" is not a control. Cite the trust center, audit report, or contract clause instead — and mark anything you can't source as unknown.
Treating unknown as pass
Unknowns are your questionnaire. Send them back to the vendor before the decision, not after the incident.
Assessing once and never again
An assessment is a dated snapshot. Without a re-review cadence, your register describes a vendor that no longer exists.
Different questions for every vendor
Inconsistent checklists make vendors impossible to compare or tier. Fix the question set and vary only the depth of evidence.
Automate the first pass
Most of the work above is reading vendor documentation and mapping it onto the same questions every time. ComplianceCheckr does that pass for you: point it at a vendor URL or upload a security PDF, and it returns this checklist graded across the six domains with the source text quoted as evidence, an overall risk score, and a saved record you can approve, deny, or revisit later.
Assessing a vendor's audit report? See the SOC 2 compliance checklist , the ISO 27001 checklist, or the HIPAA compliance vendor risk assessment.