Data Controller

Personal data in a single product rarely passes through only one company. Signup records sit in your database, that database runs on a cloud provider somewhere overseas, notification emails go out through a sending service, and support tickets land in an outsourced help desk. One row of data touches four companies.

When something goes wrong in that arrangement, everyone points sideways. The cloud provider says it rented out storage. The email vendor says it sent the list it was handed, exactly as instructed. The company that built the product says it never touched the data directly. Meanwhile the person whose data leaked has no idea who to take it up with — all four say they did their part, and none of them is holding the bag.

So the rules anchored responsibility to the head that decides rather than the hands that touch. Whoever determined why this data would be collected, what it would be used for, and when it would be deleted is the data controller, and responsibility stays there. Someone else running the servers and sending the mail doesn't move it. The person affected only has to know about that one position; how the companies settle it among themselves is a contract problem, not theirs.

There's a single test: did you decide the purpose and the means? A party working inside a scope someone else set, doing only what it was told, is a data processor. The party that decided what the data is for and how it gets used is the controller. Whether you personally touched the records is not part of the test.

A few cases make the line visible.

1. Signup records for your own product. You set the purpose, so you are the controller — including when the storage sits with an overseas cloud provider.
2. A customer's employee list that you handle on their behalf. Your customer set the purpose, so on that data you occupy the processing side.
3. Job applicant records. You set the purpose there too, separately from anything users do, so you're the controller again. It's the case teams focused on the product forget, which is how resumes from two years ago end up still sitting in a shared drive.

Standing in this position brings a bundle of obligations with it. You need a lawful basis before you process anything (such as consent); you publish what you collect and how you handle it in a privacy policy; you collect only what the purpose requires (data minimization); you delete once the retention period you set has passed; you answer a data subject within the legal deadline when they ask to see or erase their data; and you file a breach notification when data gets out.

Work handed to someone else still comes back here. If a vendor processing on your behalf makes the mistake that leaks the data, notifying the affected people and filing with the regulator is still the controller's job. What delegation buys you is not transferred liability but contractual limits: a narrow instruction scope, a ban on sub-contracting without permission, and a duty to tell you immediately when something goes wrong.

You meet this term in documents before you meet it as a concept, because which company's name goes in a given field is the same question as who carries the responsibility.

1. The opening of a privacy policy. It names the controller and the contact point for inquiries. That field is the address where user requests arrive.
2. A data processing agreement. The first clauses separate which side is the controller and which is the processor. Written loosely, it becomes the thing two companies argue about after an incident.
3. A breach filing. The controller goes in the filing-party field. The company that rented you servers doesn't file on your behalf, and the filing carries your name even when the cause sat on their side.
4. Consent screens. The sentence explaining who is receiving this data and for what purpose names the controller.
5. Compliance outside your home market. The European regime splits the deciding party from the acting party the same way, so a product with European users has to work out which side it lands on under those rules too.

"We're the controller here. Putting it in the cloud doesn't make it their responsibility."

Where the data is stored and who answers for it are separate questions.

"On the customer's employee list they're the controller and we're the processor. The contract says so."

The same company sits on different sides depending on which dataset is in question.

"We're the controller for applicant records too, and nobody's set a retention period for those."

Data outside the product is where the rules usually turn out to be missing.

Pagedeck first worked this out while reviewing an enterprise contract. The draft named Pagedeck as the controller across the board, but for the employee accounts a customer creates and uploads, the customer sets the purpose. Grace caught it, and the clause was rewritten to assign the roles dataset by dataset.

That split the day-to-day work in two. Pagedeck's own signup data is ours to control, so Mia sets the retention period and the deletion procedure for it. Customer employee data puts us on the processing side, so Theo deletes it when the customer asks and never uses it for anything they didn't ask for. Two datasets sitting on the same servers now run under different rules.

The most common misreading is that you aren't a controller unless you run the servers yourself. The word processing sounds like storing and transforming, which makes the assumption easy. The test is decision, not handling. A company with no servers at all, running entirely on third-party services, is still the controller of the data it decided to collect. Getting this backwards leads to comfort in a liability clause in a vendor contract — until the day of an incident, when it turns out the filing obligation was yours all along.

The other is reading the named individual inside the company as the controller. Privacy policies list a person and their contact details, so it looks that way. The position belongs to the company; the named person is the channel that receives requests. Blur the two and the role empties out when that person leaves, and months pass with no working address for requests. Knowing the company holds it, not the individual, is what makes a team update the document when the contact changes.