---
title: "GDPR and music recognition: is the audio you send personal data?"
description: "How the GDPR applies when you send audio excerpts to a music recognition API — the identifiability test, when a DPA is and isn't needed, where AudD processes audio, and the assurances available to enterprise customers."
slug: "/resources/articles/gdpr-music-recognition"
section: "articles"
keywords: [audd, gdpr, music recognition api, personal data, data processing agreement, dpa, audio privacy, edps v srb]
---

# GDPR and music recognition: is the audio you send personal data?

Teams integrating music recognition into a product that serves European users
usually reach the same three questions: is the audio we send personal data, do
we need a Data Processing Agreement, and where does the audio go?

The short version: **an AudD API request contains the audio itself, your API
token, and recognition settings — nothing about your users.** There is no
field for user identifiers, and the processing identifies music, not people.
That single design fact drives most of the GDPR analysis below: what AudD
receives is, in the ordinary integration, anonymous in AudD's hands. This
article sets out the reasoning and what AudD offers at each tier.

One thing before the details: this is general information about how we
understand the law and run the service — it is **not legal advice**. Your
obligations depend on what data you hold and how your product works, so assess
your own position or ask your counsel.

## What music recognition does with audio

It helps to be precise about the processing, because the GDPR's answers turn
on it. When you send an audio excerpt to the AudD API, the service computes an
audio fingerprint and matches it against a music catalog. The output is song
metadata — artist, title, album, label. The processing identifies music,
not people:

- There is no speaker identification, voice profiling, or diarization.
- No voiceprints or biometric templates are created. Biometric data under
  Article 9 GDPR arises from processing "for the purpose of uniquely
  identifying a natural person" — matching audio against a song database is
  not that.
- The standard endpoint analyzes a short excerpt (up to about 12 seconds of
  audio per recognition).

## Is the audio personal data? The identifiability test

Personal data is information relating to an **identified or identifiable**
person (Article 4(1) GDPR). Recital 26 makes identifiability practical rather
than theoretical: what counts is the means **reasonably likely to be used** to
identify someone. Information nobody can reasonably link to a person is
anonymous, and the GDPR does not apply to it.

The Court of Justice of the EU has confirmed that this test is **relative to
who holds the data**. In *Breyer* (C-582/14) it held that identifiability
depends on the means reasonably available to the party in question. In *EDPS v
SRB* (C-413/23 P, September 2025) it went further: data that is personal data
for the organization that collected it can be not personal data at all in
the hands of a recipient who has no reasonable means of linking it to anyone.

Applied to music recognition:

- **In AudD's hands**, a short audio excerpt sent without any linked
  identifying information — no names, account identifiers, or embedded
  metadata pointing at a person — is anonymous. AudD receives audio bytes and
  returns song metadata; it holds nothing to link an excerpt to an
  individual, and its processing does not try to. A voice on its own, with no
  other linked identifying information, should not be considered personal
  data under the GDPR.
- **What reaches AudD is the audio, not your user data.** An API request
  carries the audio (or a URL to fetch it from), your API token, and
  recognition settings — which metadata to return, how much of a file to
  scan. None of the parameters are about people, and there is no field for
  user identifiers. Unless you embed identifying information yourself, in
  tags or filenames, AudD receives nothing that could link an excerpt to a
  person.
  The same excerpt may still be personal data in your systems, where it
  sits next to accounts and user metadata — which is why we ask integrators
  directly: *could the audio excerpts (or the metadata embedded in them) that
  you upload be linked to individuals?*

The practical consequence of the relative test: keep the request that way.
Send the audio itself — strip embedded tags, keep identifiers out of
filenames — and what AudD receives is anonymous for AudD even when the same
recording is personal data for you.

## What this means for DPAs

Article 28 GDPR requires a Data Processing Agreement when a processor
processes **personal data** on a controller's behalf. When the audio that
reaches AudD is anonymous for AudD, that trigger is absent — the recipient is
not processing personal data, so there is nothing for an Article 28 contract
to govern. This is the position the CJEU's *EDPS v SRB* judgment supports: the
SRB passed pseudonymized data to a consultancy without a DPA, and the court
held the data was not personal data in the recipient's hands.

