A security questionnaire arrives. Question nine asks you to list every third party with access to customer data. You open package.json, then the AWS console, then the billing export from the company card, and after twenty minutes you realise those three sources disagree with each other and none of them answers the question.
This is one of the most common gaps on a small team, and it is not a tooling problem. It is that two different lists got collapsed into one. Your dependency manifest tells you what your code imports. Your vendor inventory tells you who can reach your data. Those overlap far less than people expect, and the second one is the list that gets asked for.
Here is how I would build and keep the second list on a team of ten to fifty engineers.
1. Two lists, two questions
Write the question at the top of each list so they stop drifting into one another.
The dependency list answers: what code runs inside our build and our runtime? It comes from package manifests, lockfiles, base images and an SBOM if you generate one. It is long, it is mostly automatable, and its risk is supply chain compromise and unpatched libraries.
The vendor inventory answers: which organisations outside this company can read, write or infer something about our customers' data, or can reach our production systems? It is much shorter, it is almost entirely manual, and its risk is somebody else's breach becoming your incident notification.
An npm package with no network calls is on list one and not list two. A support desk tool where agents paste customer records into tickets is on list two and will never appear on list one. Both matter. Only one of them shows up in your repository.
2. Start from data and access, not from procurement
The instinct is to ask finance for a list of software spend. Do it, because it is a useful cross-check, but do not start there. Free tiers, tools signed up for with a personal card, and anything integrated by an engineer in an afternoon will all be missing.
Start from the two things that actually define exposure.
Follow the data. For each place customer data lives, write down everything that reads from it: analytics pipelines, warehouses, BI tools, error trackers that capture request payloads, session replay, email and messaging providers, support tooling, any model or API you send text to.
Then follow the access. For each production system, write down every external party that holds a credential, a key, a webhook endpoint, an OAuth grant or a role in your cloud account. OAuth grants are the ones teams miss. Someone authorised a tool against the source control organisation in 2024, the tool is still installed, and nobody has looked at its scopes since.
Cross-check against three sources you already have: the billing export, the identity provider's list of connected applications, and the OAuth or installed-app list in source control and cloud. Where those three disagree, the disagreement itself is the finding.
3. Four facts per vendor, and resist adding a fifth
Inventories die from being too ambitious. Most teams build a twenty column spreadsheet, fill it in once, and never touch it again. Four columns survive.
What they hold or can reach. Not the marketing category. Write the actual data: customer email addresses, support ticket contents, production database read replica, nothing beyond aggregate counts.
How the access works. Federated through single sign on, a long lived API key, an OAuth grant with named scopes, or a human logging in with a shared password. This column tells you how hard revocation will be before you need to revoke anything.
Who owns it here. One named person, not a team. Ownership with no name attached means nobody renews the review and nobody notices the renewal invoice.
Whether it touches customer data. A plain yes or no. This is the column that turns a sixty row inventory into the eight rows you actually have to think hard about.
Everything else, including security certifications and contract dates, can live in the vendor's own folder. Keep it out of the row you need to be able to read at a glance.
4. Keep it where change already happens
A wiki page is where inventories go to get stale. Put the list in the place your team already touches when things change.
A file in a repository works well, as a CSV or YAML with one record per vendor, because it gets code review, it gets history, and a diff tells you exactly when a vendor appeared and who added it. You can lint it in CI: fail the check if a row is missing an owner, or if a row marked as touching customer data has no review date.
If the team will not accept a repository for this, use whatever system already holds onboarding and offboarding tasks. The requirement is not the format. It is that adding a vendor and updating the list are the same action rather than two, because any process where the second one is optional will drift within a quarter.
5. Make it a side effect, not a chore
Three hooks keep an inventory current with almost no standing effort.
Add it to the pull request template for anything that introduces a new outbound integration. One checkbox: new third party, inventory updated.
Add it to offboarding. When somebody leaves, the vendors they personally owned need a new named owner that week, otherwise you accumulate orphaned rows that nobody will claim later.
Add it to the quarterly access review you are probably already doing for humans. Walk the OAuth grants and installed applications in the same sitting. The question for each is not whether the tool is good. It is whether anyone still uses it, and whether its scopes still match what it does.
Baseline control sets treat supplier relationships as a control with a register behind it, so if you want a reference for the shape an assessor expects, IRM's free ISO 27001 gap assessment walks the supplier controls alongside the rest.
6. The subset that becomes public
Some of your vendors are subprocessors: third parties that process customer data on your behalf. If your customer contracts or your own public commitments say you will publish and maintain a subprocessor list, that published list is a subset of this inventory, and it is the subset with an external audience and a change notification obligation attached by contract.
Practically, that means one more column on the rows where the customer data answer is yes: is this vendor on the published list? A vendor that handles customer data and is not on the published list is either an omission to fix or a decision somebody made and should be able to explain. Both are better found by you than by a customer's legal team.
7. Reviews that are not questionnaire theatre
Sending every vendor a two hundred question assessment produces paperwork and very little signal, and a small team cannot sustain it anyway. Tier instead.
For vendors that hold customer data or can reach production, do the real work: read their current audit report or certification scope rather than the badge on their homepage, check that the scope actually covers the product you use, and note their breach notification commitment and your own exit path if they fail.
For everything else, record the four facts and move on. An inventory that is complete and shallow is worth more than a deep one covering a third of your vendors, because the gap in the deep one is invisible and the shallow one at least tells you where to look.
8. Test it from outside
Pick a vendor at random from the list and try to prove the row is true. Can the named owner confirm it? Does the access work the way the column says? If the row claims single sign on, log out and see whether a direct password login still works.
Then run the questionnaire exercise deliberately. Take the last customer security questionnaire you received and answer the third party questions from the inventory alone, with no searching and no asking around. Whatever you cannot answer in five minutes is the part of the list that does not exist yet. That is a cheap afternoon and it is the only honest test of whether the inventory describes your company or describes your intentions.
About IRM's Virtual CISO services
Disclosure first, so you can weigh the advice accordingly: this post comes from IRM Consulting & Advisory, and the links in it point to our own pages.
A third party inventory is one of the things a virtual CISO engagement exists to own. It is unglamorous, it never finishes, and it sits in the gap where most small companies have no one accountable: too much work for an engineering lead who already has a roadmap, not enough to justify a full time security hire. That gap is the whole reason the role exists in a fractional form.
IRM Consulting & Advisory provides virtual and fractional CISO services to small businesses, startups and SaaS companies across Canada and the United States. Half built vendor inventories are one of the most common findings when we start an engagement, which is why this post exists.
One question, because the answers vary a lot: when you find an OAuth grant nobody can account for, do you revoke it immediately and see what breaks, or do you chase down an owner first? Both go badly in different ways, and it is worth knowing which way your team would lean before it happens.
Top comments (0)