What happens when you ask a company what it holds on you
Why this is worth doing at all
Most people’s mental model of “my data” is whatever they can see: an email address, a shipping history, maybe a few saved payment methods. What companies actually hold is usually a lot wider than that, and the only reliable way to find out is to ask them directly. This isn’t a hack or a workaround. It’s a formal mechanism that exists specifically because regulators decided people should be able to see what’s been collected about them without having to guess.
The right framing here matters. A data access request doesn’t make you anonymous, doesn’t stop future collection, and doesn’t undo anything that’s already been shared with a third party. What it does is turn an abstract worry (“they probably have a ton on me”) into a concrete, readable list. That’s useful on its own. It’s also the first step if you ever want to follow up with a correction or a deletion request, because you can’t ask a company to fix or remove something you don’t know it has.
What a data access request actually is
In the EU and UK, this is formally called a subject access request, built on the right of access in data protection law. In the US, California’s privacy law gives residents a comparable right to know, and a handful of other states have followed with similar mechanisms. The mechanics differ slightly by jurisdiction, but the shape is the same: you ask a company, in writing, what personal data it holds about you, where it came from, what it’s used for, and who it’s shared with. The company has an obligation to respond within a set window, though the exact window and the exceptions to it vary by law and by the type of data involved.
You don’t need special standing to file one. You don’t need to explain why you want it. You don’t need a lawyer. You just need to be the person the data is about, and you need to be able to prove that.
Where to send it and how to word it
Every company that processes meaningful amounts of personal data is supposed to have a way to receive these requests, though the quality of that path varies enormously. Start in the footer of the company’s website, looking for links like “privacy,” “your privacy choices,” or “data protection.” Larger companies increasingly run a self-service portal that generates the export automatically. Smaller companies often just list an email address for a privacy contact or data protection officer.
If there’s no obvious link, the privacy policy itself almost always names a contact method near the bottom, since disclosing it is usually required. When you write in, keep it simple: state that you’re submitting a request under the applicable access right, ask for the categories of personal data held, the purposes of processing, the sources of the data if it wasn’t collected directly from you, and any third parties or categories of third parties it’s been shared with. You don’t need legal phrasing. A plain, direct email works fine and is arguably harder for a support queue to bounce back with a generic non-answer.
Keep a copy of what you sent and when. If a company misses its response window or gives you a form-letter non-response, that record is what you’d need if you ever escalate to a regulator, which is outside the scope of what this article covers.
Verification is the part people underestimate
Companies are required to confirm you are who you say you are before handing over a file full of your personal data, and this step trips a lot of people up. Depending on how much information the company already holds and how sensitive it is, verification can range from “reply from the email on file” to a request for a copy of a government ID. This isn’t the company being difficult for its own sake. Handing someone else’s data to an impersonator is a worse outcome than a slow response, and the law generally expects reasonable verification steps.
If a request asks for more identity information than seems proportionate to the account in question, that’s a fair thing to push back on or ask about, but don’t assume every ID request is a red flag. A bank or a healthcare portal verifying you before an access request is behaving normally.
What actually comes back
The response is usually one of two things: a structured export (a CSV, JSON, or PDF bundle) or, increasingly, access to a self-service download tool that generates the file on demand. What’s inside tends to fall into a few buckets:
Account and profile data. The obvious stuff: name, contact details, account settings, saved preferences, order or usage history.
Interaction and log data. Timestamps, IP addresses associated with logins, device or browser identifiers, and sometimes rough location data derived from those. This category is usually bigger than people expect, because most systems log far more than they surface in a user interface.
Inferred or derived data. This is the category worth paying the most attention to, because it’s the part you can’t see just by using the product. Ad platforms build interest categories. Retailers build purchase-propensity scores. Some services attach a risk or fraud score to your account. None of this is data you typed in, it’s data the company computed about you from your behavior, and an access request is often the only way to see that it exists at all.
Third-party sharing. A list, or at least a description, of who the data has been shared with, whether that’s analytics vendors, ad partners, or affiliated companies. This is frequently the vaguest part of the response, phrased in categories (“advertising partners”) rather than named companies, and that vagueness is common enough that it’s not necessarily a sign something’s wrong, just a sign the answer is worth reading carefully.
What it doesn’t do
It’s worth being blunt about the limits here, because overselling this process helps no one. An access request tells you what’s on file right now. It doesn’t retroactively unwind data that’s already been sold to a broker or baked into a model. It doesn’t stop the company from continuing to collect data on you going forward, that’s a separate opt-out or deletion mechanism, and deletion rights come with their own carve-outs for things like fraud prevention, tax records, and ongoing legal obligations. And filing a request with one company does nothing to the dozens of other companies, including ones you’ve never directly interacted with, that may hold data about you through licensing or brokerage. There’s no single request, and no single tool, that clears your footprint everywhere at once. Anyone claiming otherwise is selling something.
Data brokers are a separate problem
Companies you never signed up with, like data brokers and people-search sites, often hold the most surprising profiles because the data came from public records, other companies’ data sales, or scraped sources rather than from you directly. The same access rights generally apply to them, but you have to find and contact each one individually, since there’s no single directory that covers all of them reliably. This is slower and more tedious than requesting data from a service you actually use, and it’s a separate project from the one this article is describing.
A practical way to approach it
Pick a handful of services that matter most to your threat model: the ones with your financial data, your health data, or the ones you’ve used the longest and suspect have accumulated the most. File a request with each, using the company’s own privacy contact rather than a generic support address. Give it the time the law allows before following up. When the files come back, actually read the inferred-data and third-party-sharing sections first, since that’s where the real surprises usually live. Then decide, case by case, whether a follow-up correction or deletion request is worth filing.
None of this makes you invisible. It makes what’s currently invisible readable, which is a smaller but much more honest goal.
If you want more explainers like this one, grounded in how the mechanisms actually work rather than in fear or absolutist advice, head back to The Privacy Wire.