Controller or processor: the question music tools get wrong
A platform can be a controller for some data and a processor for the rest, and the distinction decides who answers a deletion request. Getting it clear before an audit, not during one.
Danny Starr
Co-founder, Backline · 8 June 2026 · 3 min read
In short
- Most analytics platforms are both: controller for their own users' account data, and processor for the customer data they analyse.
- The split decides who answers a request. A user asking about their own account is your responsibility; a question about a project's analytics belongs to the customer.
- Build the export around the split. A user's data export should include what they authored and exclude the customer analytics they merely had access to.
- Not holding fan personal data removes an entire category of obligation, which is why Backline measures in aggregate and stores none.
- Write the answer down in a document a customer can read, because the version invented under time pressure during an audit is always worse.
Data protection roles sound like paperwork until the first time somebody asks you to delete something and you have to work out whether that is your decision.
The question is whether you are a controller, deciding why and how personal data is processed, or a processor, acting on someone else's instructions. Most analytics platforms are both, for different data, and being unclear about which is which is what turns a routine request into a fortnight.
The split for a music analytics platform
Which role for which data
Illustrative| Role | Who answers a request | Examples | |
|---|---|---|---|
| Your users' account data | Controller | You do | Name, email, role, sign-in history, content they authored |
| A project's analytics | Processor | The customer does | Streaming, audience, ads, tickets, press, email totals |
| Documents a customer uploads | Processor | The customer does | Briefs, context notes, extracted text |
| Fan personal data | Neither, if you hold none | Nobody, because it does not exist | Names, emails, phone numbers, addresses |
Controller for your own users. The managers and label staff who hold accounts. Their name, email address, role, sign-in history, the content they authored. You decided to collect it, you decided what for, and you answer requests about it.
Processor for customer data. The analytics belonging to each project: streaming figures, audience geography, campaign performance, ticket totals. That data belongs to the customer. You process it on their instructions, under a data processing agreement, and requests about it are theirs to answer.
Neither, ideally, for fans. If the platform holds no fan personal data, there is no third relationship at all. Backline is built that way: every fan-side measurement is an aggregate count, so there is no fan record to disclose, export, delete or report on. This is the practical argument for the constraint discussed in analytics that never store fan personal data: the cheapest way to handle a category of obligation is not to be in it.
Why the split has teeth
Deletion requests. A user asking you to delete their account is a controller obligation you act on. A request to delete a project's analytics is a customer instruction, and acting on it unilaterally could destroy records the customer needs.
Access requests. A user is entitled to their own personal data. They are not automatically entitled to an export of a customer's analytics because they had access to it in your interface.
Sub-processors. As a processor you have to disclose who else touches the data and stay within what the agreement permits. Adding a vendor is not a purely technical decision.
Breach obligations. Who notifies whom, and in what timeframe, differs by role.
Build the export around it
The clearest test of whether you understand your own split is your data export.
A user export should contain their profile, their project memberships, the content they authored, their acceptances and their own security activity. It should not contain other users' records, and it should not contain the customer's project analytics, because that data belongs to the customer rather than to the person who could see it.
Backline holds both sides of that line as a guarantee rather than an intention. A user export contains everything that is theirs, complete, and never another person's records, a credential or a token. A customer export contains the project's own data in full, because the project's data belongs to the customer and leaving with it is part of the deal.
What a right-to-portability export includes
Illustrative- 1Include: the user's own profileIdentity and account fields you are controller for.
- 2Include: their project membershipsWhich projects and at what role, since that is a fact about them.
- 3Include: content they authoredTheir messages, notes and acceptances.
- 4Include: their own security activitySign-ins, password changes, two-factor events.
- 5Exclude: the customer's analyticsIt belongs to the customer, not to the person who had access to it.
- 6Exclude: other users' rows and every secretA Backline export never contains another person's records, a credential or a token.
What to write down
One document, readable by a customer, covering:
- Which data you are controller for, and which you are processor for.
- The lawful basis for the controller data.
- Retention for each category, in real numbers.
- Sub-processors, by name and purpose.
- How to make a request, and what happens.
- What happens when a source is disconnected: syncing stops, and stored data is deleted or de-identified.
- Where data is stored and transferred.
That last set of items is what customers actually ask about in procurement, and having it written removes weeks from an enterprise conversation. Backline publishes its processing terms, retention periods and named sub-processors as documents a customer can read before signing rather than after asking.
Practical habits
Do not put personal data where it does not belong. Campaign parameters, log lines, event property names. Those places are hard to clean and long-lived, so the rule has to be enforced in one place rather than remembered separately by everyone who touches the product.
Keep an activity trail. Administrative actions, context changes and account security events, appended and readable only by the people who need them. Auditors ask, and a trail built afterwards is not a trail.
Say what you do with reference to what happens, not to how you feel about it. A commitment to being careful is unverifiable. A statement that a specific field is never stored, in a product that has nowhere to put it, is a fact a customer can check.
Common questions
- Is an analytics platform a controller or a processor under GDPR?
- Usually both. It is controller for its own users' account data, which it decided to collect and holds for its own purposes, and processor for the customer data it analyses on the customer's instructions under a data processing agreement. The split determines who answers a deletion or access request.
- Should a user data export include the analytics they could see?
- No. An export should contain the user's own profile, memberships, authored content, acceptances and security activity. Project analytics belongs to the customer rather than to the individual who had access to it in the interface, and secrets or tokens must never be included.
- What difference does it make if a platform stores no fan personal data?
- An entire relationship disappears. With no fan personal data there is no third role to define, no fan-level access or deletion requests to handle, and no fan data in scope during a breach. Not holding a category of data is the cheapest way to meet the obligations attached to it.
Sources
- 1European Union, Reviewed August 2026. GDPR Article 28: processor obligations
- 2ICO (UK Information Commissioner's Office), Reviewed August 2026. Data controllers and data processors: what the difference is and what the governance implications might be
Danny Starr
Co-founder, Backline
Danny Starr is a co-founder of Backline and builds the platform. He writes about the data engineering behind music analytics: ingestion, identity, honesty in charts, and the AI layer on top of it.
Backline does this for the projects you run
Streaming, audience, social, advertising, website, search, ticketing and press data in one dashboard per project, with an AI assistant that answers questions about your own connected data. Invite-only.
Keep reading
Privacy and security
Music analytics that never store fan personal data
Every question a manager asks is answerable from counts and rates. How Backline measures streaming, ads, ticketing and press without ever holding a record about an individual fan.
Danny Starr · 4 min read
Choosing a platform
How to choose a music data analytics platform
A buying checklist for managers, labels and independent artists: the eight questions that separate a chart-tracking subscription from a platform you can actually run a project on.
Danny Angove · 5 min read
Audience
Deriving audience segments without any personal data
Backline derives named, actionable audience segments for a music project from aggregate data, each with a size, a confidence level and recommended actions, and no fan-level records anywhere.
Danny Starr · 4 min read