Data Subject

For a long stretch, whatever a company collected was treated as the company's own. You typed your name and phone number into a signup form, that became a row in a database, and what happened to the row afterward was considered the company's business. The idea that the person who supplied the data could ask for anything later never quite took hold.

What that looked like in practice was promotional email still arriving six months after someone closed their account. Write to support asking to be deleted and the answer came back as "our system doesn't allow that." It wasn't a lie. Deleting one row from the members table left the same person scattered across payment records, support tickets, and events already shipped to an analytics tool, and almost no company had decided how far deletion was supposed to reach. There was no channel to receive the request and no procedure to work through once it arrived.

Data subject is the name given to the side that was missing from that relationship. Once the side had a name, the things it could ask for became a list, and the company picked up a deadline for answering. The question shifted from what a company may do with its database to what it owes the people inside it.

Nobody applies to become a data subject. The status appears automatically the moment information is handled in a form that can identify a particular person. It covers more than signed-up users: a non-member who once wrote in with a question, a job applicant who sent a résumé, and an employee who left two years ago are each a data subject with respect to their own records.

The position facing them is the data controller — the side that decides what gets collected, why, and where it is used, and the side that owes an answer when a request arrives. The servers may actually be run by a data processor, but a processor only acts within instructions, so the counterparty for any request is always whoever set the purpose.

Four kinds of demand attach to the position.

1. Access — confirm what is held and how it is being used. The company has to come back with the items on file, the purposes behind them, and who else has received a copy.
2. Correction — have a wrong value fixed. This covers small things, like a delivery address entered incorrectly, as much as it does anything else.
3. Erasure — have the data deleted. Records that law requires keeping for a set number of years, like payment history, stay behind, so the split between what goes and what remains has to be decided in advance rather than on the day a request lands.
4. Objection and withdrawal of consent — stop further use. Turning off marketing email is the most common version.

A right that exists on paper is not a right that works. The request has to have a visible place to go inside the product, reach a named person once it arrives, and travel through a path that finishes inside the legal deadline.

The term appears in three places: documents, screens, and procedures.

In documents, it appears in the privacy policy. After listing what is collected, for what purpose, and for how long, the policy spells out what a data subject may ask for and where to write. It also appears in processing agreements, in the clause that fixes where responsibility toward the data subject stays when something goes wrong.

On screens, it appears in signup and consent flows. The reason required and optional items get separated, each with its own checkbox, is that the choice belongs to the person. The data minimization principle pushes on the same screen from the other direction by cutting what gets asked for in the first place.

In procedures, it appears in request handling and breach notification. How many days a deletion or access request takes, and whether the job that actually erases records past their retention period really runs on a schedule, both land here. So does the duty to notify affected people directly after a leak, which sits alongside — not inside — the duty to notify the regulator. Meeting those clocks depends on routing that was put in place before the first request arrived, not improvised on the day it did.

"As this screen works now, support tickets survive account deletion. If a data subject request comes in, do those go too?"

The scope of deletion hasn't been decided yet.

"We can't collect this field without consent from the data subject. Let's make it optional."

The item isn't necessary to deliver the service, so requiring it creates a problem.

"It's a cross-border transfer, so we have to tell data subjects which country it goes to."

A decision to use an overseas service brings a disclosure step with it.

At Pagedeck the phrase came up when the team decided to add an overseas analytics tool. Theo said the integration would take two days, but what Grace asked about wasn't the integration time — it was what would leave the building. If the setup ships raw email addresses, that is personally identifiable information (PII) crossing a border, and updating the policy and disclosing the transfer comes first. The team ended up hashing the email into a value that can't be reversed, which meant redesigning the integration itself.

The most frequent mistake is reading data subject as a synonym for customer. Nearly every conversation about personal data starts from service users, so the substitution feels natural. In fact it covers everyone whose personal data the company handles: an employee's payroll account, an applicant's résumé, the phone number of a prospect who never signed up. Cover only the customer side and you end up with three years of job applications sitting in a shared drive that nobody has a basis to keep.

The other common mistake is assuming the relationship ends at account deletion. The account disappears from the screen, so it looks finished. But as long as payment records are retained under a legal requirement, the person is still a data subject with respect to those records and is still owed an answer to an access request. Miss this and you build a deletion flow with no channel for anyone to reach you after they've used it, which turns a routine question into a complaint to the regulator.