To respond to a data subject access request, log the request, verify identity, and clarify what the requester wants. Search for and collect their data, then redact anyone else's data before sending it. Deliver the response securely within one month under the GDPR, or 45 days under the CCPA.
This guide walks through each step in order, covers both timelines, and explains where a website's consent records fit into the response.
How Do You Respond to a DSAR? (Quick Answer)
Responding to a DSAR follows the same eight-step sequence regardless of company size.
- Log the request and diarize the deadline
- Verify the requester's identity
- Clarify and scope the request
- Search for and collect the personal data
- Review and redact other people's data
- Prepare and deliver the response securely
- Handle extensions, exemptions, and fees
- Know when you can refuse a request
The GDPR gives you one calendar month; the CCPA gives you 45 calendar days. Both can be extended once, with notice. If you are not sure what a DSAR is or who can make one, start there before working through the steps below.
What You Need Before You Start
The prerequisite most teams skip: a single named owner and a place to log requests, decided before the first one lands. Without both, the deadline starts ticking before anyone notices the request exists.
Before a request arrives, put these four things in place.
- A named data protection lead. The Information Commissioner's Office puts it directly: a one-person band still owns this responsibility. One person has to be in charge of the response, even at a two-person company.
- A way to log requests and deadlines. A shared inbox or a ticket in whatever tool you already use works. The point is a single place every request lands, so nothing sits unread in a personal inbox.
- Knowledge of where personal data lives. Email, CRM, HR files, backups, CCTV footage, call recordings. You cannot search what you have not mapped.
- A redaction method. A dedicated redaction tool, or the copy-paste-into-a-new-document method the ICO recommends, works. Blacking out text in an editable file does not: the hidden text is often still recoverable.
A solo handler on Reddit's r/gdpr described sorting through "over 30,000 documents (twice)" for a single broad request. That is an extreme case, but it shows why the logging and search-scope steps below exist: without them, a broad request can consume weeks.
How Long Do You Have to Respond?
Under the GDPR and UK GDPR, you must respond without undue delay and at the latest within one calendar month of receiving the request. Under the CCPA, you have 45 calendar days. Both deadlines can be extended once (see Step 7).
Step 1: Log the Request and Diarize the Deadline
A DSAR can arrive by any channel, and it never has to use the word DSAR. Log the date, the channel, and the calculated deadline as soon as you recognize a request.
A subject access request is valid whether it comes by email, letter, social media message, or spoken conversation. It does not need to reference GDPR, CCPA, or use any particular form.
Record these three things immediately.
- Who made the request and how they contacted you
- The date you received it
- The calculated deadline
The ICO's own worked examples show how the one-month clock runs. A request received on Saturday 7 March is due by Tuesday 7 April. A request received on 25 November is due by 27 December. The natural date, 25 December, falls on a holiday, so the deadline rolls to the next working day. A request received on 31 January is due by 28 February, since February has no 31st day to match against.
Set an internal reminder at 28 days, not one calendar month. A 28-day marker never drifts with the length of the month, so you are never caught out by a short one. The clock can pause while you wait for identity verification, but ask for that information as soon as possible rather than waiting.
Step 2: Verify the Requester's Identity
Verify identity only when you have genuine doubt, and use the least intrusive method that resolves it. Formal photo ID is the last resort, not the default.
The ICO's own guidance is direct on this point:
You shouldn't ask for formal ID unless it's necessary and proportionate.
Start with what you already have. If the requester is a known customer or employee, questions only they would know are usually enough. A reference number or an appointment date works well. An existing username and password can serve the same purpose.
Escalate the check to match the actual risk.
- No real doubt: an ongoing relationship, a recognizable email address, or a match against records. Skip formal ID.
- Some doubt: a customer contacts you but a detail, such as a postal address, does not match your records. Ask for one more piece of information before proceeding.
- High-risk disclosure: health records, financial data, or any information where sending it to the wrong person would cause real harm. Formal photo ID is reasonable here.
A solicitor or relative may make the request on another person's behalf. Check for written authority or a power of attorney first. Children over 12 can usually make their own requests directly.
The clock does not start until you have the identity information you reasonably need, but the delay is on you to move quickly. Requesting ID late, or asking for more than the situation justifies, is not a legitimate way to buy time.
Step 3: Clarify and Scope the Request
Ask what the requester actually wants before assuming "everything you have" means every system you own. Most people are happy to narrow the request once you explain why.
A request for "all my data" often covers less ground than it sounds like. One experienced handler on Reddit's r/gdpr put it plainly.
99 times out of 100 the requester is quite happy to narrow the parameters.
That happens once you explain your goal. You want them to get exactly what they are entitled to, not to stall them.
Framing the clarification conversation as helpful, not defensive, changes how people respond. Explain what you hold, ask which parts matter to them, and most requests resolve into a focused, searchable scope within one exchange.
Three honesty guardrails apply here:
- Requests are reason-blind. A person does not have to explain why they want their data, and you cannot demand a reason before responding.
- You cannot force anyone to narrow their request. You can ask; if they decline or repeat the same broad wording, you still have to search reasonably and provide what you find.
- Only their own personal data is in scope. One Reddit commenter summed it up well: a DSAR is not a magic bullet that conjures up material that doesn't exist. It covers the requester's own data, not a company's internal records in general.
Access is one of the wider data subject rights the GDPR grants. A request to delete data instead is a deletion (right to be forgotten) request, a different right with its own process.
Asking for clarification pauses the clock the day you ask and resumes it the day you get an answer, so ask promptly. One nuance matters here: the clock only pauses for clarifying what information is requested, not for asking about the reply's format.
Under the UK GDPR, following the 2025 Data (Use and Access) Act, you only need to run a reasonable and proportionate search. You do not need to review every document you own. Document what you searched and why. That record protects you if a regulator later asks you to justify the scope you chose.
Step 4: Search for and Collect the Personal Data
Search everywhere the person's data could realistically live, not just the first system you check. Keep going until you are satisfied there is nowhere else to look.
The ICO's guidance names the full range: email and archived messages, CRM and HR systems, drives and backups. It also includes call recordings, social media posts, and CCTV footage. A broad request can mean checking several systems that were never designed to talk to each other.
Keep the search reasonable and proportionate to the request and to your organization's size and resources. A small team is not held to the same search depth as an enterprise with dedicated tooling. What matters is that you can explain, later, what you searched and why you believe it was complete.
If the request touches cookie or tracking consent specifically, your consent records are one useful, narrow data source. A timestamped, exportable consent log shows exactly what a visitor agreed to and when. That is one piece of evidence among the many systems above, not the whole response.
Step 5: Review and Redact Other People's Data
Check every piece of data before sending it. Confirm it actually belongs to the requester, and remove or protect anyone else's personal data unless sharing it is fair.
The ICO's own worked example makes the balancing test concrete. Samira requests her personnel file, which contains a complaint her colleague Tom made about her. Three outcomes are possible, depending on what Samira already knows. If she already knows the complaint came from Tom, you can share it as is. If she has no idea and would not guess, you can share the substance while redacting his name. If she would likely guess who complained regardless of redaction, you may need his consent, or you may need to withhold the detail entirely.
Redact by copying the relevant sections into a new document, not by blacking out text in the original file. Blacked-out text in an editable document is often still recoverable underneath the cover.
Information where the requester is only mentioned or implied, rather than the actual subject, is frequently out of scope entirely. Focus the response on data that is genuinely about the requester.
Step 6: Prepare and Deliver the Response Securely
Reply in the format the request arrived in unless the requester says otherwise, and include the required privacy information alongside their personal data.
If the DSAR came by email, respond by email. Provide the data in a commonly used electronic format, and write in plain language. Explain any internal codes or abbreviations rather than sending raw system exports.
Every response should include:
- The requester's personal data itself
- Why you hold it and the purposes of processing
- Where it came from
- How long you intend to keep it
- Who else you share it with
- How they can ask for corrections or deletion
Send the response through a secure channel, and keep a dated record of exactly what you sent. That record protects you if the requester later disputes what they received or makes a follow-up request.
Step 7: Handle Extensions, Exemptions, and Fees
You can extend the deadline once, but only with prompt notice, and you can only charge a fee in narrow circumstances.
Extensions. Under the GDPR and UK GDPR, a complex or numerous request earns an extra two calendar months. That is calculated as three months total from the original request date, not from whenever you decide to extend. You must tell the requester about the extension, and your reason for it, within the first month. Under the CCPA, the extension is 45 additional days, 90 total, again with notice required.
Exemptions. You may withhold information that is not the requester's own data or that is protected by legal privilege. You may also withhold information that would unfairly identify a third party (see Step 5's balancing test).
Fees. Responding is free by default. A reasonable fee applies only when a request is manifestly unfounded or excessive, or when someone asks for extra copies of the same response. The fee can cover genuine administrative costs, such as staff time and printing. Request it promptly, within the first month, rather than using it to buy extra time.
Step 8: Know When You Can Refuse a Request
You can only refuse a request that is manifestly unfounded or manifestly excessive, and that bar is high. Doing more work than usual is not, by itself, a valid reason.
One Reddit commenter framed the reality bluntly:
Just because it's a lot of work for you doesn't automatically make the request excessive. There is a high bar.
Under the GDPR, the burden of proving a request is excessive sits with your organization, not the requester.
If you do refuse, in whole or in part, tell the requester why. Also inform them of their right to complain to your data protection regulator and their right to seek a court remedy.
The realistic enforcement picture is not as alarming as it sounds, but it is not risk-free either. Missing a deadline typically leads to a regulator complaint. The usual outcome is an instruction to comply, not an immediate fine. Systemic or repeated failures can still draw formal enforcement action. Treat the deadline as real even though one missed date rarely ends in a penalty.
How US Requests Differ: Responding Under the CCPA
The core workflow above holds for CCPA requests too, but the numbers and coverage differ from the GDPR. This section covers request handling only; for the full CCPA compliance guide beyond responding to individual requests, see the walkthrough.
| Requirement | GDPR / UK GDPR | CCPA |
|---|---|---|
| Response deadline | One calendar month | 45 calendar days |
| Extension | +2 months (3 total), with notice | +45 days (90 total), with notice |
| Confirm receipt | Not a separate step | Within 10 business days |
| Fee | Free by default | Free of charge |
| Who can request | Any data subject | California consumers |
| Identity verification | Proportionate to risk | Required; info used only for verification |
Under the CCPA, businesses must respond to access, deletion, and correction requests within 45 calendar days. That deadline extends by another 45 days with notice to the consumer. California's regulations also require confirming receipt of the request within 10 business days. That confirmation step sits ahead of the substantive 45-day deadline and has no direct GDPR equivalent.
The CCPA bundles access together with deletion and opt-out-of-sale-or-sharing rights, which the GDPR treats as separate rights. If a request touches the opt-out side rather than access, the do-not-sell opt-out runs on its own, faster timeline. Do not assume any tool automatically detects a visitor's Global Privacy Control signal on your behalf. That detection is a separate technical capability from responding to the request itself.
Common DSAR Response Mistakes to Avoid
The single most damaging mistake is treating a heavy workload as grounds to refuse. The actual bar for refusal is high, and volume alone rarely meets it.
- Treating "a lot of work" as grounds to refuse. This risks an unlawful refusal and a regulator complaint. Remember the high bar, and default to a reasonable, proportionate search plus clarification instead of refusal.
- Missing the deadline, or extending without notifying within the first month. An extension you did not announce in time is not a valid extension. Diarize a 28-day internal reminder and send any extension notice inside month one.
- Deleting or altering the records once a request arrives. Tidying up or removing data after a DSAR lands is not just bad practice. Under the UK Data Protection Act 2018, deliberately altering, erasing, or concealing records to prevent disclosure is a criminal offence. Freeze the relevant data as soon as you recognize a request, and let only routine, already-scheduled deletions continue.
- Sending data without redacting other people. This creates a separate personal-data breach affecting the third party. Run Step 5's redaction and balancing test on every response, not just the obviously sensitive ones.
- Assuming a DSAR must use a form or the exact word DSAR. A request in any channel or wording still starts the clock. Recognize a valid request the moment it arrives, per Step 1.
- Not documenting your search and decisions. Without a dated record, you cannot defend your response if a regulator asks you to justify it later. Keep notes on what you searched, what you found, what you redacted, and why.
- Asking for clarification too late to leave enough search time. Clarifying scope pauses the clock, but only while you wait for the answer. Ask late, run out of search time afterward, and the missed deadline is self-inflicted.
How Consently Helps You Keep the Consent Records a Response Needs
Consently is a cookie consent management platform, not a DSAR intake or fulfillment tool. It does not verify identity, search your systems, redact data, or send responses on your behalf.
What it does give you is narrower and specific: a timestamped, exportable consent log that records exactly what each visitor agreed to and when. If a request touches the cookie-consent slice of someone's data, that export is one data source you can pull directly. It saves digging through raw analytics or ad-platform logs. Consently's Privacy Policy Generator also documents your data practices and how visitors can exercise their rights, supporting the privacy information you owe under Step 6.
Neither feature handles the identity verification, search, redaction, or delivery steps above. Those remain a task you run through your own process. Policy generators are compliance assistance, not a substitute for legal advice. The consent log is evidence for one slice of a response, not a DSAR management system. Responding to requests is one piece of making your whole website GDPR compliant, which covers the broader set of obligations beyond request handling.
FAQs
How long do you have to respond to a DSAR?
One calendar month under the GDPR and UK GDPR, counted from receipt. Under the CCPA, you have 45 calendar days. Both timelines can be extended once with prompt notice to the requester.
Can you ask for ID before responding to a DSAR?
Yes, but only when proportionate to genuine doubt about the requester's identity. The clock pauses until you receive the information you reasonably need, so ask promptly rather than as a delay tactic.
Do you have to respond to a DSAR sent by email?
Yes. A request is valid in any format, including email, a letter, a social media message, or a spoken conversation. It does not need to reference GDPR, CCPA, or use the exact word DSAR.
Can you refuse or ignore a DSAR?
You can refuse only if the request is manifestly unfounded or manifestly excessive, a high bar that a heavy workload alone does not meet. Ignoring a valid request risks a regulator complaint and possible enforcement action.
Can you charge a fee to respond to a DSAR?
No, not by default. A reasonable fee applies only to manifestly unfounded or excessive requests, or to additional copies of a response you already provided.
What happens if you miss the DSAR deadline?
The requester can complain to your data protection regulator, who will usually order you to comply rather than issue an immediate fine. Repeated or systemic failures can still draw formal enforcement action.
Can you ask the requester to narrow their DSAR?
Yes. You can ask them to clarify or focus a broad request. They are not required to give a reason, and you cannot force them to narrow it if they decline.
How is a CCPA request different from a GDPR DSAR?
The CCPA gives you 45 days instead of one month and requires confirming receipt within 10 business days. It also applies specifically to California consumers and bundles access together with deletion and opt-out-of-sale rights.
Do you have to redact other people's data from a DSAR response?
Yes. Remove or protect other people's personal data unless disclosing it is fair to them, using the balancing test in Step 5.
Who must respond to a DSAR?
The data controller, the organization that decides why and how the personal data is processed, must respond. In a small business that is usually the owner or a named data protection lead. A processor acting on the controller's behalf passes the request on rather than answering it directly.
Responding to access requests is a task you run through your own process, but the cookie-consent slice is easier when your records are already organized. Consently keeps a timestamped, exportable consent log of every visitor's choice. If a request touches cookie or tracking consent, the audit trail is one export away. See how Consently handles GDPR cookie consent, and see your consent log in Consently on your own site with a free 14-day trial.
