Controller or processor: the question music tools get wrong

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

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. 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.

Two engineering notes from building ours. Every table read is individually defensive, so a missing table or a pre-migration column produces a partial export rather than an error, on the principle that a best-effort export beats a failure. And it never includes secrets or tokens, which is easy to get wrong when a table has a credentials column and the export is built by iterating tables.

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.

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, and the rule needs to live in one shared redaction path rather than in each developer's memory.

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, backed by a schema with no such column and a test asserting it, is a fact.