The Taxonomy the DSA Already Requires You to Build

The DSA does not use the word “taxonomy.” It requires one anyway, and most platforms building trust-and-safety programmes are meeting that requirement by accident, if at all.

Article 15 of the Digital Services Act is framed as a transparency-reporting duty, and most compliance guides treat it that way — publish a report, once a year, on your content moderation. Read the actual requirement and it is more specific than that. Providers must categorise their moderation activity by the type of illegal content or terms-of-service violation involved, by the detection method that surfaced it, and by the type of restriction applied. That is three axes of classification, applied consistently, across every moderation action a platform takes. It is a harm taxonomy, legally mandated, hiding inside a reporting article.

Since 1 July 2025 that taxonomy is no longer even yours to invent. An Implementing Regulation standardised the content-moderation categories and keywords across the industry, aligned to the same categories used in the DSA’s public Transparency Database, so reports are comparable provider to provider. The first harmonised reports under the new template were published in February 2026. There is now a canonical schema to build against, not a blank page — and most membership platforms, marketplaces and community products I look at have never structured their moderation data to match it.

Why the obligation is proportionate, not just for VLOPs

It is easy to read DSA coverage and assume this only touches the giants — the systemic risk assessments, the independent audits, and the crisis-response mechanisms are genuinely VLOP-and-VLOSE-only, reserved for services above 45 million EU monthly users. Article 15’s transparency reporting is not in that tier. It applies to intermediary services generally, scaled proportionately to size. A membership platform, a niche marketplace, or a community product with a fraction of a VLOP’s user base still has to publish structured, categorised reporting on the moderation it performs. The bar is lower than a VLOP’s, not absent.

Where the taxonomy actually breaks

In most trust-and-safety stacks I encounter, categorisation was added after the moderation tooling, not designed alongside it. A queue gets built to triage reports; someone adds free-text tags for “spam,” “harassment,” “scam,” “other” as operational shorthand; and eighteen months later, someone is asked to produce a DSA transparency report and discovers the operational tags do not map cleanly to “illegal content” versus “terms-of-service violation” — a legal distinction the regulation actually cares about — or to a consistent detection-method field, because half the historical actions never recorded how the issue was found.

The result is the same fire drill I describe everywhere else on this site: a report assembled by hand, close to the deadline, by someone reconciling inconsistent historical data against a schema the operational team never used day to day. The taxonomy exists somewhere in someone’s head. It was never in the data model, so it cannot be queried.

Designing it the right way round

The fix is to treat the three DSA axes — violation type, detection method, restriction type — as the spine of the trust-and-safety data model from the start, not as a reporting overlay bolted on afterward. Every moderation action, automated or human, records against all three, using the terms the Implementing Regulation already standardised rather than a bespoke internal vocabulary that has to be mapped at report time. Build it this way and the annual transparency report becomes a query against clean data instead of a project. Build the violation taxonomy with enough granularity to distinguish, say, CSAM-adjacent content from ordinary spam — categories that carry very different legal and operational weight — and the same structure that satisfies the regulator also gives the trust-and-safety team a genuinely useful operational picture of what is actually happening on the platform, which most ad hoc tagging schemes never quite deliver.

This is the same discipline that runs through every regulation on this site: the obligation defines what must be provable, and only a data model built to carry that obligation can produce it on demand. The DSA’s harm categories are simply an unusually explicit case — the regulator wrote the taxonomy’s top level directly into the implementing act, which means there is less excuse than usual for building something incompatible with it.

The structural payoff for growing platforms

There is a second reason to get this right early rather than late. A platform that crosses the 45-million-EU-user threshold becomes a VLOP with no grace period for its data — systemic risk assessment, annual audits, and crisis-response obligations all assume the provider already has structured, categorised moderation history to assess risk against. A platform that built its harm taxonomy properly from day one, at whatever scale it currently sits, crosses that threshold with years of clean, queryable history behind it. A platform that never built the taxonomy crosses it and discovers the systemic risk assessment has no real data to run against — because the moderation history that should feed it was never structured to be assessed.

The underlying discipline is the same one covered in retrieval quality and classification generally — a harm taxonomy is a classification scheme with legal consequences.

If your moderation data cannot currently answer “how many actions, by category, by detection method, this reporting period” without a manual reconciliation, that gap is the finding. See the wider argument on why the data model comes before the tool, or the full evidence chain at evidence and assurance. A technology control assessment can map exactly where your moderation taxonomy and your DSA obligation currently diverge.