A customer emails your support inbox asking, “What data do you hold about me?” That message may be a data subject access request, and the clock may already be running. Responding to access requests is not a customer-service task that can sit in a queue until someone has time. Under GDPR, a delayed, incomplete, or careless response can create regulatory exposure, trigger a complaint, and undermine a commercial relationship with an EU customer.
For US companies without an EU establishment, the risk is often compounded by distance. Requests may arrive through an EU Representative, a local sales contact, a privacy inbox, or an app-store support channel. If no one has clear ownership, the request can be lost between teams. The right response process needs legal control, operational speed, and enough technical discipline to locate data without disclosing someone else’s information.
What Counts as an Access Request?
GDPR Article 15 gives individuals the right to obtain confirmation of whether their personal data is being processed and, where it is, access to that data and specified information about the processing. This includes information such as why the data is used, the categories of data involved, recipients, retention periods, data sources, and relevant safeguards for international transfers.
The requester does not need to cite “Article 15,” use a form, or write in legal language. “Send me everything you have on me,” “I want a copy of my account data,” and “What did you share with advertisers?” can all trigger the same obligation. Train frontline teams to recognize the substance of the request rather than wait for a formal label.
An access request is not automatically a demand for every document in your possession. The right concerns the requester’s personal data, not unrestricted access to internal legal advice, confidential business strategy, or third-party information. But companies often overcorrect here. Calling a request “too broad” is not a valid reason to ignore it. A broad request may require clarification, but the organization still has a duty to act.
The One-Month Deadline Is Real
The default deadline is one month from receipt. For example, a request received on March 8 is generally due by April 8. If the corresponding date does not exist in the following month, the deadline falls on the last day of that month. This is not a vague 30-business-day target.
You may extend the response period by up to two additional months where a request is complex or numerous. The extension must be justified, and the individual must be told within the initial one-month period that more time is needed and why. An extension is not a standard operating buffer for a disorganized data inventory.
The response is generally free of charge. A reasonable fee may be possible for manifestly unfounded or excessive requests, particularly repetitive ones, but that threshold should be treated cautiously. A company that charges first and analyzes later risks turning a manageable request into a complaint.
Start the Clock Before the Investigation Begins
The first operational step is to log the request immediately. Record when and where it arrived, who received it, the requester’s identity, the systems likely to contain relevant data, and the internal owner responsible for coordinating the response.
This record matters for two reasons. First, it prevents deadline failures. Second, if a supervisory authority asks what happened, you need to show a controlled process rather than an improvised collection exercise. Regulators look at accountability as well as the final answer.
If a request reaches your EU Representative, there should be a defined escalation route to your privacy lead and relevant operational teams. An Article 27 representative should not function as a passive mailbox. The representative needs enough context to route the request correctly, flag deadline risk, and support communications when a regulator or data subject follows up.
Verify Identity Without Creating a New Privacy Problem
You must be reasonably confident that the person making the request is the person whose data is sought. That does not mean demanding a passport from every customer. Collecting excessive identity documents can itself create unnecessary risk.
Use the context of the account and the sensitivity of the requested data. For a logged-in user requesting a standard account export, existing authentication may be enough. For a request sent from an unfamiliar email address that seeks detailed behavioral, financial, or account-security information, proportionate additional verification may be justified.
Ask only for information necessary to confirm identity. Explain why you need it, store it securely, and avoid retaining identity documents longer than necessary. Most importantly, do not let verification become a silent delay tactic. If more information is needed, ask for it promptly and document the reason.
Build a Defensible Search, Not a Performative One
The quality of your response depends on whether you know where personal data lives. For many SaaS, app, and eCommerce businesses, relevant data may sit in production databases, CRM tools, support platforms, payment processors, marketing systems, analytics products, fraud tools, data warehouses, and employee inboxes.
You do not need to search every system ever used by the business without judgment. You do need a reasonable, documented search based on the individual, your processing activities, and the systems that are likely to hold their information. That requires a current data map and clear data ownership.
A practical search workflow should identify the individual’s known identifiers first, such as account ID, email address, device identifier, order number, or support ticket number. Teams can then search relevant systems using those identifiers and preserve the results for review. Where systems cannot readily export information, document the limitation and determine whether a manual extract is required.
Before sending anything, review the collected material for information about other people. Support threads, internal notes, shared accounts, fraud investigations, and communications with multiple participants often contain mixed data. GDPR recognizes the rights and freedoms of others, so redaction may be necessary. The trade-off is delicate: redact only what is needed to protect third parties, and do not use third-party rights as a blanket excuse to withhold the entire record.
What a Proper Response Should Include
A compliant response should be understandable to a normal person, not just technically complete. Sending an unfiltered database dump with cryptic field names may be insufficient if it does not allow the individual to understand what data is processed and how.
The response generally needs two components: a copy of the relevant personal data and the Article 15 information that provides context. The exact format depends on your service and the nature of the request, but the answer should address the purpose of processing, data categories, recipients or recipient categories, retention periods or criteria, rights to rectification, erasure, restriction, objection, and complaint, the source of data where it was not collected directly, and any automated decision-making that produces legal or similarly significant effects.
Use a secure delivery method appropriate to the sensitivity of the material. If the request was made electronically, provide the information in a commonly used electronic form unless the individual asks otherwise. Emailing a sensitive export to an unverified address is not efficient compliance. It is a potential security incident.
Keep an Evidence File
For every completed request, retain a concise case file. It should show receipt date, identity-verification steps, systems searched, teams involved, data disclosed, redactions made, extension notices if any, and the date and method of delivery. Four items are especially valuable when decisions are challenged:
- the original request and all communications with the individual;
- the search plan and evidence of systems reviewed;
- the legal basis for any limitation, redaction, fee, or refusal; and
- the final response package and delivery record.
This is not bureaucracy for its own sake. It gives your legal, privacy, and leadership teams a defensible record if the individual escalates to a supervisory authority.
When You Can Limit or Refuse a Request
There are situations where full disclosure is not appropriate. A request may be manifestly unfounded or excessive. Material may be protected by legal professional privilege under applicable law. Disclosure may adversely affect the rights and freedoms of others, or conflict with certain legal obligations. The details depend on the facts and the laws that apply to your processing.
The mistake is treating an exception as a shortcut. A refusal or limitation needs a specific rationale, careful documentation, and a response to the individual explaining the action taken. The person should also be informed of their right to complain to a supervisory authority and seek a judicial remedy. If the issue is high-risk, involve qualified privacy counsel before sending a refusal.
Make Your EU Representative Part of the Response Chain
For non-EU companies subject to Article 27, an EU Representative is a visible point of contact for data subjects and supervisory authorities. That role can reduce confusion during an access request, but only if the appointment is backed by real response capability.
A mailbox provider can forward an email. It cannot assess whether the request is valid, identify an approaching deadline, help frame a lawful limitation, or coordinate an authority inquiry after a complaint. rep4eu provides lawyer-led Article 27 representation designed for that harder operational reality: receiving requests in the EU, routing them quickly, and helping clients respond with a legally defensible process.
The strongest access-request program is not the one with the longest policy. It is the one that lets your team identify a request on day one, locate the right data without panic, protect sensitive information, and give the individual a clear answer before the deadline becomes a regulatory problem.