A vendor risk register should record, for each supplier, the business owner, what the vendor does, what data and access it has, its tier, the evidence you hold with dates, open gaps with decisions, contract end date and the next review date. Keep it short enough that people actually update it.
Fields grouped by purpose
| Group | Fields | Why |
|---|---|---|
| Identity | Legal name, product, website, parent company | Avoids confusion after acquisitions |
| Ownership | Business owner, security contact, vendor contact | Someone answers when it matters |
| Purpose | What it does for you, which teams use it | Defines the scope of the assessment |
| Exposure | Data types, volume, access to systems, integrations | Drives the tier |
| Tier | Tier and the reason | The reason outlives the people |
| Evidence | Documents, issue date, expiry, who reviewed | Shows freshness |
| Gaps | Open issues, decision, compensating controls | Records accepted risk |
| Contract | Start, renewal, notice period, security clauses | Lets you act before renewal |
| Review | Last review, next review, triggers | Makes it a process |
Fields people forget
- Subprocessors and fourth parties. Who does the vendor rely on that could affect you? See fourth party risk explained.
- Exit plan. How you would get data out and what you would use instead.
- Integration list. Which of your systems connect to the vendor, and with what credentials.
- Data location. Where the data is stored and processed.
- Incident contact path. The real route to a human at the vendor on a bad day.
Keep it honest
A register full of stale rows is worse than none, because it gives false comfort. Three habits help.
- Give each row a named owner, not a team alias.
- Show the age of the evidence next to the row, so old rows stand out.
- Review the register when contracts renew, since that is when you have leverage.
Where the data comes from
Start from finance and identity records, not memory. Payments show who you pay, and your identity provider shows which apps staff sign in to. Together they catch many tools nobody listed. Sources for a SaaS app inventory covers this in more depth.
One row, as an example
| Field | Example entry |
|---|---|
| Vendor | Example Analytics Ltd (placeholder) |
| Owner | Head of Marketing |
| Exposure | Customer email addresses, read only API key |
| Tier | 2, because it holds personal data but no production access |
| Evidence | Audit report dated this year, data processing agreement signed |
| Gap | No stated breach notice period, accepted until renewal |
| Next review | Six months before contract end |
Quick check
Should every tool be in the register?
Every vendor with data or access should be. Tools with no data, no access and no integration can sit in a lighter list, as long as you can show how you decided that.
Who should own the register?
Security or risk usually maintains it, but each row needs a business owner who answers for the vendor.
Safeguard's asset discovery and compliance evidence automation can help you collect the inputs for a register, and a free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
