Ask a team of six how many external services touch their data and you will usually get a number somewhere around ten. The real answer is nearly always between twenty and forty.
The gap is not carelessness. It is that vendors arrive one at a time, each for a good reason, often on somebody's personal card during a busy week, and nothing in the process ever produces a list.
Building it is a genuinely useful afternoon, because three other things in this guide depend on it: offboarding cannot be completed without knowing where to remove someone, DPAs cannot be chased for vendors you have not identified, and a risk assessment that omits your dependencies is missing its most concrete rows.
Where the list actually comes from
Do not start from memory. Start from records, in this order.
The card statement
This is the single best source and the reason to do this quarterly. Pull the last twelve months of company card and bank statements and mark every recurring software charge. You will find things nobody has thought about in a year, and occasionally something nobody currently uses.
Annual subscriptions are the ones that hide, because they appear once and then not again for eleven months. A twelve-month window catches them; a three-month window does not.
Your identity provider
Google Workspace and Microsoft 365 both list third-party applications that have been granted access to your accounts. In Google: Admin console, Security, Access and data control, API controls, then Manage third-party app access.
This is frequently the most surprising list in the exercise, because it includes everything anyone ever authorised with "Sign in with Google", much of which was a one-off trial. Each entry is an application holding a token against your accounts.
Your own application
Every service your code calls. Read your environment variables and your dependency configuration: payment provider, mail sender, storage, error tracking, analytics, queue, search, SMS. If it has an API key, it is a vendor.
Your DNS and your source control
DNS records point at services: mail providers show up in MX records, verification tokens in TXT records, hosting in A and CNAME records. Source control integrations and installed apps are a similar list from another angle.
Ask the team
Last, not first, because memory is the weakest source. A single question in a channel, "what tools do you use for work that I might not know about", turns up the browser extensions, the note-taking apps and the free tier of something that has been quietly holding customer names for a year.
What to record
Six columns. More than that and the list stops being maintained.
- Vendor. The company name.
- What it does. One phrase.
- What data it touches. The important column. Customer personal data, customer content, employee data, billing data, or none of the above.
- Criticality. Would you be down without it? High, medium, low.
- Owner. Who inside your company is responsible.
- DPA status. Signed, not needed, or outstanding.
The data column is what turns a list of subscriptions into something useful. A project management tool holding only internal tasks and a support desk holding every message a customer has ever sent are very different exposures with similar monthly prices.
The ones that get missed
Consistent across nearly every team doing this for the first time:
- The free tier. No charge means no line on the statement. Free analytics, free error tracking and free form builders hold real data and have no billing trail.
- Browser extensions with access to internal pages. These never appear in any list and can read everything on screen.
- Anything a contractor introduced during a project and left running.
- Your vendors' vendors. Your email provider has subprocessors. You cannot enumerate the whole chain and you should know the first layer for your critical vendors, which their subprocessor page will tell you.
- The tool used once for a migration that still has database credentials.
That last category is worth a specific search. Anything that ever needed production access and is no longer used is a credential you should revoke, which connects directly to key rotation.
Classifying what each vendor can actually see
The data column is the one that makes the list useful, and it repays being more precise than a yes or no.
Four levels cover most cases, and sorting by them tells you where to spend attention:
- Full customer content. They can read what your customers wrote or uploaded. Support desks, email providers, storage, anything processing documents. Highest exposure, because the data is both personal and unpredictable in what it contains.
- Customer identifiers. Names, email addresses, account identifiers, but not content. CRMs, billing, most analytics that identifies individuals.
- Aggregate or pseudonymous. Counts, events, sessions with no direct identifier. Lower exposure, and worth confirming rather than assuming: several analytics tools collect more than teams expect by default.
- Internal only. Your own operational data and nothing about customers.
The middle two are where people guess. If you are unsure what a vendor receives, the reliable way to find out is to look: open the tool and read an actual record, or check what your code sends. A tool configured years ago may be collecting more than whoever set it up intended.
Keeping it current
The list decays quickly, because adding a vendor takes two minutes and updating a register takes deliberate effort.
Two habits keep it alive without ceremony. First, tie the review to the card statement: whoever reconciles the month's charges checks new software lines against the register. Second, make adding a vendor part of the act of signing up rather than a later task. A shared document takes thirty seconds to update at the moment of decision and is nearly impossible to reconstruct six months later.
Our vendor and DPA register does this in the browser, with export to CSV or Markdown and nothing uploaded anywhere. A spreadsheet is entirely fine too. What matters is that it exists and somebody looks at it four times a year.
What the finished list gives you
Beyond answering the questionnaire, three concrete things.
A completable offboarding process. "Remove them from everything" is not actionable. A list makes it a checklist.
A DPA gap list. Sort by the data column and every vendor touching customer personal data without a signed agreement becomes visible in one glance. That subset is the work.
A concentration check. Sorting by criticality shows where a single vendor's bad week becomes yours, which is a set of rows for your risk assessment that nobody has to invent.
Start with the statement
If the whole exercise feels large, do one thing: open twelve months of card statements and write down every software charge. That alone gets you most of the way, takes about twenty minutes, and produces the first honest answer most teams have ever had to the question.