Every vendor you give data or system access to is an extension of your own attack surface — and increasingly, it's also a specific question in nearly every enterprise security review and audit framework. "How do you assess vendor risk?" isn't a rhetorical question; auditors want to see a repeatable process, not a one-off spreadsheet you filled in once.
Step 1: Build a real vendor inventory
You can't assess risk you haven't identified. Start with a genuine inventory of every third party that has access to your systems, your data, or your customers' data — not just the obvious infrastructure vendors, but SaaS tools individual teams signed up for, contractors, and subprocessors your own vendors use. For each one, record what data or systems they can reach and why.
Step 2: Tier vendors by risk, not by spend
Not every vendor deserves the same scrutiny, and treating them all identically either wastes effort on low-risk vendors or under-scrutinises high-risk ones. A simple, defensible tiering approach looks at two dimensions:
- Data sensitivity — does this vendor touch personal information, payment data, health data, or your source code/IP?
- Access level — do they have standing access to production systems, or only a narrow, occasional integration?
A payroll provider with access to employee bank details and ID numbers is high risk regardless of the contract size. A tool that only receives anonymised, aggregate analytics is low risk even if it's expensive.
Step 3: Match the assessment depth to the tier
- High risk — a full security questionnaire, request their SOC 2 report or ISO 27001 certificate if available, review their subprocessor list, and confirm a signed data processing agreement (DPA) is in place.
- Medium risk — a shorter questionnaire focused on the specific access/data they have, plus confirmation of basic security hygiene (encryption, access controls, incident response contact).
- Low risk — a lightweight check: what data do they actually touch, and is there a standard contract in place. Revisit only if their access or your usage changes.
A practical question template
For higher-risk vendors, these are the categories a real assessment should cover — adjust depth based on tier:
- Data handling — What specific data do you process for us? Where is it stored (country/region)? How long is it retained, and how is it deleted?
- Access control — How is access to our data restricted internally? Do you enforce MFA and least-privilege access?
- Encryption — Is data encrypted in transit and at rest?
- Subprocessors — Do you use any subprocessors that would also touch our data? Are they listed anywhere we can review?
- Certifications & reports — Do you hold SOC 2, ISO 27001, or an equivalent, and can you share the report?
- Incident response — What is your process and typical timeline for notifying customers of a security incident affecting their data?
- Business continuity — What's your backup and disaster recovery approach, and what's your target recovery time?
Step 4: Document residual risk and a decision
An assessment that doesn't end in a documented decision isn't really an assessment. For each vendor, record: what risk remains after reviewing their answers, whether that risk is acceptable, and if not, what mitigation is required before (or as a condition of) onboarding — additional contractual protections, restricting the data shared, or in some cases, choosing a different vendor entirely.
Step 5: Reassess on a schedule, not just at onboarding
This is the step most programs skip, and it's usually the one auditors ask about directly: what happens after a vendor is approved? High-risk vendors should be reassessed at least annually (a lapsed SOC 2 report, a new subprocessor, or a past-year security incident all change the picture). Medium and low-risk vendors can be reassessed less frequently, but "never again after onboarding" isn't a defensible answer in any audit.
This guide is general information — the specific depth and frequency your vendor risk program needs depends on your industry, the frameworks you're audited against, and your regulatory obligations.
Making this a system instead of a spreadsheet
The pattern above works, but it breaks down fast in a spreadsheet once you have more than a handful of vendors — reassessment dates get missed, and evidence lives in scattered email threads. ComplianceDesk's vendor risk module lets you record vendors, run assessments against a structured risk level, and see at a glance which ones are overdue for reassessment — the same underlying practice this guide describes, just with nothing falling through the cracks.