DSAR Template: DSAR Response Template and Intake Form

A DSAR template is a reusable starting point for the letters you send when responding to a data subject access request: an acknowledgment note, a cover letter, and the response itself. A good template covers who is writing, what data is enclosed, why it is processed, who it is shared with, how long it is kept, and how the requester can follow up, while leaving room to adapt the specifics to each request.

This is general information, not legal advice, and the wording below is illustrative. Adapt it to your organization, the law that applies, and the facts of each request before you send it.

The three letters in a DSAR response

Most requests need three short pieces of writing, and it helps to keep a template for each. Standardizing them through a set of response templates keeps your language accurate and consistent across the team.

1. The acknowledgment. Sent soon after intake to confirm you received the request and to request any verification details.
2. The cover letter. Accompanies the disclosure and explains what is enclosed and why.
3. The response detail. The substance: the categories of data, purposes, recipients, retention, and the data copy itself or a link to it.

Acknowledgment template

Keep it short and set expectations. A sample:

"Thank you for your request dated [date]. We are treating this as a data subject access request. To protect your data, we first need to confirm your identity; please [describe the proportionate step]. Once we have confirmed your identity, we will respond within the applicable statutory deadline. If we need to extend that period because your request is complex, we will let you know within the initial timeframe and explain why."

Sending this promptly matters, because the deadline is already running. See the DSAR response deadline for exactly when the clock starts and how extensions work.

Cover letter template

The cover letter frames the disclosure so the requester can make sense of it. A sample structure:

• Confirmation that this is your response to their access request and the date of that request.
• A plain summary of what is enclosed and the format it is in.
• A note that some information has been redacted where it relates to other people or is exempt, without revealing what.
• The purposes for which you process their data, the categories involved, the recipients, and your retention approach.
• How they can query the response, correct data, or complain to a supervisory authority.

What the response must cover

Whatever format you use, a complete response generally addresses each of these points. Keeping them in a table helps you check nothing is missing before sign-off.

Subject access request form template

The templates above are what you send back. This one is what you publish. A subject access request form is the intake form you put on your privacy page so requests arrive with the details you need, instead of as a one-line email that starts a one-month clock and tells you nothing.

Keep it short. Every field you add is a field someone abandons the form over, and you cannot require any of it: a request made by email, by phone, or on social media is still valid whether or not your form exists. A workable form asks for:

• Full name, and any other names your records might hold them under, such as a maiden name or a name on an old account.
• Contact details, plus how they would like to receive the response.
• Which right they are exercising, as plain options: a copy of my data, correct my data, delete my data, stop using my data. Do not make them know the word "rectification".
• What they are looking for and roughly when, marked optional. This is the field that saves you the most work, because "my support tickets from last year" is a far smaller search than "everything".
• Their relationship to you: customer, former customer, employee, job applicant. It tells you which systems to search before you start.
• Identity verification, handled proportionately to the sensitivity of the data, and asked for separately rather than as an upload field on a public form.

Two lines of wording to include on the form itself: tell people you will respond within one month under the GDPR or 45 days under the CCPA and the US state laws, and tell them the clock starts when the request arrives, not when they finish the form. That single sentence prevents most of the "why has nobody replied" follow-ups.

What not to do: do not require the form. Do not demand ID before you will accept the request at all. Do not ask for a reason, because a person does not have to give one. And do not bury the form three clicks into a footer, since a request that lands in a support inbox instead is still a request, and it still starts the clock.

Why a template is only the starting point

A template saves time and keeps your language consistent, but it cannot fill itself in. The hard work happens before the letter: finding the data and deciding what is in scope. You cannot list categories, purposes, and recipients accurately until you have discovered where the person's data actually lives, which is why automated personal data discovery feeds the template rather than the other way around.

Fill from a manifest, not from memory

The most reliable way to complete a response is to draft it from a manifest of what discovery found, rather than from what you think you hold. That way the letter reflects reality. This is a core part of the wider DSAR process, and it keeps your disclosure honest and complete.

Redact before you attach

Never populate the data copy from raw exports without redacting first. A response covers the requester's own data, so third-party names, other people's details, and any exempt or privileged material have to be removed. Our guide on how to redact a DSAR response walks through the categories, and a dedicated redaction step keeps it consistent and auditable.

Adapt the template to each request

A template is a scaffold, not a script. The facts that fill it change with every request, and using boilerplate without adapting it is how errors creep in. Watch for these points as you tailor each letter:

• The applicable law. A response under the GDPR reads differently from one under the CCPA, so keep the language matched to the right rules.
• The categories you actually hold. Only list the categories, purposes, and recipients that your discovery confirmed, not a generic set.
• What you redacted. Note that some material was withheld because it relates to others or is exempt, without describing the withheld content.
• The response format. Tell the requester whether the data is attached, provided as a structured export, or available through a secure link.

Standardized wording keeps you consistent; adapting the specifics keeps you accurate. The two are not in tension when the template is filled from a real manifest rather than from memory.

Always end with human sign-off

A template can be pre-filled automatically, but a person should read the final letter and the attached data before it goes out. Human review catches a stray third-party detail or an out-of-scope item that automation missed. That human review gate is what keeps you in control of the disclosure.

Want your templates filled from real discovery instead of a blank page? Obtainer drafts the cover letter and response from your templates using the manifest it compiles, then holds everything at a review gate. Response templates give you a deadline-safe starting point that you redact and approve before anything is sent.