Do I need a Data Processing Agreement (DPA) with AudD?

An Article 28 DPA is required when a processor processes personal data on a controller's behalf. When the audio that reaches AudD is anonymous for AudD, that requirement is not triggered — a position consistent with the CJEU's EDPS v SRB judgment. AudD offers a DPA to enterprise customers, for a fee, for organizations whose compliance frameworks require one. This is general information, not legal advice.

Where does AudD process audio?

AudD uses various infrastructure providers located in and outside Europe, including AWS, Google Cloud, Azure, OVHcloud, and others.

Does AudD keep or train on the audio I send?

For enterprise customers, AudD offers a separate data processing agreement (outside the GDPR framework) confirming that audio is removed immediately after processing, that industry-standard security practices are used, and that AudD does not train models on customer audio. Contact api@audd.io.

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

Q: Is audio sent to AudD personal data under the GDPR?

Usually not, in AudD's hands. An API request contains the audio, your API token, and recognition settings — nothing about your users — so AudD has no reasonable means to link an excerpt to an individual, and its processing matches audio against a music catalog rather than identifying speakers. Under the GDPR's identifiability test and the CJEU's EDPS v SRB judgment (C-413/23 P), data that a recipient cannot reasonably link to a person is not personal data for that recipient.

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:

Name AudD in your privacy notice as a recipient of audio excerpts, as part of your ordinary transparency disclosures.
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 [email protected].

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 [email protected].

A practical checklist

Assess your side. Decide whether the excerpts you send (or their embedded metadata) are linkable to individuals in your systems.
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.
Disclose. Name AudD as a recipient in your privacy notice.
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.
Enterprise needs. If you require a DPA or contractual data-handling assurances (immediate deletion, no training), ask [email protected].

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 and Recital 26 — identifiability and anonymous information
Article 28 GDPR — processors and DPAs
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)

Related