A proportionate SaaS vendor-risk checklist covering business criticality, security, privacy, resilience, subcontractors, contracts and exit readiness.
Assess proportionally, or you will assess nothing well
The most common failure in SaaS vendor risk assessment is not being too lax — it is sending the same 200-question spreadsheet to every supplier. Security teams become a bottleneck, the business routes around them, and the genuinely risky vendors get the same attention as the note-taking app.
Tier first, then assess.
| Tier | Criteria | Assessment depth | Typical effort |
|---|---|---|---|
| Critical | Personal or sensitive data at scale, or business-stopping if unavailable, or privileged access to your systems | Full assessment, evidence review, contract negotiation, annual re-review | Days |
| Important | Some personal data, meaningful operational impact, integrates with core systems | Standard questionnaire, attestation review, standard clauses | Hours |
| Low | No personal data, easily replaced, no system integration | Lightweight self-service check, register entry | Minutes |
Roughly 10–15% of vendors usually land in the critical tier. That is where the real effort belongs.
What actually predicts risk
Four questions do most of the work, and they can be answered before any questionnaire goes out:
- What data does it touch? Personal, special category, financial, credentials, source code.
- What access does it have? Read-only API, write access, admin privileges, network access, OAuth scopes into your identity provider.
- What breaks if it disappears tomorrow? Not the vendor's marketing claim — your actual dependency.
- Who else is behind it? Sub-processors, and where they are.
The fourth is the most under-asked and the most frequently painful. Supply chain compromise reaches you through your vendor's vendor.
Evidence to request — and how to read it
| Artefact | What it proves | The catch |
|---|---|---|
| ISO 27001 certificate | A managed security programme exists | Read the scope statement. It frequently excludes the product you are buying |
| SOC 2 Type II report | Controls operated effectively over a period | Check the period is current, and read the exceptions section, not just the opinion |
| Penetration test summary | Independent technical testing occurred | Check date, scope and whether findings were remediated and retested |
| Sub-processor list | Onward data flow | Should be public and change-notified |
| DPA | Lawful basis to process on your behalf | Check it covers sub-processors and international transfers |
| Business continuity / DR evidence | Recovery is planned and tested | A plan that has never been tested is a document, not a capability |
| Cyber insurance | Financial backstop | Confirms nothing about security quality |
A vendor who provides a SOC 2 Type II with a clean opinion and a current scope has told you more than one who answers 200 questions with "yes".
Contract terms that matter more than the questionnaire
Questionnaires capture a moment. Contracts govern the relationship.
- Breach notification with a specific timeline — must be short enough to let you meet your own 72-hour regulatory obligation
- Right to audit, or acceptance of pooled/third-party audit
- Sub-processor notice and right to object
- Data location and change notification
- Deletion and return on exit, with a defined timeline
- Security incident cooperation at no extra cost
- Liability that is not capped at one month's fees for data breaches specifically
- Service levels with remedies, not aspirations
That liability point is worth pushing on. A cap of one month's subscription fee against a breach of your entire customer database is a term many buyers sign without reading.
Ongoing, not one-off
Assessment at purchase and never again is the norm, and it is where risk accumulates. Minimum viable ongoing programme:
- Annual re-review for critical vendors; refresh attestations
- Trigger-based review on: security incident, acquisition, material change of sub-processors or data location, change in the data you send them
- Maintain a live register — vendor, owner, tier, data types, access, contract dates, evidence expiry
- Track access decay — offboard integrations and API keys when a service is retired. Abandoned OAuth grants and API tokens are a persistent source of exposure
Red flags
- Refusal to name sub-processors
- No named security contact
- Attestation whose scope excludes the purchased service
- Requests for broader OAuth scopes or admin access than the function requires
- "We're SOC 2 compliant" with no report available under NDA
- Breach notification undefined or longer than 72 hours
- Any pressure to skip assessment because of a deal deadline
A workable process
- Business owner completes a short intake describing data, access and dependency
- Automatic tiering from that intake
- Tier-appropriate assessment — low tier is self-service and same-day
- Evidence review for critical and important tiers
- Contract clauses applied from a pre-approved playbook
- Register entry with owner, tier and review date
- Scheduled and trigger-based re-review
The single highest-value improvement most organisations can make is making the low tier genuinely fast. If the lightweight path takes a week, the business stops using it, and you lose visibility of exactly the long tail you were trying to see.
Frequently asked questions
How many questions should a questionnaire have?
For most vendors, 20–30 targeted questions plus attestation review outperforms a 200-question spreadsheet, because you will actually read the answers.
Can we accept a vendor's SOC 2 instead of our own assessment?
For most vendors, yes — that is what it exists for. For critical vendors, use it as the foundation and add targeted questions about your specific use, integration and data.
What about free tools staff sign up for themselves?
That is where most unassessed risk lives. Address it with identity-layer visibility (SSO and OAuth app reporting) plus a genuinely fast approval route, rather than a policy nobody follows.