Right to Access

For most of the history of recordkeeping there was nowhere to ask what a company knew about you. People understood that files were accumulating somewhere. Which fields those files contained, and where copies had gone, was visible only from inside the organization holding them.

That produced decisions nobody on the receiving end could examine. A loan gets declined or a service application is refused, and the reason given is an internal standard. If the information feeding that standard was wrong to begin with, there was no route to find out. A late payment settled years ago still sitting in one agency's file is the classic shape of it.

The problem was never only the inaccurate record. It was the absence of any way to discover the inaccuracy. A right to have data corrected is worthless to someone who cannot see what has been written down.

The right to access turns that route into a procedure. When a data subject asks, the company has to lay out what it holds and how it is being used, within a fixed deadline. It functions as the doorway to the rights that follow: correcting or deleting something requires knowing it is there, and this is where that knowledge comes from.

The person files a request through the company's designated channel; the company verifies identity, then compiles what it holds and how it is used and returns it inside the statutory deadline.

1. Intake. The channel is whatever the privacy policy names — usually a dedicated web form or a specific mailbox. When an agent files on someone's behalf, proof of authorization comes with the request.
2. Identity verification. This step stops someone from collecting another person's data, but demanding excessive documentation is itself treated as obstructing the right. A request submitted from an already authenticated account does not need a scan of a government ID on top of it.
3. Scope. What gets returned is more than a list of stored fields. It includes the purposes the data is used for, who it has been disclosed to, which vendors process it, and how long it is kept. Screenshotting the profile page does not cover that scope. A complete answer for one user of a collaboration product runs closer to a short report: the account fields, the three vendors that received a copy, the purpose attached to each, and the date each item is due for deletion.
4. Response inside the deadline. The clock is short, and it varies: ten days from receipt in some jurisdictions, one month under the General Data Protection Regulation (GDPR). Where an extension is genuinely needed, the reason has to be communicated rather than assumed.
5. Redaction. Parts containing another person's personal data, and items the law restricts from disclosure, are removed before the response goes out, with an explanation of what was withheld and why. Refusing a request outright and returning it partially redacted are different acts with different consequences.

The response is free as a rule. A fee covering actual costs is only defensible when the same person repeats the same request within a short span.

Requests arrive in four places.

1. An export feature in the product — an account setting that downloads your own data resolves most requests without a human touching them. Even two or three requests a month justify building it, because assembling one by hand costs hours of engineering time, and the same export satisfies every later request at no additional cost.
2. The support channel — anything outside the automated path lands on a person. Without a procedure that logs the receipt date and tracks the deadline, ten days passes easily.
3. Enterprise contracts — when a company processes data on a customer's behalf, access requests reaching that customer get forwarded down to it. How many days the vendor has and what format the answer takes become contract terms.
4. The data map — responding is impossible without knowing which tables and which external tools hold whose data. This is the point where responsibility as a data controller turns into concrete work.

"An access request came in. We owe a response in ten days, so this has to get compiled this week."

Deadline work, which means it moves ahead of whatever else was queued.

"Include the disclosure history too. Sending the stored fields alone answers half the question."

The scope of access is wider than the list of what is kept.

"This support thread has the other party's name in it, so that part gets redacted before it goes out."

Avoiding the disclosure of a third person's data while honoring the request.

Pagedeck's first access request arrived after it started signing enterprise customers. An employee at one of those customers asked to see their own data, Sofia took the request and passed it to Grace, and the contract gave the team five days to compile and return it.

What Theo assembled came from six places rather than one row: account details, document view history, support threads, records at the payment processor, events sent to the analytics tool, and delivery records in the email service. One support thread carried another employee's name, so that section was redacted. The first request took two days, and a download button appeared in account settings shortly afterward.

The most common assumption is that letting people see their own data in the product already satisfies the right. A profile page shows a name and an email address, so it looks like access. But the question this right asks covers more than what is stored: it reaches what the data is used for and who received it. A profile page does not show events forwarded to an analytics tool, records handed to a payment processor, or the retention period. Teams that skip building a real procedure because a screen exists end up spending the full ten days and still answering half of it. A partial answer also tends to generate a second, sharper request, which is how one routine inquiry turns into a complaint filed with a regulator.

The other misreading is that a request for data is best met by sending everything held, which feels like the cooperative response. The complication is that one person's records routinely contain other people. A support thread names the person on the other side; a shared-document history carries the accounts of collaborators. Forward the whole thing unchecked and the act of honoring an access request becomes a data breach against someone who never asked for anything. The fix is cheap if it is planned: a review step before the response goes out, done by a person rather than by the export script.