What a subject access request is.
A subject access request is a formal question, in writing, asking an organisation to disclose the personal data it holds about you, why it holds it, and who else it has been shared with. It is broader than a single right to correct one field or delete one record, it is closer to asking for the full file kept under your name.
Anyone can send one, regardless of whether anything appears to be wrong. Curiosity about what a long-running account actually contains is a perfectly ordinary reason to send one, not only a step reserved for a dispute or a suspected problem.
It is one of the oldest and most direct tools available under data protection law, and it does not require any particular format or legal wording, only that it is clear about what is being requested and that it comes from the person the data actually belongs to.
It predates a good deal of modern data protection law in spirit, and it remains one of the simplest ways to check whether an organisation's own description of its data handling actually matches what it is doing in practice, rather than taking a privacy notice at its word alone.
What a complete reply should include.
A proper response covers more than a raw data dump. It should explain the purpose the data is used for, the categories involved, how long it is expected to be kept, and who it has been shared with, in addition to the data itself sitting behind those explanations. A response missing several of these is worth a polite follow up rather than being accepted as final.
How to word one that gets a useful answer.
State plainly that the message is a subject access request, and be as specific as reasonably possible about the account, booking or period involved. A request that is too broad, asking for everything ever held since the very beginning, can still be answered, but a narrower one, naming an account or a rough date range, is easier for a business to process quickly and accurately.
It is also fine to ask a follow up question once the first reply arrives, rather than treating the initial response as the final word. A genuine request is not a single exchange with a strict limit on how many times it can be clarified.
The deadline that applies.
Under the standard timeline, a business has about a month from receiving the request to respond. Where the request is genuinely complex or involves an unusually large volume of data, that period can stretch by a further two months, but the business is expected to flag the delay within that first month rather than simply going quiet and explaining nothing until much later.
A response that comes back with no explanation at all, well past that window, is a reasonable point to escalate the matter further.
What it does not cover.
A subject access request explains what is held and why, but it is not the same tool as asking for that data in a portable, reusable file, which falls under a separate right to data portability, or asking for it to be deleted outright, which falls under the right to erasure. Each right answers a slightly different question, and naming the correct one in the request itself avoids a reply that answers something you did not actually ask for.
It also does not require a business to create new analysis or a new document that did not already exist in some form. It has to disclose what it holds, not produce a fresh report summarising it in a format never previously generated.
A short, realistic example.
A booking arranged with Stacy or time spent with someone filed under slim generates very little in the first place, so a subject access request sent to a discreet agency in Rotterdam is likely to come back with a short, plain answer: a name to greet you by, a working contact detail, and the dates involved, nothing more elaborate hiding underneath.
That brevity is deliberate rather than evasive. An agency that only ever collects what a duo booking or similar arrangement genuinely requires has, by design, very little left to disclose once asked.
If the answer seems incomplete.
A reply that clearly leaves out a category you know exists, such as a payment record or a previous message thread, is worth following up on directly before escalating further. If the follow up goes nowhere, the Dutch Data Protection Authority guide sets out what a complaint should include and how it tends to be handled from there.
It is also worth reading alongside our broader guide to GDPR rights, since a subject access request is often the first step that reveals whether a separate right, such as erasure, is actually needed next.
Before sending one.
A quick look at the rates page or any other part of a site rarely generates enough to be worth a formal request on its own, but the option exists precisely so that anyone can check, at any point, exactly what a record actually contains rather than guessing at it from the outside.