Data Processor

As outsourcing became normal, the party deciding what happens to personal data split away from the party actually touching it. Company A collected the member list, vendor B sends the email using it, and a third company runs the servers the list sits on. One user's email address passes through three companies.

That made it unclear who to hold accountable after an incident. The leak happened at vendor B, so B looks like the answer — except the user has never heard of B. They signed up with A, and they never agreed to have their data handed anywhere. Flip it around and make B carry everything, and A can throw its list at whichever vendor is cheapest and walk away. Price wins every selection, and lists drift toward the places least equipped to guard them.

So the anchor was placed on the party that decides rather than the party that touches. The data controller, which decided what to collect and why, carries the responsibility toward the user, and the party taking instructions and doing the actual processing gets its own seat as the processor. A processor can't change the purpose on its own judgment, and in exchange it isn't the one facing users after an incident. The design fixes accountability at a single address.

Three constraints come with the processor seat.

1. Process only within instructions. Hired to send email, you send email. Promoting your own service to that list, or blending it with another customer's data to produce statistics, falls outside. Do it and you have set a purpose yourself, which moves you into the controller seat and brings responsibility toward those users with it.
2. Don't sub-contract freely. Passing the work to another vendor requires advance notice and approval, or at minimum a published list. The point is to prevent a situation where a company the client has never heard of is reading the list.
3. Return or delete at the end. Data still sitting there after the contract ends is personal data held with no basis at all. Sending proof of deletion back to the client is the normal practice, and backups are the part teams usually forget, since a copy erased from the live database is still sitting in last month's snapshot.

Which seat someone occupies is decided by who sets the purpose. Touching the data isn't the test. Someone else can run your servers and you are still the controller if you decided what to collect.

One company often occupies both seats at once. A collaborative document service is a processor for the documents and account details its customers' employees upload, because the customer decided why that data is handled. At the same time it's a controller for the email addresses and payment details of people who signed up directly. Both sets live in the same servers, so the company has to be able to tell which request belongs to which seat. A deletion request from a free-plan user is its own decision to make; the same request from an employee at a customer company is the customer's decision to make.

Four places where the distinction actually changes the work.

1. Contracts. A data processing agreement (DPA) is the procedure that fixes this seat in writing — the fields transferred, the scope of instructions, and the notification window all go in it.
2. Public disclosure. The privacy policy lists who you entrust data to and for what. Change vendors and the list changes.
3. Incident response. When a leak happens at the processor, notification travels through the client to the users. The processor doesn't contact them directly, because it isn't the party those users have a relationship with.
4. User requests. When something like a right to erasure request arrives at the processor, the processor routes it to the client instead of deciding. Whether to delete isn't within its authority.

Companies selling business software meet this distinction during sales. Customer security questionnaires ask which seat you occupy, who your sub-vendors are, and how you handle a vendor assessment. Answering those takes a written record of where each kind of data goes, which is why the question usually lands back on the product team.

"We're the processor here. The customer set the purpose."

Confirmation that the final address for responsibility isn't us.

"If we train our model on that data, doesn't that take us outside the processor role?"

Going beyond instructions changes the seat itself, not just the task.

"A user asked us directly to delete their data. Do we pass that to the customer?"

The desk that received the request and the authority to decide sit in different companies.

Pagedeck had to sort out its two seats when it started signing companies. Sofia came back with a customer security questionnaire whose first item asked which role Pagedeck played, and the answer wasn't one thing. For documents uploaded by a customer's employees it was a processor; for people who signed up directly on the free plan it was a controller.

Grace and Mia wrote the data out in two columns. Theo then attached different rules to each. Data belonging to customers was pulled out of the path feeding Pagedeck's internal analytics, and a job was scheduled to erase it within 30 days of a contract ending. A seat recorded only in a document leaves the code treating both kinds of data the same way, and the gap shows up the first time a customer asks for an export of everything held on their behalf.

People assume that outsourcing moves the responsibility too. You signed a contract and paid for the service, so whatever happens next feels like the vendor's problem. But responsibility toward users stays with whoever set the purpose. What you can hold a processor to is the contract; the party users report and regulators investigate is the client.

That leaves the client with two duties that can't be delegated: choosing well and watching. Picking a vendor without checking its security posture, or never once verifying that the contract terms are being followed, becomes your own negligence. Left uncorrected, this belief turns vendor selection into a price comparison, and "we outsourced it" is not accepted as an answer afterward. Fines and user notifications go out under the client's name.