A customer emails your support inbox asking for every piece of personal data your company holds about them. Another asks to delete their account, but your finance team needs certain records for tax and fraud-prevention purposes. These are not routine tickets. This data subject request guide explains how US companies can handle GDPR requests without missing deadlines, exposing other people’s data, or making promises their systems cannot support.
For businesses outside the EU, a poorly handled request can quickly become visible to a supervisory authority, a major customer’s procurement team, or your company’s legal department. The real risk is not merely receiving a request. It is having no defensible process when one arrives.
What counts as a data subject request?
A data subject request is an individual’s exercise of rights over their personal data under the GDPR. It does not need to cite the GDPR, use a formal form, or arrive through a dedicated privacy email address. A message to customer support, a social media team, or an account manager can still trigger an obligation if the person is asking to access, correct, delete, restrict, object to, or transfer their data.
The most common requests concern access, erasure, and correction. But your process also needs to recognize objections to marketing or other processing, requests to restrict processing while a dispute is evaluated, and requests for data portability where applicable.
The word "request" matters less than the substance. “Stop emailing me and remove my information” may involve both an objection to direct marketing and an erasure request. Treating it as a simple unsubscribe ticket can leave the deletion portion unanswered.
Not every request requires the same result. A person has rights, but those rights are not absolute. Whether you must erase data, for example, depends on why you process it, whether a legal obligation requires retention, whether a claim must be defended, and whether an exemption applies. The correct answer is often more nuanced than yes or no. It must still be timely, clear, and documented.
Data subject request guide: the first 24 hours
Speed at intake protects the deadline. Under the GDPR, organizations generally must respond without undue delay and within one month of receiving a request. In complex cases, that period can generally be extended by up to two further months, but the requester must be told about the extension and the reasons for it within the initial one-month period.
Do not calculate this as a casual 30-day internal target. Record the date received, the channel, the person handling intake, the request type, and the deadline. If you receive a request on a weekend or holiday, your team still needs a reliable method for capturing it and escalating it promptly.
Route the request to a single owner
Support should not decide whether a request is valid, search company systems independently, or promise deletion on the spot. Give one privacy owner, legal lead, or designated response team authority to coordinate the case. That owner should bring in security, engineering, marketing, finance, and relevant vendors as needed.
A shared inbox can work for a small company, but only if it has monitoring, escalation rules, and a clear backup. An unattended privacy address is evidence of a process failure, not a compliance program.
Confirm identity proportionately
Before disclosing data, assess whether you have reasonable doubts about the requester’s identity. Account-based requests may be verified through the authenticated account, an email confirmation, or another proportionate method. The goal is to avoid releasing personal data to an impersonator.
Do not turn identity verification into a barrier. Asking every person for a passport copy, particularly when you can verify them through existing account controls, can create unnecessary security and privacy risk. Request additional information only when it is necessary, explain why, and keep the verification evidence limited.
Preserve the original request and clarify only when needed
Save the original message and maintain a case record. If the request is genuinely broad or unclear, ask the person to specify relevant accounts, time periods, products, or data categories. Clarification can make the search more accurate, but it is not a license to delay or discourage the request.
Keep moving on information you can identify. A requester should not lose meaningful access simply because your company’s data environment is messy.
Build the response around the right, not the department
The person’s right should determine the workstream. Internal teams naturally think in terms of their own systems: CRM, billing platform, product database, analytics, support desk, and cloud storage. The requester is entitled to an outcome that addresses the relevant processing across those systems.
For an access request, identify personal data and the required contextual information, including purposes of processing, categories of data, recipients or recipient categories, retention periods or criteria, data sources where applicable, and relevant rights. A raw database export alone is rarely enough. Neither is a policy document that says nothing about the person’s actual data.
For erasure, create a defensible decision record. Identify data that can be deleted, data that must be retained, and data that should be suppressed from active use. If information remains because of a legal obligation or a legitimate need to establish, exercise, or defend legal claims, explain that limitation plainly. Deleting production data while leaving the same record available in an active marketing tool is not a complete response.
For correction, ensure the update reaches systems that continue to rely on the inaccurate data. For marketing objections, suppress the person from future direct marketing promptly. A person may still receive transactional messages that are necessary to perform a contract, but those messages should not become a pretext for continued promotional outreach.
Where a processor handles data for your company, the controller usually remains responsible for responding to the individual. Your vendor contracts and operational procedures should require processors to assist quickly enough for you to meet your deadline. If a vendor’s support queue takes weeks to return an export, that is your compliance exposure as well.
Search intelligently and protect other people’s data
A complete search does not always mean searching every backup tape, log, or archived record with no practical ability to retrieve it. The scope depends on the request, the systems used, the data available, and the effort required. But “our data is distributed” is not a valid response strategy.
Maintain a current data map that identifies the systems holding customer, prospect, user, employee, and device data. Include key service providers, data owners, retention settings, and the method for retrieving or deleting records. This is operational infrastructure, not paperwork for a privacy folder.
Review results before disclosure. Access responses may contain information about employees, other users, confidential business information, security controls, or another person’s personal data. Redaction or partial disclosure may be appropriate, but it must be narrowly justified. Do not use confidentiality as a blanket reason to withhold the response.
When an EU representative changes the process
Non-EU companies that offer goods or services to people in the EU or monitor their behavior may need an EU representative under GDPR Article 27, subject to limited exceptions. The representative is a contact point for supervisory authorities and data subjects, but appointing one does not transfer the company’s accountability or eliminate the need for an internal request process.
The practical value is coordination when a request reaches Europe first or escalates beyond a routine case. Your representative should be able to receive communications, route them to accountable decision-makers, preserve the record, and help ensure that a regulator receives a substantive response rather than silence.
That is where lawyer-led representation differs from a mailbox service. A forwarding address may pass along an email. It does not assess the urgency, coordinate a legally coherent response, or help your team avoid statements that create further exposure. rep4eu provides Article 27 representation designed for that active role.
Mistakes that turn a request into a regulatory problem
The most damaging failures are usually predictable. Teams lose requests in support queues, start the clock only after a privacy team sees them, or assume a request is invalid because it was informal. Others disclose data before verifying identity, delete evidence needed for a dispute, or ignore downstream vendors and marketing platforms.
Another common error is sending a vague refusal. If you cannot fulfill all or part of a request, explain what you did, what you could not do, the legal basis or reason for the limitation, and the individual’s right to complain to a supervisory authority and seek a judicial remedy. The tone should be respectful and direct, not defensive.
Keep a request register showing intake dates, identity checks, systems searched, decisions made, exemptions considered, response dates, and any vendor involvement. This record helps you improve operations, but it also gives your company evidence if a regulator asks how the request was handled.
A data subject request is a live test of whether your privacy program works beyond the policy page. Assign ownership before the next email arrives, map the systems your team will need to search, and make sure the people receiving customer messages know exactly where to send them.