A vendor register is only as good as the questions it can answer under pressure. When a regulator, an auditor, or a data subject asks who processes personal data on your behalf, for what purpose, and on what legal footing, a spreadsheet of company names will not survive the follow-up questions. The register that holds up is the one built around purposes and categories, kept honest by a repeatable discipline. Here is how to structure it so your DPO can defend it, line by line.
Start from purposes, not from logos
Most registers begin as a list of tools: the analytics platform, the CRM, the email service, the chat widget. That framing fails the moment someone asks why a given vendor touches personal data at all. Under the GDPR, processing must be tied to a specific, explicit and legitimate purpose, so the register should be organised the same way.
For each vendor, record the purpose in operational language: "measure campaign attribution", "deliver transactional email", "detect payment fraud". A single vendor can serve several purposes, and each one deserves its own line, because each may carry a different legal basis and a different retention rule. When purposes are explicit, gaps become visible. A tag that fires on every page but maps to no declared purpose is not a mystery to investigate later; it is a finding.
Categories of data and categories of people
Two axes turn a vendor list into a defensible record: the categories of personal data involved, and the categories of data subjects affected.
- Data categories: identifiers, contact details, device and network data, behavioural or usage data, financial data, and any special category data under Article 9 (health, biometrics, and so on). Special categories should be flagged loudly, because they change your risk posture and your documentation obligations.
- Subject categories: prospects, customers, employees, job applicants, website visitors. The same vendor may process very different populations, and a data subject request needs to resolve to the right rows quickly.
This is also the structure that Article 30 records of processing expect, so a register built this way feeds your wider accountability documentation instead of duplicating it.
Legal basis, transfers and retention on every row
Three fields separate a register that reassures from one that alarms:
- Legal basis: consent, contract, legitimate interest, legal obligation. If the basis is consent, the register should point to how and where that consent is captured, because a vendor that loads before consent is a live compliance problem.
- International transfers: where the data actually goes and under what mechanism (adequacy decision, standard contractual clauses, supplementary measures). Post-Schrems II, "the data stays in the EU" is a claim that needs evidence, not an assumption.
- Retention: how long the vendor keeps the data and what happens at the end of the contract.
A useful shape for the core of the register looks like this:
| Field | Example |
|---|---|
| Vendor / processor | Analytics provider |
| Purpose | Campaign attribution |
| Data categories | Device data, behavioural data |
| Subject categories | Website visitors |
| Legal basis | Consent |
| Transfer mechanism | SCCs + supplementary measures |
| Retention | 14 months |
The discipline that keeps it true
A register decays the day it is signed off. New tools arrive through marketing, product, and support teams who never see the DPO. Sub-processors change without notice. The document that was accurate at audit time drifts within weeks, and drift is precisely what regulators probe.
Three habits keep it honest:
- Reconcile declared against observed. The register says which vendors should be present. What actually loads in the browser, including tags injected by tag managers and sub-processors pulled in by your first-party vendors, is the ground truth. The two lists must be compared on a schedule, not once a year.
- Assign an owner per row. Every vendor needs a named internal owner who can answer for the purpose and the contract. Orphaned rows are how registers rot.
- Log the changes. When a vendor is added, removed, or re-scoped, capture who, when, and why. That change history is often the most persuasive artefact you can show, because it demonstrates a process rather than a snapshot.
Where tooling earns its place
Manual reconciliation does not scale past a handful of pages. This is where continuous third-party monitoring helps: Seqlense GDPR renders your live pages in a real browser, captures the full network waterfall, and matches every detected host against your declared vendor register, raising a drift alert the moment an undeclared tag ships. The register stays the source of truth; the tooling keeps reality lined up with it and gives your DPO a timestamped trail to point to.
A vendor register your DPO can defend is not a longer spreadsheet. It is one organised around purposes and categories, carrying legal basis, transfers and retention on every row, and maintained by a discipline that treats drift as the default and reconciliation as routine. Build it that way and the hard questions become easy to answer, because you asked them of yourself first.