We agree with that approach, and in the ordinary case we don't consider a DPA
necessary for using the API. The straightforward setup is:

1. **Name AudD in your privacy notice** as a recipient of audio excerpts, as
   part of your ordinary transparency disclosures.
2. **Send audio that is anonymous for us** — the excerpt itself, stripped of
   embedded metadata and not accompanied by user identifiers.

For organizations whose compliance frameworks nevertheless require a signed
DPA — common in larger enterprises — **AudD offers a DPA to enterprise
customers, for a fee**. Contact [api@audd.io](mailto:api@audd.io).

## Where the audio is processed

AudD uses various infrastructure providers located in and outside Europe —
AWS, Google Cloud, Azure, OVHcloud, and others. If the audio you send is
anonymous in AudD's hands, the GDPR's international-transfer rules (Chapter V)
do not attach to it for AudD's processing; your own transfer analysis, as
ever, depends on your own data.

## Data handling assurances for enterprise customers

Separately from the GDPR framework, enterprise customers can sign a data
processing agreement with AudD that confirms how audio is handled as a matter
of contract:

- audio is **removed immediately after processing**;
- **industry-standard security practices** protect data in transit and during
  processing;
- AudD does **not train models on customer audio** or retain it for any
  other purpose.

If your security review or vendor-assessment process needs these assurances
in writing, contact [api@audd.io](mailto:api@audd.io).

## A practical checklist

1. **Assess your side.** Decide whether the excerpts you send (or their
   embedded metadata) are linkable to individuals in *your* systems.
2. **Strip what AudD doesn't need.** Send the audio bytes; drop ID3 tags and
   other embedded metadata, and keep user identifiers out of filenames and
   request parameters. The SDKs send only what you pass them.
3. **Disclose.** Name AudD as a recipient in your privacy notice.
4. **Short excerpts.** The standard endpoint analyzes up to ~12 seconds of
   audio per recognition — send the excerpt, not the whole recording, when
   recognition is the goal.
5. **Enterprise needs.** If you require a DPA or contractual
   data-handling assurances (immediate deletion, no training), ask
   [api@audd.io](mailto:api@audd.io).

## FAQ

**Is audio sent to AudD personal data under the GDPR?** Usually not in AudD's
hands: the API request contains the audio, your API token, and recognition
settings — nothing about your users — so the excerpt is anonymous for AudD
under the identifiability test, and AudD's processing identifies music, not
people.

**Do I need a DPA with AudD?** Article 28 requires a DPA for processing
personal data; when what reaches AudD is anonymous for AudD, that requirement
is not triggered — consistent with the CJEU's *EDPS v SRB* judgment. If your
compliance framework requires one anyway, a DPA is available to
enterprise customers for a fee.

**Where is the audio processed?** On infrastructure in and outside Europe:
AWS, Google Cloud, Azure, OVHcloud, and others.

**Is the audio kept, or used for training?** Enterprise customers can sign a
contractual agreement confirming immediate removal after processing,
industry-standard security, and no training on customer audio.

**Is this legal advice?** No. It describes how AudD understands the law and
operates the service. Assess your own obligations or consult counsel.

## Sources

- [Article 4(1) GDPR — definition of personal data](https://gdpr-info.eu/art-4-gdpr/)
  and [Recital 26 — identifiability and anonymous information](https://gdpr-info.eu/recitals/no-26/)
- [Article 28 GDPR — processors and DPAs](https://gdpr-info.eu/art-28-gdpr/)
- CJEU, *Breyer v Germany*, C-582/14 (2016) — identifiability is assessed
  against the means reasonably available to the party holding the data
- CJEU, *EDPS v SRB*, C-413/23 P (4 September 2025) — data can be personal
  data for the sender and not for a recipient with no reasonable means of
  identification ([court press release](https://curia.europa.eu/site/upload/docs/application/pdf/2025-09/cp250107en.pdf))

---

**Related**

- [Music recognition API pricing](/resources/articles/music-recognition-api-pricing)
- [Detect copyrighted music in user-generated content](/resources/articles/detect-copyrighted-music-in-user-generated-content)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [API reference](https://docs.audd.io)