Fideslang is an open privacy taxonomy, maintained as an industry standard by IAB Tech Lab, that gives you a standard vocabulary for describing personal data along three axes: what the data is (data categories), whose it is (data subjects), and what you do with it (data uses). Because it is developed through a standards process rather than as one product's schema, it separates the description of data from any particular tool or regulation, so a field annotated once as a contact email belonging to a customer, used for account management, can answer GDPR, CCPA and whatever comes next without being re-described. That portability is the whole argument for an open standard over a vendor's proprietary schema — your annotation work is the expensive part, and it should outlive your tooling.
The problem an open taxonomy solves
Every privacy tool needs to know what personal data you hold. Most of them ask you to describe it in their own schema. That description is genuinely expensive to produce — it requires walking your systems, making classification decisions, and getting them reviewed — and when it lives in a vendor's proprietary format, all of that effort is locked to the vendor.
It is also locked to one framing. A schema designed around GDPR concepts needs rework when you fall under a US state regime that carves up personal data differently. An open taxonomy separates the description from the regulation: you say what the data is, and the mapping to any given law is a separate, replaceable layer.
Fideslang is that kind of vocabulary. It is developed in the open and maintained by IAB Tech Lab — the non-profit standards consortium established in 2014 whose 700-plus member companies span publishers, agencies, brands and ad technology vendors, and whose other specifications include OpenRTB, ads.txt and the Global Privacy Platform. Fideslang forms the basis of that body's Privacy Taxonomy, so the terms you annotate against are governed by a standards process rather than by a product roadmap.
That governance is the part worth caring about, and it is a familiar argument if you have ever picked a data format. A standard maintained by a member consortium has a public specification, a versioned change history, a comment process and other organisations already implementing it. None of that guarantees the vocabulary is right for you, but it does mean the terms cannot be quietly redefined to suit one vendor's product, and that an annotation you make today remains legible to a tool you have not bought yet.
The three axes
Data categories — what the data is
A hierarchical classification of the data itself: contact information, government identifiers, biometric data, financial details, device identifiers and so on. The hierarchy matters because it lets you annotate at the depth you can justify. Classifying a column as contact information is useful; refining it later to a contact email address is an improvement, not a rewrite.
Data subjects — whose data it is
Who the data is about: customer, employee, job applicant, patient, child. This axis carries more weight than teams expect, because obligations attach to it. Data about a child triggers different requirements from the same data about a business contact, and special-category data under Article 9 is largely identified by the intersection of category and subject.
Data uses — what you do with it
The purpose: account management, personalisation, marketing, fraud detection, analytics. This is the axis most often left thin, and it is the one that matters most, because purpose is what an Article 30 record requires and what a lawful basis attaches to. A data map that says you hold email addresses but not what for cannot produce a register entry.
Annotating a real codebase
The instinct is to annotate everything and the result is that nothing gets annotated. A workable sequence looks like this.
- Start with the systems holding the most sensitive data — identity, payments, health, anything about children — rather than the easiest ones.
- Annotate at the coarsest level you can defend, then refine. A field classified as contact information today is worth more than a perfect classification you never finish.
- Get the data use right even when the category is coarse, because purpose is the field your register and your lawful basis actually depend on.
- Treat unannotated fields as visible debt with an owner, not as an invisible gap.
- Review classifications where category and subject intersect on special-category data, since that is where a wrong call has the largest consequence.
Where the taxonomy stops
Fideslang describes data. It does not decide whether your processing is lawful. Annotating a field as a contact email used for marketing tells you what a register entry should say; it does not tell you whether you have consent, whether legitimate interests survives a balancing test, or whether the retention period is defensible. Those are judgements, and the taxonomy's job is to make sure they are being made about an accurate description.
The specification and the vocabulary are published openly and maintained by IAB Tech Lab — see the fideslang specification and fideslang on GitHub — which is what makes it checkable rather than something you take on trust from a vendor.
How this feeds the rest of the programme
Once data is described in a shared vocabulary, several downstream artefacts stop being separate documentation exercises. The Article 30 register draws its categories, subjects and purposes from the annotations. Assessment scoping can key off sensitive intersections. Retention rules can be expressed against categories rather than against individual columns. Transfer records follow from where annotated systems are hosted.
If you want to see fideslang annotations turned into a live data map and register against your own systems, you can explore it at noru.tech.