A vendor register for a supply chain review should list each outside service with what data it sees, whether it can change your code or infrastructure, why you use it, who owns the relationship, what you checked and when you will check again. Keep it to one table you can share.
Two kinds of vendor risk
Reviewers care about two different exposures, and a good register separates them.
- Data vendors. Services that store or process customer data: hosting, email, support tools, analytics, payment providers.
- Access vendors. Services that can change what you ship: source hosting, CI, package registries, deployment tools, build plugins, third party apps in your storefront.
Many vendors are both. A CI service reads your code and holds deploy credentials, so it belongs in both columns.
Fields to include
| Field | Why it matters |
|---|---|
| Vendor and service | The exact product, not just the company |
| Purpose | Forces a business reason |
| Data accessed | Categories such as customer contact data, order data, none |
| Code or infra access | Read, write, deploy, none |
| Owner | One named person |
| Authentication | Single sign on, MFA required, shared password |
| Evidence reviewed | Their public security page, report or terms, with the date you read it |
| Last review and next review | Shows the register is alive |
| Exit plan | How you would replace or remove it |
How to build it in a day
- Export the list of paid tools from your finance system. Add free tools your engineers use.
- Walk each repository and pipeline for registries, scanners, build plugins and deploy targets.
- For each vendor, fill the table. Mark unknowns honestly and assign someone to find out.
- Rank by access, not by spend. A cheap tool with deploy rights matters more than an expensive one with no data.
- Review the top group first: anything with write access to production code or broad customer data.
What to check on the vendor side
Read what they publish and note it with a date: security page, data processing terms, incident notification promises, where data is stored, and whether they support single sign on. Do not copy their claims into your own answers as if they were yours. Say "our vendor states" and keep the source.
Common gaps
- Free tools adopted by one engineer with company data in them.
- Former vendors still holding API tokens.
- Third party apps with admin scopes in the storefront.
- No owner, so nobody notices when the vendor changes terms or has an incident.
Keep it current
Review quarterly for high access vendors and yearly for the rest. When an incident hits a vendor, the register tells you in minutes whether you are exposed and who to ask.
For the related subject of subprocessor lists, see your subprocessor list is out of date.
Safeguard's asset discovery and compliance and evidence automation can help you see which packages, services and pipelines are actually in use, which feeds the register. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Do open source packages belong in the vendor register?
Track them in your dependency inventory instead, and reference it from the register.
How detailed should vendor evidence be?
Note what you read and the date. You do not need to audit each vendor, only show you looked.
Should we share the whole register?
Share a version with vendor names and purposes if your confidentiality terms allow, and keep internal notes private.
Last reviewed: 19 October 2026.
